USG показывает контроллер как «Недоступен».

USG показывает контроллер как «Недоступен»., UniFi Network

BrianCriswell

Guest

28.10.2016 16:52:00

Я управляю сетью из 4 площадок. На каждой площадке установлен USG, коммутаторы Unifi и точки доступа Unifi по необходимости. Между площадками настроен site-to-site VPN. В центральной точке запущен контроллер cloudkey с прошивкой 0.5.5 и версией контроллера 5.2.9. Недавно я изменил адрес set inform в контроллере, чтобы быстро подключать устройства без необходимости искать их в сети, заходить по SSH и вручную задавать set-inform с WAN-адресом контроллера (для других площадок). Затем я подключаю устройство в центральной точке, принимаю его в контроллере, назначаю на нужную площадку и уже потом устанавливаю устройство на площадке. Устройство включается и синхронизируется с контроллером через интернет. Всё работает хорошо. За исключением USG в центральной точке. Он отключился от управления. Когда я захожу на USG по SSH и запускаю команду «info», там написано, что контроллер недоступен. Я сделал set-inform с внутренним IP cloudkey. После нескольких попыток set-inform он, наконец, принял команду, но при любом изменении в контроллере адрес снова сбрасывается на WAN URL. Не могу понять, почему USG не может достучаться до контроллера, если все остальные устройства — могут. При подключении по SSH с USG я спокойно могу пропинговать WAN URL. Есть идеи?

BrianCriswell Guest	#2 21.10.2017 14:00:00 Решение с /etc/hosts кажется пока что самым разумным вариантом.

olliecampbell Guest	#3 21.10.2017 13:41:00 Кто-нибудь нашёл решение этой проблемы?

zaudo

Guest

18.08.2017 01:02:00

В чём тут решение? У меня такая же проблема. У меня есть устройства, которые используют inform URL на публичном домене, который сам по себе ссылается на сервер в той же сети, что и USG. Так что когда USG пытается использовать этот inform URL, он не может разрешить его через публичный домен, потому что не может сделать NAT loopback для своих собственных запросов. Я могу изменить inform URL на локальный IP только для USG с помощью set-inform... но это не сохранится. Как только устройство переподключится, оно опять не сможет соединиться. Есть ли способ задать другой inform URL только для USG, который сохраняется?

chamm Guest	#5 24.06.2017 12:04:00 Да, это вполне правдоподобно, и это всё объясняет. Большое спасибо за объяснение!

UI-Team

Guest

24.06.2017 06:20:00

Да, в этом случае то же самое. Невозможно отличить коммуникацию с контроллером, которая была инициирована IP-адресом, от той, что по hostname — трафик абсолютно идентичен в любом случае.

Моё первое предположение — возможно, устройство было принято на уровне L2, и команда set-inform на самом деле не изменила URL информирования, либо оно откатилось к unifi:8080, который сам зарегистрировался на внутренний IP контроллера.

chamm

Guest

24.06.2017 00:35:00

Я подозревал, что это может быть так. Но если это именно так, как тогда сработало, когда я использовал WAN IP-адрес в set-inform? Разве это не тот же самый NAT-reflection? В любом случае, split DNS действительно работает. Сейчас мне просто интересно. Я подумываю порекомендовать USG для пары больших сетей и хочу убедиться, что понимаю всё правильно, чтобы не столкнуться с неожиданностями. :-)

Спасибо за помощь!

UI-Team Guest	#8 23.06.2017 22:50:00 NAT reflection не применяется к трафику, инициированному самим USG, поэтому он не вернётся обратно через переадресацию порта. На данный момент лучшим решением является использование Split DNS.

chamm

Guest

23.06.2017 14:15:00

Хорошо, по крайней мере я могу подтвердить, что внутренняя запись IP в /etc/hosts осталась после перезагрузки шлюза. Этого может быть достаточно, чтобы всё работало, но выглядит это жутко костыльно. Не могу понять, почему моя внешняя DNS-запись разрешается правильно, и всё работает, когда я задаю set-inform с публичным IP-адресом, но не работает, когда использую валидное публичное FQDN. Похоже, это баг. Я собираюсь сообщить об этом как о баге. Но на ближайшее время этого мне хватит, чтобы система работала.

chamm

Guest

#10

23.06.2017 14:01:00

Пока что я добавил строчку в файл /etc/hosts, чтобы изменить DNS-запись на внутренний адрес. Это работает, но я почти уверен, что после перезагрузки всё слетит. Честно говоря, возможно, её даже перезапишут, когда какое-нибудь устройство в моей сети получит IP-адрес от DHCP-сервера, ведь, по-видимому, он вписывает свои записи именно в этот файл. Я в полном шоке, что мы, похоже, единственные, у кого такая проблема.

BrianCriswell Guest	#11 23.06.2017 13:58:00 К сожалению, мне снова пришлось вручную настраивать все устройства.

chamm Guest	#12 23.06.2017 13:44:00 Никто так и не ответил на это, а у меня точно такая же проблема. Я работаю на версии 4.3.41.4975503 на USG, а Cloud Key с прошивкой v0.6.4 и контроллером UniFi версии 5.4.16-9234. Я могу задать set-inform на внутренний адрес моего Cloud Key, и всё работает отлично. Более того, я могу указать внешний IP-адрес моего USG — и это тоже работает. Но если я задаю DNS-запись публичного IP моего USG, при использовании команды «Info» высвечивается «Unreachable». В интерфейсе Cloud Key статус USG колеблется между «Adopting» и «Disconnected». У меня ещё 6 других сайтов подключены к Cloud Key и обновляются без проблем. Это, должно быть, какая-то ошибка, да?

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