USG Pro: отключение маршрутизации между VLAN

USG Pro: отключение маршрутизации между VLAN, UniFi Network

mheagerty

Guest

14.06.2017 07:29:00

Привет, я недавно настроил свой офис с Usg Pro 4, двумя Unifi AC Pros и коммутатором usg. Все устройства подключены к моему Unifi Controller в AWS (v5.5.11).

Я настроил VLANы следующим образом:
Vlan1 (управление): 192.168.1.0/24
Vlan10: 192.168.2.0/24
Vlan20: 192.168.3.0/24
Vlan30: 192.168.4.0/24

VLANы и назначенные сети работают нормально, но все устройства могут видеть друг друга между VLANами, а это нехорошо!
Думаю, это связано со стандартными настройками или правилами файрвола на роутере USG.

Можно ли отключить маршрутизацию между VLANами через интерфейс контроллера или по SSH?
Я искал на форумах и нашел статьи, которые предлагают использовать правила файрвола, но это не совсем обычная практика при настройке роутера с VLANами.
Кстати, в интерфейсе контроллера, похоже, нельзя изменить приоритет правил файрвола.

Прошу помощи.
С уважением, Майк

digeratiab

Guest

11.10.2018 13:53:00

Думаю, проблема решена. У меня был компьютер в каждой сети, которые постоянно пинговали друг друга. Пока пинг работал, соединение было активно, но когда я приостановил пинг на минуту (30 секунд оказалось недостаточно), всё стало работать как надо. Я думал, что каждый пинг — это отдельное состояние, но, похоже, файрвол как-то запоминает соединения между пингами.

UI-Team

Guest

09.10.2018 15:58:00

Я только что проверил это в своей лаборатории, и всё работает как надо. Можешь сделать скриншот и показать свои две правила, чтобы я мог посмотреть? Интересно, не выбрал ли ты источник/назначение для правила «allow» (established/related).

digeratiab

Guest

09.10.2018 11:09:00

@UBNT-jaffe

Спасибо за ответ. Нет, выбран пункт «Все». Как я и писал, опция 1 «Блокировать правило» работает нормально, она блокирует все в обоих направлениях. Но когда я добавляю опцию 3 «Разрешить правило», начинаются странности. Я трижды проверял настройки, и они точно такие же, как в статье. Я только что попробовал поменять правило блокировки, поменяв местами исходную и целевую сеть — работает как ожидалось: http и rdp блокируются и разрешаются в обратном направлении, но пинг всё равно проходит в обе стороны.

UI-Team Guest	#5 09.10.2018 01:52:00 @digeratiab В твоём правиле блокировки ты выбрал только tcp/udp? Пинг использует ICMP, поэтому для его блокировки нужно выбрать опцию «all» для протокола.

digeratiab

Guest

08.10.2018 13:51:00

Что касается этой статьи https://help.ubnt.com/hc/en-us/articles/115010254227-UniFi-How-to-Disable-InterVLAN-Routing-on-the-U... Я протестировал первый вариант, который работает, как описано — блокирует трафик между LAN и VLAN в обе стороны. Затем я добавил третий вариант, чтобы разрешить доступ VLAN к LAN, при этом LAN к VLAN должен оставаться заблокированным. Это работает для обычного трафика вроде http и rdp, но почему-то теперь можно пинговать в обе стороны. VLAN -> LAN: http, rdp и пинг работают. LAN -> VLAN: http и rdp блокируются, а пинг работает. Контроллер и USG обновлены до версий 5.9.29 и 4.4.29.5124210. Это баг, фича или я что-то пропустил?

iccctr

Guest

23.04.2018 02:04:00

Я наткнулся на твою тему, когда искал то же самое, и нашёл вот это, что решило мою проблему: https://www.mcbsys.com/blog/2017/11/control-inter-vlan-communication-with-the-unifi-usg-firewall/
Блокировать весь трафик между VLAN с исключениями.

Мне показалось, что статья выше больше подходит под мои задачи, чем база знаний UniFi: https://help.ubnt.com/hc/en-us/articles/115010254227-UniFi-How-to-Disable-InterVLAN-Routing-on-the-UniFi-USG
Однако в базе знаний есть важное уточнение (я думал, что новые правила не работают, чуть не с ума сошёл, пока не прочитал следующее. После перезагрузки USG всё заработало как надо.):

При добавлении новых правил нужно учитывать, что они не вступают сразу в силу для уже существующих stateful-соединений. Чтобы решить это, сделай один из следующих вариантов:
- Подожди, пока состояния истекут (закрой все соединения и подожди таймаут, примерно 30 секунд)
- Подключись по SSH к USG и введи clear connection-tracking. Это очистит всю таблицу состояния USG
- Перезагрузи USG

