Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
+7 (495) 108-0-888 info@ubiquiti.ru
Каталог
+7 (499) 350-36-46 info@ubiquiti.ru
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Форумы: UniFi Protect, UniFi Network, UniFi Access, UniFi Talk, UniFi Drive, UniFi Mobility, UniFi Connect, UniFi Play, Wifiman, Feature-request, Site-manager, Edgemax, airfiber-ltu, unifi-led, unifi-voip, solar, security, link, aircontrol, unifi-video, new-to-unifi, ufiber, unms, Airfiber, Innerspace, ISP-design-center, Airmax, UISP-app, UID, 60GHz, General
Поиск  Пользователи  Правила  Войти
Страницы: 1 2 След.
RSS
Проблема с гостевым порталом и сертификатом Let's Encrypt, UniFi Network
 
#1
22.10.2018 14:36:00
Ребята, у меня странная проблема с сертификатом Let's Encrypt на Ubuntu Xenial с UniFi версии 5.9.29. Сертификат был создан с помощью Certbot и затем импортирован этим популярным скриптом. Пока что всё работало нормально — при заходе на unifi.domain.example:8443 сертификат валидный.

Но как я только что обнаружил в ходе теста, гостьевой портал не работает в большинстве браузеров. Только Firefox принимает сертификат гостевого портала, остальные — Chrome, мобильный Chrome или Edge — ругаются на ошибку сертификата или вообще не пускают на гостевой портал из-за HSTS.

Если же подключить эти устройства к обычной сети и зайти на unifi.domain.example:8443, сертификат снова валидный.

В чём тогда проблема с гостевым порталом? Очевидно, что если я пытаюсь открыть https://google.com, меня должны переадресовывать на гостевой портал, и по пути может выскочить ошибка сертификата. Но даже при непосредственном заходе на гостевой портал unifi.domain.example как гость сертификат считается недействительным.

Буду признателен за любую помощь. 😀
 
 
 
#2
28.05.2019 21:18:00
@TVT73

@slooffmaster

Это специфический случай, в котором (если я правильно понимаю) у вас FQDN указывает на публичный адрес интерфейса, принадлежащего вашему USG, а не самому контроллеру. Переадресация портов необходима, чтобы трафик доходил до контроллера, так как на USG нет автоматических правил, которые бы перенаправляли этот трафик без них.

Именно функция NAT Hairpin в переадресации портов позволяет это сделать, потому что запросы приходят с интерфейса, который считается «внутренним» для USG (обычная переадресация портов работает только на WAN-интерфейсе, а hairpin запускает эту функцию и на LAN/VLAN-интерфейсах).

В статье описывается tcpdump на AP, где вы могли видеть этот сценарий — трафик идет к USG, но никогда к контроллеру. Мы стараемся не перегружать статью, чтобы она оставалась простой и понятной для большинства пользователей.

P.S. Статья с инструкциями по решению этой проблемы тут: https://help.ubnt.com/hc/en-us/articles/235723207-UniFi-USG-Port-Forward-Port-Forwarding-Configuration-and-Troubleshooting#3
 
 
 
#3
28.05.2019 22:10:00
https://help.ubnt.com/hc/en-us/articles/360012848693#2 Примечание добавлено в раздел «Шаги по устранению неисправностей».
 
 
 
#4
28.05.2019 22:03:00
@UBNT-AlexCaldas, @UBNT-jaffe, спасибо, логично!
 
 
 
#5
28.05.2019 22:03:00
@UBNT-jaffe

Ты прав. Главная задача — получить SSL-сертификат для контроллера и для портала хотспота. Let’s Encrypt не позволяет подписывать сертификаты для локальных IP, так что я подумал, что достаточно будет просто сделать редирект на мой внешний FQDN. Наверное, нас не так много, кто это пробовал, потому что SSL-сертификат для UniFi до сих пор недоступен, но это просто одна строка в инструкции. Я думал, что контроллер достаточно «умный», и когда я добавляю FQDN, который используется и самим контроллером, то достаточно включить этот FQDN в список предварительной авторизации. Можно обсудить, может, это просто недостающая функция контроллера, а я предполагал, что все само сработает... Все остальные правила брандмауэра настраиваются автоматически, почему бы не такому же правилу? Насколько я понимаю сейчас, это всегда нужно, если контроллер находится на локальной площадке.

Итого, можно сказать так:
Если контроллер UniFi размещен локально, надо добавить правило переадресации портов с 8880 и 8843 TCP на локальный IP контроллера.
Больше ничего не нужно.
 
 
 
