Камери NVR зникають через VPN? Перевірте перекриття підмережі PoE

Відкрийте NVR з віддаленого майданчика, і живий перегляд може не працювати, поки сторінка LAN ще завантажується. Тунель піднятий, реєстратор відповідає, а відповідь іде шляхом, який ніхто не малював: через внутрішній порт камери реєстратора. У моделі з PoE ця друга підключена мережа входить до плану адрес, незалежно від того, чи відображається вона на головній сторінці налаштувань LAN.

Простежте збій від клієнта до реєстратора й назад. Саме на зворотному відрізку з'являється прихований інтерфейс.

Відтворюйте з віддаленого клієнта, а не з LAN

Перевіряйте з клієнта, який справді проходить через VPN. Браузер у тій самій LAN потрапляє до реєстратора напряму, тому ніколи не проходить збійним шляхом. Запишіть адресу клієнта, LAN-адресу реєстратора та точний сервіс, що відмовляє.

Спробуйте більше одного сервісу. Вебсторінка керування, прямий потік і запит відтворення можуть використовувати різні порти й різні проксі, і один може працювати, поки інший збоїть. Це порівняння показує, чи збій залежить від сервісу. Воно також не дає прийняти один збійний порт за мертвий реєстратор.

Зверніть увагу, чи запит узагалі доходить до реєстратора. З'єднання, яке ніколи не надходить, указує на маршрутизацію або міжмережевий екран на вхідному шляху; запит, що надходить і потім застрягає, указує на зворотний шлях або сервіс. Використовуйте журнал з'єднань реєстратора або лічильник, якщо він їх пропонує. Перехоплення пакетів на межі майданчика — запасний варіант.

Простежте відповідь на виході з реєстратора

Розгляньте ілюстративну схему з двома майданчиками. Віддалений клієнт — 10.60.0.25/24, LAN майданчика реєстратора — 10.70.0.0/24, LAN-адреса реєстратора — 10.70.0.50, а його внутрішня мережа PoE — 10.60.0.0/24.

Site A client:        10.60.0.25/24
Site B LAN:           10.70.0.0/24
NVR LAN address:      10.70.0.50
NVR internal PoE net: 10.60.0.0/24

Трафік із майданчика A досягає 10.70.0.50 через тунель. Далі реєстратор шукає зворотну адресу у власній таблиці й знаходить підключений префікс, що покриває 10.60.0.25. Цей префікс конкретніший за його маршрут за замовчуванням, тому відповідь іде до портів камер, а не до тунелю.

Ані узгоджений стан тунелю, ані правильний зворотний маршрут на маршрутизаторі майданчика B не можуть скасувати цей локальний вибір. Успішний запит до іншого сервера на майданчику B теж нічого не доводить про другий інтерфейс цього пристрою.

Складіть опис прихованої мережі PoE

Прочитайте мережеві налаштування реєстратора, шукаючи внутрішню мережеву карту, розділ PoE або окрему підмережу камер. Деякі моделі показують її як другий інтерфейс із власною адресою; інші ховають її за сторінкою налаштування камер.

Перевірте документацію моделі та прошивки, а не припускайте заводський префікс. Типове значення за замовчуванням у одній лінійці продуктів не є фактом про кожен реєстратор, і скопійований номер може приховати реальне перекриття замість того, щоб його виявити.

Порівняйте виявлений діапазон з обома LAN майданчиків, пулами клієнтів VPN і будь-якою іншою підключеною мережею на реєстраторі. Перекриття з пулом віддалених клієнтів — це випадок, який перенаправляє відповіді; перекриття з не пов'язаним локальним діапазоном може зламати локальний доступ до камер, не зачіпаючи VPN. Намалюйте перекриття на одному аркуші, перш ніж вибирати нові номери. Два перекритих діапазони там виглядають очевидними, а на двох окремих сторінках налаштувань — невидимими.

Запишіть діапазон, назву інтерфейсу та адреси камер на ньому. Саме цей опис план перенумерації має зберегти. Додайте моделі камер і версії прошивки, поки ви там.

Перенумеруйте разом з камерами, а не лише NVR

Виберіть діапазон камер, який не перекривається ні з майданчиками, ні з пулами VPN, ні з іншою підключеною мережею. Потім перелічіть усе, що залежить від старого: динамічні оренди, статично налаштовані адреси камер, збережені канали, розклади запису та будь-яку автоматичну конфігурацію, яку виконує модель. Цей список — контрольний список міграції, а не запізніла думка.

Перемістіть внутрішню мережу в дозволене вікно й тримайте доступ до резервної копії та відновлення реєстратора доступним. Зміна лише внутрішньої адреси реєстратора може залишити камери, що досі тримають старий діапазон, без зв'язку, і реєстратор може повідомити про них як про офлайн, а не як про неправильно налаштовані. Зберігайте експорт старої конфігурації, поки нові потоки не пропрацюють повний день.

Перевірте локальні потоки камер і запис, перш ніж тестувати віддаленого клієнта. Віддалене виправлення, побудоване на реєстраторі, який втратив свої камери, — не виправлення.

Перевірте потоки, запис і віддалений доступ

З віддаленого клієнта перевірте окремо живий перегляд, відтворення та сторінку керування. Спостерігайте за запитом і відповіддю на контрольованих межах LAN і VPN, щоб зворотний шлях було видно, а не виведено з робочої сторінки.

Якщо проксі доступу до камер або функція віртуального хоста є частиною проєкту, розглядайте його зіставлення портів і дозволи як ще один явний шлях із власним оглядом. Не відкривайте кожен порт камери й не розширюйте селектори VPN, щоб компенсувати перекриття.

Коли перенумерація неможлива, будь-який альтернативний варіант трансляції адрес потребує підтримуваного подання адрес і власного огляду політик. Загальний урок виходить за межі реєстраторів: пристрій може тримати мережу камер, сервісів або керування, яку віддалений майданчик уже нумерує.

Запишіть підсумкові діапазони й перевірені сервіси в план майданчика. Наступний реєстратор, розширення камер або зміна пулу VPN знову використають ці номери, а одного разу виправлене перекриття легко внести знову.