Функция изоляции гостей (без использования портала) — не получается запустить (v4.8.15)

Функция изоляции гостей (без использования портала) — не получается запустить (v4.8.15), UniFi Network

Matthewb57

Guest

01.05.2016 21:46:00

Первый раз использую оборудование Ubiquiti и пока что действительно нравятся продукты Unifi. Но столкнулся с некоторыми проблемами при настройке более сложных конфигураций (по крайней мере для домашнего использования). Сейчас настраиваю одну точку доступа у себя дома и тестирую конфигурацию гостевой WiFi-сети с изоляцией клиентов, чтобы они не могли видеть или подключаться к другим ресурсам внутри локальной сети.

Мне трудно заставить работать встроенную функцию гостевых политик в контроллере Unifi. Насколько я понял из прочитанных форумов, включение "Guest policy" должно включать изоляцию клиентов без необходимости запускать гостевой портал. Я хочу, чтобы гости на одной точке доступа не могли "видеть или подключаться" друг к другу. Планирую просто использовать общий ключ WPA-Personal без гостевого портала.

Может, кто-то поможет разобраться с проблемой...

Некоторые детали:

-- оборудование --
EdgeRouter X
UAP-AC-Lite AP
Unifi Controller v4.8.15 на ноутбуке

-- общая схема сети --
eth0 – WAN
eth1-3 – настроены как порты коммутатора [192.168.1.1/24] (несколько устройств, например NAS, включая ноутбук с контроллером по адресу 192.168.1.50)
eth4 – WLAN порт [192.168.2.1/24] (к этому порту подключена UAP-AC-Lite с IP 192.168.2.100)
eth4.100 – VLAN для гостевой сети WLAN

У меня настроены три SSID в двух WLAN группах:

2G (WLAN группа 1):
SSID: Internal (WPA-P; без VLAN – 192.168.2.0/24 DHCP)
SSID: GuestWiFi (WPA-P; VLAN 100 – 192.168.100.0/24 DHCP; Гостевая политика ВКЛЮЧЕНА)

5G (WLAN группа 2):
SSID: Internal5G (WPA-P; без VLAN – 192.168.2.0/24 DHCP)

-- Текущий статус --
VLAN и основная локальная сеть, кажется, работают отлично с их DHCP-серверами. Все устройства получают правильные IP: 192.168.1.x для проводных устройств, 192.168.2.x для внутренних WiFi клиентов, 192.168.100.x для гостевых WiFi клиентов.
– Все устройства, кроме гостевых 192.168.100.x, могут пинговать и подключаться между подсетями без проблем.
– На EdgeRouter X настроен файрвол так, что гостевая подсеть блокирует все попытки подключения к другим LAN-подсетям и разрешен только выход в интернет (похоже, работает корректно).

-- Проблема --
Так вот, проблема в том, что устройство в гостевой сети GuestWiFi с IP 192.168.100.x НЕ должно иметь доступ к другим LAN-подсетям, должно иметь доступ только в интернет и НЕ должно видеть или подключаться к другим устройствам в своей же гостевой подсети 192.168.100.0/24.

Сейчас я могу пинговать и обнаруживать другие устройства в гостевой подсети с телефона на Android, подключенного к GuestWiFi, и даже подключаться к ноутбуку с контроллером, который тоже подключен к гостевой сети по адресу https://192.168.100.102:8443 — чего я не ожидал.

У ноутбука в таком случае два IP на двух сетевых интерфейсах: 192.168.1.50 (проводная LAN) и 192.168.100.102 (гостевая WiFi).

Переключаться на другие подсети не могу, что и ожидал, хотя не уверен, это из-за правил файрвола на EdgeRouter или из-за настроек гостевых политик UniFi (в гостевых политиках стоит запрет всего, кроме гостевой подсети).

Есть идеи, из-за чего может не работать изоляция устройств в гостевой сети?

Извиняюсь за длинный пост — старался быть подробным, чтобы сразу избежать массы вопросов по настройке.

Спасибо всем!

UI-Team

Guest

10.07.2017 15:36:00

@Golovics

Я слышал, что недавно была подана заявка на функцию, позволяющую включать изоляцию клиентов без необходимости делать сеть гостевой. Мы будем следить за активностью по этой заявке и займёмся её разработкой, если сообщество сочтёт это полезным. В текущей реализации есть два варианта гостевого контроля. Первый — это пометить сеть или SSID как гостевой, и тогда включится изоляция клиентов, как вы и хотели. Второй — включить Captive Portal, который делает кучу других вещей и добавляет нагрузку, которую вы, вероятно, хотите избежать. Вы пробовали просто сделать свою сеть гостевой, чтобы проверить, подходит ли это для ваших целей? Хотя стоит учесть, что это изолирует клиентов, подключённых к разным точкам доступа (хотя вы в посте об этом не упоминали).

Golovics

Guest

08.07.2017 11:50:00

Я давно этого не проверял, поэтому буду рад, если кто-то расскажет о прогрессе в реализации изоляции клиентов. Мне нужна L2-изоляция между клиентами: на одном и том же точке доступа и той же частоте; на одном и том же точке доступа, но на разных диапазонах/частотах (например, между клиентами 2G и 5G). Это должна быть отдельная функция, отличная от настройки гостевого доступа, потому что изоляция клиентов часто нужна в корпоративных сетях, где клиенты должны видеть друг друга только на L3 через маршрутизатор и файервол (DHCP-сервер выдаёт клиентам маску подсети /32 255.255.255.255). Если клиенты могут «видеть» устройства в проводной сети за точкой доступа, включая клиентов на других точках доступа, меня это устраивает, потому что я могу изолировать порты коммутатора или использовать split horizon bridging, когда все точки доступа напрямую подключены к маршрутизатору.

UI-Team

Guest

17.06.2016 12:08:00

MDDA, так что проблема с несовместимостью оборудования связана с AC-Pro. Проблема, о которой говорил другой пользователь на UAP-AC (квадратное устройство), на самом деле была из-за того, что он использовал коммутатор 802.3af для питания 802.3at UAP-AC. Поэтому UAP-AC терял питание и перезагружался.

Campotrabajo Guest	#5 16.06.2016 07:22:00 @UBNT-BenBuckley @UBNT-Brandon @UBNT-MikeD Ребята, есть какие новости по этому вопросу? Я тоже не вижу, чтобы этот баг был упомянут в этом обсуждении ошибок. Спасибо за ваши старания!

UI-Team

Guest

11.08.2016 17:29:00

@WySSOne

Извини, если ты уже обсуждал это с техподдержкой и теперь приходится повторяться, но можешь объяснить, какое поведение ожидается и какое наблюдается на самом деле? Проблема с тем, что гости могли пинговать друг друга, была исправлена начиная с версии 3.7.3, а другие улучшения по пропускной способности и ограничению скорости для не гостей появились в версии 3.7.8. Версия 3.4.19 безопасна для установки и не приведёт к сбою, но для гостевого режима в версиях выше 3.7.8 она не даст никаких преимуществ. Если у тебя есть доступ, можешь скачать 3.7.9 (бета-прошивка) здесь. Если доступа к бете нет, но ты хочешь его получить, можешь запросить в своём профиле. Если не хочешь пробовать бета-прошивку, можешь просто поставить 3.4.19 и проверить, поможет ли это. В любом случае, дай знать 😀

WySSOne

Guest

11.08.2016 15:10:00

@UBNT-BenBuckley

Меня направили сюда из поддержки, потому что у меня были сомнения по поводу работы Wireless Isolation на оборудовании Ubiquiti — оно ведёт себя совсем не так, как то, что я видел раньше (Cisco, Ruckus, Meraki и прочие). Есть ли прошивка на базе версии 3.7.5.4969? Именно на ней сейчас работают наши точки доступа. Если нет, можно ли поставить образ 3.4.19 по той ссылке, что вы указывали, без риска превратить устройство в кирпич?

cj0

Guest

17.07.2016 15:26:00

Разве у точки доступа Ubiquiti (радиомодуля) не должно быть какого-то встроенного «DHCP и ARP-защиты» (правила фильтрации ebtables?), как у Cisco <http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/emob41dg/emob41dg-wrapper/ch4_Secu.html#wp1019184>, чтобы хотя бы предотвратить ARP-спуфинг, DHCP-спуфинг и атаки с исчерпанием DHCP? Например, не перенаправлять широковещательные сообщения от клиентов WLAN обратно в WLAN?

UI-Team Guest	#9 01.07.2016 00:03:00 Образ для аппаратного обеспечения Gen2 на базе 3.4.X LTS теперь доступен. Подробности смотрите в этой теме: http://community.ubnt.com/t5/UniFi-Wireless/gen2-Guest-mode-and-rate-limiting-fixes/m-p/1608006#U1608006

UI-Team Guest	#10 22.06.2016 22:23:00 @Campotrabajo, спасибо за тестирование. Изменение будет включено в наш следующий релиз 3.4.X.

