The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Не работает tcp в pptp-туннеле после nat"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Маршрутизация, NAT / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"Не работает tcp в pptp-туннеле после nat"  +/
Сообщение от kapunov81email (?), 06-Июл-21, 14:06 
Итак, на хосте есть две клетки, одна vpn (mpd5) с адресом 192.168.1.9, другая mail с адресом 192.168.1.4
К vpn-клетке через pptp подключается клиент, получающий адрес 192.168.0.130. Для того, чтобы он мог ходить по внутренним адресам 192.168.1.0/24, на хосте добавлено правило route add 192.168.0.0/24 192.168.1.9. На этом этапе все ок, win-клиент подключается по pptp к vpn-серверу, и имеет доступ к внутренней сети - нормально отрабатывают и udp (ping 192.168.1.4) и tcp (curl 192.168.1.4).
Поскольку идея состоит в том, чтобы пускать клиента напрямую в Инет (чертовы видеоконференции не работают нормально через прокси), то без nat не обойтись, и я моделирую ситуацию с nat-ом наружу - включаю ipfw kernel nat на vpn-сервере (eth1=192.168.1.9):

ipfw -q nat 1 config if eth1 reset
#NAT для входящих пакетов
ipfw -q add 00002 nat 1 ip4 from any to any in recv eth1
ipfw -q add 00010 check-state
ipfw add 00290 allow ip from any to any via lo0
#NAT для исходящих пакетов
ipfw -q add 00800 nat 1 ip4 from any to any out xmit eth1
#открываем все
ipfw add 00900 allow ip from any to any

Такая конфигурация nat точно рабочая, и на хосте подобный вариант пускает нужные клетки напрямую в Инет через белый ip. Теперь пакеты от клиента натятся внутренним адресом vpn-сервера и к 192.168.1.4 приходят будто-бы от 192.168.1.9. UDP-протокол работает без проблем, пинг отрабатывает, а вот tcp работать после nat не хочет. При этом пакеты ходят в обе стороны, но на клиенте команда curl 192.168.1.4 не выдает ответ, будто-бы сервер не отвечает, хотя tcpdump на крайнем к клиенту интерфейсе ng0 (создается при подключении) показывает что пакеты клиенту идут.
Подскажите, в чем заключается проблема? Я предполагаю, что pptp-туннель, после того как в его пакетах поковырялся nat, отказывается признавать приходящие пакеты своими, но что-то никак не найду схожий вариант с решением.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Pahanivo пробегал (?), 06-Июл-21, 23:14   +/
Хм. Нихрена не понятно.
НАН на приватном интерфейсе?
Зачем в фаере чек стейт без кипа?
То про eth1, то про ng0.
И шо за манера вместо текущих правил выкидывать командник их создания?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от kapunov81email (?), 07-Июл-21, 08:03   +/
> Хм. Нихрена не понятно.
> НАН на приватном интерфейсе?
> Зачем в фаере чек стейт без кипа?
> То про eth1, то про ng0.
> И шо за манера вместо текущих правил выкидывать командник их создания?

По порядку.
"НАН на приватном интерфейсе?" - В итоге nat будет работать наружу в Инет с белого ip. Т.к. у vpn-клиента не работает tcp через nat, то для нахождения проблемы я смоделировал ситуацию с nat-ом на приватном интерфейсе - на нем я могу пускать клиента ко внутренним адресам и через nat, и без него, а также слушать tcpdump-ом на интерфейсе сервера к которому обращается клиент. Я убедился, что проблема именно в нате - без него работают и tcp и udp. Только включаешь nat для трафика pptp-клиента (кстати, пробовал и с L2TP/IPSEC), как tcp перестает работать в отличие от udp, пинг на стороне клиента продолжает работать.
"Зачем в фаере чек стейт без кипа?" & "И шо за манера вместо текущих правил выкидывать командник их создания?" - nat делал по методичке https://forums.freebsd.org/threads/ipfw-share-internet.62149/, удаляя все что мне было не нужно. Насчет чек-стейта у меня уверенности не было, и я его оставил, он ведь не мешает? В этой же методичке все листинги настроек ipfw выложены именно как команды создания, если уж на официальном форуме Фряхи это не считается плохим тоном, то и здесь можно так поступать.
"То про eth1, то про ng0" - ng0 я упомянул только в том контексте, что это крайний к клиенту интерфейс у vpn-сервера, создающийся динамически при создании туннеля, и я убедился, что tcp-пакеты идут к клиенту через этот интерфейс, т.е. проблема не в маршрутизации.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от BarS (??), 07-Июл-21, 11:30   –1 +/
подключи модули ppptp_nat и другие, инет в руки
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от Ann None (?), 07-Июл-21, 12:23   +/
когда я последний раз подобное смотрел у меня tcp на связке jail+ipfw nat не заработал. перенес nat в pf и забил.
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от butcher (ok), 11-Авг-21, 15:29   +/
> клетки напрямую в Инет через белый ip. Теперь пакеты от клиента
> натятся внутренним адресом vpn-сервера и к 192.168.1.4 приходят будто-бы от 192.168.1.9.
> UDP-протокол работает без проблем, пинг отрабатывает, а вот tcp работать после
> nat не хочет. При этом пакеты ходят в обе стороны, но
> на клиенте команда curl 192.168.1.4 не выдает ответ, будто-бы сервер не
> отвечает, хотя tcpdump на крайнем к клиенту интерфейсе ng0 (создается при
> подключении) показывает что пакеты клиенту идут.

Выглядит так, что вы забыли выключить TSO на eth1.

Ответить | Правка | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру