После замены домашнего роутера основная сеть заработала: открывались сайты, были доступны серверы, устанавливались соединения между сетями. Но одна проверка видеонаблюдения в Uptime Kuma продолжала показывать проблему.

При этом само видеонаблюдение работало. Контейнер был запущен, камеры обрабатывались, свободное место для записи оставалось. Нужно было выяснить, почему исправный сервис не может сообщить о своём состоянии.

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

Почему я решил заменить роутер

Домашняя сеть постепенно выросла: появились отдельные сегменты для устройств и серверов, межсетевые правила, VPN-соединения и несколько сервисов с доступом извне. Всё это обслуживал MikroTik RB2011.

Перед заменой я проверил его нагрузку. С открытым окном соединений WinBox процессор временами загружался до 100%. Сам интерфейс управления заметно влиял на показания, поэтому я повторил наблюдение после закрытия WinBox: загрузка обычно составляла 22–41%, с отдельным пиком до 74%.

Более показательной оказалась передача данных между двумя локальными сегментами. В контрольном HTTP-тесте я получил около 73 Мбит/с при загрузке процессора примерно 98,5%. Для этого теста ограничение уже было ощутимым.

Я решил заменить RB2011 на RB5009, чтобы получить больше запаса для существующей сети. При этом мне требовалось сохранить накопленные настройки: сегменты сети, выдачу адресов, DNS, правила доступа и соединения между площадками.

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

Почему я проверял не только доступность серверов

После переноса легко ограничиться несколькими очевидными тестами: открыть сайт, подключиться к серверу, проверить интернет. Я тоже начал с них, но затем посмотрел на мониторинг.

Большинство проверок восстановилось. Одна — проверка состояния видеонаблюдения — оставалась без свежего результата.

Это была push-проверка: скрипт рядом с сервисом проверял его состояние и отправлял результат в Uptime Kuma. Поэтому отсутствие нового сигнала ещё не означало, что перестали работать камеры. Неисправность могла находиться на любом участке этой цепочки.

Я проверил её по частям:

  • работает ли сам сервис;
  • выполняется ли локальная проверка;
  • доступен ли сервер мониторинга;
  • завершается ли отправка результата.

Сервис оказался исправен, а сервер мониторинга был доступен по сети. Дальнейшая проверка вывела меня на зависание при обращении к API Telegram из обработчика мониторинга.

Правило перенеслось, а список — не полностью

В конфигурации MikroTik правило может ссылаться на список адресов — address-list. Так удобнее объединять несколько адресов или сетей, которым требуется одинаковая обработка.

Но правило и содержимое списка — разные объекты конфигурации.

Например, в обезличенном виде правило может использовать список SERVICE_DESTINATIONS. Наличие такого правила ещё не подтверждает, что в самом списке есть все нужные назначения.

После переноса у меня сохранились правила, ссылавшиеся на списки адресов. Однако часть записей в этих списках отсутствовала. Из-за этого трафик не всегда попадал под предусмотренную обработку.

При беглом просмотре конфигурация выглядела убедительно: знакомые правила были на месте. Ошибка обнаружилась при сравнении их зависимостей с исходным роутером.

Как записи потерялись при подготовке конфигурации

Для переноса я использовал скрипт подготовки конфигурации. Он разбирал экспорт старого роутера и собирал настройки для нового устройства.

В экспорте длинные команды могут переноситься на несколько строк. Между знаком = и значением параметра после обработки такого переноса мог оставаться пробел.

Мой разборщик ожидал более строгую запись. Он не учитывал этот вариант для параметра list=, а также для ссылок src-address-list= и dst-address-list=.

В результате часть записей и зависимостей не распознавалась.

Это была ошибка моего скрипта подготовки. Новый роутер получил неполный набор данных, хотя сами правила обработки трафика присутствовали.

Всего я обнаружил 41 пропущенную активную статическую запись в девяти используемых списках.

Почему я не стал повторно импортировать всю конфигурацию

К моменту обнаружения ошибки основная сеть уже работала. Полный повторный импорт затронул бы гораздо больше настроек, чем требовалось для исправления.

Я сохранил резервную копию текущей конфигурации и сравнил содержимое списков по парам «имя списка — адрес».

Так я получил конкретный перечень недостающих записей. Восстановил только их, не заменяя конфигурацию целиком.

Отдельно я исправил разборщик: добавил учёт пробелов после = в соответствующих параметрах. Затем заново сформировал подготовленную конфигурацию и использовал её для проверки. Повторно импортировать весь полученный файл на работающий роутер не потребовалось.

Для меня здесь было важно исправить обе части: восстановить настройки на устройстве и убрать ошибку из инструмента, которым я готовил перенос.

Что я проверил после восстановления

Сначала я повторил сравнение списков. Недостающих записей больше не было.

Затем вернулся к исходному симптому — проверке видеонаблюдения.

До исправления обращение из системы мониторинга к API Telegram зависало на установлении соединения. После восстановления списков HTTPS-запрос завершился с успешной проверкой TLS-сертификата.

Штатная проверка видеонаблюдения тоже отработала: подтвердила доступность API сервиса, работу детектора, наличие двух камер и свободного места для записи.

В Uptime Kuma появился свежий успешный результат. Все 46 активных проверок, без учёта групп, находились в состоянии UP.

Это подтвердило, что устранён исходный сбой: исправный сервис снова смог передать результат своей проверки в мониторинг.

Отдельное тестовое сообщение в Telegram я в этой проверке не отправлял. Поэтому восстановление HTTPS-доступа к API и успешный heartbeat я не подменяю утверждением о прочтении уведомления на телефоне.

С каким результатом я закончил

Я восстановил 41 пропущенную запись, исправил обработку экспорта в скрипте и повторным сравнением подтвердил полноту списков. Проверка видеонаблюдения восстановилась, а все активные проверки мониторинга показывали UP.

Это завершённое исправление конкретной ошибки переноса. Оно не означает, что одним таким тестом проверены все функции нового роутера: для остальных направлений нужны собственные проверки.

Главный вывод для меня — проверять не только наличие правил, но и данные, на которые они ссылаются. Внешне знакомая конфигурация может оказаться неполной, а несколько успешно открывшихся сайтов этого не покажут.

В этот раз до ошибки меня довела одна проверка, которая не восстановилась вместе с остальными. Хорошо, что я разобрался с ней до того, как стал считать перенос законченным.