UI-Team Guest	#8 21.03.2018 16:16:00 @Kruppus https://help.ubnt.com/hc/en-us/articles/115003173168-UniFi-Introduction-to-USG-Firewall-Rules На самом деле я недавно обновил эту статью, в ней объясняется локальный набор правил.

UI-Team Guest	#9 20.03.2018 14:34:00 На самом деле, я не думаю, что включил объяснения местных правил в ту статью, возможно, мне стоит добавить их.

Kruppus Guest	#10 20.03.2018 13:40:00 Я нашёл решение своего вопроса: https://community.ui.com/questions/08e70505-c4f0-4630-947f-8a956b06742a Просто добавил правила в разделы LAN Local и Guest Local.

UI-Team Guest	#11 19.03.2018 19:40:00 https://help.ubnt.com/hc/en-us/articles/115010254227-UniFi-How-to-Disable-InterVLAN-Routing-on-the-UniFi-USG

Kruppus

Guest

#12

19.03.2018 19:00:00

Я следил за разговором и наконец-то всё заработало. Мои корпоративные сети теперь разделены. Мой USG имеет стандартный IP 192.168.1.1. А теперь я хочу запретить всем остальным корпоративным сетям доступ к веб-интерфейсу USG. Например, когда я в корпоративной сети 50.50.50.0/24, я могу зайти на USG по IP 50.50.50.1. Я хочу запретить всем корпоративным сетям, кроме 192.168.1.0/24, доступ к USG через X.X.X.1 (например, 50.50.50.1). Спасибо за совет!

UI-Team

Guest

#13

12.07.2017 16:33:00

Без включённых политик гостя на SSID я не могу придумать ничего, что могло бы заставить точку доступа блокировать трафик. Вы пробовали проверять связь между другими устройствами по беспроводной сети в той же подсети? На этом этапе я бы сделал tcpdump или wireshark прямо на клиентах, чтобы понять, доходит ли трафик до назначения или нет. Как вы вообще тестируете? По TCP-портам? ICMP?

dlow Guest	#14 11.07.2017 23:56:00 Ты пробовал эти шаги для отладки? Видишь ли какие-нибудь сообщения об отказе фаервола при использовании AP?

mheagerty Guest	#15 11.07.2017 22:47:00 Привет, Jaffe! Нет, у меня на SSID нет никаких гостевых политик. Что ещё может вызывать эту проблему? Заранее спасибо!

UI-Team

Guest

#16

11.07.2017 15:40:00

@mheagerty

У тебя в проблемном SSID включена опция «apply guest policies»? Если да, то в настройках контроллера в разделе «Guest control» по умолчанию стоят ограничения после авторизации с адресами из RFC1918 (все приватные сети). Ebtables на точке доступа отвечает за фильтрацию этого трафика.

mheagerty

Guest

#17

11.07.2017 03:16:00

После этого я проверил подключение своего устройства «Raspberry Pi» к Ethernet и теперь могу спокойно получить к нему доступ из той же VLAN/подсети. Проблема, похоже, возникает только у устройств, подключённых по Wi-Fi. Также заметил, что когда пытаюсь запустить IP-сканер (например, Angry IP Scanner) при подключении по Wi-Fi, не вижу всех своих устройств. Что может заставлять мои точки доступа блокировать этот трафик?

baddaybeav Guest	#18 11.07.2017 03:00:00 Одна и та же подсеть не должна пересекать USG, если только у вас не настроено что-то в режиме моста (прозрачный файрвол).

mheagerty

Guest

#19

11.07.2017 00:08:00

Привет, Jaffe, спасибо за информацию. Я попробовал создать правило, которое ты предложил, и теперь у меня успешно получается обращаться к общим принтерам из разных VLAN! Спасибо 😀

Но теперь появилась другая проблема: не могу получить доступ к некоторым устройствам, находясь в той же VLAN/подсети.
Пытаюсь подключиться к устройству, заданному в правиле "Raspberry Pi" (например, 10.0.2.242).
Однако не получается получить доступ к этим устройствам из той же VLAN (10.0.2.0/24). При этом доступ с других VLAN работает отлично.

P.S. Я также проверял доступ к общим принтерам в той же VLAN (10.0.1.0/24) — там всё работает нормально.

Все правила файрвола настроены в LAN_IN. Ниже приложил скриншот.

UI-Team Guest	#20 10.07.2017 14:59:00 @mheagerty Создайте правило в самом начале (первое правило) LAN_IN с настройками: accept any protocol, source blank, destination blank, states checked: establish, related. Проблема в том, что ответы от ваших принтеров блокируются по пути обратно, потому что нет правила, разрешающего трафик с источником принтеров и направленный на ALL_VLANS. Добавление этого правила в начале позволит пройти всему установленному и связанному состоянию трафика через файрвол (по сути, всему «ответному» трафику).

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