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

"Не работает tcp в pptp-туннеле после nat"	+/–
Сообщение от kapunov81 (?), 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. "Не работает tcp в pptp-туннеле после nat"	+/–
Сообщение от Pahanivo пробегал (?), 06-Июл-21, 23:14
Хм. Нихрена не понятно. НАН на приватном интерфейсе? Зачем в фаере чек стейт без кипа? То про eth1, то про ng0. И шо за манера вместо текущих правил выкидывать командник их создания?
Ответить | Правка | Наверх | Cообщить модератору

	2. "Не работает tcp в pptp-туннеле после nat"	+/–
	Сообщение от kapunov81 (?), 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ообщить модератору

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

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

5. "Не работает tcp в pptp-туннеле после nat"	+/–
Сообщение от 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 | Индекс форумов | Темы | Пред. тема | След. тема