Campotrabajo

Guest

#11

22.06.2016 20:51:00

@UBNT-BenBuckley

Только что протестировал прошивку bjb-guest-mode-isolation-3.4.20.-1. Всё работает как и ожидалось. Трафик на уровне 3 не проходит к ограниченным подсетям и другим устройствам, подключённым к тому же SSID, на который применены политики гостевого доступа. Трафик на уровне 2 же проходит; хотя хосты, например, не отвечают на пинги, их IP-адреса отображаются в MAC-таблице клиента, который проводит сканирование. В результате сеть можно в какой-то мере просканировать. Для нас это нормально. L3 unicast и multicast трафик блокируются для клиентов, подключённых к тому же гостевому SSID, и для клиентов в ограниченных подсетях.

UI-Team

Guest

#12

17.06.2016 23:31:00

@Campotrabajo

Вот образ на основе версии 3.4.x: http://dl.ubnt-ut.com/uapac-guest-isolation-3.4.19.bin Если хотите попробовать образ с этим исправлением на текущей версии прошивки 3.4.18: http://dl.ubnt-ut.com/uapac-guest-isolation-3.4.18.bin Как уже отмечалось, это не позволит клиентам общаться друг с другом, но не остановит гостевого клиента от сканирования сети. Если хотите запретить сканирование, попробуйте предложение @redfive.

Пожалуйста, протестируйте у себя и дайте нам знать.

redfive

Guest

#13

17.06.2016 10:22:00

Если я правильно помню, в версии 5.0.x, хотя доступ на уровне L3 запрещён между хостами, подключёнными к одному и тому же SSID «guest», сканирование сети показывает все проводные устройства, а также хосты на других диапазонах. Я добавил правило ebtables в GUESTOUT, оно запрещает видимость между всеми хостами (разрешает только кадры, приходящие от шлюза по умолчанию, который в этом случае также является DHCP и DNS-сервером). Возможно, чтобы запретить подмену MAC-адресов, стоит использовать такое же правило, но без знака «!» и поместить его в цепочку GUESTIN... GUESTOUT -s ! 44:d9:e7:aa:bb:cc -j DROP GUESTIN -s 44:d9:e7:aa:bb:cc -j DROP Будь здоров, jonatha

MDDA

Guest

#14

17.06.2016 09:37:00

@UBNT-BenBuckley

Проблема несовместимости PoE для комбинаций UniFi AP и некоторых моделей PoE / PoE+ коммутаторов: пока что упомянуты 2 модели Cisco, но возможно есть и другие, если у них схожая архитектура. В настоящее время это решается заменой оборудования по RMA, но я все еще читаю другие темы, чтобы понять, возникает ли проблема только с прошивками из серии 5.x. Спасибо.

UI-Team Guest	#15 17.06.2016 07:44:00 @mdda_prl О какой совместимости PoE ты говоришь? По вопросам DHCP надо будет потом ответить. Спасибо, Брандон

Campotrabajo

Guest

#16

17.06.2016 06:27:00

Дорогой @UBNT-BenBuckley, спасибо за быстрый ответ. В основном я просто проверял статус, потому что хочу убедиться, что этот фикс попадёт в версии 4.8.19/20. Если вы сможете добавить этот фикс в 4.8.19RC, я с удовольствием протестирую его на нашем высоконагруженном стенде, который обслуживает около 1500 устройств в день с пиковым количеством до 200 одновременно подключённых устройств на одну точку доступа.

mdda_prl

Guest

#17

17.06.2016 05:22:00

@UBNT-BenBuckley

Я сейчас использую стабильную версию 4.x и слежу за этой темой, чтобы понять, когда проблема будет решена. Мы не перейдем на 5.x, пока она не станет новым LTS, и только когда будет исправлена отдельная проблема с совместимостью PoE.

Глядя на правила фаервола для AP (особенно по портам 67/68), разрешается ли или запрещается ли другим беспроводным устройствам становиться DHCP-сервером для гостевой сети? Я уже спрашивал об этом, но так и не прояснил.

Иначе говоря, будет ли возможность указать, откуда могут исходить DHCPOFFER / DHCPACK? Я понимаю, что DHCP в основном работает через широковещательные пакеты (строго говоря, OFFER и ACK идут с одного конкретного IP-адреса, плюс обновления идут сначала unicast), но в любой реальной сети DHCP-сервер должен работать через проводной интерфейс, а не через другое беспроводное устройство, и правила должны это отражать.

Возможно, самым строгим решением было бы позволить нам указывать (список) разрешённых исходных IP- или MAC-адресов для OFFER / ACK.

