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

Отваливаются внешние подключения после включения VPN

 , ,


0

1

Есть два хоста с Debian. Нужно завернуть собственный (т.е. инициированный им самим) трафик одного хоста (клиента) через второй (сервер). Сделал pptp vpn, настроил, работает. Одна беда: когда включается vpn - отваливаются уже подключенные к клиенту соединения и вообще невозможно достучаться до него напрямую. Нужно или ребутать его или стучаться до VPN-сервера, а с него подключаться к клиенту. Причём с VPN-сервера подключается как по адресу назначенному VPN, так и по внешнему адресу (до которого остальные в этот момент не могут достучаться). Я определённо туплю. Подскажите пожалуйста, что нужно поправить, чтобы клиент не терялся из исходной сети и можно было свободно к нему подключаться не из VPN?

КоньФигурация

Адрес клиента 10.1.1.168

Маршрутизатор подсети клиента 10.1.1.161

10.1.2.106 - VPN-сервер

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.1.161   0.0.0.0         UG    0      0        0 xenbr0
10.1.1.160   0.0.0.0         255.255.255.224 U     0      0        0 xenbr0
10.1.2.106  10.1.1.161   255.255.255.255 UGH   0      0        0 xenbr0
192.168.168.0   0.0.0.0         255.255.255.0   U     0      0        0 xenbr1

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
10.1.1.160   0.0.0.0         255.255.255.224 U     0      0        0 xenbr0
10.1.2.106  10.1.1.161   255.255.255.255 UGH   0      0        0 xenbr0
192.168.10.1    0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.168.0   0.0.0.0         255.255.255.0   U     0      0        0 xenbr1

# iptables-save
# Generated by iptables-save v1.4.14 on Sat Jun  4 23:36:26 2016
*nat
:PREROUTING ACCEPT [881747:56696529]
:INPUT ACCEPT [72439:5554730]
:OUTPUT ACCEPT [40572:2692848]
:POSTROUTING ACCEPT [46252:3369042]
-A PREROUTING -d 10.1.1.168/32 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.168.2:3389
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.168.0/24 ! -d 192.168.168.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.168.0/24 ! -d 192.168.168.0/24 -o xenbr0 -j MASQUERADE
COMMIT
# Completed on Sat Jun  4 23:36:26 2016
# Generated by iptables-save v1.4.14 on Sat Jun  4 23:36:26 2016
*filter
:INPUT ACCEPT [2312018:1648329198]
:FORWARD ACCEPT [1527774:2514275872]
:OUTPUT ACCEPT [2378596:2470855620]
:ISPMGR - [0:0]
-A INPUT -j ISPMGR
-A FORWARD -m physdev --physdev-out vif8.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -p udp -m physdev --physdev-in vif8.0 --physdev-is-bridged -m udp --sport 68 --dport 67 -j ACCEPT
-A FORWARD -m physdev --physdev-out vif8.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -s 192.168.168.5/32 -m physdev --physdev-in vif8.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-out vif7.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -p udp -m physdev --physdev-in vif7.0 --physdev-is-bridged -m udp --sport 68 --dport 67 -j ACCEPT
-A FORWARD -m physdev --physdev-out vif7.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -s 192.168.168.6/32 -m physdev --physdev-in vif7.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-out vif5.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -p udp -m physdev --physdev-in vif5.0 --physdev-is-bridged -m udp --sport 68 --dport 67 -j ACCEPT
-A FORWARD -m physdev --physdev-out vif5.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -s 192.168.168.4/32 -m physdev --physdev-in vif5.0 --physdev-is-bridged -j ACCEPT
-A OUTPUT -j ISPMGR
COMMIT

Интерфейсы xenbr т.к. на клиенте живёт несколько виртуалок под управлением xen.


Нефиг шлюз по-умолчанию устанавливать через vpn :)

Чтоб установленные соединения не отваливались нужно чтоб для них не менялся маршрут (а у тебя он судя по всему меняется).

в pptp нет штатного механизма передачи списка маршрутов клиенту, т.ч. на клиенте нужно городить огород с добавлением маршрутов. Эта проблема решена в openvpn.

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

Но мне же и нужно чтобы весь исходящий трафик хоста, за исключением трафика в рамках прямых подключений от других хостов к нему, был через VPN. Т.е. например к нему подключаются на внутренний портал (http), ssh, rdp прямо (без VPN), но когда он обращается к внешним ресурсам (например забирает почту или кто-то с RDP-сессии в браузер сунулся) нужно чтобы трафик шёл строго по VPN. Я как-то считал что дефолтный маршрут != единственный маршрут и думал что я затупил в iptables. Пните что почитать на тему установки корректных роутов, если проблема в них?

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

Но мне же и нужно чтобы весь исходящий трафик хоста, за исключением трафика в рамках прямых подключений от других хостов к нему, был через VPN.

соединения через прямые маршруты не пострадают после подъема vpn, а вот все остальные ( те что устанавливались через начальный DGW ) после подъема vpn умрут. Чтоб они не умирали нужно очень хитро настроить iptables и policy-routing. Так что тебе этим лучше не заморачиваться.

А проблема недоступности каких-то адресов через vpn лечится правильной выдачей адресов клиентам vpn (так чтоб в пределах своей сети все знали как до них добраться) и настройкой nat, если эти клиенты идут за пределы своей сети. Почему-то все забывают, что пакет должен не только дойти до сервера, но и вернуться назад.

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

соединения через прямые маршруты не пострадают после подъема vpn, а вот все остальные ( те что устанавливались через начальный DGW ) после подъема vpn умрут. Чтоб они не умирали нужно очень хитро настроить iptables и policy-routing. Так что тебе этим лучше не заморачиваться.

Нет, мне нужно именно сделать чтобы не умирал direct connection, а на VPN-сервере ничего лишнего не торчало и тем более через него не бегало всё подряд (это будут лютые тормоза и оверхед), да и он не совсем в моей юрисдикции. Так что в данном контексте он просто гейтвей в мир.

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

Одна беда: когда включается vpn - отваливаются уже подключенные к клиенту соединения и вообще невозможно достучаться до него напрямую.

под «direct connection» ты это имел ввиду существующие соединения с клиентом ?

Чтобы их сохранить нужно чтоб новый DGW не перебил их.

Если те, кто подключен к клиенту находятся в ограниченом диапазоне адресов, то все просто - перед подъемом vpn на клиенте нужно прописать статические маршруты до них.

Если к клиенту подключается произвольная машине в инете, то задача становится совсем нетривиальной.

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

Под прямым подключением я имел в виду соединения на его реальный ip, а не по VPN

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

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

ну тогда policy-routing нужно настраивать на клиенте. «ip ru» наше все!

Фактически это подключение через 2-х провайдеров. Через первого осуществляется подключение vpn и прием входящих соединений, а через второго все исходящие. Если это так, то задача не сложная.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
General