#6
28.05.2019 21:55:00
@slooffmaster

@UBNT-jaffe предложил добавить в статью по устранению неполадок ссылку на статью, которую он прислал (она про проброс портов). Мне кажется, это хорошее решение, и я так и сделал. Нам точно не нужны дублирующие статьи, поэтому информация не будет повторяться в обеих, а будет просто заметка с переходом на другую статью. Ещё раз спасибо за упоминание! Это помогает держать центр поддержки в курсе проблем, которые вы ребята замечаете в сообществе.
 
 
 
#7
28.05.2019 21:52:00
@UBNT-jaffe

Спасибо за отзыв. На мой взгляд, оригинальная статья по устранению проблем с перенаправлением гостевого портала должна включать информацию и по этому сценарию. Возможно, это кажется узкоспециализированным случаем, но с captive portal мы всё чаще видим, что гостевые устройства требуют действительный SSL-сертификат (и соответствующее FQDN) на контроллере. В таких случаях, когда в сети есть USG, конечно же требуется проброс портов на USG. За последние пару недель я столкнулся с несколькими участниками форума, у которых были именно такие же проблемы.
 
 
 
#8
28.05.2019 20:31:00
Спасибо за тег, @slooffmaster, я свяжусь с командой UniFi, чтобы добавить подробности об этом в статью. Извиняюсь, что пропустил это в статье, @TVT73!
 
 
 
#9
28.05.2019 18:04:00
@TVT73

Хорошее замечание. Отмечаю @UBNT-AlexCaldas, возможно, она сможет сделать обновление?
 
 
 
#10
28.05.2019 17:51:00
@slooffmaster

Ты прав, с самого начала я так и думал. Но какой позор службе поддержки Ubiquiti — они этого не знали (Тикет 1798523). В статье базы знаний ничего не говорится, что нужна настройка переадресации портов. Я проверил, открыты ли порты — да, открыты, но забыл проверить, доходят ли они до контроллера. https://help.ubnt.com/hc/en-us/articles/360012848693-UniFi-Troubleshooting-Guest-Portal-Redirection Я бы очень рекомендовал добавить эту информацию сюда, потому что эта статья сбила меня и поддержку с толку... Кто может добавить эти данные? Спасибо всем!
 
 
 
#11
28.05.2019 13:17:00
@TVT73

Рад слышать. На самом деле это не временное решение, а часть настройки контроллера с внешним IP-адресом и полным доменным именем (FQDN). Эти дополнительные шаги (настройка проброса портов на вашем локальном USG) нужны только если контроллер работает внутри вашей локальной сети. Если же контроллер размещён у провайдера, например в AWS или DigitalOcean, то там, конечно, нужно настроить правильный проброс портов.
 
 
 
#12
28.05.2019 10:49:00
Нет, я его не изменял. Это просто личное локальное фото.
 
 
 
#13
28.05.2019 10:47:00
@slooffmaster

Хорошо, понял. Я удалил всю предварительную авторизацию, кроме моего FQDN. Добавил правило переадресации портов, как ты сказал, и попробовал свою ссылку с вечера вчерашнего дня, конечно же, с адресом контроллера. Ошибок не было, открылась промо-страница переадресации, и в контроллере я вижу, что мой Huawei Mediapad авторизован, хотя я заходил извне через WAN с офисной системы. (Из-за полного пути), раньше так не получалось. Сегодня вечером посмотрю, что будет дома. Если это сработает, значит, мы нашли обходной путь, но, насколько я понимаю, это должно работать автоматически при активации переадресации с использованием имени хоста.
 
 
 
#14
28.05.2019 05:40:00
@TVT73

Чтобы точно убедиться, не мог бы ты перенаправить порты 8880 и 8843 на внутренний IP-адрес контроллера? Скорее всего, они недоступны с «наружи». ПРАВКА: не добавляй ни один из этих адресов подключения в список доступа до аутентификации. Если сделаешь, портал с авторизацией точно не появится.
 
 
 
#15
27.05.2019 23:26:00
Привет, @TVT73

У тебя на странице HTML есть какие-то внешние источники? Например, Google Fonts, CDN, Paypal, Stripe и так далее? Если да, их нужно разрешить в предавторизации. Если нет, портал просто выйдет по таймауту, потому что они не разрешены. Можешь проверить это через консоль разработчика в браузере (F12).

