Как отключить правило маскарадинга NAT на UDM Pro, чтобы сохранять исходный IP-адрес при использовании прокси-сервера?

RSS

Как отключить правило маскарадинга NAT на UDM Pro, чтобы сохранять исходный IP-адрес при использовании прокси-сервера?, wifiman

axelpichon

Guest

28.10.2023 10:46:00

Всем привет! У меня проблема с UDM Pro при использовании проброса портов на прокси-сервер. Все подключения через этот проброс показывают внутренний IP-адрес UDM Pro, а не внешний IP-адрес клиента, как обычно ожидалось бы.

Погуглив, я нашёл похожую ситуацию, когда кто-то решил проблему, отключив правило NAT masquerade на интерфейсе br0 в UDM Pro. Вот что он сказал:
«В конце концов я понял, в чём дело, после экспериментов. Оказывается, UBNT ставит правило masquerade на мостовом интерфейсе (который внутренний), поэтому любой пакет, проходящий через него, получает переписанный исходный IP, будто он исходит с IP адреса br0.»

Сейчас я подключён по SSH к своему UDM Pro и хочу понять, как отключить это правило post-routing, чтобы прокси-сервер видел настоящий IP клиента, который к нему подключается.

Заранее спасибо за помощь!

kkingsto Guest	#2 26.04.2024 21:26:00 Невозможно отключить NAT на UDM.

Vigni Guest	#3 26.04.2024 21:09:00 Ты нашёл решение?

BlackThorneDK

Guest

12.10.2024 20:00:00

Даже при отключённом Global NAT мой туннель WireGuard всё равно маскирует пакеты. Я не хочу прокладывать весь трафик через WireGuard, только несколько выбранных CIDR-диапазонов центрального UDM.

Моя настройка:

UDM SE в «центральном офисе»:
WireGuard сервер с публичным IP a.b.c.d
WireGuard сервер работает в диапазоне: 172.31.42.0/24 — шлюз: 172.31.42.1
UDM SE имеет 2 VLAN в «центральном офисе»: 172.16.10.0/24 и 172.16.20.0/24

UDM Pro в «филиале»
WireGuard клиент, за CNAT — публичный IP и dyndns невозможны, что исключает вариант IPSec Site2Site. По сути, клиент может быть и мобильным.

IP WireGuard клиента: 172.31.42.2 — туннель с этой стороны уже работает.
Дополнительные VLAN в «филиале»: 192.168.10.0/24 и 192.168.11.0/24

Пинг с 192.168.10.10 на 172.16.10.4 показывает, что исходный IP переписывается в 172.31.42.2 — подтверждено с помощью TCP Dump.

Пинг с 172.16.10.4 на 192.168.10.10 невозможен из-за правил маскарадинга на UDM Pro в филиале.

Я достаточно покопался через SSH на UDM Pro, и действительно цепочка UBIOS_POSTROUTING_USER_HOOK в таблице iptables nat содержит стандартные правила маскарадинга для eth7, eth8 и wgclt+ (wan2, wan1 и интерфейс WireGuard соответственно).

Кроме того, похоже, что отключение global nat лишь добавляет правило перед стандартными маскарадинговыми правилами, которое совпадает с ipset под названием UBIOS_skip_nat_subnets и выходит из цепочки UBIOS_POSTROUTING_USER_HOOK.

Логично, что туннель должен перестать маскировать, если это правило вставляется при отключении global nat. Но в tcpdump на 172.16.10.4 я всё равно вижу исходящий IP 172.31.42.2.

Кто-нибудь сталкивался с похожим? Удавалось ли отключить маскарадинг на интерфейсе WireGuard клиента?

stephan-storm Guest	#5 10.07.2024 17:42:00 Это неправильно! UDM Pro подменяет пакеты! Исходный IP-адрес заменяется на IP UDM. Пожалуйста, предложите решение!

thebenhatfield Guest	#6 27.04.2024 12:45:00 Понимаю, что оригинальный пост уже довольно старый, но если у кого-то ещё возникнет такая проблема... сложно сказать что-то конкретное без подробностей о настройках и конфигурации железа и софта, но это звучит немного странно. Я предполагаю, что речь идёт именно о реверс-прокси, который используется для размещения сайтов или других сервисов внутри сети, и при этом хочется видеть внешний IP клиента. Если это так, то никаких особых настроек или удаления уже существующих правил на UDM не требуется, кроме проброса портов на сервер реверс-прокси. У меня в настройке из ONT провайдера идёт CAT6 прямо в WAN-порт моего UDMSE. С UDMSE настроен проброс портов на сервер реверс-прокси (у меня traefik), и я абсолютно нормально получаю правильные внешние IP клиентов в запросах к внутренним сервисам и могу их применять по назначению, например, чтобы определить, нужно ли клиенту проходить авторизацию перед ответом — всё работает отлично. Если у вас не так, скорее всего, у вас двойной NAT или просто прокси-сервер неправильно настроен. Попробуйте убрать двойной NAT, если он есть (например, поставить модем/роутер провайдера в режим моста, обойти его или режим пасстру), а также перепроверьте настройки прокси, чтобы он правильно выставлял заголовки с внешним IP клиента, который к вам подключается. И не забудьте, что внутренние сервисы за прокси должны использовать правильные заголовки для получения IP клиента.

Читают тему (гостей: 1)