Двойной WAN с маршрутизацией на основе политик, DNS на WAN2 отсутствует.

Двойной WAN с маршрутизацией на основе политик, DNS на WAN2 отсутствует., UniFi Network

Qlii256

Guest

21.04.2025 14:36:00

У меня между модемом провайдера и шлюзом (UXG-Fiber) не управляемый коммутатор. К шлюзу подключены два ethernet-кабеля от этого коммутатора, и я настроил интерфейсы WAN и WAN2 на подключенных портах. Я получаю два публичных IPv4-адреса от провайдера, и оба интерфейса WAN и WAN2 подключены. Я установил DNS-серверы как 1.1.1.1 и 1.0.0.1 как для WAN, так и для WAN2, и интерфейсы работают в режиме переключения при отказе, потому что это один и тот же модем/провайдер. Я создал маршрут на основе политики, который направляет весь трафик с источника, одного клиента, через интерфейс WAN2 на основе MAC-адреса. Это, похоже, работает, потому что этот конкретный клиент теперь использует публичный IPv4-адрес интерфейса WAN2. Но вскоре я перестал иметь возможность открывать веб-сайты, и выяснилось, что DNS-сервер не работает. Когда я вручную назначаю DNS-сервер на клиенте, например 1.1.1.1, он работает. Но когда я использую шлюз, 192.168.60.1 (vlan 60), он перестает работать. Является ли это известной проблемой? Возможно, я что-то делаю не так с правилами? Я использую межсетевой экран на основе зон, и там точно есть правило разрешения DNS от моей зоны vlan 60 к зоне шлюза. Нужно ли это настроить по-другому, чтобы конкретный клиент и/или сеть (vlan) использовал интерфейс WAN2 вместо интерфейса WAN?

Имя сервера: 192.168.1.60 или 192.168.1.1> dig google.com

;; communications error to 127.0.0.53#53: таймаут
;; communications error to 127.0.0.53#53: таймаут
;; communications error to 127.0.0.53#53: таймаут

; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Не удалось связаться ни с одним сервером

Имя сервера: 1.1.1.1 или 8.8.8.8> dig google.com

; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56178
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.          IN   A

;; ANSWER SECTION:
google.com.       69   IN   A    64.233.167.139
google.com.       69   IN   A    64.233.167.138
google.com.       69   IN   A    64.233.167.101
google.com.       69   IN   A    64.233.167.113
google.com.       69   IN   A    64.233.167.100
google.com.       69   IN   A    64.233.167.102

;; Query time: 0 мс
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Пн Апр 21 14:53:03 UTC 2025
;; MSG SIZE rcvd: 135
Я попробовал добавить правило межсетевого экрана, чтобы разрешить клиенту иметь полный доступ к внешней зоне, но результат тот же.

Qlii256

Guest

02.05.2025 17:21:00

Вот два скриншота: один для маршрутизации на основе политик, которая направляет трафик с моей сети (VLAN) с именем Dito на WAN2. Второй скриншот показывает правило брандмауэра, которое я создал для порта 20202 и 20203 (WAN2 и WAN3) из зоны брандмауэра DMZ в шлюз. Ниже правило брандмауэра "Разрешить DNS", которое создано по умолчанию, что явно неправильно (порт 53).

Упоминаю @UI-Glenn, чтобы привлечь внимание. Нам/нам нужно разъяснение, является ли такое поведение желательным или это ошибка/баг.

deniciomariz Guest	#3 02.05.2025 13:47:00 Поздравляю с информацией. 👏 Пожалуйста, выложи фотографии настроек. Заранее спасибо. 🤝 Денисиу (Бразилия)

OlivierP

Guest

02.05.2025 11:18:00

Привет, довольно интересно, спасибо! Может, попробуй отмечать UI Glenn или Team в своих комментариях и добавить файл поддержки к этому (если еще не добавил), они всегда просят его. Полагаю, ты также можешь связаться с поддержкой.

Qlii256

Guest

26.04.2025 13:40:00

