Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Портал для гостей WiFi недоступен из-за превышения времени ожидания проверки подключения., UniFi Network
 
<TL;DR>Когда клиенты на Android или Windows подключаются к гостевому WiFi, они не могут попасть на гостевой портал, потому что, похоже, не проходят загрузку нужного (зависимого от ОС) теста подключения. Ошибки на неавторизованных клиентах связаны не с проблемами разрешения DNS, а с тайм-аутами при попытке соединения с: Android: connectivitycheck.gstatic.com/generate_204 (Ошибка тайм-аута) Windows: www.msftconnecttest.com/redirect (Ошибка тайм-аута) Я пробовал добавить эти хосты в список разрешённых до авторизации — без изменений. Неавторизованные клиенты могут вручную зайти на адрес портала без проблем (https://prefix.domain.com:8843/guest/s/default/), но, понятно, войти они не могут без автоматических флагов, связанных с процессом аутентификации.</TL;DR>

У меня достаточно мощная сеть среднего размера, разбитая на 7 VLAN. Управляющая сеть находится на родном VLAN без тегирования, остальные — с тегами. Большинство клиентов маршрутизируются в другие VLAN в зависимости от подключаемого SSID или настроек родного VLAN на свитчах Unifi (родное тегирование в основном для проводных устройств с требованиями PCI compliance).

Аппаратное обеспечение и прошивки:  
1x UC-CK — UCK.mtk7623.v0.10.1.417b59e.180403.1128 / 5.7.23-106701  
1x USG-4p — 4.4.21.5080354  
1x 24-POE-250W — 3.9.27.8537  
1x 8-POE-60W — 3.9.27.8537  
1x Switch-8 — 3.9.27.8537  
1x UAP-AC-LR — 3.9.27.8537  
1x UAP-AC-Pro — 3.9.27.8537  

На контроллере установлен SSL-сертификат от Let’s Encrypt, все нужные порты открыты для гостевого портала. Для доменного имени (prefix.domain.com) работает DDNS. Прямое подключение к интерфейсу управления CK controlador по HTTPS/secure подтверждается в разных браузерах.

Все устройства Unifi в сети настроены на статические IP в дефолтном VLAN с указанием шлюза управления сети для DNS. Гостевая сеть настроена как корпоративная на отдельном VLAN с гостевыми политиками, портал сделан в виде хотспота с переадресацией после входа, включён защищённый портал, переадресация по hostname (https://prefix.domain.com). Опции входа — через Facebook и Google (соответствующие приложения настроены). Стандартное время сессии — 8 часов. Остальные настройки гостевого контроля — почти без изменений.

Я добавил все subnet’ы для предварительного доступа Facebook, FQDN контроллера, accounts.google.com и Google аутентификационный подсеть из руководства. При подключении Android и Windows клиентов они, кажется, падают на соответствующем тесте подключения, и страница портала не загружается из-за этого.

Ошибки не связаны с DNS, а с тайм-аутами соединения:  
Android: connectivitycheck.gstatic.com/generate_204 (тайм-аут)  
Windows: www.msftconnecttest.com/redirect (тайм-аут)  

Добавление этих хостнеймов в список разрешённых до авторизации не помогает.

Неавторизованные клиенты могут вручную открыть портал (https://prefix.domain.com:8843/guest/s/default/) без проблем, но, естественно, не могут залогиниться без автоматически генерируемых флагов аутентификации.

Буду очень благодарен за любую помощь. Уже сталкивался с разными проблемами гостевого портала и всегда удавалось их решить с небольшой поддержкой. Очень надеюсь, что это не какая-то глупая ошибка с моей стороны, но я тщательно изучал вопрос перед публикацией. Не находил похожих тем про невозможность доступа к гостевому порталу с похожим поведением клиентов (у большинства в таких темах просто не удаётся открыть портал вручную, а у меня это работает, и ошибка клиента обычно связана именно с URL портала).

Если нужно, дайте знать, могу ли я предоставить ещё какую-то информацию для диагностики.

Спасибо заранее за помощь!
 
Всем привет, у меня тоже такая же проблема с клиентом. Мне удалось воспроизвести её в своей среде, и вот что я обнаружил. На самом деле, с мобильными устройствами (телефоны и планшеты) под Android или Apple проблем нет. На компьютерах с Windows 10 тоже всё в порядке.

А вот с Windows 7 и Windows 8 я не могу получить IP-адрес по DHCP. Пришлось вручную поставить IP-адрес из подсети для гостей, и тогда страница авторизации открылась без проблем.

Я отправил тикет в поддержку Ubiquiti и только что им передал всю найденную информацию.
 
Я использую контроллер версии 5.8.24, и Гостевой портал отлично работает на всех сайтах. Мой контроллер запущен на Google VM Instance с Ubuntu 16.04 (фиксированный IP с FQDN). Не думаю, что проблема в версии контроллера. Проверьте в меню Гостевого портала, не предлагает ли он обновиться до более новой версии Hotspot (у меня он запросил обновление после перехода на 5.8.23). Всего доброго.
 
У меня тоже проблемы с порталом для гостей — он не работает. Я не менял настройки фаервола. Похоже, все сломалось после обновления до версии 5.8.24.
 
@bpapaPLP

Привет. Постараюсь помочь. Во-первых, устройствам нужен доступ к контроллеру. Если он в той же сети, что и гости, ничего делать не нужно (предварительная авторизация не требуется). Если контроллер размещён вне сети, возможно (не всегда), придется добавить его IP-адрес в список предварительной авторизации. В списке пост-авторизации добавляйте только IP-адреса и подсети, к которым вы не хотите, чтобы гости подключались.

Имейте в виду, что если вы используете Hotspot Guest Portal с входом через Facebook, необходимо добавить IP-адреса, которые Facebook использует для аутентификации, в список предварительной авторизации. Также убедитесь, что контроллер принимает подключения через порты 8880 и 8843.

Не добавляйте адреса connectivitycheck.gstatic.com и www.msftconnecttest.com в список предварительной авторизации, так как эти домены нужны для проверки подключения к интернету. Если устройство видит подключение, оно не обнаружит captive portal.

Ещё момент: некоторые старые устройства на Android не видят captive portal — это частая проблема. Практически все устройства Apple тоже не умеют его обнаруживать. Chrome на Windows иногда тоже подводит. Firefox работает отлично.

Когда гости жалуются, что не могут подключиться к порталу, мы советуем им открыть любой http-сайт через Chrome на Android, Safari на Apple и IE, Edge или Firefox на Windows. Так captive portal загрузится.

При использовании VLAN убедитесь, что гости видят контроллер по портам 8880 и 8843.

Всего доброго!
 
На самом деле нет, но у меня почти не было возможности с этим поэкспериментировать. Это удалённый объект, и 95% времени, когда я там, Wi-Fi — критически важен, так что я не могу свободно менять настройки портала. Но у меня запланировано окно технического обслуживания на этой локации где-то на этой неделе, тогда я смогу нормально покопаться и попытаться всё настроить. В целом, после сброса настроек до заводских и восстановления из бэкапа только с настройками, я сначала просто попробовал включить гостевой портал с прежними параметрами. И после этого клиенты (у меня были под рукой только Windows и Android-девайсы для теста) всё равно не могли перейти на портал для соцавторизации. Зато многие мелкие проблемы с получением данных и логированием, с которыми я сталкивался раньше, исчезли после перезагрузки контроллера...
 
Сбрасывала контроллер, чтобы решить проблему? У меня всё то же самое, даже после перезагрузки ПО.
 
Да, это точно те же самые ошибки, которые я получаю от клиентов, пытающихся (но безуспешно) подключиться к порталу. Странно то, что у меня есть два разных контроллера с почти идентичными настройками управления гостями: один работает без проблем, а у другого постоянно возникает эта проблема. Недавно я просто сбросил к заводским настройкам контроллер, который давал сбой (сделал резервную копию только настроек → сброс до заводских → восстановление из резервной копии только настроек). Но пока не успел заново настроить SSL-сертификат и включить гостевой портал на этом контроллере (пока гостевой Wi-Fi полностью открыт). Надеюсь, позже сегодня настрою сертификаты и портал. Сообщу, если сброс контроллера что-то изменит.
 
Дайте знать, удалось ли вам решить эту проблему. У меня такое же происходит у нескольких клиентов. Некоторые подключаются к порталу без проблем. Но чаще всего сбои случаются на iPhone и некоторых устройствах Android. Если я отключаю авторизацию их входа, они успешно подключаются к порталу и проходят аутентификацию. Но это длится всего несколько дней, после чего проблема повторяется. Я использую контроллер версии 5.7.23 с набором UAP, UniFi AP-AC-Pro и UniFi AP-AC-Lite. Проблема проявляется независимо от того, к какой точке доступа подключается клиент. Моя сеть довольно простая, без VLAN и подсетей. Корпоративная и гостевая сети используют одни и те же IP-адреса. Это для отеля, где интернет предусмотрен только для гостей (корпоративный трафик не идет). Гости могут подключаться к обычным беспроводным сетям с аутентификацией WPA, но заказчик хотел бы использовать портал для управления доступом постоянных клиентов. Ошибки такие:  
Android: connectivitycheck.android.com/generate_204 (Ошибка таймаута)  
Windows: www.msftconnecttest.com/redirect (Ошибка таймаута)
Страницы: 1
Читают тему (гостей: 1)