Фантомный IP у Dahua: почему регистратор появляется в сети с двумя адресами

Видеонаблюдение давно перестало быть простой схемой «камера, провод, монитор, сторож с термосом». Современный объект похож на маленький дата-центр: IP-камеры, регистраторы, PoE-коммутаторы, VLAN, VPN, облако, мобильные приложения, распознавание лиц, номера машин, тревожные события, проброс портов, удаленный доступ и роутер, который в углу делает вид, что он все это контролирует.

И вот в такую, казалось бы, понятную инфраструктуру приезжает регистратор Dahua. Один Ethernet-порт. Один MAC-адрес. Один назначенный IP. Все должно быть скучно. Но скучно не будет.

Регистратору задают статический адрес, например 192.168.0.245. Он появляется в сети. Но рядом внезапно всплывает еще один адрес, например 192.168.0.244, с тем же самым MAC-адресом. Меняешь регистратору IP на .244, фантомный адрес смещается на .243. Включаешь DHCP, регистратор получает .112, но старый фантом все равно продолжает светиться. Локально устройство пингуется по обоим адресам. А вот проброс портов, доступ из другой подсети и маршрутизация начинают вести себя так, будто сетевой стек ушел на обед и оставил вместо себя стажера.

Это не мистика. Это ARP. А ARP, как известно, штука древняя, простая и поэтому особенно опасная. Как табуретка: вроде надежно, но если подставить не туда, падают все.

Суть проблемы

В нормальной IP-сети один адрес должен соответствовать одному устройству. На практике связь выглядит так:

192.168.0.245 -> AA:BB:CC:DD:EE:FF

Где 192.168.0.245 это IP-адрес регистратора, а AA:BB:CC:DD:EE:FF его MAC-адрес.

При фантомном IP картина становится другой:

192.168.0.245 -> AA:BB:CC:DD:EE:FF

192.168.0.244 -> AA:BB:CC:DD:EE:FF

Один и тот же MAC отвечает сразу за два IP-адреса. Это не классический конфликт IP, где два разных устройства дерутся за один адрес. Здесь один регистратор как будто говорит: «Я и там, и тут. И вообще я сеть».

Для обычного коммутатора это может выглядеть безобидно. MAC один, порт один, петли нет, шторм не начался. Но маршрутизатор видит ситуацию иначе. Ему нужно строить таблицу соседей, обслуживать DHCP, NAT, проброс портов, VPN, межсетевые правила, список клиентов, иногда mesh, иногда WOL, иногда еще десяток внутренних сервисов. Когда одно устройство внезапно оказывается на двух адресах, логика становится грязной.

Локально камера или регистратор могут открываться по обоим IP. Но при доступе извне начинается лотерея: сегодня проброс работает, завтра нет, через соседнюю подсеть открывается один порт, другой зависает, мобильное приложение видит устройство, веб-интерфейс не видит, а роутер смотрит в таблицу ARP и явно жалеет, что вообще включился.

Почему это особенно неприятно в видеонаблюдении

В офисной сети фантомный IP может раздражать. В видеонаблюдении он может ломать эксплуатацию.

Регистратор это не просто еще один клиент сети. На него часто завязаны:

удаленный доступ;
просмотр архива;
мобильное приложение;
проброс RTSP, HTTP, HTTPS или сервисных портов;
интеграция с VMS;
облачный P2P;
доступ охраны;
доступ службы безопасности;
VPN-доступ подрядчика;
мониторинг доступности;
иногда интеграция с СКУД, шлагбаумами и тревожными системами.

Если у регистратора плавает сетевое поведение, проблема выглядит не как «в ARP-таблице странная запись», а как «у заказчика опять не работает удаленный просмотр». А это уже совсем другой уровень боли. ARP инженер может объяснить. Заказчик ARP не покупал. Он покупал «чтобы камеры работали».

Особенно неприятно, что локальная работа часто сохраняется. Запись идет, камеры видны, монитор у охраны показывает картинку. Поэтому дефект кажется не критичным. Но как только появляется L3-доступ, VPN, проброс портов или доступ из другого сегмента, сетевой скелет начинает хрустеть.

