LINUX.ORG.RU
Форум — Admin  

Маршрутизация OpenVPN


0

1

Здравствуйте. И так был приобретен vps сервер. На нем включили модули tun/tap, CentOS 5.5 настроил OpenVPN на другом конце Микротик. Задача: нужно сделать, чтобы запросы на 80 порт vps сервера перенаправлялись в другую сеть. Так-же другая сеть должна получать доступ к Интрентету через vpn. Проблема в том, что из другой подсети ping проходит, http запрос нет.

На OpenVPN сервере при http запросе:

# tcpdump -i tun0 

14:22:10.490150 IP 192.168.33.6.52638 > lasvegas-nv-datacenter.com.http: . ack 1 win 457 <nop,nop,timestamp 3207681 3168233474>
14:22:10.565172 IP 192.168.33.6.52638 > lasvegas-nv-datacenter.com.http: P 1:132(131) ack 1 win 457 <nop,nop,timestamp 3207681 3168233474>
14:22:10.565207 IP lasvegas-nv-datacenter.com.http > 192.168.33.6.52638: . ack 132 win 54 <nop,nop,timestamp 3168233584 3207681>
14:22:10.565527 IP lasvegas-nv-datacenter.com.http > 192.168.33.6.52638: P 1:468(467) ack 132 win 54 <nop,nop,timestamp 3168233584 3207681>
14:22:10.565560 IP lasvegas-nv-datacenter.com.http > 192.168.33.6.52638: F 468:468(0) ack 132 win 54 <nop,nop,timestamp 3168233584 3207681>
14:22:10.679886 IP 192.168.33.6.52638 > lasvegas-nv-datacenter.com.http: . ack 468 win 490 <nop,nop,timestamp 3207855 3168233584>
14:22:10.749884 IP 192.168.33.6.52638 > lasvegas-nv-datacenter.com.http: F 132:132(0) ack 469 win 490 <nop,nop,timestamp 3207855 3168233584>
14:22:10.749910 IP lasvegas-nv-datacenter.com.http > 192.168.33.6.52638: . ack 133 win 54 <nop,nop,timestamp 3168233769 3207855>

при icmp: 

15:42:13.418261 IP 192.168.33.6 > web.hostmaster.ua: ICMP echo request, id 2054, seq 1, length 64
15:42:13.418300 IP web.hostmaster.ua > 192.168.33.6: ICMP echo reply, id 2054, seq 1, length 64
15:42:14.426712 IP 192.168.33.6 > web.hostmaster.ua: ICMP echo request, id 2054, seq 2, length 64
15:42:14.426739 IP web.hostmaster.ua > 192.168.33.6: ICMP echo reply, id 2054, seq 2, length 64
15:42:15.413705 IP 192.168.33.6 > web.hostmaster.ua: ICMP echo request, id 2054, seq 3, length 64
15:42:15.413729 IP web.hostmaster.ua > 192.168.33.6: ICMP echo reply, id 2054, seq 3, length 64
15:42:16.419753 IP 192.168.33.6 > web.hostmaster.ua: ICMP echo request, id 2054, seq 4, length 64
15:42:16.419781 IP web.hostmaster.ua > 192.168.33.6: ICMP echo reply, id 2054, seq 4, length 64

iptables -L -t nat -v 

