(в MT и выше не производиться по умолчанию, поведение верное) Проброс портов из пространства vpn server во вне.
Цитата: Martin82 от 15/12/2019, 19:06Доброго времени.
Помогите, при наличии Вашего драгоценного времени, разобраться чайнику)
Вопрос по пробросу портов чз vpn.
Ситуевина следующая.
На SNR-CPE-MD1 (8.2.13.RU.07122019 ) поднят l2tp-сервер и проброшен порт на рдп для vpn-клиента.
[spoiler]
Интерфейс Протокол Порт ист. IP назначения Порт назн. Nat loopback Комментарий Действие
WAN TCP 3389 172.16.200.2 3389 rdp_testМожет и криво, но клиент один, связь падает редко, поэтому тупо на 172.16.200.2 )
[/spoiler]Иногда требуется извне подключиться к этому клиенту по rdp. Т.е. ткнуться не на его адрес, а уже через
ж5.172.63.ххх:3389И как бы возможно кто-то скажет, ерунда так не должно работать. Ыднака..
Если на актуальной проше, увы, тишина (порты не пробрасываются подобным образом).
То на давно почившей версии Wive-RTNL 4.6 это даже работает и даже без бубна.Ниже привел Static Routing Settings, может это как-то поможет понять чего не хватает.
[spoiler]
Таблица с древренго RTNL, где проброс работает, таблица маршрутизации ДО подключения клиента по vpn
No. Destination Netmask Gateway Flags Metric Ref Use Interface Comment Actions
1 0.0.0.0 0.0.0.0 5.172.63.1 3 0 0 0 WAN
2 5.172.63.0 255.255.255.0 0.0.0.0 1 0 0 0 WAN
3 5.172.63.1 255.255.255.255 0.0.0.0 5 0 0 0 WAN
4 127.0.0.0 255.0.0.0 0.0.0.0 1 0 0 0 lo
5 178.49.132.66 255.255.255.255 5.172.63.1 7 0 0 0 WAN
6 178.49.132.67 255.255.255.255 5.172.63.1 7 0 0 0 WAN
7 192.168.0.0 255.255.255.0 0.0.0.0 1 0 0 0 LAN
8 224.0.0.0 240.0.0.0 0.0.0.0 1 0 0 0 WAN
9 239.0.0.0 255.0.0.0 0.0.0.0 1 0 0 0 LANТаблица с древренго RTNL, где проброс работает, таблица маршрутизации при подключении по vpn
1 0.0.0.0 0.0.0.0 5.172.63.1 3 0 0 0 WAN
2 0.0.0.0 0.0.0.0 172.16.200.2 3 10010 0 0 ppp10
3 5.172.63.0 255.255.255.0 0.0.0.0 1 0 0 0 WAN
4 5.172.63.1 255.255.255.255 0.0.0.0 5 0 0 0 WAN
5 127.0.0.0 255.0.0.0 0.0.0.0 1 0 0 0 lo
6 172.16.200.2 255.255.255.255 0.0.0.0 5 0 0 0 ppp10
7 178.49.132.66 255.255.255.255 5.172.63.1 7 0 0 0 WAN
8 178.49.132.67 255.255.255.255 5.172.63.1 7 0 0 0 WAN
9 192.168.0.0 255.255.255.0 0.0.0.0 1 0 0 0 LAN
10 224.0.0.0 240.0.0.0 0.0.0.0 1 0 0 0 WAN
11 239.0.0.0 255.0.0.0 0.0.0.0 1 0 0 0 LANNG декабрьская, проброс НЕ работает, таблица маршрутизации до подключения по vpn
No. Адрес назначения Маска сети Шлюз Флаги Метрика Ref Use Интерфейс Комментарий Действие
1 0.0.0.0 0.0.0.0 37.192.220.1 3 0 0 0 WAN
2 0.0.0.0 0.0.0.0 0.0.0.0 1 100 0 0 WAN
3 37.192.220.0 255.255.255.0 0.0.0.0 1 0 0 0 WAN
4 37.192.220.1 255.255.255.255 0.0.0.0 5 100 0 0 WAN
5 127.0.0.0 255.0.0.0 0.0.0.0 1 0 0 0 LAN
6 178.49.132.66 255.255.255.255 37.192.220.1 7 0 0 0 WAN
7 178.49.132.67 255.255.255.255 37.192.220.1 7 0 0 0 WAN
8 192.168.1.0 255.255.255.0 0.0.0.0 1 0 0 0 LAN
9 224.0.0.0 240.0.0.0 0.0.0.0 1 0 0 0 WAN
10 239.0.0.0 255.0.0.0 0.0.0.0 1 0 0 0 LANNG декабрьская, проброс НЕ работает, таблица маршрутизации после подключения по vpn
No. Адрес назначения Маска сети Шлюз Флаги Метрика Ref Use Интерфейс Комментарий Действие
1 0.0.0.0 0.0.0.0 37.192.220.1 3 0 0 0 WAN
2 0.0.0.0 0.0.0.0 0.0.0.0 1 100 0 0 WAN
3 37.192.220.0 255.255.255.0 0.0.0.0 1 0 0 0 WAN
4 37.192.220.1 255.255.255.255 0.0.0.0 5 100 0 0 WAN
5 127.0.0.0 255.0.0.0 0.0.0.0 1 0 0 0 LAN
6 172.16.200.2 255.255.255.255 0.0.0.0 5 0 0 0 VPN SERVER
7 178.49.132.66 255.255.255.255 37.192.220.1 7 0 0 0 WAN
8 178.49.132.67 255.255.255.255 37.192.220.1 7 0 0 0 WAN
9 192.168.1.0 255.255.255.0 0.0.0.0 1 0 0 0 LAN
10 224.0.0.0 240.0.0.0 0.0.0.0 1 0 0 0 WAN
11 239.0.0.0 255.0.0.0 0.0.0.0 1 0 0 0 LAN[/spoiler]
Доброго времени.
Помогите, при наличии Вашего драгоценного времени, разобраться чайнику)
Вопрос по пробросу портов чз vpn.
Ситуевина следующая.
На SNR-CPE-MD1 (8.2.13.RU.07122019 ) поднят l2tp-сервер и проброшен порт на рдп для vpn-клиента.
Иногда требуется извне подключиться к этому клиенту по rdp. Т.е. ткнуться не на его адрес, а уже через ж 5.172.63.ххх:3389
И как бы возможно кто-то скажет, ерунда так не должно работать. Ыднака..
Если на актуальной проше, увы, тишина (порты не пробрасываются подобным образом).
То на давно почившей версии Wive-RTNL 4.6 это даже работает и даже без бубна.
Ниже привел Static Routing Settings, может это как-то поможет понять чего не хватает.
Цитата: sfstudio от 15/12/2019, 19:23Всё верно. В MT такая схема не пройдёт ибо по сути делаете дырку если я правильно поняло чём речь.
См и сравнивайте вывод iptables -L -v -n и iptables -L -v -n -t nat (MT/RTNL после подъёма туннеля), увидите разницу, сразу поймёте как поправить. Дело не в роутах. Пробросы и нат выполняет подсистема netfilter в ядре, а что ей делать задаётся через iptables.
Смотрите наборы правил там и сям.
Свои произвольные правила можно добавить положив скрипт с их перечнем в /etc/iptables.d и сделав оный исполняемый. Не забываем fs save && reboot для сохранения содержимого RWFS.
Ну и что бы убедиться что с роутами всё ок не лишним будет посмотреть traceroute с клиента до хоста куда цепляетесь.
P.S В ооочень редких случаях проброс может "ломаться" на L2TP/PPTP если src/dst разные и не подпадают под обработку ALG иза включенного NAT Complex/Software режима (софт оффлоад скипает часть логики conntrack собсно за счёт этого и ускоряеется, но иногда бывают побочки). Поэтому на время разборки с проблемами стоит в misc вовсе выключить NAT Offload. А вот когда уже всё настроите то вернуть назад и проветь всё ли ОК. L2TP/PPTP ускоряются исключительно софтово. Так же на работу UDP соединений влияет режим работы NAT. Full Cone/Restricted Cone (см гугл за подробностями) в некоторых случаях позволяют обойтись без ручного прокидывания порта для callback соединений сервер->клиент. Ну эт так для справки. RDP умеет юзать и TCP и UDP, поэтому поведение может отличаться.
PP.S. Я правда не очень понимаю нафига вообще все эти городушки с RDP в туннеле. Он же весь из себя и так защищённый в т.ч. SSL нынче юзать умеет. Вытащить его наружу и дело с концом. =) Для пущей безопасности зарезать доступ к нему с только нужных IP. L2TP сервер в wive-ng-rtnl/mt никакого бонуса к безопасности не даёт, т.к. не использует шифрование трафика с обычными клиентами. Т.к. винда не умеет mppe в l2tp, а wive не умеет l2tp поверх ipsec. Т.е. разницы особой нет будет rdp внутри туннеля или просто во вне торчать (разве что не будет в общем адресном пространстве светиться если туннель юзать, но вы же хотите его таки в общем адресном пространстве видеть до кучи, ещё и идя через туннель, смысл его ещё менее понятен чем использование nat loopback при возможности по нормальному разрулить в DNS по именам адреса, но эт лирика). И более правильным была бы схема выше, или вовсе какой openvpn сервер на том же сервере по которому до rdp ходите с протягиванием наружу собсно одного единственного порта этого openvpn сервера.
Всё верно. В MT такая схема не пройдёт ибо по сути делаете дырку если я правильно поняло чём речь.
См и сравнивайте вывод iptables -L -v -n и iptables -L -v -n -t nat (MT/RTNL после подъёма туннеля), увидите разницу, сразу поймёте как поправить. Дело не в роутах. Пробросы и нат выполняет подсистема netfilter в ядре, а что ей делать задаётся через iptables.
Смотрите наборы правил там и сям.
Свои произвольные правила можно добавить положив скрипт с их перечнем в /etc/iptables.d и сделав оный исполняемый. Не забываем fs save && reboot для сохранения содержимого RWFS.
Ну и что бы убедиться что с роутами всё ок не лишним будет посмотреть traceroute с клиента до хоста куда цепляетесь.
P.S В ооочень редких случаях проброс может "ломаться" на L2TP/PPTP если src/dst разные и не подпадают под обработку ALG иза включенного NAT Complex/Software режима (софт оффлоад скипает часть логики conntrack собсно за счёт этого и ускоряеется, но иногда бывают побочки). Поэтому на время разборки с проблемами стоит в misc вовсе выключить NAT Offload. А вот когда уже всё настроите то вернуть назад и проветь всё ли ОК. L2TP/PPTP ускоряются исключительно софтово. Так же на работу UDP соединений влияет режим работы NAT. Full Cone/Restricted Cone (см гугл за подробностями) в некоторых случаях позволяют обойтись без ручного прокидывания порта для callback соединений сервер->клиент. Ну эт так для справки. RDP умеет юзать и TCP и UDP, поэтому поведение может отличаться.
PP.S. Я правда не очень понимаю нафига вообще все эти городушки с RDP в туннеле. Он же весь из себя и так защищённый в т.ч. SSL нынче юзать умеет. Вытащить его наружу и дело с концом. =) Для пущей безопасности зарезать доступ к нему с только нужных IP. L2TP сервер в wive-ng-rtnl/mt никакого бонуса к безопасности не даёт, т.к. не использует шифрование трафика с обычными клиентами. Т.к. винда не умеет mppe в l2tp, а wive не умеет l2tp поверх ipsec. Т.е. разницы особой нет будет rdp внутри туннеля или просто во вне торчать (разве что не будет в общем адресном пространстве светиться если туннель юзать, но вы же хотите его таки в общем адресном пространстве видеть до кучи, ещё и идя через туннель, смысл его ещё менее понятен чем использование nat loopback при возможности по нормальному разрулить в DNS по именам адреса, но эт лирика). И более правильным была бы схема выше, или вовсе какой openvpn сервер на том же сервере по которому до rdp ходите с протягиванием наружу собсно одного единственного порта этого openvpn сервера.
Цитата: sfstudio от 15/12/2019, 19:44Да, ещё. На клиенте должен быть роут до внешнего адреса к которому цепляетсь мимо туннеля. Иначе потребуются ещё городушки с DNAT внутри сервера что бы завернуть это дело.
В общем городушки они и в африке городушки.
Для них специально оставлены хуки для исполнения своих скриптов. Ибо всего "хочу странного" в UI не предусмотреть, получиться удав скрещённый со стекловатой.
А вот через консоль с помощью RWFS можно делать что угодно. См в соседних темах были примеры и описания хуков.
Да, ещё. На клиенте должен быть роут до внешнего адреса к которому цепляетсь мимо туннеля. Иначе потребуются ещё городушки с DNAT внутри сервера что бы завернуть это дело.
В общем городушки они и в африке городушки.
Для них специально оставлены хуки для исполнения своих скриптов. Ибо всего "хочу странного" в UI не предусмотреть, получиться удав скрещённый со стекловатой.
А вот через консоль с помощью RWFS можно делать что угодно. См в соседних темах были примеры и описания хуков.
