URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 97177
[ Назад ]
Исходное сообщение
"Windows за двойным NAT, как правильно направить трафик?"
Отправлено mango , 13-Апр-18 20:27 
Всем привет.

Имеем Proxmox с внешним IP-адресом, на нём три Windows Server 2016 и FreeBSD в качестве шлюза для них (нужен для схемы GRE over IPsec). NAT (masquerade) происходит между Proxmox и FreeBSD (через iptables) и между FreeBSD и серверами на Windows (через pf). Пакетные фильтры пока выключены в обоих роутерах, роутинг включен.

Проблема в том, что у FreeBSD никаких проблем, через NAT поднимаются даже GRE с IPsec'ом, а с Windows проходит только пинг. То есть пингануть 8.8.8.8 я могу, а получить от него DNS-ответ - нет; пинг до другого сервера за удалённым шлюзом ходит, RDP - нет.

Что интересно, tcpdump внешнего интерфейса на Proxmox'е показывает, что запросы от FreeBSD уходят с внешним source IP, а такие же запросы от Windows - с внутренним, который отнатился один раз, т. е. как будто второй NAT не происходит. Интересно, что даже внутри GRE-туннеля, когда натятся уже пакеты GRE, Windows терпит крах.

Где может быть проблема? В iptables банальный postrouting masquerade, основанный на source IP, на FreeBSD просто nat on wan all -> wan. Может быть, я дико туплю и не вижу чего-то очевидного или просто недостаточно глубоко знаю технологии.
Спасибо.

P. S.

Вывод tcpdump: первые 8 строк это, очевидно, пинги, последние 5 - nslookup ya.ru 8.8.8.8, всё с сервера Windows. Очень странно.

~# tcpdump -n host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:25:40.687072 IP x.x.203.43 > 8.8.8.8: ICMP echo request, id 4854, seq 74, length 40
18:25:40.715676 IP 8.8.8.8 > x.x.203.43: ICMP echo reply, id 4854, seq 74, length 40
18:25:41.695257 IP x.x.203.43 > 8.8.8.8: ICMP echo request, id 4854, seq 75, length 40
18:25:41.723833 IP 8.8.8.8 > x.x.203.43: ICMP echo reply, id 4854, seq 75, length 40
18:25:42.710761 IP x.x.203.43 > 8.8.8.8: ICMP echo request, id 4854, seq 76, length 40
18:25:42.739347 IP 8.8.8.8 > x.x.203.43: ICMP echo reply, id 4854, seq 76, length 40
18:25:43.726352 IP x.x.203.43 > 8.8.8.8: ICMP echo request, id 4854, seq 77, length 40
18:25:43.754949 IP 8.8.8.8 > x.x.203.43: ICMP echo reply, id 4854, seq 77, length 40
18:26:06.450895 IP 10.6.100.2.56611 > 8.8.8.8.53: 1+ PTR? 8.8.8.8.in-addr.arpa. (38)
18:26:08.462490 IP 10.6.100.2.58269 > 8.8.8.8.53: 2+ A? ya.ru. (23)
18:26:10.462353 IP 10.6.100.2.65350 > 8.8.8.8.53: 3+ AAAA? ya.ru. (23)
18:26:12.477537 IP 10.6.100.2.55766 > 8.8.8.8.53: 4+ A? ya.ru. (23)
18:26:14.494460 IP 10.6.100.2.60016 > 8.8.8.8.53: 5+ AAAA? ya.ru. (23)

Вывод таблицы NAT iptables на Proxmox'е:

~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             tcp dpt:ssh to:10.6.100.2

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.6.100.0/30        anywhere


10.6.100.0/30 - это сеть между FreeBSD и Proxmox'ом.

Содержание
Сообщения в этом обсуждении
"Windows за двойным NAT, как правильно направить трафик?"
Отправлено aaa , 14-Апр-18 17:36 
>[оверквотинг удален]
>           destination
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source    
>           destination
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source    
>           destination
> MASQUERADE  all  --  10.6.100.0/30      
>   anywhere
> 10.6.100.0/30 - это сеть между FreeBSD и Proxmox'ом.

Сделать iptables -t nat -I POSTROUTING -j MASQUERADE
и смотреть почему FreeBSD не натить

"Windows за двойным NAT, как правильно направить трафик?"
Отправлено mango , 14-Апр-18 21:03 
>[оверквотинг удален]
>> target     prot opt source
>>           destination
>> Chain POSTROUTING (policy ACCEPT)
>> target     prot opt source
>>           destination
>> MASQUERADE  all  --  10.6.100.0/30
>>   anywhere
>> 10.6.100.0/30 - это сеть между FreeBSD и Proxmox'ом.
> Сделать iptables -t nat -I POSTROUTING -j MASQUERADE
> и смотреть почему FreeBSD не натить

Но маскарад и так включён. FreeBSD как раз натит, с неё запрос улетает с src=10.6.100.2, это её внешний адрес. Странно, что с этим адресом он и уходит в интернет с Proxmox'а, хотя включен маскарад этой сети.

