Или, если быть точным, то GRE.
В общем, есть сервер с Xen'ом, есть domU с PPTP-сервером. dom0 занимается вопросами роутинга трафика. VPN-сервер в своей подсети; плюс сервер обслуживает локальную сеть.
vpn-сервер включен в br2, IP 192.168.221.251
Локальная сеть - через br0, адрес хоста клиента в данном случае 192.168.1.133.
Суть проблемы: с внешнего мира все прекрасно подключается и работает. С локальной сети при обращении на внешний адрес сессия не устанавливается. 1723 доступен, nmap'ится и так далее. GRE уходит на шлюз, SNAT'ится от внешнего адреса, DNAT'ится на VPN сервер, тот успешно отвечает (на br2 есть ответ), а вот дальше, такое ощущение, что шлюз не знает, что с этими пакетами делать. На br0 есть только клиентские запросы.
iptables
"${ipt}" -A FORWARD -p tcp -d 192.168.221.251 -j ACCEPT #
"${ipt}" -A FORWARD -p gre -j ACCEPT # vpn
"${ipt}" -A PREROUTING -t nat -p tcp -d $exip --dport 1723 -j DNAT --to 192.168.221.251:1723 # VPN
"${ipt}" -A PREROUTING -t nat -p gre ! -s 192.168.221.251 -d $exip -j DNAT --to 192.168.221.251 # VPN
"${ipt}" -A POSTROUTING -t nat -p tcp -s $homenet/24 -d 192.168.221.251 --dport 1723 -j SNAT --to-source $exip
"${ipt}" -A POSTROUTING -t nat -p gre -s $homenet/24 -d 192.168.221.251 -j SNAT --to-source $exip
lsmod
lsmod | grep -E 'gre|pptp'
ip_gre 24576 0
gre 16384 1 ip_gre
nf_nat_pptp 16384 0
nf_nat_proto_gre 16384 1 nf_nat_pptp
nf_conntrack_pptp 16384 1 nf_nat_pptp
nf_conntrack_proto_gre 16384 1 nf_conntrack_pptp
*** ну и + зависимости ***
Первые 2 модуля - это я уже игрался, подгружая то, что хоть как-то может к этой теме относиться. Результат не меняется.
pptpd log: https://paste.ubuntu.com/p/cGzWmzc5Cr/
tcpdump:
br0: https://paste.ubuntu.com/p/sjwyW9PrZD/
br2: https://paste.ubuntu.com/p/8HH3GfZGqs/
Если убрать SNAT для локальной сети и подключаться на адрес VPN-сервера - то, естественно, тоже все работает.
Вроде на старом сервере (с подобной конфигурацией, но Debian 7 и на ядре 3.9) оно работало (по-крайней мере, я не помню, чтобы оно не работало). Правда, есть подозрение, что тогда из локальной сети я ходил на локальный адрес - сейчас уже не проверю.
Смахивает немного на вот это. Но поведение поменялось только с 3.5, т.е., со старым вариантом я не должен был столкнуться. Кроме того, попытка использовать правила с -j CT --helper pptp или установка net.netfilter.nf_conntrack_helper в 1 вообще блокирует трафик с локальной сети на 1723-й порт VPN-сервера (да и нужно ли оно, если на 1723 все ходит нормально и так?)
Насчет предложений сменить PPTP на что-то более вменяемое - возможно, в будущем :). Пока устраивает и так, но хотелось бы разобраться в проблеме и сделать максимально универсальный вариант (с одинаковым адресом сервера как изнутри, так и снаружи).
