LINUX.ORG.RU
решено ФорумAdmin

Интернет через OpenVPN на VDS/VPS не подключается

 , , , ,


0

2

Доброе...

Посмотрел много на эту тему и у всех все немного разное...

Не нашел ответа, либо не увидел...

Есть CentOS 6.6x64, стоит OpenVPN 2.3.5. Хочу весь трафик клиентов пустить через впн, шлюз своеобразный сделать.

Проверил на локальных машинах, все работало с таким конфигом впн:

port 1194
proto tcp
dev tun

ca  /etc/openvpn/keys/ca.crt
cert  /etc/openvpn/keys/server.crt
key  /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh2048.pem

server 10.68.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.68.1.0 255.255.255.0"
client-config-dir ccd

;route 10.68.0.0 255.255.255.0
route 10.68.3.0 255.255.255.0
route 10.68.4.0 255.255.255.0
route 10.68.5.0 255.255.255.0
route 10.68.6.0 255.255.255.0
route 10.68.7.0 255.255.255.0
route 10.68.8.0 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"
;push "redirect-gateway def1"
keepalive 5 240

tls-server
tls-auth /etc/openvpn/keys/ta.key 0
tls-timeout 120

auth SHA512
cipher AES-256-CBC   # AES
comp-lzo
status-version 2
user nobody
group nobody

persist-key
persist-tun

status openvpn-status.log
log-append /etc/openvpn/openvpn-tun.log
;crl-verify /etc/openvpn/keys/crl.pem

verb 3

mute 10
management localhost 7557

И такой настройкой iptables:

*nat
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m conntrack --ctstate NEW -i tun0 -s 10.68.0.1/24 -j ACCEPT
-P FORWARD DROP
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 1194 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Решил все перенести на VDS/VPS.

Столкнулся с проблеvой, что клиент подключается, получает адрес и все, пингкует только сам сервер впн и адрес dvs внешний.

Пробовал разнsе варианты и по всей видимости запутался)

вот не много изменил iptables:

*nat
:PREROUTING ACCEPT [0:0].
:POSTROUTING ACCEPT [0:0].
:OUTPUT ACCEPT [0:0].
#-A POSTROUTING -s 10.68.0.0/24 -o venet0:0 -j MASQUERADE
-A POSTROUTING -o venet0:0 -j SNAT --to-source 37.*.*.181
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m conntrack --ctstate NEW -i tun0 -s 10.68.0.1/24 -j ACCEPT
-P FORWARD DROP
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 1194 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A FORWARD -i tun0 -o venet0:0 -j ACCEPT
-A FORWARD -i venet0:0 -o tun0 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
#-A FORWARD -i tun0 -o venet0:0 -j ACCEPT
#-A FORWARD -i venet0:0 -o tun0 -j ACCEPT
COMMIT

Результат тот же.

Вывод iptables -nvL -t nat выдает:

Chain PREROUTING (policy ACCEPT 373 packets, 65501 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 363 packets, 65069 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 SNAT       all  --  *      venet0:0  0.0.0.0/0            0.0.0.0/0           to:37.*.*.181

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Вывод iptables -v -nL выдает:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0
  853  295K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    1    28 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    1    52 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:1194
    1    40 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
    7   312 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with-icmp-host-prohibited

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  741  139K ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           ctstate RELA
TED,ESTABLISHED
    0     0 ACCEPT     all  --  tun0   *       10.68.0.0/24         0.0.0.0/0           ctstate NEW
    0     0 ACCEPT     all  --  tun0   venet0:0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  venet0:0 tun0    0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with
icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 728 packets, 98004 bytes)
 pkts bytes target     prot opt in     out     source               destination

Так понимаю, что просто не до конца пробрасывается все) или все не пробрасывается)

Подскажите пожалуйста.

Спасибо.

Ответ на: комментарий от dhameoelin

sysctl -p

net.ipv4.ip_forward = 1
net.ipv4.tcp_syncookies = 1
error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
error: "net.bridge.bridge-nf-call-iptables" is an unknown key
error: "net.bridge.bridge-nf-call-arptables" is an unknown key

может ошибки мешают?)

firefedot ()