Реальный пример: Dahua NVR и адрес-призрак

Типичный сценарий выглядит так.

Есть регистратор Dahua 4116-4KS3. Не PoE. Один физический сетевой интерфейс. Один MAC-адрес. Ему задают статический IP, например:

192.168.0.245

Но в сети он появляется еще и как:

192.168.0.244

Меняем основной адрес на .244. Фантом смещается на .243.

Ставим DHCP. Регистратор получает, например:

192.168.0.112

Но фантомный адрес продолжает жить где-то рядом, как старый домовой из подсети.

Самое интересное: оба адреса пингуются из локальной сети. На оба может отвечать один и тот же MAC. Но при доступе из другой сети или через проброс портов начинается нестабильность. Роутер то видит устройство, то видит его не там, то строит таблицу клиентов странным образом, то начинает обновлять ARP-записи, которые лучше бы не трогать.

На первый взгляд можно подумать: виноват роутер. Сначала стоял TP-Link, проброс не получился. Поставили Keenetic, стало видно больше деталей, и метаморфоза проявилась во всей красоте. Но это не обязательно значит, что виноват Keenetic. Часто хороший роутер просто лучше показывает проблему. Он как врач с нормальным томографом: болезнь не он придумал, он ее увидел.

ARP: маленький протокол, большая головная боль

Чтобы понять проблему, нужно вспомнить ARP.

Когда компьютер хочет отправить пакет на 192.168.0.245, он должен узнать MAC-адрес устройства. Для этого он отправляет широковещательный запрос:

Кто имеет 192.168.0.245?

Устройство с этим IP отвечает:

192.168.0.245 это я, мой MAC AA:BB:CC:DD:EE:FF

После этого отправитель записывает связку в ARP-таблицу и передает трафик уже на конкретный MAC.

Проблема начинается, когда устройство отвечает не только за свой IP, но и за чужой, старый, внутренний или служебный адрес. Тогда в ARP-таблице появляются ложные соответствия.

Для одной подсети это еще может кое-как жить. Но ARP не маршрутизируется. Он работает внутри L2-сегмента. Когда трафик приходит из другой сети, через NAT или VPN, все решения принимает роутер. А роутеру нужна чистая картина: вот IP, вот MAC, вот интерфейс, вот правило. Если вместо этого он видит один MAC на двух адресах, стабильность становится делом веры.

А вера, как известно, плохо документируется в сетевых схемах.

Dahua ARP/Ping IP set service: полезная функция, которая может выйти из берегов

У Dahua есть сервисная функция, которая позволяет назначать или изменять IP-адрес устройства через ARP/Ping, если известен MAC-адрес. Идея понятна: инженер приезжает на объект, устройство в непонятной подсети, доступ потерян, нужно быстро вернуть управление.

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

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

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

Это классический случай из мира инженерии: молоток полезен, пока им забивают гвозди. Если молоток сам бегает по объекту и стучит в шкафы, это уже не инструмент, а заявка в техподдержку.

Откуда может взяться второй адрес

У современных регистраторов внутри не «железная коробка с веб-мордой», а полноценная встраиваемая Linux-система. Там могут быть физические интерфейсы, виртуальные интерфейсы, bridge, служебные сетевые механизмы, внутренние сервисы автонастройки, P2P-модули, ONVIF, RTSP, HTTP-сервер, discovery-сервисы и многое другое.

Даже если снаружи у регистратора один Ethernet-порт, внутри логика может быть сложнее. В некоторых моделях есть режимы для нескольких сетевых интерфейсов, fault tolerance, load balancing, отдельные внутренние подсети для PoE-камер, виртуальные мосты и служебные адреса.

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

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

Это не официальное вскрытие Dahua с осциллографом и доступом к исходникам. Это инженерная гипотеза, которая хорошо объясняет симптомы: один MAC, два IP, смещение фантома, реакция на ARP-активность, исчезновение проблемы после изоляции устройства в отдельный сегмент.

Почему часто всплывает .254

Адрес .254 в подсети /24 формально обычный адрес хоста. Например, в сети 192.168.0.0/24 адреса 192.168.0.1 и 192.168.0.254 одинаково допустимы для устройств. Но реальная жизнь, как обычно, плюет на формальную красоту.

Адреса в конце диапазона любят использовать:

роутеры;
mesh-узлы;
служебные сетевые механизмы;
временные recovery-режимы;
WOL-сценарии;
старое оборудование;
инженеры, которые «всегда так делали»;
автоматические функции, которые никто не вспоминает до аварии.

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

Если Dahua сама начинает фантомно светиться на .254, конфликт может быть не только с другим устройством, но и с внутренней логикой роутера. Например, роутер может использовать верхние адреса для своих задач, сканировать сеть, строить карту клиентов, обслуживать mesh или WOL. И тогда фантомный ответ регистратора становится не просто странностью, а активным раздражителем для всей сети.

Роль роутера: виноват или просто увидел?

В подобных случаях часто начинается спор: «Это Dahua виновата или роутер?»

Ответ неприятный: иногда оба участвуют, но виноват не обязательно роутер.

Роутер отправляет ARP-запросы, ищет клиентов, обновляет таблицы, ведет DHCP, поддерживает NAT и маршрутизацию. Это нормальное поведение. Если регистратор некорректно отвечает на ARP-запросы, роутер просто фиксирует то, что происходит.

Keenetic может чаще проявлять проблему, потому что активно ведет список клиентов и сканирует сеть. MikroTik позволяет быстрее увидеть это через /ip arp. TP-Link может просто не показывать красиво, но проброс портов все равно будет ломаться.

То есть роутер в этой истории часто не поджигатель, а пожарная сигнализация. Просто сигнализация орет, а все смотрят на нее с подозрением.

Почему проброс портов начинает работать нестабильно

Port forwarding требует однозначности. Есть внешний порт, есть внутренний IP, есть внутренний порт. Например:

Внешний порт 8080 -> 192.168.0.245:80

Если регистратор реально живет на 192.168.0.245, все понятно. Но если он одновременно отвечает как 192.168.0.244, роутер может видеть одну физическую машину в двух логических ролях. Особенно если список клиентов, ARP-таблица и NAT-правила обновляются в разное время.

Добавим сюда DHCP, статические привязки, старые записи, mesh, ARP-сканирование, мобильное приложение, P2P, сервисные порты Dahua, и получим прекрасный суп из сетевых состояний. Такой суп обычно не едят, его диагностируют.

Снаружи это выглядит просто: «Не открывается регистратор». Или еще хуже: «Иногда открывается». Сетевики знают: «иногда» страшнее, чем «никогда». Когда не работает никогда, можно чинить. Когда работает иногда, оно еще и издевается.

Как распознать именно этот тип проблемы

Есть несколько характерных признаков.

Первый: у регистратора один физический Ethernet-порт, но в сети он виден по двум IP-адресам.

Второй: у обоих IP одинаковый MAC-адрес.

Третий: локальный ping проходит по обоим адресам.

Четвертый: при смене основного IP фантомный адрес смещается или сохраняется.

Пятый: при переходе на DHCP основной адрес меняется, но фантом остается.

Шестой: удаленный доступ, port forwarding или доступ из другой подсети работают нестабильно.

Седьмой: после изоляции регистратора в отдельный сегмент или уменьшения широковещательной активности фантом может исчезнуть.

Восьмой: в логах роутера или ARP-таблице появляются странные записи на .254, .253 или соседних адресах.

Если совпало несколько пунктов, это уже не «показалось». Это сетевое поведение, которое надо фиксировать и предъявлять прошивке, а не лечить танцами вокруг DHCP.

Базовая диагностика на Windows

Самый простой способ начать проверку: посмотреть ARP-таблицу с обычного компьютера в той же подсети.

Сначала очищаем ARP-кэш:

arp -d *

Пингуем основной адрес регистратора:

ping 192.168.0.245

Пингуем подозрительный фантомный адрес:

ping 192.168.0.244

Смотрим ARP-таблицу:

arp -a

Если видим что-то вроде:

192.168.0.245 aa-bb-cc-dd-ee-ff
192.168.0.244 aa-bb-cc-dd-ee-ff

это почти чистое признание. Один MAC отвечает за два IP.

На Windows 10/11 можно использовать PowerShell:

Get-NetNeighbor -AddressFamily IPv4 | Sort-Object IPAddress | Format-Table IPAddress,LinkLayerAddress,State,InterfaceAlias

Нужно искать одинаковый LinkLayerAddress у разных IP-адресов.

Диагностика через Wireshark

Если нужно доказательство железобетоннее, запускаем Wireshark.

Фильтр:

arp && eth.addr == AA:BB:CC:DD:EE:FF

Где AA:BB:CC:DD:EE:FF это MAC-адрес регистратора.

Дальше смотрим, на какие запросы отвечает Dahua. Если в сети идет запрос:

Who has 192.168.0.244?

а Dahua отвечает:

192.168.0.244 is at AA:BB:CC:DD:EE:FF

при том что основной адрес регистратора другой, проблема подтверждена. Это уже не «роутер показывает странно», а само устройство объявляет себя владельцем фантомного адреса.

Также стоит смотреть gratuitous ARP. Если регистратор сам рассылает объявления о втором адресе, это еще сильнее указывает на проблему в его сетевом стеке или служебной логике.

Полевая диагностика на MikroTik

На объектах удобно иметь быстрый индикатор. Особенно если инженер ездит с походным MikroTik hEX для ПНР. Маленькая коробка, большой характер. Почти как мультиметр, только ругается пакетами.

Базовый скрипт для проверки подозрительного .254:

:local targetIp "192.168.88.254"

:local activeMac [/ip arp get [/ip arp find where address=$targetIp] mac-address]

/log info "DAHUA BUG DETECTED: virtual bridge is active on .254, MAC: $activeMac"

Лучше сделать безопаснее, чтобы скрипт не падал, если записи нет:

:local targetIp "192.168.88.254"

:local arpId [/ip arp find where address=$targetIp]

:if ([:len $arpId] > 0) do={

:local activeMac [/ip arp get $arpId mac-address]

/log warning ("DAHUA ARP anomaly detected: phantom IP " . $targetIp . " is active, MAC: " . $activeMac)

} else={

/log info ("DAHUA ARP check: no ARP record for " . $targetIp)

}

Для проверки нескольких верхних адресов:

