Ошибка подключения при попытке доступа к Debug Terminal

Ошибка подключения при попытке доступа к Debug Terminal, UniFi Network

coachmark2

Guest

14.05.2019 01:05:00

У меня есть контроллер, размещённый на сервере Ubuntu в VPS Vultr. У меня около десятка сайтов, на каждом по несколько устройств. Этот сервер находится за файерволом и имеет приватный IP. Устройства могут подключаться и управляться контроллером без проблем. Я открыл нужные порты, указанные в статье помощи по этой теме. STUN работает правильно. Я сделал захват пакетов на WAN-интерфейсе файервола и вижу, что STUN-пакеты идут туда и обратно между файерволом и публичным IP сайта, где находится устройство.

В /var/log/unifi/server.log появляются следующие строки каждый раз, когда я пытаюсь зайти в отладочный терминал:
[00:56:58,935] <webapi-196> WARN sdn - не удалось получить детали подключения: config.ubnt.com
[00:56:58,935] <webapi-196> INFO api - [api] api.err.Invalid: /api/s/90xiq3g1/cmd/sdn

Замечу, что это в Chrome, не в Firefox, и это НЕ та проблема, когда в отладочном терминале показывается ошибка STUN или ошибка открытия websocket или что-то подобное. Ошибка появляется настолько быстро, что задержки почти нет.

Есть идеи?

hisashi

Guest

17.12.2022 07:03:00

У меня такой же вопрос. Для меня использование внешних серверов для доступа к локальным устройствам — это своего рода «дырка» в файрволле, и мне не нужно, чтобы всё работало именно так. Если я захожу в USC на контроллере VLAN с моего ПК, я использую роутер Synology RT2600ac с установленной защитой Threat Prevention, и именно она автоматически блокирует этот внешний трафик. На прикреплённом скриншоте вы видите пример события, когда я пытаюсь запустить debug console. Кстати, я использую докер-образ unifi SC, размещённый на моём Synology NAS. Вот почему я не понимаю, зачем нужны внешние серверы для доступа по ssh к моим локальным устройствам, если я уже подключён к консоли через локальный IP.

AustinW

Guest

04.01.2021 14:24:00

Согласен, не понимаю, почему при использовании локально размещённого контроллера для доступа к внутренней точке доступа он обращается к облачному STUN-серверу. Вся эта история с SolarWinds должна заставить всех быть немного осторожнее и не слепо доверять тому, что эти сервисы безопасны и неуязвимы.

miltos.koutsokeras

Guest

26.11.2020 13:22:00

Привет, у меня вопрос: почему контроллер Unifi требует доступа к сервисам, доступным из интернета, чтобы подключиться к терминалу локальной сети? У меня настроена система, где вся сеть, включая контроллер Unifi, не подключена к интернету. До сих пор всё работает нормально, кроме функции отладки терминала. Кто-нибудь может подтвердить, что для этой функции нужен интернет? Есть ли способ обойти это для настроек, работающих только в приватных локальных сетях? Спасибо.

esesmac

Guest

20.05.2020 18:01:00

Привет, ребята, мне кажется, у меня такая же проблема, как у вас. У меня контроллер размещён в Azure, терминал отладки всегда работал отлично, но пару недель назад мы заметили, что он перестал работать. У нас на самом деле два контроллера: один с большим количеством сайтов, другой — с несколькими, оба в Azure. Так вот, контроллер с большим числом сайтов перестал работать, а терминал отладки на контроллере с меньшим числом сайтов работает. Оба контроллера размещены на сервере с Ubuntu и находятся в одной подсети Azure. Странно, что терминал отладки вдруг перестал работать. Не подскажете, что можно проверить на сервере, чтобы заново включить какую-то службу, которая могла остановиться? Есть идеи по этой проблеме и что и где проверить? Спасибо!

arndt.nowaczyk

Guest

26.12.2019 17:26:00

Запущен последний Unifi Controller версии 5.12.46, и при попытке подключиться к любому устройству в Firefox 71.0 выдает ту же ошибку. В Chrome 79.0 кое-что работает. В консоли Firefox появляется такая ошибка:
Source map error: Error: request failed with status 404
Resource URL: https://?<controller>:8443/manage/js/dynamic.ufsdn.4467e47c5f9f705cb449.js
Source Map URL: dynamic.ufsdn.4467e47c5f9f705cb449.js.map

ubmdi

Guest

12.12.2019 11:45:00

@marlonrod — я только что столкнулся с тем, что ты описал на своём AC-Pro. Не смог зайти в Debug Terminal, проверил логи прошивки и заметил, что на UniFi management VLAN пропадают исходящие UDP-пакеты к IP-адресу AWS. Моей точке доступа абсолютно ни к чему выходить в открытый интернет, да и всё это вообще должно быть заблокировано — система закрытая. Как все знают, даже обновления прошивки получаются и устанавливаются через контроллер. Для меня это совсем не нормально. В наше время неприемлемо иметь нежелательный исходящий трафик с любого устройства... ну, может, ещё можно понять от дешёвого IoT-гаджета, но никак не от относительно дорогой точки доступа бизнес/предприятия. UniFi нужно с этим разобраться получше. Ты выяснил, к кому можно обратиться с этим вопросом (жалобой) и получил ли ответ?

marlonrod Guest	#8 08.06.2019 04:46:00 Проверьте в вашем файрволе, не блокируются ли UDP-соединения от вашей точки доступа (AP) к какому-то внешнему IP:3478. В моём случае AP проверялось по какому-то IP AWS. Как только я разрешил это соединение — всё заработало. Правило нужно только в момент попытки подключения. Как только связь устанавливается, правило больше не нужно. Если попробуете снова запустить терминал, правило понадобится снова. Почему так — не знаю, но пытаюсь выяснить, куда можно пожаловаться, потому что по очевидным причинам я не собираюсь разрешать соединение с каким-то публичным IP, которым не управляю, особенно когда не использую их облако, и моя точка доступа не должна запрашивать у них разрешение.

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