Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Не могу адаптировать USW Pro Max 48 после миграции на VM., UniFi Network
 
Начинаю сходить с ума, так что надеюсь, кто-нибудь здесь сможет подсказать, в каком направлении двигаться. Месяц назад купил USW Pro Max 48 и без проблем подключил его на Windows Server 2025 VM. Прошло время, и после того как я перенес VM на новый сервер ProxMox, я внезапно потерял возможность управлять USW.

Сначала попытался восстановить из резервной копии, думал, что что-то пошло не так при переносе VM, потому что особо не обращал внимания на приложение UniFi Network при этом. Не помогло, и после того как я перепробовал несколько разных вещей, решил просто попробовать начать все с нуля, чтобы проверить, смогу ли я вообще запустить его... Не смог. Даже установил Unifi Network Server на свой компьютер и запустил оригинальный VM, но и это не сработало.

После заводского сброса он получает подходящий IP-адрес для моей сети и отображается как доступный для подключения, но когда я нажимаю, чтобы подключить его, в итоге происходит сбой, и IP-адрес устанавливается на 1.20. Пытался подключиться к коммутатору через SSH и пинговать мой сервер — работало отлично, и даже явно прописал inform, хотя это и могло иметь значение. Все работает на последней прошивке.

Как для меня странно, что несмотря на то, что он находится между EdgeRouter4, AP Pro и остальными устройствами в доме, он не блокирует мои проводные подключения к интернету (кроме случаев заводского сброса), даже когда IP-адрес установлен на 192.168.1.20. Однако он заблокировал мое AP от подключения к чему-либо, так что я потерял беспроводной доступ.

В общем, я испробовал все, что только можно, поэтому надеюсь, что у кого-нибудь там есть хорошие идеи :) Или знает, есть ли где-то файл журнала, к которому я могу получить доступ, чтобы хотя бы узнать, почему не удается подключить.
 
Спасибо за обновление!
 
Ладно, каким-то образом заставил это работать, хотя до конца не уверен, как именно. Но вдруг кому-нибудь пригодится в будущем, вот примерно что я в итоге сделал.

Вынул переключатель из Unifi Server.

Физически отключил переключатель от питания перед выполнением сброса к заводским настройкам. Не уверен почему, но что-то оставалось между сбросами к заводским настройкам, пока отключение питания не очищало то, что заставляло его вести себя странно. (Среди прочего, это влияло на мою возможность подключиться к переключателю по SSH)

Подключился к переключателю по SSH, используя стандартные учетные данные ubnt/ubnt и запустил следующие команды (только одна, в чём я действительно уверен, что что-то сделала, это set-inform, но даже этого было недостаточно, когда я в первый раз этим занималась, так что очевидно, что что-то ещё было важно).

Попыталась принять (все равно не получилось, но по-другому).

Снова подключилась по SSH, но уже используя учетные данные Settings->System->Advanced->Device Authentication.

Установила IP-адрес снова, и вдруг все заработало.

Я толком не понимаю, зачем мне приходилось прыгать через все эти препятствия, но в данный момент мне это совершенно не важно. Единственное, что меня действительно удивило, это то, что переключатель изначально запускался, думая, что сейчас 26 сентября, а после первой неудачной попытки принятия он сумел найти NTP-сервер и получить правильное время, но я не хочу отключать это, чтобы проверить, исправило бы просто изменение часов мои проблемы :)
 
Ну всё, наконец-то зашёл. Оказывается, подключения хватало, чтобы получить новые учетные данные с Unifi Server, о чём я и не подозревал, что он использует сгенерированный пароль, используя мой логин. Ничего супер очевидного не вижу, получает IP-адрес, потом находит IP-адрес сервера перед `initial contact failed #1 .... rc=2` неважно, что это значит. После этого сразу меняет свой собственный IP-адрес и просто зацикливается на ошибках, потому что, очевидно, больше не может подключиться. Ещё одна вещь, которая бросается в глаза как возможная проблема – это очень неправильный timestamp. Изначально, когда я выложил отрывки логов, я этого не заметил, но, видимо, он думает, что сегодня 26 сентября, так что не знаю, может ли это быть проблемой? Или как это можно изменить, честно говоря.
 
Ты не покупал, но это было первое, что произошло, когда я подключился к коммутатору по SSH. Просто .88 был хостом, с которого я подключался, а не хостом, на котором работает Unifi Server.
 
Да ну, не имеет значения. Где я это вообще написал?
 
Спасибо! Не знал, что подключение по SSH сразу назначает подключающую машину точкой "inform", это полезно, потому что я изначально подключался не с сервера. Как только я подключу машину напрямую, чтобы изменить подсеть и смогу прочитать логи после отключения, сразу же сообщу об этом :) Я убираю коммутатор перед заводской сбросом. Нашел, что если не делать этого, то он пытается переподключить его сразу после сброса, и я половину раз его пропускаю.
 
Непринятые (unadopted) коммутаторы UniFi (в заводских настройках) превращаются в обычные коммутаторы. Так что то, что вы видите, вполне ожидаемо: все порты находятся в одной VLAN, без тегов, как и внутренний виртуальный интерфейс управления коммутатора. Вы кликнули "Remove" на коммутаторе в контроллере? Там могли остаться настройки, например, переопределение VLAN управления или конфигурации портов, которые мешают ему снова подключиться к контроллеру после получения конфигурации. Это соответствует тому, что ваш AP перестал работать, что также может быть вызвано изменением конфигурации VLAN на соответствующем порту коммутатора.
 
Зайди на устройство через SSH, запусти tail -f /var/log/messages и там должны быть ошибки.
Страницы: 1
Читают тему (гостей: 1)