Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Повторная авторизация роуминга через гостевой портал, UniFi Network
 
Мы всё ещё используем Unifi Controller 5.0.6 и сталкиваемся с проблемами, когда пользователи переключаются между точками доступа. Как и в нескольких других сообщениях на этом форуме, похоже, что это общая проблема.

Ситуация такова:  
Пользователь подключается к Wi-Fi на точке доступа А, проходит авторизацию и выходит в интернет.  
При переключении на другую точку доступа B снова появляется страница входа.  
За кулисами точка доступа обращается к контроллеру и снова даёт доступ устройству (в логах это отображается как повторная авторизация).  
Проблема в том, что пользователь видит страницу входа и не замечает, что в фоновом режиме происходит авторизация.  
=> В целом пользователь получает крайне неприятный опыт.

Мы замечаем эту проблему как на устройствах iOS, так и на Android — Windows Phone, кажется, справляется с этим как-то получше.  
У нас используется кастомный внешний портал, и мы могли бы обнаруживать, что устройство уже зарегистрировано, и показывать другую страницу («с возвращением»), но это не то, чего мы ожидаем от системы.

Вопрос:  
Есть ли какое-то обходное решение этой проблемы?

Альтернативное решение:  
Из другой ветки форума понятно, что авторизация передаётся только на точку доступа, к которой подключено устройство (иначе это плохо масштабировалось бы).  
В нашем случае:  
- На площадке работает от трёх до пяти точек доступа (в целом по системе около 50–70 площадок).  
- Около 15–50 пользователей одновременно на площадку, в среднем около 20. Пики до 75 и более — редкость.  
- Почти все пользователи перемещаются между точками доступа по зданию, поэтому роуминг — ключевая функция.

Поэтому было бы здорово иметь возможность проактивно передавать авторизацию на точку доступа (или группу точек доступа).  
Идеально, если контроллер мог бы делать это автоматически, иначе мы могли бы расширить наш портал, чтобы запускать авторизацию на других точках доступа. Мы уже тестировали это (отправляли команду authorize-guest с MAC-адресами для других точек доступа), но, по-видимому, контроллер не передаёт авторизацию гостям (потому что пользователь уже авторизован на контроллере?).

Есть ли способ добиться этого?
 
@nuvotex

Настройки вроде в порядке. Просто включи «переопределять шаблоны пользовательскими изменениями» и нажми «применить». Если проблемы останутся, лучше связаться с поддержкой и заглянуть по этой ссылке тоже.
 
Мне пришлось переделать по схеме: «Внутренний портал с редиректом на внешний портал» https://community.ui.com/questions/a430bb89-8a58-40f9-8150-c005d6551e26#comment/74c3cc56-d4c5-484a-ba18-bde851918736. Это немного уменьшило проблему — пустая страница для авторизованных пользователей теперь появляется гораздо быстрее.
 
@nuvotex

Я могу помочь вам с решением проблемы. Но для проверки мне нужен удалённый доступ к системе. Это возможно? Если да, отправьте детали в личку, и я с радостью всё проверю.
 
К сожалению, нет, так и не удалось это окончательно решить.
 
Вы или Ubiquiti как-нибудь решили эту проблему?
 
Вот тест (без роуминга — только подключение/отключение от точек доступа):

1. Подключение к AP1. Пользователь перенаправляется на внешний портал.  
2. Авторизация на AP1. Доступ разрешён.  
3. Отключение от AP1.  
4. Подключение к AP2. Уже авторизованный пользователь (!) снова перенаправляется на внешний портал.  
5. Ожидание ~1 минуты.  
6. Видим, что доступ в интернет разрешён AP1.