Если ты прочитаешь мой пост, то увидишь мою проблему. Как только я начал использовать маршрутизацию на основе политик, чтобы направлять весь трафик определенной сети (vlan) через WANx (где x — это номер одного из моих множества WAN), устройства в этой сети могут пинговать IP-адреса и имеют рабочий интернет, и маршрутизируются через правильный WAN-интерфейс. Но они не могут заходить на сайты, используя доменные имена. Кажется, что DNS перестает работать. Когда я ставлю вручную DNS-сервер, отличный от IP-адреса шлюза, всё начинает работать. Так что очевидно, что что-то не так, когда маршрутизация идет через WAN-интерфейс, отличный от первого, потому что запросы DNS к шлюзу не проходят. Когда смотрю в логах (Flows), вижу, что клиенты пытаются связаться со шлюзом на порту 2020x, где x снова является номером приоритета WAN. В моем случае это 20202 (2-й WAN). И в логах указано, что это правило блокировки всего трафика из DMZ в зону шлюза. Как только я разрешаю порт 20202 из DMZ в зону шлюза, клиенты в этой сети, которые маршрутизируются через WAN2, работают без проблем, они снова могут заходить на сайты (DNS-шлюз доступен). Я знаю, что это потому, что правило блокировки всего трафика блокирует весь трафик из DMZ в зону шлюза. Но мой вопрос в том, почему оно использует порт 20202 и теперь "по умолчанию" порт 53 для DNS-запросов? У него даже есть правило для этого из DMZ в зону шлюза под названием Allow DNS... Так что я думаю, что, возможно, это баг, потому что нигде на сайтах Unifi не указано, что порт 2020x используется для чего-то.

Qlii256

Guest

26.04.2025 09:30:00

Обновлений нет? Надеюсь, кто-нибудь из Ubiquiti увидит это, потому что это похоже на ошибку с (зонированным) файрволом. Чтобы всё было понятно: Multi-WAN заставляет клиентов пытаться подключиться к шлюзу на порту 2020x, где x — номер WAN (порта/приоритета). По умолчанию это блокируется, и как только я разрешаю этот порт с сетей, которые я размещаю на WAN x посредством политически-ориентированной маршрутизации, DNS для устройств в сети снова начинает работать.

Qlii256 Guest	#7 21.04.2025 17:25:00 Я умудрился "починить" это. Я пытался добавить мой основной компьютер, находящийся в сети по умолчанию, в зону Internal, к WAN2 с использованием маршрутизации на основе политик. И вот, получилось. Я был в замешательстве. Так что я был почти уверен, что дело в файрволе. Я создал новую зону и добавил в нее одно устройство. У меня было правило блокировки всего трафика из этой зоны в зону шлюза, кроме DNS и DNS-TLS. Тем не менее, это не сработало, но, просматривая потоки, я смог заметить это заблокированное действие, установленное моим правилом блокировки всего трафика, которое не видно для стандартных правил в зонах по умолчанию (не знаю почему?). И там я увидел, что устройство пытается получить доступ к моему шлюзу на порту 20202. Я не смог найти, что это за порт, но, разрешив этот порт в зоне, где находится мое устройство WAN2, в зону шлюза, оно "волшебным образом" заработало. Кажется, оно пытается получить доступ к DNS-серверу на порту 20202, что довольно странно. Есть какие-нибудь идеи, что это может быть? Надеюсь, кто-то из Ubiquity сможет посмотреть на это. ДОБАВЛЕНО: Немного больше информации. Мне удалось подключить третий WAN (используя новейший Network Controller 9.1.118), и клиенты на WAN3 столкнулись с той же проблемой. Опять же, я создал правило блокировки всего трафика, и в Flows я обнаружил, что клиент теперь пытается связаться с шлюзом на порту 20203. Кажется, последний номер увеличился с номером WAN (20203 ↔ WAN3). После изменения политики с разрешения только порта 20202 в шлюз я теперь установил его на 20202-20203, и это работает. Это должно быть какая-то внутренняя структура Unifi Gateway, но порт не указан как какой-либо внутренне используемый порт на сайте Unifi.

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