Что касается connectivycheck — это нормально. Android, Apple и Windows используют URL, чтобы проверить, есть ли у телефона/планшета/компьютера доступ в интернет, и если нет, перенаправляют на гостевой портал. Так что их в предавторизации разрешать не нужно.
 
 
 
#16
27.05.2019 23:19:00
Привет @TVT73

По твоей второй ссылке — это нормально, потому что Android проверяет этот URL, чтобы убедиться, что есть интернет-соединение. Apple использует captive.apple.com, а Windows — www.msftncsi.com. И поскольку эти URL не разрешены, их перенаправляет на Splash Portal. Так что не стоит включать их в предавторизацию.

По поводу твоего Внешнего Портала: загружаешь ли ты в html-страницу какие-то внешние ресурсы, типа Google Fonts, CDN, Stripe, Paypal и так далее? Если да, то портал будет зависать из-за тайм-аута, потому что эти URL заблокированы (не включены в предавторизацию). Проверить это можно через консоль разработчика (F12 в Chrome, IE, Firefox).

Я сам не использую опцию «External Portal», а беру HotSpot (Legacy JSP) с кастомным index.html, который перенаправляет на мой внешний портал. Мой Unifi Controller использует сертификат Let’s Encrypt (там, где лежит кастомный index.html), и у моих клиентов нет никаких ошибок сертификата.
 
 
 
#17
27.05.2019 23:04:00
Все еще не работает. Но теперь ситуация другая. Теперь, после долгого ожидания, страница с обычным адресом, который указывает на контроллер + Mac + токен, не загружается. Похоже, что USG всё равно не передает данные на этот адрес перенаправления. https://controllerpublicip:8843/guest/s/default/?ap=fc:ec:da:d4:dc:0d&ec=7rns_5HSG0D6pPr1YAyv3sN8V0MO1O3JhWNUyQGZUG7A0CoyJ5xBpssQD­dMn3n3Z06pBjOFELQwemiFCmxudfKFb4p-G5PHM2i2UEn42_sVVBLVShxZe5rZjYclAN2NoQB4vo3KJAjjqDSwQyLbFq7S­F0vY3vXgN4lR_qEODMZv-Rh0eMyf1W3GBw0BcFnayR4KApHm9oTFxomqMfYtStF9Z4OHL9_5I6WY10-CjuPRFLe-2iYA4UvWmOtwK8SDXuhZS0KwSFhyUs1GLkMEdWQ

С планшетами Huawei mediapad M5 ситуация кажется ещё сложнее. Они пытаются обратиться сначала к этой странице: http://connectivitycheck.platform.hicloud.com/generate_204_650e2e57-ed6d-4e95-ad2e-8caa3988330c Добавление этого адреса в список предварительной аутентификации ничего не меняет.
 
 
 
#18
27.05.2019 12:20:00
@TVT73

Да, суффикс /32 нужен только для создания CIDR-нотации подсети для одного IP-адреса. Перенаправление с HTTP на HTTPS обычно ломает гостевые редиректы на большинстве мобильных устройств, поэтому лучше его отключить. Цепочка сертификатов может быть неполной, если вы используете браузер, который умеет самостоятельно загрузить и проверить промежуточные сертификаты, но для браузеров на неавторизованных гостевых устройствах нужна полная цепочка, потому что они не могут получить эти сертификаты в момент подключения – у них ещё нет полного доступа в интернет.
 
 
 
#19
27.05.2019 12:11:00
Я только что добавил к своему IP-адресу суффикс /32 и убрал FQDN. При использовании FQDN с /32 это невозможно. Также отключил редирект с https, но зачем — пока не знаю. Планирую проверить сегодня вечером. Ещё использовал geocerts для проверки сертификата. По моему мнению, если бы была проблема с сертификатом, разве я не получил бы предупреждение о сертификате, а не сообщение о невозможности загрузить сайт?
 
 
 
#20
27.05.2019 12:01:00
@TVT73

Отвечаю здесь после получения вашего личного сообщения. Несколько замечаний:

пожалуйста, отключите перенаправление на HTTPS  
пожалуйста, добавьте суффикс /32 к записи в списке предварительного доступа для вашего внешнего IP-адреса  
пожалуйста, подтвердите, что вы установили полный цепочку сертификатов, включая промежуточные сертификаты (используйте https://www.geocerts.com/ssl-checker, я уже быстро проверил, и всё кажется в порядке)
 
 
 
Страницы: 1 2 След.
Читают тему (гостей: 1)