Cloud Key зависает на сообщении «Устанавливается связь»

Cloud Key зависает на сообщении «Устанавливается связь», UniFi Network

emichael

Guest

25.01.2016 16:17:00

Cloud Key работает отлично для локального доступа. В этом плане я доволен. Но вот с удалённым доступом проблема — не получается подключиться. Я могу зайти на портал UniFi и увидеть контроллер. При клике на «Launch Site» открывается новая вкладка браузера. Несколько сообщений мелькают вроде «Loading U» и «Verifying SSO», а потом всё зависает на «Establishing communications».

Технические детали:
- Chrome 48.0.2562.82 (я не пользователь Chrome, это чистая установка с настройками по умолчанию)
- Cloud Key 0.4.2
- UniFi controller 4.8.10
- Межсетевой экран SonicWall
- Статический публичный IP-адрес
- Простая сеть 192.168.x.x
- Нет дополнительных NAT-слоёв или внутренней маршрутизации

Есть идеи? Спасибо,
Эрик

cmam_az

Guest

05.01.2017 16:07:00

У меня тоже проблемы с подключением через Chrome и iOS-приложение, если пытаться зайти из интернета (вне файрвола от Cloud Key). В iOS-приложении застревает на «Отправке SDP-ответа», а потом соединение падает. Локально я могу подключиться прямо к контроллеру Cloud Key или через Cloud Access по VLAN, изолированной от подсети Cloud Key. Последнее крупное обновление, которое я сделал — это переход на Unifi 5.3.8. До этого доступа у меня был.

mbrust

Guest

03.01.2017 09:29:00

Привет! Сейчас у меня точно такая же проблема. Я не могу запустить CloudKey (v5.3.8) через Chrome (с WebRTC или без) когда в дороге. Интересно, что в это же время всё отлично работает через приложение Unifi на моём iPhone (тоже не в локальной сети). Понятия не имею, почему так происходит. Спасибо за помощь! Майк

toysareforboys Guest	#4 25.02.2016 14:15:00 Ничего, почему-то только что заработало! 🙁 -Jamie M.

toysareforboys

Guest

25.02.2016 09:46:00

У меня та же проблема уже с вчерашнего дня 🙁 Всё работало отлично недели, а потом внезапно останавливается на «Requesting SDP offer...» 🙁 В панели управления я всё ещё вижу точки доступа и количество подключённых клиентов, значит данные до UBNT доходят, просто войти в контроллер не получается. Пробовал через браузер Chrome на телефоне — тоже ничего не выходит. — Jamie M.

Sango Guest	#6 23.02.2016 21:28:00 Не уверен, связано ли это тоже с проблемой. Обычно у меня застревает на «Requesting SDP offer...». Но происходит это не постоянно. Это случается, когда я подключаюсь удалённо из другого места вне сети.

Jelte

Guest

23.02.2016 20:58:00

Я застрял на этапе «установления соединения» при доступе к cloud key через облако на компьютере с Windows 10 в Chrome. Однако... мой телефон на Android без проблем устанавливает соединение через браузер Chrome (тот же Wi-Fi). Так что, думаю, дело в каких-то настройках файрвола на моём компьютере. По вашим ответам видно, что вы многое поняли из этого поста, но для меня многое непонятно. Есть ли у вас идеи, в чём может быть проблема?

phk46

Guest

08.02.2016 21:29:00

На мой взгляд, это *реальная* ошибка. Насколько я понимаю, предполагается, что если можно получить доступ к порту 8080, то автоматически доступен и порт 8443. На самом деле так быть не должно. (Как ты и показал.) Поэтому не стоит переходить на прямое соединение, пока не будет успешно установлено и аутентифицировано подключение к 8443. (Хотя можно сначала попробовать 8080 — это дешевый способ предварительно проверить связь, если посчитают это полезным.)

Springs

Guest

08.02.2016 20:46:00

Только что с этим столкнулся. Долгое время всё работало отлично. Заходишь с другого сайта, подключаешься к unifi.ubnt.com... и сразу попадаешь в контроллер. Сегодня первый раз за долгое время проверил — и он снова показывает «устанавливается соединение»... Раньше я был очень впечатлён этим. Версия ПО 4.8.10-7345.
Редактирование: Подключился через VPN и попытался обновить устройство.
Редактирование: Обновление решило проблему. Версия ПО 4.8.12-7387 сразу подключилась без VPN.

greggmh123

Guest

#10

08.02.2016 20:14:00

@phk46

«И как в текущем случае, это может служить запасным вариантом, если из-за сбоя в программном обеспечении оптимизация не срабатывает». В моём случае это не баг, что не срабатывает. Если Cloud Access (CA) видит порт 8080, он пытается переключиться на порт 8443 для «локального» доступа к контроллеру. Так что если я подключаюсь с клиента вне моей сети через CA, он увидит порт 8080, потому что я разрешаю такой трафик с клиентских сайтов к моему Cloud Key, но мой файервол блокирует порт 8443. Я не оставляю порт 8443 открытым в файерволе, вместо этого сначала аутентифицируюсь, чтобы файервол его открыл. Из-за этого CA не работает, если я не принудительно включу webRTC, тогда подключение проходит нормально. Gregg

phk46 Guest	#11 08.02.2016 16:36:00 Я рассматриваю оптимизацию как расширение работы ICE по поиску точечного маршрута для канала данных. А возможность «принудительно включить WebRTC» может быть полезной (в первую очередь для гиков) как способ протестировать или проверить маршрут WebRTC. И в текущем случае это может служить резервным вариантом, если из-за ошибки в программном обеспечении оптимизация не сработает. Но очень жаль, если становится необходимо использовать опцию «принудительно включить WebRTC» потому, что оптимизационный путь выбирается в ситуации, когда он не работает. Я по-прежнему считаю, что это баг, который нужно включить в очередь на исправление. Просто, вероятно, это баг с низким приоритетом, так как есть обходное решение.

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