Итак, на хосте есть две клетки, одна 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, отказывается признавать приходящие пакеты своими, но что-то никак не найду схожий вариант с решением.
|