"Windows за двойным NAT, как правильно направить трафик?"
Отправлено artemrts , 15-Апр-18 15:10 
>[оверквотинг удален]
>>> target     prot opt source
>>>           destination
>>> Chain POSTROUTING (policy ACCEPT)
>>> target     prot opt source
>>>           destination
>>> MASQUERADE  all  --  10.6.100.0/30
>>>   anywhere
>>> 10.6.100.0/30 - это сеть между FreeBSD и Proxmox'ом.
>> Сделать iptables -t nat -I POSTROUTING -j MASQUERADE
>> и смотреть почему FreeBSD не натить

Если не изменяет память у pf есть проблемы с nat'ом gre. Погуглите или попробуйте nat через ipfw.

"Windows за двойным NAT, как правильно направить трафик?"
Отправлено mango , 15-Апр-18 15:59 
>[оверквотинг удален]
>>>> Chain POSTROUTING (policy ACCEPT)
>>>> target     prot opt source
>>>>           destination
>>>> MASQUERADE  all  --  10.6.100.0/30
>>>>   anywhere
>>>> 10.6.100.0/30 - это сеть между FreeBSD и Proxmox'ом.
>>> Сделать iptables -t nat -I POSTROUTING -j MASQUERADE
>>> и смотреть почему FreeBSD не натить
> Если не изменяет память у pf есть проблемы с nat'ом gre. Погуглите
> или попробуйте nat через ipfw.

Я, может, плохо объяснил. FreeBSD с pf сидит на сером адресе и сама генерирует GRE, а натит его уже шлюз с iptables, у которого как раз белый IP, причём нормально в целом натит, соединение устанавливается, пингуется второй конец туннеля. Но любой трафик, который отнатился pf и должен натиться второй раз в iptables, почему-то ходит выборочно, TCP и UDP не работают, в интернет уходит серый source-адрес, ICMP (пинги) при этом натятся и уходят с белым адресом, что видно в выводе tcpdump. В этом и странность.

"Windows за двойным NAT, как правильно направить трафик?"
Отправлено aaa , 16-Апр-18 15:22 
>[оверквотинг удален]
>> Если не изменяет память у pf есть проблемы с nat'ом gre. Погуглите
>> или попробуйте nat через ipfw.
> Я, может, плохо объяснил. FreeBSD с pf сидит на сером адресе и
> сама генерирует GRE, а натит его уже шлюз с iptables, у
> которого как раз белый IP, причём нормально в целом натит, соединение
> устанавливается, пингуется второй конец туннеля. Но любой трафик, который отнатился pf
> и должен натиться второй раз в iptables, почему-то ходит выборочно, TCP
> и UDP не работают, в интернет уходит серый source-адрес, ICMP (пинги)
> при этом натятся и уходят с белым адресом, что видно в
> выводе tcpdump. В этом и странность.

Таблица nat не для фильтрации пакетов. Делайте как написал: iptables -t nat -I POSTROUTING -j MASQUERADE -- т.е. всё что летит от Вас к провайдеру это от вашего ип. Фильтрацию делайте в таблице filter. Т.е. добавить полиси дроп и вашу подсеть. iptables -P FORWARD -j DROP и iptables -I FORWARD -s 10.6.100.0/30 -j ACCEPT и iptables -I FORWARD -d 10.6.100.0/30 -j ACCEPT.
Дальше tcpdump'ом изучайте пакеты.

"Windows за двойным NAT, как правильно направить трафик?"
Отправлено mango , 16-Апр-18 21:48 
>[оверквотинг удален]
>> и UDP не работают, в интернет уходит серый source-адрес, ICMP (пинги)
>> при этом натятся и уходят с белым адресом, что видно в
>> выводе tcpdump. В этом и странность.
> Таблица nat не для фильтрации пакетов. Делайте как написал: iptables -t nat
> -I POSTROUTING -j MASQUERADE -- т.е. всё что летит от Вас
> к провайдеру это от вашего ип. Фильтрацию делайте в таблице filter.
> Т.е. добавить полиси дроп и вашу подсеть. iptables -P FORWARD -j
> DROP и iptables -I FORWARD -s 10.6.100.0/30 -j ACCEPT и iptables
> -I FORWARD -d 10.6.100.0/30 -j ACCEPT.
> Дальше tcpdump'ом изучайте пакеты.

Спасибо за попытку помочь, но я отлично знаю, для чего нужны таблица nat, таблица filter и таблица mangle. Несколько раз писал, что маскарадинг включён, в нужную сторону, фильтрацию не включал вообще, чтобы не мешало, политики были все ACCEPT. И FreeBSD с pf отлично натил пакеты, которые я и ловил tcpdump'ом на интерфейсах следующего за ним шлюза с нужным адресом; и результат этого отлова я выложил выше.

Но более это не актуально, а ведь я уже даже настраивал белый адрес на FreeBSD (провайдер выдал), не работало даже так, хотя теперь в инет безответно уходили виндовые пакеты с белым source-адресом. Сброс конфига в ноль не помог, зато помогла чистая установка, а единственное отличие от прошлой в том, что сетевые карты не virtio, а Intel E1000. Работает как часы. Что мешало так же работать в прошлый раз - загадка, т. к. настройка абсолютно аналогичная, только на этот раз не одним махом, а очень осторожная, с проверкой на каждом шагу.

Ради эксперимента в качестве шлюза на том же гипервизоре с тем же белым адресом и virtio-картами пробовал Debian - пошло сразу как надо.