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

Проблемы с форвардингом в openvpn

 , ,


0

1

Добрый день. Цель: настроить openvpn тонель и сидеть через ip сервера безопасно.
Что проделано: Само подключение настроено. Клиенты конектятся. Пинги идут и с клиентов на сервер, и с сервера на клиентов. 

# cat /proc/sys/net/ipv4/ip_forward 
1
Добавил правила 
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o tun+ -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -s 10.8.0.0/24 -j SNAT --to-source 192.168.210.123
Но инет так и не появляется. Делаю трейс с клиента 
$ traceroute mail.ru
traceroute to mail.ru (94.100.191.204), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  97.212 ms  98.238 ms  99.104 ms
 2  192.168.210.1 (192.168.210.1)  99.632 ms  100.446 ms  100.960 ms
 3  * * *
Я чего-то не понимаю. По идее захлеб идет после лан интерфейса сервера. Что я делаю не так? Буду благодарен за помощь.
ЗЫ. Конфиги не писал ибо имхо там все нормально. Но если не так, то могу предоставить конфиги сервера, клиента или что еще потребуется. Заранее благодарен.


← что использует диск
Поиск изменений в таблицах бд postgresql →

iptables-save с сервера в студию

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

Мне выдается 10.8.0.6 Трейс идет в один хоп 

# iptables-save -c
# Generated by iptables-save v1.4.8 on Tue Apr 24 10:40:51 2012
*nat
:PREROUTING ACCEPT [4474:336446]
:POSTROUTING ACCEPT [71:4355]
:OUTPUT ACCEPT [71:4355]
[1331:80280] -A POSTROUTING -s 10.8.0.0/24 -o eth1 -j SNAT --to-source 192.168.210.123 
COMMIT
# Completed on Tue Apr 24 10:40:51 2012
# Generated by iptables-save v1.4.8 on Tue Apr 24 10:40:51 2012
*filter
:INPUT ACCEPT [6779:1506234]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [981:109217]
[45:6694] -A INPUT -i tun+ -j ACCEPT 
[4033:249285] -A FORWARD -i tun+ -o eth1 -j ACCEPT 
[3:264] -A FORWARD -i eth1 -o tun+ -j ACCEPT 
COMMIT
# Completed on Tue Apr 24 10:40:51 2012

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

Трейс идет в один хоп

Куда идёт? Я имел в виду с сервера с openvpn работает ли команда:

traceroute -s 192.168.210.123 mail.ru

И нормально ли с правилами firewall на клиенте?

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

А вот так не идет 

traceroute -s 192.168.210.123 mail.ru
traceroute to mail.ru (94.100.191.204), 30 hops max, 60 byte packets
 1  192.168.210.1 (192.168.210.1)  5.071 ms  3.159 ms  2.148 ms
 2  * * *
Правила файрвола у клиента абсолютно чисты. Есть еще 2 интерфейса на серве с внешними адрессами (eth1:0 и eth1:1). Наверно сейчас попробую через них отправить.

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

Значит на 192.168.210.1 не со всех адресов дан выход в Инет. Смотрите с какого адреса ходит в инет openvpn-сервер и делаете SNAT на этот адрес.

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

В инет смотрят еще два интерфейса eth1:0 (IP1) и eth1:1 (IP2) Добавил те же правила только для eth1:0 

# iptables-save -c
# Generated by iptables-save v1.4.8 on Tue Apr 24 11:25:01 2012
*nat
:PREROUTING ACCEPT [522:36098]
:POSTROUTING ACCEPT [344:20531]
:OUTPUT ACCEPT [4:339]
[0:0] -A POSTROUTING -s 10.8.0.0/24 -o eth1:0 -j SNAT --to-source IP1
COMMIT
# Completed on Tue Apr 24 11:25:01 2012
# Generated by iptables-save v1.4.8 on Tue Apr 24 11:25:01 2012
*filter
:INPUT ACCEPT [1246:173458]
:FORWARD ACCEPT [648:40324]
:OUTPUT ACCEPT [360:41891]
[13:1687] -A INPUT -i tun+ -j ACCEPT 
[0:0] -A FORWARD -i tun+ -o eth1:0 -j ACCEPT 
[0:0] -A FORWARD -i eth1:0 -o tun+ -j ACCEPT 
COMMIT
# Completed on Tue Apr 24 11:25:01 2012
Трейс с клиента теперь не идет дальше tun интерфейса vpn сервера. При том что с сервера traceroute -s IP1 mail.ru идет нормально. Я теперь теряюсь в догадках.

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

Я, если честно, только постигаю всю мощь iptables. Не могли бы помочь разобраться как это сделать? Заранее благодарен.

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