Телепатия уводит в сторону маршрутизации. ip route get <ip> для проверки что и куда. Ну и вообще, схема нагляднее смотрится. Я так и не понял как ты подключаешь и как проверял.

turtle_bazon ★★★★★ ()
Ответ на: комментарий от turtle_bazon

Всмысле не понятно?)

Есть сервер на vds/vps там впн, подключаюсь к нему из венды. планирую из CentOS...

ip route get <ip> на какой адрес показать?

firefedot ()
Ответ на: комментарий от odii

Да, у этого хостера можно ...

и по впн нормально цепляюсь, все нужно в впн-сети вижу

firefedot ()

Поставил клиента на другой машине с CentOS.

Вот конец лога с маршрутами

/sbin/ifconfig tun0 10.68.0.6 pointopoint 10.68.0.5 mtu 1500
/sbin/route add -net 37.143.13.181 netmask 255.255.255.255 gw 192.168.1.1
/sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.68.0.5
/sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.68.0.5
/sbin/route add -net 10.68.1.0 netmask 255.255.255.0 gw 10.68.0.5
/sbin/route add -net 10.68.0.1 netmask 255.255.255.255 gw 10.68.0.5
Initialization Sequence Completed

Вот эта строка видимо ключевая )

/sbin/route add -net 37.143.13.181 netmask 255.255.255.255 gw 192.168.1.1

gw идет на мою локался , а не куда надо...

как поменяьт не пойму, то ли в конфиге сервера , то ли в конфиге iptables

firefedot ()
Ответ на: комментарий от firefedot

а хотя нет. он же через роутер все равно в начале идет....

firefedot ()
Ответ на: комментарий от turtle_bazon

Вот вывод команды на клиенте (адрес яндекса)

[root@localhost openvpn]# ip route get 213.180.193.3
213.180.193.3 via 10.68.0.5 dev tun0  src 10.68.0.6
    cache  mtu 1500 advmss 1460 hoplimit 64

firefedot ()
Ответ на: комментарий от firefedot

Мне не понятно как было, когда работало. И непонятно как сейчас, когда не работает. По выводу - 10.68.0.5 - твой маршрутизатор на vps? Если да, то там есть ip_forward и маскарадинг ip, ну и само по себе пингуется то, что ты от клиента хочешь?

turtle_bazon ★★★★★ ()
Ответ на: комментарий от turtle_bazon

Маскарадинг включал, сейчас епробовал в SNAT

Работало, когда все проверял на живых машинах, брал системник ставил и другим подключался

При подключении по впн, клиент пингкет сервер 10.68.0.1, пингует типа внешний адрес сервера 37.*.*.181

просто не пойму, проблема из-за не впн, хотя он вроде все правильно раздал или из-за iptables, не точно или совсем не верно настроил все...

firefedot ()
Ответ на: комментарий от firefedot

Они в одной сети находились? Маскарадинг на внешний интерфейс вешается.

turtle_bazon ★★★★★ ()
Ответ на: комментарий от firefedot

Сейчас тебе расскажу ключевые моменты:

  • ip_forward на сервере;
  • маскарадинг на внешнем интерфейсе на сервере;
  • маршрутизация на ip сервера через обычный маршрут (роутер там или что);
  • маршрутизация по умолчанию через IP vpn;
  • не забыть ещё про resolv.conf, чтобы имена резолвились.
turtle_bazon ★★★★★ ()
Последнее исправление: turtle_bazon (всего исправлений: 1)
Ответ на: комментарий от firefedot

В общем перемудрил...

Вроде нашел причину, кроме прокладки мержу экраном и стулом)

Утром выложу решение, если оно есть, дабы потом самому не наткнуться еще раз.

firefedot ()
Ответ на: комментарий от turtle_bazon

ip_forward на сервере - есть

маскарадинг на внешнем интерфейсе на сервере - есть (-A POSTROUTING -o venet0:0 -j MASQUERADE)

маршрутизация на ip сервера через обычный маршрут (роутер там или что); - оно? -A FORWARD -i tun0 -o venet0:0 -j ACCEPT

маршрутизация по умолчанию через IP vpn; - имеется ввиду redirect-gateway?