На коммутаторах у меня включена функция DHCP snooping, которая помогает, но она не защитит от клиентов, подключенных к одному и тому же AP.

UI-Team

Guest

#18

16.06.2016 17:33:00

@Campotrabajo, @UBNT-Brandon прав. Это обновление находится в версии 5.0.X, и я уже выкладывал в этом форуме кастомную сборку, основанную на 3.4.18 (Gen2 FW, поставляемую вместе с контроллером версии 4.8.18). Мы ждали отзывов от сообщества, но продолжаем работу над обновлением независимо от этого. У тебя есть какой-то конкретный вопрос или просьба, или ты просто хотел узнать, как обстоят дела?

UI-Team

Guest

#19

16.06.2016 11:35:00

@UBNT-BenBuckley подтвердил регрессию и уже имеет решение. Подробности он расскажет сам. По моим данным, исправление уже есть в версии 5.0.8 (внутренний релиз-кандидат сегодня) и вскоре мы выпустим это и для 4.8.X. Пока что, думаю, @UBNT-BenBuckley может напрямую предоставить прошивку. Спасибо, Brandon.

Matthewb57 Guest	#20 05.06.2016 18:35:00 Наконец-то удалось кое-что протестировать после возвращения из отпуска. Похоже, вы ребята проделали большую работу с тех пор и в основном разобрались (по крайней мере, до комфортного уровня, когда сеть достаточно изолирована для промышленного использования в некоторых средах). Только что установил последнюю версию контроллера 5.0.6 и свежую прошивку 3.7.5.4969 на AC-Lite и AC-PRO, работающие в одной сети, и проверил сканирование и пинг клиентов по беспроводной сети. Это у меня дома, я выделил отдельный VLAN специально для гостей Wi-Fi, и на этом VLAN нет проводных устройств, кроме IP-адреса VLAN самого EdgerouterX. Гостевой VLAN настроен с ID 100 и использует диапазон 192.168.100.x (DHCP настроен на 192.168.100.100-199). Сценарий 1 — устройства на одном и том же AP И на одном и том же диапазоне (оба на AC-LITE или оба на AC-PRO, тестировалось на 2.4G и 5G): - Устройства НЕ МОГУТ сканировать и видеть IP-адреса других Wi-Fi устройств, но ВИДЯТ Edgerouter (IP 192.168.100.1, то есть, как я понимаю, все проводные устройства). - Устройства НЕ МОГУТ пинговать другие устройства. Сценарий 2 — устройства на разных AP ИЛИ на одном AP, но в разных диапазонах (одно на AC-LITE, другое на AC-PRO, или оба на одном AP, но 2.4G и 5G): - Устройства МОГУТ сканировать и видеть IP-адреса других Wi-Fi устройств и роутера (то есть, вероятно, всех проводных устройств). - Устройства НЕ МОГУТ пинговать другие устройства. В общем, получается, что если вы не на одном диапазоне и одном AP, правильной изоляции между гостевыми Wi-Fi клиентами нет (проводные устройства всё ещё просачиваются). Во всех остальных случаях с разными AP или разными диапазонами на одном AP происходит утечка информации при сканировании устройств. Однако весь трафик, кроме обнаружения других устройств, вроде бы блокируется как надо. Без дополнительного тестирования остальных возможных настроек контроллера или других специфичных сценариев, похоже, что мы уже близки к финальному рабочему решению в последней версии контроллера 5.0.6 с прошивкой 3.7.5 на точках доступа. Наверное, эта тема уже исчерпала себя, и, на мой взгляд, нужен более конкретный «тестовый/разработочный» тред, посвящённый окончательной настройке гостевой сети и её опций в Unifi. Конечная цель Ubiquiti — создать систему, соответствующую требованиям отелей и других объектов с жёсткими требованиями. Если систему можно будет сертифицировать для таких сред, это откроет больше возможностей и позволит демонстрировать продукт на крупных объектах. Поэтому я предлагаю сотруднику UBNT открыть новую тему для дальнейшей работы над этой функцией, дать ссылку на неё в этой теме и, скорее всего, закрыть эту. Отличная работа по продвижению к полноценно работающему решению! Теперь я достаточно уверен, чтобы использовать это у себя как гостевую сеть на автосалоне, но всё равно хотелось бы видеть развитие до полной изоляции без возможности видеть другие устройства в сети, как описано в посте @alex_cambui с примером следующих требований. Спасибо ещё раз UBNT за продолжающееся развитие этого отличного продукта!

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