forum.opennet.ru - "Windows за двойным NAT, как правильно направить трафик?" (6)

"Windows за двойным NAT, как правильно направить трафик?"

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

"Windows за двойным NAT, как правильно направить трафик?"	+/–
Сообщение от mango (ok) on 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'ом.
Ответить \| Правка \| Cообщить модератору

Оглавление

Windows за двойным NAT, как правильно направить трафик?, aaa, 17:36 , 14-Апр-18, (1)

Windows за двойным NAT, как правильно направить трафик?, mango, 21:03 , 14-Апр-18, (2)

Windows за двойным NAT, как правильно направить трафик?, artemrts, 15:10 , 15-Апр-18, (3)

Windows за двойным NAT, как правильно направить трафик?, mango, 15:59 , 15-Апр-18, (4)

Windows за двойным NAT, как правильно направить трафик?, aaa, 15:22 , 16-Апр-18, (5)

Windows за двойным NAT, как правильно направить трафик?, mango, 21:48 , 16-Апр-18, (6)

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

1. "Windows за двойным NAT, как правильно направить трафик?" +/–

Сообщение от aaa (??) on 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 не натить

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

2. "Windows за двойным NAT, как правильно направить трафик?" +/–

Сообщение от mango (ok) on 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'а, хотя включен маскарад этой сети.

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

3. "Windows за двойным NAT, как правильно направить трафик?" +/–

Сообщение от artemrts (ok) on 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.

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

4. "Windows за двойным NAT, как правильно направить трафик?" +/–

Сообщение от mango (ok) on 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. В этом и странность.

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

5. "Windows за двойным NAT, как правильно направить трафик?" +/–

Сообщение от aaa (??) on 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'ом изучайте пакеты.

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

6. "Windows за двойным NAT, как правильно направить трафик?" +/–

Сообщение от mango (ok) on 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 - пошло сразу как надо.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Windows за двойным NAT, как правильно направить трафик?"	+/–
Сообщение от aaa (??) on 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 не натить
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Windows за двойным NAT, как правильно направить трафик?"	+/–
	Сообщение от mango (ok) on 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'а, хотя включен маскарад этой сети.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Windows за двойным NAT, как правильно направить трафик?"	+/–
	Сообщение от artemrts (ok) on 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.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "Windows за двойным NAT, как правильно направить трафик?"	+/–
	Сообщение от mango (ok) on 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. В этом и странность.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "Windows за двойным NAT, как правильно направить трафик?"	+/–
	Сообщение от aaa (??) on 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'ом изучайте пакеты.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "Windows за двойным NAT, как правильно направить трафик?"	+/–
	Сообщение от mango (ok) on 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 - пошло сразу как надо.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору