Контроллер -> provision USG + цикл перезагрузки

Контроллер -> provision USG + цикл перезагрузки, UniFi Network

kinetix

Guest

04.01.2016 04:16:00

Сегодня у меня возникла странная ситуация, которую я пока не могу решить. Около недели назад я обновил контроллер с версии stable 4.7.6 до 4.8.9-7340, и, помимо некоторых мелких изменений в конфигурации USG между этими версиями, всё прошло довольно спокойно, и моя система работала тихо и стабильно. Сегодня на контроллере я включил гостевую Wi-Fi сеть, с которой однажды игрался, а потом выключил, так как она мне не была особо нужна. После включения и обнаружения, что что-то работает не так, я узнал, что тип гостевой сети стоит Corporate и его никак нельзя поменять. Тогда я удалил гостевую сеть и создал её заново уже с правильным типом.

С тех пор контроллер постоянно пытается применить настройки к USG, и USG постоянно перезагружается при обновлении конфигурации. Как мне известно, единственный способ остановить этот процесс — остановить контроллер. У меня включены откаты конфигурации, и сначала казалось, что контроллер просто добавляет пару правил в файрвол и сетевой адрес, но USG не очень это «любит», поэтому я сам закоммитил изменения и отправил json обратно на контроллер.

Теперь, кажется, в конфигурации ничего не меняется, а контроллер всё равно пытается применить настройки, из-за чего USG перезагружается каждый раз и при этом на несколько минут пропадает сервис. Вот что я вижу: последние несколько попыток обновления и перезагрузок создали такие откаты:

0 2016-01-03 12:02:20 root by boot-config-loader
1 2016-01-03 11:59:02 root by other
2 2016-01-03 11:57:44 root by boot-config-loader
3 2016-01-03 11:54:28 root by other
4 2016-01-03 11:47:30 root by boot-config-loader
5 2016-01-03 11:44:13 root by other
6 2016-01-03 11:42:54 root by boot-config-loader

kinetix@HomeUSG:~$ configure
[edit]
kinetix@HomeUSG# compare 1
[edit firewall group address-group unifi_controller_addresses]
-address 1.2.3.4
[edit service dns forwarding]
-options host-record=unifi,1.2.3.4
[edit unifi mgmt] >cfgversion d54f9c44f575feb7
[edit]
kinetix@HomeUSG# compare 2
No changes between working and revision 2 configurations
[edit]
kinetix@HomeUSG# compare 3
[edit firewall group address-group unifi_controller_addresses]
-address 1.2.3.4
[edit service dns forwarding]
-options host-record=unifi,1.2.3.4
[edit unifi mgmt] >cfgversion d54f9c44f575feb7
[edit]
kinetix@HomeUSG# compare 4
No changes between working and revision 4 configurations
[edit]
kinetix@HomeUSG# compare 5
[edit firewall group address-group unifi_controller_addresses]
-address 1.2.3.4
[edit service dns forwarding]
-options host-record=unifi,1.2.3.4
[edit unifi mgmt] >cfgversion d54f9c44f575feb7
[edit]
kinetix@HomeUSG# compare 6
No changes between working and revision 6 configurations
[edit]

Перед публикацией я заменил реальный IP контроллера на 1.2.3.4.

Есть идеи? Логи, кажется, стираются при перезагрузке, поэтому сейчас у меня нет подсказок, что именно вызывает проблему. Знаю, что есть и другие способы настроить USG, которые тоже приводят к загрузочному циклу с контроллером. Очень хотелось бы, чтобы Ubiquiti добавили функцию, которая запрещала бы перезагрузку при изменении конфигурации контроллером без одобрения администратора. Админ мог бы получать уведомления по почте или сразу в CLI или на контроллере, если тот сейчас в сети, но, честно говоря, перезагружать устройство из-за простой смены настроек просто не должно происходить никогда.

Что делать дальше?

UI-Team

Guest

03.12.2016 20:46:00

Пока не могу сказать точно, но это отличная информация, которая действительно сузила круг поиска. Спасибо за помощь.

Может ли быть возможность временно отключить IPsec VPN и поработать на проблемной прошивке достаточно долго, чтобы понять, исчезнет ли проблема? Это помогло бы еще больше сузить круг.

UI-Team

Guest

08.02.2017 11:32:00

Я объяснил суть проблемы, которая, собственно, является одной из присущих ограничений операционных систем в целом. Если вы перегружаете систему нагрузкой, которая обрабатывается внутри ядра, например, очень интенсивным использованием VPN на протяжении длительного времени, процессы в пользовательском пространстве начинают "захлёбываться" до такой степени, что пропускают уведомления. Из-за этого контроллер теряет связь. Это не та проблема, которую можно легко решить.

Есть небольшая разница в производительности между USG и ERL при использовании IPsec, которую нужно будет изучить подробнее. Это планируется сделать в рамках обновления до последней версии EdgeOS. Мы также постараемся одновременно выяснить, что можно сделать, чтобы минимизировать пропущенные уведомления.

Корень проблемы известен всего несколько недель. С учётом сложной истории USG, с которой я сейчас разбираюсь, мы всё ещё не решили вопросы, которые в некоторых случаях тянутся уже год и затрагивают намного больше пользователей, хотя их сейчас стало гораздо меньше. Поэтому мы пока не в состоянии ставить это в приоритет. Мы обязательно дойдём до этого, но на это потребуется время, так как проблема очень серьёзная и имеет ограниченное влияние по сравнению с другими нерешёнными задачами. Как только общая ситуация стабилизируется, решение подобных проблем пойдёт гораздо быстрее.

Я рекомендую то же, что и раньше: поскольку передаваемые данные уже зашифрованы и аутентифицированы, лучше передавать их через Интернет напрямую, а не через VPN.

oliverkadak Guest	#4 08.02.2017 10:51:00 Прошло уже несколько месяцев, а проблема с site-to-site VPN на USG так и не решена...

oliverkadak Guest	#5 25.01.2017 21:58:00 Проблема всё та же, и решения нет. При передаче данных через site-to-site VPN USG зависает и отключается. Это продолжается уже несколько месяцев, и я потерял связь также с @UBNT-cmb...

oliverkadak Guest	#6 18.01.2017 22:29:00 @UBNT-cmb, @UBNT-MikeD — мы всё ещё зависли на проблеме с отключениями site-to-site VPN... это уже затянулось...

Uberseehandel Guest	#7 05.01.2017 11:08:00 Иногда результат важнее, чем способ . . . UBNT рано или поздно доберется до цели . . .) R+C

oliverkadak

Guest

05.01.2017 11:01:00

@UBNT-cmb

Только сегодня удалось обнаружить одну из проблем с сбором мусора и продолжаю работать над вопросами с VPN (возможно, они связаны). Всё ещё вижу пропуски heartbeat и разрывы связи с замороженным трафиком, но, кажется, мы движемся в правильном направлении.

@Uberseehandel

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

Uberseehandel Guest	#9 05.01.2017 10:53:00 Пожалуйста, предоставьте текст для перевода.

oliverkadak

Guest

#10

04.01.2017 23:45:00

У меня начинает заканчиваться время, так как нужно синхронизировать много данных между двумя площадками к февралю, а, похоже, что USG не справляется с передачей данных через VPN на 100 Мбит/с, что совсем не то, чего я ожидал. Мне полностью вернули деньги за первый USG, который я купил, потому что дилер не захотел менять мой текущий. То же самое произошло с камерой USG Pro, которая работала с перебоями. Есть какие-то решения по этому поводу?

@UBNT-cmb

oliverkadak

Guest

#11

14.12.2016 11:39:00

@UBNT-cmb, какие новости по этому поводу? Я уже отправил первый USG по гарантии (он тоже странно вел себя в других моментах), а сейчас новый, который я только что купил, я не могу использовать как планировал... ИЗМЕНЕНИЕ: Похоже, это затянется до следующего года 😲

oliverkadak Guest	#12 06.12.2016 06:34:00 Спасибо, просто чтобы уточнить — соединение с основным сайтом 100/100 Мбит/с, так что это теоретический максимум для IPsec site-to-site.

UI-Team

Guest

#13

06.12.2016 00:47:00

Спасибо за помощь, @oliverkadak, я сейчас ищу источник регресса и скоро свяжусь с вами.

Рутину с «пропущенным сигналом» и «отключением» можно объяснить тем, что система находится под таким сильным нагрузкой (сотни Мбит IPsec через USG3), что она просто не успевает обрабатывать сигналы — аппаратных ресурсов не хватает. Не думаю, что это что-то серьёзное, скорее просто раздражает, потому что в такой ситуации вы будете пропускать обновления статистики, но я подумаю над возможными вариантами решения.

oliverkadak

Guest

#14

04.12.2016 09:03:00

Надеюсь, это просто банальная ошибка в коде. Сегодня займусь своим устройством. ОБНОВЛЕНИЕ: пока всё ещё застрял на версии 4.3.15, и @UBNT-cmb, надеюсь, скоро поможет разобраться. Мы сузили проблему с прошивкой как минимум до следующего: в версии 4.3.16, самой старой из первых, происходит сбой уже через 5 минут; версия 4.3.15 тоже ломается (Heartbeat missed, Disconnecting) при большой нагрузке на VPN site-to-site, но соединения остаются (буду дополнять).

scyto

Guest

#15

03.12.2016 23:24:00

@UBNT-cmb

Решил проблему. Хотя в интерфейсе отображалась правильная информация, в файле system.cfg был показан порт 0. Удалил одну цифру порта в интерфейсе, потом добавил её обратно и нажал «сохранить» (важно: изменялось поле, не было двух отдельных сохранений). В итоге правильные данные записались в system.cfg. Это вызвало автоматическое повторное развертывание и перезагрузку.