Потому что для iptables не существует интерфейса eth1:0, есть только eth1. Алиасы интерфейсов это алиасы, их нет при движении пакета по правилам iptables и правилам маршрутизации.

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

Маскарадинг для статического адреса не нужен, достаточно SNAT.

iptables -t nat -L -n -v

покажет правила со счётчиками (байт и пакетов). Для SNAT/DNAT правил счётчик пакетов фактически показывает кол-во установленных (с момента загрузки правила) соединений, попадающих под это правило. Если счётчик нулевой, а попытки попинговать машины в Инет были, значит пакеты не попадают под это правило.

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

Сделал. Теперь правила выглядят так 

# Generated by iptables-save v1.4.8 on Tue Apr 24 18:44:46 2012
*nat
:PREROUTING ACCEPT [12:804]
:POSTROUTING ACCEPT [1:116]
:OUTPUT ACCEPT [1:116]
[0:0] -A POSTROUTING -s 10.8.0.0/24 -o eth1 -j SNAT --to-source IP1
COMMIT
# Completed on Tue Apr 24 18:44:46 2012
# Generated by iptables-save v1.4.8 on Tue Apr 24 18:44:46 2012
*filter
:INPUT ACCEPT [188:20184]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [104:14992]
[0:0] -A INPUT -i tun+ -j ACCEPT 
[0:0] -A FORWARD -i tun+ -o eth1 -j ACCEPT 
[0:0] -A FORWARD -i eth1 -o tun+ -j ACCEPT 
COMMIT
# Completed on Tue Apr 24 18:44:46 2012
Состояние счетчиков сразу после добавления - по нулям 
Chain PREROUTING (policy ACCEPT 95 packets, 8577 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1 packets, 116 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 SNAT       all  --  *      eth1    10.8.0.0/24          0.0.0.0/0           to:IP1

Chain OUTPUT (policy ACCEPT 1 packets, 116 bytes)
 pkts bytes target     prot opt in     out     source               destination
После пары заходов и трейсов счетчики выглядят уже обнадеживающе 
# iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 502 packets, 45352 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1 packets, 116 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  278 26217 SNAT       all  --  *      eth1    10.8.0.0/24          0.0.0.0/0           to:IP1

Chain OUTPUT (policy ACCEPT 1 packets, 116 bytes)
 pkts bytes target     prot opt in     out     source               destination
И судя по трейсу все ок 
$ traceroute mail.ru
traceroute to mail.ru (94.100.191.201), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  106.354 ms  106.362 ms  108.904 ms
 2  192.168.253.93 (192.168.253.93)  116.405 ms  120.454 ms  120.464 ms
 .............
 9  cat13.Moscow.gldn.net (194.186.80.70)  145.071 ms cat13.Moscow.gldn.net (194.186.159.14)  145.089 ms cat13.Moscow.gldn.net (194.186.80.70)  145.093 ms
В общем похоже со скрипом и ревом завелось. Огромнейшее спасибо. Бился над проблемой чуть больше недели. Но так меееедлееееннно. Это скорость так резко из-за ната упала? И еще хочу IP проверить, но не могу зайти например на http://2ip.ru . Пинг идет, а wget похоже не может ничего получить. Это надо понимать вина сервера?

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

На счёт медленно не знаю, но если сервер хотя бы Pentiun II то уже «так меееедлееееннно» быть не должно. По трейсу у вас огромное (106.354 ms = 0,1 c) время ответа уже на openvpn тунеле. Не знаю, или у вас там совсем слабые компы и им сложно шифровать трафик, или узкий физический канал связи, как я понимаю, вы подключаетесь к openvpn-серверу не из локальной сети.

Это надо понимать вина сервера?

Наверное, проблема в MTU, попробуйте:

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

или

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1200

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

Да. Я еще вчера ночью столкнулся с проблемой подобного рода. Если выполняешь что-то в терминале, что генерирует вывод чуть больше пары сотен байт, то сессия замирает и даже Control-C не спасает. ПОчитал. Пишут проблема с MTU. По ssh подключался напрямую. Сравнил mtu на интерфейсах сервера и клиента. Везде по 1500.Даже с пустыми правилами на фаерволе имеет место быть подобное. По советам в инете добавил в конфиг сервера и клиента это 

tun-mtu 1500
fragment 1400
mssfix
Но не спасло. Даже когда подключаюсь по ssh через vpn, то ситуация с зависаниями не исчезает. Сапорта пока нету, но я даже не знаю что им писать. И вобще проблема у меня, или у них?

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

Ах да. Прошу прощения что не сказал сразу. VPN сервер работает по udp.

furang
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← что использует диск
Admin
Поиск изменений в таблицах бд postgresql →