Гостевой портал с SSL-сертификатом — зависает при перенаправлении на https://Wi-Fi.<mydomain.com>:8843

Гостевой портал с SSL-сертификатом — зависает при перенаправлении на https://Wi-Fi.<mydomain.com>:8843, UniFi Network

HotelIT

Guest

28.02.2017 16:39:00

Привет! Гостевой портал с SSL-сертификатом — застревает на перенаправлении на https://Wi-Fi.<mydomain.com>:8843/guest/s/default/

Ранее функция гостевого портала хот-спота работала нормально, но без SSL. Похоже, я что-то пропустил в разделе «guest control». Я включил «use secure portal», выбрал «redirect using hostname» — https://<mydomain.com>, и активировал «enable https redirection».

Порты на USG 4P 8843 и 8880 открыты — тест показывает, что они доступны. Если открыть порт 8443, можно зайти в контроллер, при этом SSL-сертификат явно установлен.

В контроле доступа разрешил предварительный доступ по статическому IP на WAN Wi-Fi.<mydomain.com>, это локальный IP контроллера.

Адрес wi-fi.<mydomain.com> резолвится и внутри сети (до авторизации), и снаружи.

Если же вернуться к настройкам и снять галочку с «use secure portal», поставить «redirect using hostname» на http://localIP и отключить «enable HTTPS redirection», то всё работает.

Я думал, что настройки для SSL должны были сработать, неужели я упускаю что-то очевидное?

Unifi controller работает на Windows Server 2012 R2.
Я установил сертификат SHA2 — Chrome спокойно его принимает.

turtle2472

Guest

21.07.2017 03:20:00

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

Quicksilver:~ turtle2472$ host unifi.domain.com
;; connection timed out; no servers could be reached
Quicksilver:~ turtle2472$ ping unifi.domain.com
PING dyndns.dyndns.org (71.120.224.76): 56 data bytes
64 bytes from 71.120.224.76: icmp_seq=0 ttl=64 time=1.137 ms
64 bytes from 71.120.224.76: icmp_seq=1 ttl=64 time=1.170 ms
64 bytes from 71.120.224.76: icmp_seq=2 ttl=64 time=1.349 ms
^C
--- dyndns.dyndns.org ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.137/1.219/1.349/0.093 ms
Quicksilver:~ turtle2472$ cat /etc/resolv.conf
nameserver 192.168.1.10
nameserver 208.67.222.222

Команда «host» не сработала, а ping разрешился идеально. В /etc/resolv.conf прописаны правильные DNS-серверы. К тому же, похоже, перенаправление шло по адресу: https://unifi.domain.com:8880/guest/s/default/stuffandthings. Обрати внимание, там «https» и порт 8880. По крайней мере, я почти уверен, что сузил круг поиска, но проблема пока так и не решена.

turtle2472

Guest

21.07.2017 01:49:00

Сначала я подумал, что проблема в DNS, поэтому поменял гостевую сеть, чтобы использовать конкретные DNS-серверы, а не шлюз по умолчанию. Также разрешил доступ для этих двух IP-адресов. Я проверил с мобильного устройства и смог успешно подключиться к unifi.domain.com по обоим адресам — http(s) 8880 и 8843. Оба работают и выводят страницу ввода пароля портала снаружи моей сети: http://unifi.domain.com:8880/guest/s/default/ https://unifi.domain.com:8843/guest/s/default/

Хотя это вряд ли влияет, имя хоста — это CNAME, а не A-запись. Так как я могу попасть на сайт снаружи фаервола, думаю, проблема не в этом.

Правка: посмотрел URL перенаправления: http://unifi.domain.com:8880/guest/s/default/?id=98:fe:94:aa:aa:aa&ap=f0:9f:c2:aa:aa:aa&t=1500602444&url=http://domain.com%2f

Параметр &ap — это мой US-24, потому что у меня нет UAP, я сейчас использую старые AirPort Extreme. Конечно же, проблема не в том, что я не использую Unifi Access Points, правда?

turtle2472

Guest

20.07.2017 23:19:00

В моём случае у меня есть хостнейм, который указывает на мой дом: unifi.domain.com. Я настроил и запустил Let’s Encrypt для этого URL в контроллере. Порты 8880, 8843 и порт управления проброшены на IP контроллера. Мой контроллер находится в локальной сети: 192.168.1.1 USG, 192.168.1.253 контроллер Unifi на Debian-сервере, 192.168.1.9 — прокси Nginx для маршрутизации хостнеймов. Для unifi.domain.com порты 80 и 8080 проброшены на 192.168.1.253 — это я настроил только что в ответ на твой пост. Для предавторизационного доступа у меня есть подсеть для гостей, IP контроллера 192.168.1.253/32, сервер Nginx 192.168.1.9/32 и хостнейм unifi.domain.com. Проблема только с опцией редиректа по хостнейму. Если она включена, то всё просто виснет. Если же включить Secure Portal и HTTPS-редирект, то всё работает. ** Хостнеймы и айпи изменены ради очевидных причин, просто так легче воспринимать без всяких «ххх» и прочего.

HotelIT

Guest

18.07.2017 08:51:00

Порты 8880 и 8843 нужно перенаправить на контроллер с помощью перенаправления портов на роутере. 8880 — это первоначальное незащищённое подключение, через которое гости по моим воспоминаниям переходят на 8843. Также в настройках предварительной авторизации гостевого контроля должен быть прописан «ipaddressof controller»/32.

То есть ты говоришь, что на той же машине, где контроллер, стоит веб-сервер? Если да, и ты используешь указанные порты, то всё должно работать. Но если гости заходят на портал по адресу GuestPortal.mydomain.com, то по умолчанию это порт 80 — здесь может быть проблема. Правильнее будет использовать GuestPortal.mydomain.com:8843 или GuestPortal.mydomain.com:8880. DNS не назначает порты, тебе нужно настроить сервер так, чтобы он перенаправлял запросы с обычного порта (80 для HTTP) на нужный порт (8880 или 8843).

Когда я настроил работу с GuestPortal.mydomain.com:8843, собирался запустить веб-сервер на отдельном сервере и сделать перенаправление либо через META REFRESH, либо через .htaccess (если используешь Apache или Lighttpd). Затем «A-запись» с именем GuestPortal должна указывать на контроллер и нужный порт.

turtle2472 Guest	#6 18.07.2017 03:31:00 У меня такая же проблема, но с Debian 9 и Let’s Encrypt. Куда должны быть направлены порты 8880 и 8843? У меня сейчас они указывают на контроллер. Также есть небольшая сложность: весь трафик на порты 80 и 8080 идёт на мой веб-сервер. Это значит, что мой субдомен разрешается туда по стандартным и альтернативным HTTP/S портам. Контроллер находится за фаерволом, и для контроллера изменены порты на отличные от стандартных. Эти порты проброшены на IP моего контроллера. Что я упускаю? Мой Googlefu меня подводит, и я пока не нашёл решения.

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