Вход в гостевой Wi-Fi через Google: перенаправление не работает, если включен Google Sign on

Вход в гостевой Wi-Fi через Google: перенаправление не работает, если включен Google Sign on, feature-request

cheetoh

Guest

23.08.2019 16:34:00

Я уже довольно долго пытаюсь понять, почему устройства на Android (тестирую на Pixel 2) не перенаправляются на страницу входа через captive portal, когда включена авторизация через Google. Что я выяснил: если в Unifi контроллере в настройках Guest Control просто активировать Google sign-in, то проверки подключения, которые Android обычно делает по HTTP к любому из следующих URL, – и которые должны были бы перехватываться и вызывать редирект на страницу портала – проходят напрямую в интернет:
connectivitycheck.android.com/generate_204
connectivitycheck.gstatic.com/generate_204
clients1.google.com/generate_204
clients3.google.com/generate_204

В итоге, Pixel 2 не перенаправляется на страницу портала. И, неудивительно, многое из Google действительно работает без нормального входа. А вот устройства на Windows работают нормально.

Версия моего контроллера – 5.10.26. На границе сети стоит Edgerouter для DNS, DHCP и прочего. По сути, похоже, что реализован слишком широкий «встроенный» допуск предавторизации гостевой сети (по IP-адресам) для google – вероятно, чтобы дать доступ к API для авторизации через Google. Это ломает механизм, который должен направлять пользователей Android на страницу входа в гостевой Wi-Fi.

Пока функция Google sign-in не активирована, редирект работает как положено для Pixel 2 или Samsung Tab A: трафик блокируется и ведёт на страницу авторизации, как и должно быть. Если бы список предавторизованных хостов/IP был настроен конкретно под Google API, то редирект, скорее всего, работал бы корректно.

Кстати, если вручную ввести в браузере URL типа http://neverssl.com, появится страница портала, и можно будет успешно войти через Google.