[2016-12-02 12:55:18,737] <inform-128> INFO inform - от [44:d9:e7:64:a9:f6](<AP1>, BZ2, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.167, dev_ip=172.31.31.167, время работы=90890
[2016-12-02 12:56:45,769] <inform-151> INFO inform - от [44:d9:e7:64:a9:f6](<AP1>, BZ2, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.167, dev_ip=172.31.31.167, время работы=90977
[2016-12-02 12:56:45,788] <inform_stat-821> INFO событие - [event] Гость[38:a4:ed:65:5d:fd] подключился к AP[44:d9:e7:64:a9:f6] с ssid "<SSID>" на "канале 1(ng)"
[2016-12-02 12:57:23,627] <inform-169> INFO inform - от [44:d9:e7:64:a9:f6](<AP1>, BZ2, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.167, dev_ip=172.31.31.167, время работы=91015
[2016-12-02 12:57:23,628] <inform-169> INFO inform - <<< [cmd authorize-guest] устройство[44:d9:e7:64:a9:f6] { "_id" : "584145835b745f4842492f57" , "_type" : "cmd" , "cmd" : "authorize-guest" , "datetime" : "2016-12-02T09:57:23Z" , "device_id" : "56baf4ce22f023f5dc63f4e8" , "mac" : "38:a4:ed:65:5d:fd" , "server_time_in_utc" : "1480672643628" , "time" : 1480672643607}
[2016-12-02 12:57:25,755] <inform-172> INFO inform - от [44:d9:e7:64:a9:f6](<AP1>, BZ2, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.167, dev_ip=172.31.31.167, время работы=91017
[2016-12-02 12:57:25,798] <inform-188> INFO inform - от [44:d9:e7:64:a9:f6](<AP1>, BZ2, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.167, dev_ip=172.31.31.167, время работы=91017
[2016-12-02 12:58:30,823] <inform-190> INFO inform - от [44:d9:e7:64:a9:f6](<AP1>, BZ2, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.167, dev_ip=172.31.31.167, время работы=91082
[2016-12-02 12:59:05,860] <inform-200> INFO inform - от [44:d9:e7:64:a9:f6](<AP1>, BZ2, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.167, dev_ip=172.31.31.167, время работы=91117
[2016-12-02 13:00:26,898] <inform-33> INFO inform - от [44:d9:e7:64:a9:f6](<AP1>, BZ2, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.167, dev_ip=172.31.31.167, время работы=91198

AP2

[2016-12-02 13:21:32,224] <inform-47> INFO inform - от [44:d9:e7:66:20:64](<AP2>, BZ2LR, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.229, dev_ip=172.31.31.229, время работы=417
[2016-12-02 13:23:00,323] <inform-90> INFO inform - от [44:d9:e7:66:20:64](<AP2>, BZ2LR, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.229, dev_ip=172.31.31.229, время работы=506
[2016-12-02 13:23:00,340] <inform_stat-824> INFO событие - [event] Гость[38:a4:ed:65:5d:fd] подключился к AP[44:d9:e7:66:20:64] с ssid "<SSID>" на "канале 11(ng)"
[2016-12-02 13:23:00,342] <inform_stat-824> INFO гость - [повторная авторизация гостя] 38:a4:ed:65:5d:fd на uap[44:d9:e7:66:20:64]
[2016-12-02 13:23:00,360] <inform-89> INFO inform - от [44:d9:e7:66:20:64](<AP2>, BZ2LR, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.229, dev_ip=172.31.31.229, время работы=506
[2016-12-02 13:23:00,361] <inform-89> INFO inform - <<< [cmd authorize-guest] устройство[44:d9:e7:66:20:64] { "_id" : "58414b845b745f4842492fa3" , "_type" : "cmd" , "cmd" : "authorize-guest" , "datetime" : "2016-12-02T10:23:00Z" , "device_id" : "5790856a22f023f5dc69a24d" , "mac" : "38:a4:ed:65:5d:fd" , "server_time_in_utc" : "1480674180361" , "time" : 1480674180341}
[2016-12-02 13:23:01,814] <inform-88> INFO inform - от [44:d9:e7:66:20:64](<AP2>, BZ2LR, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.229, dev_ip=172.31.31.229, время работы=507
[2016-12-02 13:23:01,857] <inform-80> INFO inform - от [44:d9:e7:66:20:64](<AP2>, BZ2LR, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.229, dev_ip=172.31.31.229, время работы=507
[2016-12-02 13:23:54,949] <inform-105> INFO inform - от [44:d9:e7:66:20:64](<AP2>, BZ2LR, 3.3.22.4024): состояние=CONNECTED, ext/stun_ip=172.31.31.229, dev_ip=172.31.31.229, время работы=560
 
Это с внешним порталом? Проблема не в внешнем портале, а в «медленной связи» между контроллером и точками доступа, что может быть вызвано разными причинами. Истечение срока аутентификации, которое требует повторной авторизации, задаётся контроллером и точками доступа на основе длительности, указанной в первоначальном запросе на аутентификацию. Единственный случай, когда преждевременное истечение срока может быть связано с внешним порталом — это когда контроллеру через API передаётся некорректная (слишком короткая) длительность аутентификации. Вот почему я и попросил данные по событиям устройств с проблемами.
 
Это через внешний портал?
 
У нас версия 5.2.9, более 300 точек доступа, всё работает отлично. Иногда пользователям нужно повторно пройти аутентификацию, но при этом страница входа не появляется снова.

Правка. Нужно уточнить: на их телефоне на уровне ОС появляется сообщение «нажмите здесь, чтобы войти в Wi-Fi», при нажатии быстро загружается серая страница на долю секунды, а затем открывается нужный сайт. Так и должно быть, по идее.
 
Я только что купил два UAP-AC-PRO в надежде поиграться с ними и использовать по назначению. К сожалению, у меня те же проблемы. Похоже, мне придется продолжать использовать DNS Redirector для captive portal, который работает вне зависимости от оборудования AP и переключения клиентов.
 
«Linux Server» находится в той же подсети, что и AP? Можешь прислать логи с устройства, где это происходит? Да, в той же подсети. Постараюсь собрать нужную информацию и отправить завтра.
 
Сервер "Linux Server" находится в той же подсети, что и точки доступа? Можете поделиться событиями для устройства, на котором это происходит? В целом рекомендуется обновление, хотя бы до стабильных версий, которые уже были выпущены несколько недель назад.
 
Контроллер и внешний портал установлены на Linux-сервере. L2-сеть с точками доступа.  
> Я бы порекомендовал сначала обновить контроллер и прошивку точек доступа до версии 5.2.9.  
Это действительно поможет или это просто общее рекомендация?  
Спасибо.
 
Я бы порекомендовал сначала обновить прошивку контроллера и точек доступа до версии 5.2.9. Обязательно сделайте резервные копии на всякий случай. Можете немного подробнее описать свою сетевую архитектуру? Особенно интересно, где расположены контроллер и внешний портал, а также какие средства защиты (например, фаервол) могут находиться между точками доступа и контроллером.
 
У нас пилотное развертывание в небольшом отеле с 7 точками доступа (4 ap + 3 ap-lr). Версия контроллера 4.8.20, версия AP 3.3.22.4024. Внешний портал.

Ситуация такова: пользователь подключается к Wi-Fi на точке доступа A, проходит авторизацию и выходит в интернет. При переключении на другую точку доступа B снова появляется страница входа. За кулисами точка доступа запрашивает контроллер и повторно предоставляет устройству доступ (в логах это отображается как повторная авторизация).
 
Сомневаюсь, что у вас такая же проблема, если только вы тоже не используете версию 5.0.6. Пожалуйста, поделитесь более подробной информацией (какие клиентские устройства, контроллер и версия прошивки, модели точек доступа и т.д.), чтобы сообщество могло попытаться вам помочь.
 
Столкнулись с этой проблемой 🙁 Есть ли какое-то решение? Это серьёзная проблема для нас и мешает нам устанавливать точки доступа Ubiquity в отелях.
Страницы: 1
Читают тему (гостей: 1)