не забыть ещё про resolv.conf, чтобы имена резолвились. - тут прописаны днс сервера

firefedot ()
Ответ на: комментарий от firefedot

маршрутизация на ip сервера через обычный маршрут (роутер там или что); - оно? -A FORWARD -i tun0 -o venet0:0 -j ACCEPT

Нет, не оно. Сделай на клиенте ip route get <ip сервера>

маршрутизация по умолчанию через IP vpn; - имеется ввиду redirect-gateway?

имеется в виду ip route set default via <openvpn ip>

turtle_bazon ★★★★★ ()
Ответ на: комментарий от turtle_bazon

то есть это все клиенте ... сейчас посмотрим ... спасибо...

firefedot ()
Ответ на: комментарий от turtle_bazon

пробовал и так и сяк...

вот трейс до яндекса с подлключенным впн...

traceroute to ya.ru (93.158.134.3), 30 hops max, 60 byte packets
 1  10.68.0.1 (10.68.0.1)  23.146 ms  68.260 ms  68.289 ms
 2  * * *
 .........
 30  * * *

так понпимаю, что все равно дело не в клиенте, он то пробует, а вот сервер не пробрасывает...

так ведь? значит сетевой экран?

firefedot ()
Ответ на: комментарий от firefedot

Нарисовал бы диаграмму, было бы проще. 10.68.0.1 - это кто? Сервер VPN? Если да, то он сам пингуется? Если пингуется, то он либо не пробрасывает, либо нарушена маршрутизация.

UPD: Да, вроде VPN, если твои конфиги смотреть. Давай тогда поступим так - на VPS вообще очищай iptables и правила маршрутизации. И сделай только ip_route=1 и MASQUERADE. И покажи ifconfig на сервере. И, вообще, что это за VPS? По какой технологии? Чую, что что-то типа openvz.

turtle_bazon ★★★★★ ()
Последнее исправление: turtle_bazon (всего исправлений: 2)
Ответ на: комментарий от turtle_bazon

Часть проблемы решил, в конфиге сервера убрал строки

push "route 10.68.1.0 255.255.255.0"
;route 10.68.0.0 255.255.255.0
route 10.68.3.0 255.255.255.0
route 10.68.4.0 255.255.255.0
route 10.68.5.0 255.255.255.0
route 10.68.6.0 255.255.255.0
route 10.68.7.0 255.255.255.0
route 10.68.8.0 255.255.255.0

После чего, пинги пошли нормальные.

Спасибо, всем откликнувшимся, прошу прощения, что не мог оперативно реагировать.но все помогли.

Если бы не проверил все настройки сетевого экрана, то не догадался бы прошерстить конфиг.

firefedot ()
Ответ на: комментарий от firefedot

По идее, убирание только этих строк ситуацию не должно было изменить. Это же просто директива для клиента о том, на какие сети прописывать маршрут.

turtle_bazon ★★★★★ ()
Ответ на: комментарий от odii

а разве в vps ты сможешь создать tun/tap устройство?

Зависит от технологии виртуализации и, в случае контейнеров типа openvz, от жадности админов (например, FirstVDS раньше давали на openvz по запросу, а после появления тарифов с kvm перестали).

INFOMAN ★★★★★ ()
Ответ на: комментарий от turtle_bazon

забыл дописать...

Убрал строки и прописал правило

iptables -t nat -I POSTROUTING -s 10.68.0.0/24 -j MASQUERADE

Осталось только теперь через клиента-впн вывести в интернет влю локальную сеть) Мега шлюз)

firefedot ()
Ответ на: комментарий от firefedot

Когда делаешь маскарадинг, правильнее таки указать выходной его интерфейс. Иначе он будет маскарадить всё подряд, что через маршрутизацию проходит.

turtle_bazon ★★★★★ ()
Ответ на: комментарий от firefedot

Да. Иначе локальные сети (которых ты там кучу прописал) тоже будут друг к другу через маскарад ходить. Что не совсем правильно.

turtle_bazon ★★★★★ ()
Ответ на: комментарий от turtle_bazon

Понял, убрал те сети, оказались излишни .. но суть я понял.

Спасибо.

firefedot ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.