Ещё момент: запись ‘172.217.20.0/19’ (указанная здесь: https://help.ubnt.com/hc/en-us/articles/115000871247-UniFi-Social-Media-Guest-Authentication) — невалидный CIDR. Возможно, на это стоит обратить внимание (может, запрос на функцию?).

Есть идеи, как это обойти? Возможно, в контроллере можно как-то изменить диапазоны для «встроенной» предавторизации?

cheetoh

Guest

17.02.2020 17:36:00

Учитывая, что в вашей конфигурации команды etables заканчиваются на 49, а не на 56, значит, ваша конфигурация отличается в одном или нескольких моментах, и вы не можете ожидать, что приведённый выше пример сработает без доработок. Тем не менее, сама концепция остаётся той же. Просто нужно заменить встроенный iplist на более подходящий (ограничительный), который поможет устройствам на Android перенаправляться на портал. Для начала вам нужно изучить существующие правила EBTABLES на точке доступа с конфигурацией по умолчанию.

Llopez91

Guest

11.02.2020 14:40:00

Просто чтобы убедиться. Я добавил ещё одну точку доступа к тому же контроллеру и смог подключиться к Google, но в «плохом и нормальном» режиме. Для меня что-то не работает, но по крайней мере могу подтвердить, что проблема не в аутентификации Google. Спасибо за помощь.

Llopez91

Guest

11.02.2020 09:11:00

Привет, у меня пока никаких успехов, попробую ответить на все вопросы. Моя точка доступа может без проблем пинговать www.google.com. Используя команду cat для стандартного AP, я увидел, что последняя строка в моих ebtables — № 49. Не знаю, стоит ли вставлять твой скрипт начиная с 50-й строки и дальше, но я попробовал тот, что ты привел выше. Записи dnsmasq я не увидел, и я поменял её на свой домен (думал, может в этом и была ошибка). Домены общедоступны и разрешаются, а конфигурация портала у меня такая же, как у тебя, за исключением настройки адреса гостевой сети в preauth.

Но у меня это не работает: портал появляется, но выдает ошибку при аутентификации. Пробовал на прошивке 4.0.80.

Ещё я заметил странную вещь при выполнении команды cat. После строки с ipset1 со статусом disable идет включение (enable). Может ли это быть причиной того, что скрипт не использует ipset/ebtables, который ты написал?

dnsmasq.1.ipset.1.domain.6=fbstatic-a.akamaihd.net
dnsmasq.1.ipset.1.domain.7=fbcdn-sphotos-h-a.akamaihd.net
dnsmasq.1.ipset.1.domain.8=clients2.google.com
dnsmasq.1.ipset.1.domain.9=fbexternal-a.akamaihd.net
dnsmasq.1.ipset.1.name.1=guest_allowed_ip
dnsmasq.1.ipset.1.status=disabled
dnsmasq.1.ipset.1.status=enable
dnsmasq.1.ipset.2.domain.1=accounts.google.com
dnsmasq.1.ipset.2.domain.2=apis.google.com
dnsmasq.1.ipset.2.domain.3=android.googleapis.com

Большое спасибо за помощь.
С наилучшими пожеланиями.

cheetoh

Guest

08.02.2020 14:21:00

Привет, @Llopez91! Я опять перепроверил файл config.properties, и он точно такой же, как у меня в этой ветке, за исключением реальных MAC-адресов AP вместо 'ap_mac_addr' и FQDN портала. Твои точки доступа могут разрешать интернет-имена?
Кроме того, если выполнить команду 'cat /tmp/system.cfg' на AP с дефолтной конфигурацией, последним правилом ebtables будет ebtables.56?
Обрати внимание, что 18-я строка — это запись dnsmasq для FQDN моего cloud key, на котором размещён портал, и это имя должно разрешаться:
config.system_cfg.ap_mac_addr.18=dnsmasq.1.ipset.2.domain.5=cloudkey2.mydomain.com
Кроме этого, у меня в GUI в списке предварительно авторизованных указаны адресные пространства и гостевой сети, и cloudkey, но честно говоря, не уверен, что это обязательно.
Также у меня так настроен гостевой портал:

Не знаю, что ещё может быть проблемой.
Было бы здорово, если бы в дефолтной конфигурации обновлялся ipset, чтобы этот костыль не был нужен.
Поддержка Oath или SAML для Azure AD была бы просто верхом совершенства.

Llopez91

Guest

07.02.2020 08:54:00

Привет, @cheetoh72, спасибо за ответ. Да, думаю, всё нормально. Если я не использую твой скрипт и просто настраиваю в соответствии с руководством UniFi по предроутингу IP-диапазона, то на Android гостевая страница не появляется при подключении к Wi-Fi, и мне приходится вручную заходить по HTTP, чтобы она появилась. После этого я могу пройти Google-аутентификацию и потом спокойно пользоваться интернетом. На ПК гостевая страница появляется как задумано, и проблем с Google-аутентификацией нет.

Используя твой скрипт: когда я подключаюсь к Wi-Fi, гостевая страница появляется сразу. Но при попытке пройти Google-аутентификацию иногда возникает таймаут, а иногда ошибка 403.

Я отправил это в службу поддержки, прикрепив эту тему, чтобы они могли увидеть, что это общая проблема, но мы пока не достигли прогресса. Я использовал бета-версии прошивки на точках доступа и контроллере, но это не дало решения. Также пытался, чтобы служба поддержки проверила твой скрипт, чтобы они могли создать или изменить его и выпустить какой-то «официальный» скрипт, который решит эту проблему. Я передал им всю информацию, чтобы они могли воспроизвести баг в лаборатории.

С наилучшими пожеланиями.

cheetoh Guest	#7 01.02.2020 02:10:00 Привет, Llopez91! Дополнительного времени на это не потратил, но решение всё ещё работает. Может, проблема на стороне Google API? Ты правильно настроил URIs в консоли Google API?

Llopez91 Guest	#8 20.01.2020 11:28:00 Привет, Cheetoh72, у меня точно такие же проблемы, как ты описал (и, думаю, это общая проблема в unifi). Вход через Google работает, но не на устройствах Android, потому что они проверяют подключение, и, когда видят, что соединение есть, им не нужно проходить через гостевой портал. А вот если сделать вручную http-запрос, портал появляется. Я пытался использовать твой скрипт, но столкнулся с проблемами. Гостевой портал появляется, как задуманно (так же, как при простой пароле), но когда пытаюсь подключиться, соединение пытается установиться, но не удаётся. (Без скрипта всё работает, если делать ручной http-запрос.) Выходит ошибка 403 Disallowed_useragent, но без скрипта всё нормально, значит, что-то в скрипте идёт не так. Я не привык работать с iptables/ebtables, поэтому сверяюсь с твоим скриптом и документацией, но толком не понимаю, что именно ты хочешь сделать этим скриптом (я в этом полный новичок). У тебя есть какие-то успехи в решении этой проблемы?

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