:foreach targetIp in={"192.168.88.254";"192.168.88.253";"192.168.88.252"} do={

:local arpId [/ip arp find where address=$targetIp]

:if ([:len $arpId] > 0) do={

:local activeMac [/ip arp get $arpId mac-address]

/log warning ("DAHUA ARP anomaly detected: phantom IP " . $targetIp . " is active, MAC: " . $activeMac)

}

Такой скрипт не лечит проблему. Он нужен, чтобы быстро поймать симптом. Это как табличка «Осторожно, люк». Люк от нее не исчезает, но хотя бы понятно, куда не наступать.

Что делать в первую очередь

Первое действие: отключить Dahua ARP/Ping IP set service.

В меню регистратора нужно искать пункт примерно такого смысла:

Network
TCP/IP
Ethernet
Enable ARP/Ping to set device IP address service

После отключения:

сохранить настройки;
перезагрузить регистратор;
очистить ARP-кэш на компьютере;
проверить ARP-таблицу на роутере;
пропинговать основной и фантомный адреса;
убедиться, что один MAC больше не отвечает за два IP.

Если функция была источником проблемы, фантом должен исчезнуть или хотя бы перестать стабильно воспроизводиться.

Почему иногда нужна перепрошивка и сброс

Если отключение ARP/Ping service не помогло, следующий шаг: прошивка.

Но не «обновить по воздуху и надеяться». У Dahua, как и у многих производителей видеонаблюдения, прошивки зависят от точной модели, аппаратной ревизии, региона, языка и линейки. Две коробки с похожим названием могут требовать разные файлы. А автообновление может поставить не самую свежую, не самую подходящую или просто доступную для конкретного канала версию.

Правильный порядок:

уточнить точную модель регистратора;
проверить аппаратную ревизию;
найти подходящую прошивку у поставщика или производителя;
обновить вручную;
сделать factory reset;
не импортировать старый конфиг без необходимости;
заново настроить сеть руками;
сразу отключить ARP/Ping service;
проверить ARP-таблицу.

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

Импорт старого конфига после сброса тоже риск. Можно аккуратно вернуть все настройки и вместе с ними вернуть сетевую нечисть. Романтично, но бесполезно.

Адресация: не ставьте регистратор на .254

Один из практических выводов: не используйте верхние адреса подсети для регистраторов и камер, особенно .254, .253, .252.

Да, формально можно. Нет, лучше не надо.

Нормальная схема для небольшого объекта может выглядеть так:

Роутер: 192.168.0.1
Сетевое: 192.168.0.2-19
NVR: 192.168.0.20
Камеры: 192.168.0.30-80
DHCP pool: 192.168.0.100-199
Резерв: 192.168.0.200-239
Не трогать: 192.168.0.240-254

Это скучно. А скучная адресация в видеонаблюдении прекрасна. Сеть должна быть скучной. Веселым пусть будет рекламный ролик, а не ARP-таблица.

Лучшее решение: отдельный CCTV-сегмент

Самый правильный архитектурный подход: выносить видеонаблюдение в отдельный сегмент или VLAN.

Например:

Офисная сеть: 192.168.0.0/24
CCTV-сеть: 192.168.50.0/24
NVR: 192.168.50.10
Камеры: 192.168.50.20-80
Доступ: через firewall или VPN

Преимущества очевидны:

ARP-шум от камер и регистраторов не попадает в офисную сеть;
камеры не видят пользовательские устройства;
пользователи не видят камеры напрямую;
проще писать firewall-правила;
проще диагностировать;
меньше конфликтов с mesh, WOL и бытовой сетевой автоматикой;
выше безопасность.

На крупных объектах это не рекомендация, а базовая гигиена. Камеры и регистраторы не должны жить в одной плоской сети с бухгалтерией, Wi-Fi для гостей, телевизорами, принтерами и кофемашиной, которая тоже, вероятно, уже хочет в облако.

VPN вместо прямого проброса

Прямой проброс портов на регистратор это быстрый путь. Иногда слишком быстрый. Примерно как оставить ключ под ковриком и написать на двери «ключ под ковриком».

Лучше использовать VPN:

WireGuard;
L2TP/IPsec;
OpenVPN;
VPN на Keenetic;
VPN на MikroTik;
корпоративный site-to-site VPN.

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

Если прямой проброс все же нужен, его надо делать только после проверки ARP:

у регистратора один IP;
в ARP-таблице нет фантомного адреса;
ARP/Ping service отключен;
прошивка актуальна;
IP не находится в верхнем конфликтном диапазоне;
роутер видит устройство однозначно.

И только потом настраивать NAT.

IP/MAC binding: полезный костыль, но не лекарство

На роутере можно сделать статическую привязку IP/MAC. Это иногда помогает стабилизировать поведение маршрутизатора и списка клиентов. Но важно понимать ограничение: если сам регистратор продолжает отвечать за фантомный IP, привязка не исправляет сетевой стек Dahua.

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

IP/MAC binding можно использовать как дополнительную меру, но не вместо отключения ARP/Ping service, обновления прошивки, сброса и нормальной сегментации.

Что не стоит делать

Не надо бесконечно менять IP туда-сюда. Если фантом смещается вслед за основным адресом, проблема не в том, что вы выбрали «плохой» IP. Проблема глубже.

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

Не надо считать, что если локально пингуется, значит все хорошо. Локальный ping в одной подсети не доказывает корректную L3-работу.

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

Не надо импортировать старый конфиг после сброса, не проверив сеть.

Не надо открывать Dahua напрямую в интернет, если можно сделать VPN.

Не надо игнорировать фантомный IP только потому, что «архив пишет». Сегодня пишет. Завтра не откроется удаленно. Послезавтра кто-то будет объяснять директору, почему «на телефоне опять нет камер».

Контрольный чек-лист после исправления

После всех работ нужно проверить:

1. Регистратор отвечает только на один IP.

2. Один IP соответствует одному MAC.

3. Фантомные .254, .253 или соседние адреса не появляются.

4. После перезагрузки регистратора фантом не возвращается.

5. После перезагрузки роутера фантом не возвращается.

6. После ARP-сканирования фантом не возвращается.

7. Доступ из соседней подсети стабилен.

8. VPN-доступ стабилен.

9. Проброс портов, если он используется, работает предсказуемо.

10. В списке клиентов роутера нет дублей одного MAC на разных IP.

Отдельно стоит сохранить скриншоты ARP-таблицы, версию прошивки и сетевую схему. Это поможет, если придется обращаться в техподдержку или объяснять проблему поставщику.

Как описать проблему для техподдержки

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

Пример формулировки:

На NVR Dahua 4116-4KS3 с одним физическим Ethernet-интерфейсом наблюдается некорректное ARP-поведение. Устройство с одним MAC-адресом отвечает в LAN сразу за два IPv4-адреса. После изменения статического IP фантомный адрес смещается или сохраняется. При DHCP основной IP меняется, но фантомный IP продолжает появляться. Локальный ping работает по обоим адресам, но L3-доступ, port forwarding и доступ из соседней подсети нестабильны. Просим предоставить актуальную прошивку или инструкцию по полному отключению ARP/Ping IP setup service и связанных служебных сетевых механизмов.

К заявке полезно приложить:

модель устройства;
серийный номер;
версию прошивки;
схему сети;
скриншот ARP-таблицы;
Wireshark-дамп ARP-ответов;
описание шагов воспроизведения;
информацию о роутере и подсети;
результаты проверки после factory reset.

Чем меньше в заявке «оно чудит» и чем больше «один MAC отвечает на два IP, вот дамп», тем выше шанс получить не шаблонный ответ.

Более широкий вывод для видеонаблюдения

История с Dahua это не только история про Dahua. Это пример более общей проблемы в IP-видеонаблюдении: камеры и регистраторы стали полноценными сетевыми устройствами, но к ним все еще часто относятся как к «железкам для картинки».

А это уже не просто железки. Это Linux внутри, сетевые сервисы, ONVIF, RTSP, HTTP, P2P, облачные агенты, discovery-протоколы, multicast, ARP, DHCP, UPnP, NTP, DNS, иногда SSH/Telnet в прошлом, иногда странные сервисные механизмы, о которых вспоминают только в момент аварии.

Современная система видеонаблюдения должна проектироваться как IT-система. С адресным планом, сегментацией, журналированием, политикой обновлений, резервным доступом, VPN, мониторингом, нормальной документацией и пониманием, что «воткнули в роутер» это не архитектура. Это начало расследования.

Итоги

Фантомный IP у регистратора Dahua не всегда убивает объект. Камеры могут писать, монитор может показывать, локальный доступ может работать. Но для удаленного доступа, проброса портов и маршрутизации это неприятный дефект. Он превращает простую задачу «открыть регистратор снаружи» в сетевой квест с ARP-таблицами, Wireshark и философскими вопросами к прошивке.

Главные правила простые:

проверяйте ARP-таблицу;
не используйте .254 для NVR;
отключайте ARP/Ping IP set service;
обновляйте прошивку вручную и осознанно;
после серьезных сетевых глюков делайте factory reset;
не тащите старый конфиг без проверки;
выносите CCTV в отдельный VLAN;
используйте VPN вместо прямого проброса;
фиксируйте проблему дампами, а не только словами.

Видеонаблюдение давно стало частью сетевой инфраструктуры. А значит, к нему нужно относиться как к сети. Иначе однажды регистратор решит, что у него два IP, роутер решит, что ему хватит, а инженер снова достанет походный MikroTik, откроет ARP-таблицу и тихо произнесет древнюю монтажную мантру: «Ну вот, опять Dahua разговаривает с подсетью».