Вопросы: если бы чёртова версия лога в интерфейсе показывала ошибку с номером порта, я бы давно (неделями раньше) нашёл решение — улучшите, пожалуйста, отображение лога в UI. Что вообще может вызвать ситуацию, когда интерфейс показывает одни параметры, а в system.cfg — совсем другие? Это явно указывает на серьёзную проблему с проверкой данных или с кодом управления изменениями.

С уважением, Алекс.

P.S. Вот конец файла .cfg, где была ошибка (буквально в самом конце). Не припомню точно, был ли только порт равен 0 или и ключ тоже был пустым:

"vpn" : { "pptp" : { "remote-access" : { "authentication" : { "mode" : "radius" , "radius-server" : { "192.168.1.48" : { "key" : "redacted" , "port" : "0"}}} , "client-ip-pool" : { "start" : "192.168.50.1" , "stop" : "192.168.50.254"} , "dns-servers" : { "server-1" : "192.168.1.1"}}}}}

scyto

Guest

#16

03.12.2016 23:07:00

@UBNT-cmb

В прошлый раз, когда мы переписывались, вы попросили меня удалить неправильный VPN-профиль. В интерфейсе отображается только один (см. скриншот), но в логах сервера есть такие ошибки:
[2016-12-03 14:48:45,790] <inform-20> ERROR dev - [commit errors] dev[80:2a:a8:4c:66:d2], { "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "6a50a1510898e8727dc8f08298" , "SET" : { "error" : { "vpn pptp remote-access authentication radius-server 192.168.1.48 port 0" : "Port number must be in range 1 to 65535\n\nValue validation failed\n"} , "failure" : "1" , "success" : "1"}}
[2016-12-03 14:49:28,892] <inform-21> ERROR dev - [commit errors] dev[80:2a:a8:4c:66:d2], { "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "6a50a1510898e8727dc8f08298" , "SET" : { "error" : { "vpn pptp remote-access authentication radius-server 192.168.1.48 port 0" : "Port number must be in range 1 to 65535\n\nValue validation failed\n"} , "failure" : "1" , "success" : "1"}}
[2016-12-03 14:50:12,175] <inform-7> ERROR dev - [commit errors] dev[80:2a:a8:4c:66:d2], { "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "6a50a1510898e8727dc8f08298" , "SET" : { "error" : { "vpn pptp remote-access authentication radius-server 192.168.1.48 port 0" : "Port number must be in range 1 to 65535\n\nValue validation failed\n"} , "failure" : "1" , "success" : "1"}}
[2016-12-03 14:50:55,359] <inform-5> ERROR dev - [commit errors] dev[80:2a:a8:4c:66:d2], { "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "6a50a1510898e8727dc8f08298" , "SET" : { "error" : { "vpn pptp remote-access authentication radius-server 192.168.1.48 port 0" : "Port number must be in range 1 to 65535\n\nValue validation failed\n"} , "failure" : "1" , "success" : "1"}}

Дело в том, что порт явно указан и он правильный:

scyto

Guest

#17

03.12.2016 22:51:00

@UBNT-cmb

Окей, я разобрался, как пользоваться терминалом и командой upgrade alias. Прошивка обновлена. Но всё ещё застрял в состоянии «provisioning». Что бы ни вызывало мою проблему — оно осталось. Кстати, теперь у меня контроллер версии 5.4.3 с тех пор, как мы последний раз переписывались. Алекс

scyto

Guest

#18

03.12.2016 22:41:00

@UBNT-cmb

Я пытался забыть USG и нажать перезагрузку с повторным подключением. Это не помогло. Я пробовал обновить через интерфейс, но номер прошивки так и не меняется с 4.3.30 на 4.3.31 — я использую ссылку и вставляю её в интерфейс для обновления https://dl.ubnt-ut.com/cmb/ER-e120-upgrade-v4.3.31dev.4934639.161128.1958.tar — нужно ли делать что-то иначе, ведь это не bin-файл?

oliverkadak

Guest

#19

03.12.2016 20:43:00

Ладно, теперь это действительно странно. После отката с версии .16 на .15 у меня снова постоянный цикл: отключено > настройка > подключено > отключено. Почти как с предыдущим USG, но при этом все соединения (между сайтами и в интернет) вроде работают. USG отвечает на пинг, можно зайти через ssh, но в контроллере он показывает статус "отключено". В .16 что-то действительно вредное и опасное 😲 Стоит ли сделать полный сброс USG и заново его настраивать? Отключение от питания и повторное включение не помогло.

oliverkadak Guest	#20 08.02.2017 12:53:00 Хорошо. Я не знал, что у USG сейчас такая ужасная ситуация — избегал бы этот продукт какое-то время. Как мы уже обсуждали, скорость передачи здесь 6 МБ/сек, так что это на самом деле не что-то сверхбыстрое. Удачи в решении проблем, посмотрим, когда мы дойдём до того момента, когда смогу использовать устройства Ubiquity для реальной синхронизации двух NAS по VPN.

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