Chain PREROUTING (policy ACCEPT 31 packets, 1600 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   44  2931 DNAT       all  --  tun0   any     anywhere             anywhere            to:внешний_ip 

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   25  1794 SNAT       all  --  any    venet0  anywhere             anywhere            to:внешний_ip 
    0     0 SNAT       all  --  any    venet0  anywhere             anywhere            to:внешний_ip



Последнее исправление: fedor888 (всего исправлений: 4)
← Передача файлов через XMPP оффлайн-клиенту
Проблемы с работой snmp trap →
Ответ на: комментарий от fedor888

Не знаю кто тебе советовал включать такое правило в DNAT, но это плохой совет. Правило должно быть одно, в POSTROUTING, и выглядеть как:

-s ! внешний IP -o vnet0 -j SNAT --to-source внешний_ip

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi 
# iptables -L -t nat -v
Chain PREROUTING (policy ACCEPT 25 packets, 1326 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 10 packets, 661 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   19   950 SNAT       all  --  any    venet0 !внешний_ip  anywhere            to:внешний_ip 

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

так, нет ответа вообще: 

# tcpdump -i tun0
11:36:17.324355 IP 192.168.33.6 > web.hostmaster.ua: ICMP echo request, id 3189, seq 10, length 30
11:36:18.370916 IP 192.168.33.6 > web.hostmaster.ua: ICMP echo request, id 3189, seq 11, length 30
11:36:19.405816 IP 192.168.33.6 > web.hostmaster.ua: ICMP echo request, id 3189, seq 12, length 30
11:36:20.450668 IP 192.168.33.6 > web.hostmaster.ua: ICMP echo request, id 3189, seq 13, length 30
c DNAT хоть был ответ на icmp

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

И с того, что делал: 

iptables -t nat -A POSTROUTING -o venet0 -j SNAT --to-source внешний_ip
или так 
iptables -t nat -A POSTROUTING -d ! 192.168.33.0 -j SNAT --to-source внешний_ip
или так 
iptables -t nat -A POSTROUTING -s 192.168.33.0 -d ! 192.168.33.1 -j SNAT --to-source внешний_ip
не работает!

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

Тебя кто учил с tcpdump'ом работать? На раутерах их бесполезно снимать одной стороны. Смотреть надо на оба интерфейса - на tun0 и на venet0. Вот тогда и понятно станет

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

Вместо того чтобы тролить помогли бы чем-то. В начале я писал, что с другой стороны соединение клиент подымает по средствам Микротик. Маршрутизация на роутере настроена правильно, сомнений нет. Установил iftop. На сервере видно, что подключение к тому же ya.ru хосту есть, ответа нет. Мне вот интересно одна вещь, при snat, dnat правилах masqarade точно работает???

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

Я же по-русски сказал, что нужен tcpdump с обоих интерфейсов. Что тут непонятно? На раутерах так всегда делось, делается и будет делаться.

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

И так оптимальным вариантом, есть данная настройка: 

iptables -t nat -A PREROUTING -j DNAT --to-destination внешний_ip
iptables -t nat -A POSTROUTING -s user_lan -j SNAT --to-source внешний_ip
iptables -A FORWARD -s user_lan/24 -j ACCEPT
Но все же tcpdump мне не сильно и поможет. Судя по всему, не все включено в ядре... А это vps - блин. Картина маслом, не могу пользоваться ни одним портом кроме icmp. Это пожет быть связано с настройкой сервера котой у провайдера? (какими нибудь ограничениями).

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

Судя по всему, не все включено в ядре... А это vps - блин. Картина маслом

Почему я и попросил - сделай tcpdump по обоим интерфейсам. На всяких VPS это первое, что надо делать при косяках с раутингом. Кстати, судя по этой картинке

Chain POSTROUTING (policy ACCEPT 10 packets, 661 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   19   950 SNAT       all  --  any    venet0 !внешний_ip  anywhere            to:внешний_ip

всё не так плохо - твой сервер маскарадит что-то... Вот только что именно? И каким образом? tcpdump на внешнем интерфйесе даст ответ.

ни одним портом кроме icmp

icmp - не порт, icmp - протокол :-)

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

К стати да, маскарадит. 

iptables -t nat -A POSTROUTING -d ! внешний_ip -j SNAT --to-source внешний_ip

# tcpdump src port 80 -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
15:07:50.323840 IP www.yandex.ru.http > 192.168.33.6.33959: S 3267503178:3267503178(0) ack 3400610603 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:07:51.698857 IP www.yandex.ru.http > 192.168.33.6.33959: S 3267503178:3267503178(0) ack 3400610603 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:07:53.698901 IP www.yandex.ru.http > 192.168.33.6.33959: S 3267503178:3267503178(0) ack 3400610603 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:07:57.698989 IP www.yandex.ru.http > 192.168.33.6.33959: S 3267503178:3267503178(0) ack 3400610603 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:08:05.699161 IP www.yandex.ru.http > 192.168.33.6.33959: S 3267503178:3267503178(0) ack 3400610603 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:08:21.699446 IP www.yandex.ru.http > 192.168.33.6.33959: S 3267503178:3267503178(0) ack 3400610603 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:08:46.636077 IP www.yandex.ru.http > 192.168.33.6.41315: S 2514981146:2514981146(0) ack 3207271003 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:08:48.105297 IP www.yandex.ru.http > 192.168.33.6.41315: S 2514981146:2514981146(0) ack 3207271003 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:08:50.109305 IP www.yandex.ru.http > 192.168.33.6.41315: S 2514981146:2514981146(0) ack 3207271003 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:08:54.113489 IP www.yandex.ru.http > 192.168.33.6.41315: S 2514981146:2514981146(0) ack 3207271003 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>

10 packets captured
10 packets received by filter
0 packets dropped by kernel

# tcpdump src port 80 -i venet0
tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
15:09:02.129608 IP www.yandex.ru.http > внешний_ip.41315: S 2514981146:2514981146(0) ack 3207271003 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:09:16.536044 IP www.yandex.ru.http > внешний_ip.39233: S 2080691908:2080691908(0) ack 3805601983 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:09:17.686291 IP www.yandex.ru.http > внешний_ip.39233: S 2080691908:2080691908(0) ack 3805601983 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:09:18.354044 IP www.yandex.ru.http > внешний_ip.41315: S 2514981146:2514981146(0) ack 3207271003 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:09:19.686031 IP www.yandex.ru.http > внешний_ip.39233: S 2080691908:2080691908(0) ack 3805601983 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>
15:09:23.690146 IP www.yandex.ru.http > внешний_ip.39233: S 2080691908:2080691908(0) ack 3805601983 win 14100 <mss 1410,nop,nop,sackOK,nop,wscale 9>

6 packets captured
6 packets received by filter
0 packets dropped by kernel
Запрос по http есть, ответ тоже. У клиента: 
# curl -v http://ya.ru
* About to connect() to ya.ru port 80 (#0)
*   Trying 213.180.193.3... connected
* Connected to ya.ru (213.180.193.3) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: ya.ru
> Accept: */*
>
Странно, какие еще могут быть варианты?

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

Может неправильно тунель построил? Конфиг сервера: 

# cat /etc/openvpn/server.conf
mode server
tls-server
daemon
port 1194
proto tcp-server
dev tun0

ca /etc/openvpn/.key/ca.crt
cert /etc/openvpn/.key/key0.crt 
key /etc/openvpn/.key/key0.key 
dh /etc/openvpn/.key/dh1024.pem 

push "redirect-gateway def1 bypass-dhcp"
server 192.168.33.0 255.255.255.0
push "route 192.168.33.0 255.255.255.0"
push "route-gateway 192.168.33.1"
 
keepalive 10 120
auth SHA1
persist-key
persist-tun
verb 3
log-append /var/log/openvpn.log
Или что-то с форвардом...

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

Да у тебя на клиенте косяк, кстати. Видишь же, что ответы яндексового сервера через tun0 уходят в первом tcpdump? Лечи клиента.

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

Что я и хотел понять. Да действительно проблема на клиенском микротике была. Огромное спасибо за подсказку по iptables.

fedor888
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Передача файлов через XMPP оффлайн-клиенту
Admin
Проблемы с работой snmp trap →