Відеоспостереження через VPN: надійний доступ до DVR/NVR без відкриття в інтернет

Реальна модель загроз (і чому порт‑форвардинг — пастка)

Більшість систем відеоспостереження виходять з ладу двома шляхами: вони або стають доступними зовні, або починають працювати нестабільно. Іноді — обидва разом.
Звична схема вражаюче постійна: хтось переадресовує порти з інтернету на DVR/NVR, можливо змінює стандартний пароль (можливо ні), а потім дивується,
чому пристрій бомбардують спробами входу або чому баг у прошивці перетворюється на зовнішній інцидент.

Ваш DVR/NVR — не загартований сервіс для роботи в інтернеті. Це пристрій‑апарат. Часто він працює на старому вбудованому Linux, має веб‑інтерфейс сумнівного походження
і комплектується «корисними» функціями на кшталт UPnP та P2P‑релейів постачальника, які хороші для демонстрацій і жахливі з погляду ризику.

Що ви захищаєте

• Введення облікових даних та брутфорс на портах веб/RTSP/SDK. Користувачі повторно використовують паролі; зловмисники — списки.
• Відкриті інтерфейси управління: веб‑UI, telnet/ssh (іноді приховані), служби ONVIF та порт‑орієнтовані SDK.
• Тихий віддалений доступ на кшталт P2P‑хмари і UPnP, які можуть знову відкрити доступ після того, як ви «виправили» проблему.
• Бічне переміщення: якщо DVR скомпрометовано, він опиняється в LAN поруч із сервісами, що вам справді важливі.
• Порушення приватності та відповідності: відеопотоки часто містять персональні дані; «ми відкрили 37777 на DVR» — це не політика.

Що змінює VPN

VPN сам по собі не робить DVR безпечним. Він суттєво зменшує площу атаки, прибираючи DVR з публічного інтернету.
Далі доступ контролюється там, де слід: на крайовому VPN‑вузлі з сучасною криптографією, розумною автентифікацією, логами та «kill switch» для відключення доступу.

VPN — це ваш вхід. DVR залишається всередині. Не ставте замок від банку на садову комірку.

Жарт №1: Переадресація портів на DVR — як ховати ключі під килимок: тільки от інтернет має карту вашого килимка.

Цікавинки та історичний контекст

1. Ранні системи CCTV були закритими за задумом (1940‑1960‑ті): коаксіальні кабелі, локальні монітори, без маршрутизації. «Віддалений доступ» означав довший кабель.
2. RTSP походить з кінця 1990‑х: стандартизував управління потоковим медіа, і виробники CCTV його прийняли як «достатньо хороший» варіант.
3. ONVIF зʼявився у 2008 щоб уніфікувати сумісність IP‑камер. Це допомогло інтеграції, але також стандартизувало виявні служби в LAN.
4. UPnP (кінець 1990‑х) зробив простим для побутових пристроїв відкривати порти на фаєрволі — саме те, чого ви не хочете для безпечного обладнання.
5. Хмари P2P від виробників вибухнули в 2010‑х: вони обходили NAT для зручного перегляду з мобільних, але платилися довірою та відсутністю аудиту.
6. Mirai (2016) популяризував ботнети IoT, зловживаючи стандартними обліковими даними і відкритими сервісами, в тому числі камерами та DVR‑подібними пристроями.
7. WireGuard (публічно з 2018) зробив сучасні VPN простішими: менше компонентів, менший код і менше сюрпризів при налагодженні TLS‑ренеготіацій.
8. Сотовий CGNAT став нормою у операторів: часто ви не можете «просто відкрити порт», і це іноді — прихована перевага.

Еталонні архітектури, які дійсно працюють

1) «Road‑warrior» VPN до шлюзу на сайті (найпоширеніше)

Поставте невеликий VPN‑шлюз на місці камер (брандмауер‑пристрій, міні‑ПК або потужний роутер).
Ваш телефон/ноутбук підключається до шлюзу, а шлюз маршрутизовує трафік до VLAN/підмережі CCTV. DVR/NVR не має публічного доступу.

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

2) Site‑to‑site VPN між офісами та сайтом з камерами (для SOC/NOC)

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

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

3) Hub‑and‑spoke з центральним концентраторам VPN (масштаб і послідовність)

Кожен сайт тримає тунель до центрального вузла (хмара або дата‑центр). Користувачі підключаються до того ж центрального вузла. Операційно це чисто:
одне місце для керування ідентифікацією, одне місце для логування, одне — для обмежень пропускної здатності.

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

Чого не робити

Уникайте «VPN‑сервера на DVR», якщо вам не подобається відлагодження закритої прошивки.
Уникайте «відкрити порт і дозволити IP офісу», якщо ви не впевнені, що кожен віддалений користувач ніколи не покине офіс.
І уникайте P2P‑хмар постачальника, якщо вам потрібні аудит, детермінізм або історія відповідності, що витримає зустріч із юридичним відділом.

Вибір VPN: WireGuard, OpenVPN, IPsec чи «хмарний сервіс постачальника»

WireGuard: стандартний вибір на 2025 рік

WireGuard компактний, швидкий і передбачуваний. Він використовує сучасну криптографію, має мінімальну площу конфігурації й зазвичай поводиться добре на ненадійних лінках.
Для CCTV це не розкіш — це різниця між «працює з паркування» і «працює завжди».

Операційно WireGuard чесний: якщо кінцеву точку недосяжно — ви її не досягнете. Ніяких «TLS‑хендшейк пройшов, але маршрути не ті».
Ця простота окупається, коли ви налагоджуєте о 03:00.

OpenVPN: все ще корисний, особливо для інтеграції з корпоративною автентифікацією

OpenVPN старший і важчий, але має зріле оточення для керування сертифікатами та автентифікації користувачів, і довгий досвід експлуатації.
Якщо потрібно інтегруватися з існуючими системами (RADIUS, певні моделі розповсюдження клієнтів, застаріле обладнання), OpenVPN може бути прагматичним вибором.

IPsec: чудово, коли він у вас уже всюди

IPsec site‑to‑site може бути відмінним, особливо з гідними фаєрволами. Але дрібні проблеми сумісності, налаштування фаз і UI‑абстракції вендорів
можуть перетворити просту маршрутизацію на інтерпретаційний танець. Якщо у вас вже багато IPsec — лишайтеся з ним. Якщо ні — не починайте з нього лише заради камер.

Хмара постачальника P2P: зручно, непрозоро й ризиково

P2P існує, бо NAT‑траверсія складна, і люди хочуть «скануй QR і воно працює».
Це також означає, що ваш доступ до відео може залежати від зовнішніх реле, невідомих політик логування і клієнтів, що оновлюються самостійно.
Якщо вам важливі доступність і безпека — вам потрібно менше залежностей, а не більше.

Парафраз ідеї, приписуваної Gene Kranz: «Тверді й компетентні» — це стандарт: системи мають працювати під тиском, а не вимагати героїчних зусиль.

Проєкт мережі: підмережі, маршрутизація, DNS та не пробивати дірки в стінах

Сегментуйте камери й реєстратор

Помістіть камери та DVR/NVR у виділену VLAN/підмережу. Не тому, що VLAN — чарівна штука, а тому що вона змушує вас визначати політику.
Ви можете дозволити NVR спілкуватися з камерами, дозволити VPN‑клієнтам звертатись до NVR і блокувати все інше за замовчуванням.

Якщо у вашого реєстратора два інтерфейси (LAN + камери), використовуйте їх правильно: одна сторона для трафіку камер, інша — для адміністрування/клієнтського доступу.
Інакше принаймні розділіть через VLAN і правила фаєрволу.

Вирішіть: повний тунель чи split‑tunnel

• Split‑tunnel: через VPN йдуть лише підмережі CCTV. Менше трафіку, менше сюрпризів. Потрібна обережність, щоб уникнути витоку DNS або конфліктів локальних мереж.
• Full‑tunnel: весь трафік іде через VPN. Більше контролю й передбачуваності, але ви стаєте інтернет‑провайдером для користувача — плануйте пропускну здатність.

Для доступу до CCTV split‑tunnel зазвичай підходить, якщо правильно зробити DNS і уникнути перекриття підмереж.
Для керованих пристроїв full‑tunnel іноді зручніший, бо дозволяє централізовано застосовувати політики й логування.

Маршрутизація: робіть її явною

VPN — це не «магічний віддалений доступ». Це маршрутизація плюс шифрування. Якщо користувач підключився, але не може дістатися NVR, у 90% випадків це проблема маршруту,
фаєрволу або MTU. Інші 10% — це NVR, який чинить опір.

DNS: оберіть стратегію, яку зможете підтримувати

Не покладайтеся на те, що користувачі назавжди вводитимуть IP‑адреси. Дайте NVR стабільне імʼя типу nvr.site1.lan і зробіть його резольвним через VPN.
Це можна зробити внутрішнім DNS, сервери DNS, що поширюються через VPN, або статичними записами hosts у крайньому випадку (не рекомендовано в масштабі).

Автентифікація та авторизація: ставтесь як до продуктивного середовища

Використовуйте ідентичність для кожного користувача, коли це можливо. Вмикайте MFA для VPN, якщо можете. Не діліться одним профілем «security@company» між десятьма телефонами.
Це не контроль доступу — це надія з логотипом.

Зміцнення боку CCTV: DVR/NVR, камери та проблема застосунків

Вимкніть «корисні» функції експозиції

На DVR/NVR та на верхньому роутері/фаєрволі:

• Вимкніть UPnP.
• Вимкніть P2P/хмарні релeї постачальника, якщо у вас немає формального прийняття ризику.
• Вимкніть віддалене керування з WAN.
• Обмежте інтерфейси управління лише до підмережі VPN.

Заблокуйте облікові записи

• Створюйте іменовані облікові записи, а не спільні.
• Видаліть або відключіть облікові записи за замовчуванням (або принаймні змініть паролі та зменшіть права).
• Застосовуйте принцип найменших привілеїв: користувачі лише для перегляду не повинні мати права оновлення прошивки.

Прошивка та синхронізація часу

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

Жарт №2: Єдина річ більш впевнена у собі, ніж веб‑UI DVR — це драйвер принтера: обидва вважають себе найважливішою службою у вашій мережі.

Інженерія надійності: затримки, MTU, NAT і чому відео «обманює» мережі

Розрахунок пропускної здатності: не вгадуйте

Один 1080p H.264 потік може споживати 2–6 Мбіт/с залежно від бітрейту, руху в кадрі, складності сцени та оптимізму постачальника.
Помножте це на кількість одночасних переглядів або відтворень. Додайте накладні витрати VPN‑капсуляції та повторні передачі на поганих каналах.

Для віддаленого відтворення користувачі часто «перемотують» хронологію і викликають сплески трафіку. Це не «один стабільний потік», а «випадкові піки».
Якщо ваш аплінк асиметричний (типовий кабель/DSL), саме upstream на сайті буде обмежувати.

Затримка і джиттер важливіші, ніж здається

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

MTU: тихий вбивця

VPN додає заголовки. На лінках із меншим path MTU (LTE, PPPoE, деякі DOCSIS) ви побачите дивні симптоми:
сторінки логіну завантажуються, але відео — ні; маленькі ping проходять, а застосунок таймаутиться.
Налаштування MTU/MSS — одна з найменш гламурних, але найефективніших мережевих робіт.

NAT‑траверсія: обирайте детерміновані архітектури

Якщо сайт камер за NAT, який ви не контролюєте, модель «сервер у хмарі + сайт як клієнт» часто краща:
сайт ініціює тунель назовні, тож вхідні порти не потрібні.
Це чистий підхід для ритейлу, будівельних майданчиків і будь‑якого місця, де ISP‑роутер «керує тим, хто його встановив у 2017».

Логування та спостережуваність

Якщо ви не можете відповісти на «хто підключився, звідки і до чого дісталися», у вас не віддалений доступ — у вас загадка.
Логуйте підключення VPN, призначайте стабільні IP‑клієнтам і фіксуйте відмови/блоки фаєрволу для підмереж CCTV.

Практичні завдання: команди, виводи та рішення

Це перевірки, випробувані в полі, які ви можете виконати з Linux‑шлюзу VPN або з jump‑host в VPN. Кожне завдання містить: команду, реалістичний вивід,
що це означає і яке ви приймаєте рішення далі.

Завдання 1: Перевірте, що інтерфейс VPN піднятий і має правильну адресу

cr0x@server:~$ ip -brief addr show wg0
wg0             UNKNOWN        10.60.0.1/24

Значення: Інтерфейс wg0 існує і має 10.60.0.1/24. Стан UNKNOWN для WireGuard нормальний.
Рішення: Якщо інтерфейс відсутній або має неправильну підмережу — виправте конфіг WireGuard перед пошуками проблем із камерами.

Завдання 2: Перевірте свіжість хендшейку WireGuard peer

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 9mQq...V1k=
  listening port: 51820

peer: pQ0w...h3c=
  endpoint: 198.51.100.24:46211
  allowed ips: 10.60.0.10/32, 10.20.30.0/24
  latest handshake: 54 seconds ago
  transfer: 1.23 GiB received, 3.88 GiB sent
  persistent keepalive: every 25 seconds

Значення: Пір сайту живий (хендшейк менше хвилини). Allowed IPs включають підмережу камер 10.20.30.0/24.
Рішення: Якщо хендшейк «ніколи», ви не підключені — перевірте досяжність ендпойнта, NAT, ключі та фаєрвол.

Завдання 3: Підтвердіть наявність маршрутів до підмережі CCTV

cr0x@server:~$ ip route show | grep 10.20.30.0
10.20.30.0/24 dev wg0 proto static

Значення: Трафік до підмережі камер іде через VPN.
Рішення: Якщо маршруту немає — додайте його (або виправте AllowedIPs, якщо використовуєте WireGuard з політикою маршрутів).

Завдання 4: Перевірте базову досяжність IP NVR

cr0x@server:~$ ping -c 3 10.20.30.50
PING 10.20.30.50 (10.20.30.50) 56(84) bytes of data.
64 bytes from 10.20.30.50: icmp_seq=1 ttl=63 time=34.8 ms
64 bytes from 10.20.30.50: icmp_seq=2 ttl=63 time=35.2 ms
64 bytes from 10.20.30.50: icmp_seq=3 ttl=63 time=35.0 ms

--- 10.20.30.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 34.8/35.0/35.2/0.2 ms

Значення: ICMP працює; затримка ~35 мс — придатно для перегляду.
Рішення: Якщо ping не проходить — не звинувачуйте застосунок; перевірте маршрути і фаєрвол. Якщо ping працює, а відео ні — перевіряйте порти й MTU.

Завдання 5: Визначте, які порти відкриті на NVR (без гадань)

cr0x@server:~$ sudo nmap -sS -Pn -p 80,443,554,8000,8080,37777 10.20.30.50
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-28 10:18 UTC
Nmap scan report for 10.20.30.50
Host is up (0.035s latency).

PORT      STATE SERVICE
80/tcp    open  http
443/tcp   closed https
554/tcp   open  rtsp
8000/tcp  open  http-alt
8080/tcp  closed http-proxy
37777/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 1.42 seconds

Значення: Веб‑UI на 80, RTSP на 554, сервіс постачальника на 8000. Порт 37777 відфільтрований (ймовірно блокує фаєрвол).
Рішення: Переконайтеся, що лише потрібні порти доступні з VPN; заблокуйте інші. Якщо клієнту потрібен 37777 — ви знайшли причину збою.

Завдання 6: Підтвердіть, що політика фаєрволу працює як задумано

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "wg0" tcp dport { 22, 80, 554, 8000 } accept
    iif "wg0" icmp type echo-request accept
    counter log prefix "DROP input " drop
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "lan0" ip daddr 10.20.30.0/24 accept
    iif "lan0" oif "wg0" ip saddr 10.20.30.0/24 accept
  }
}

Значення: За замовчуванням drop, явні дозволи з VPN до підмережі CCTV. Це правильний підхід.
Рішення: Якщо правила пересилання відсутні — VPN‑клієнти підключаться, але не дістануться до камер. Додайте мінімальні forward‑правила.

Завдання 7: Перевірте, що IP‑форвардинг увімкнений на шлюзі VPN

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Значення: Машина буде маршрутизувати пакети.
Рішення: Якщо значення 0 — увімкніть і збережіть у /etc/sysctl.d/. Без цього «VPN працює», але за ним нічого не буде.

Завдання 8: Перевірте NAT (тільки якщо ви навмисно робите NAT для VPN‑клієнтів у LAN CCTV)

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oif "lan0" ip saddr 10.60.0.0/24 masquerade
  }
}

Значення: IP‑адреси клієнтів VPN маскуються при виході через lan0.
Рішення: NAT — це обхід, коли сторона NVR/камер не вміє маршрутизувати назад до підмережі VPN. Віддавайте перевагу маршрутизації, але NAT прийнятний, якщо треба.

Завдання 9: Перевірте TCP‑доступ до веб‑UI реєстратора

cr0x@server:~$ curl -I --max-time 3 http://10.20.30.50/
HTTP/1.1 200 OK
Server: uc-httpd/1.0.0
Content-Type: text/html
Content-Length: 4132

Значення: HTTP відповідає швидко. Шлях відкритий.
Рішення: Якщо таймаут — перевірте фаєрвол і маршрути. Якщо повертає 401/403 — це питання застосунку/автентифікації, а не мережі.

Завдання 10: Перевірте досяжність RTSP (поширено для інтеграцій VMS)

cr0x@server:~$ timeout 3 bash -c 'echo > /dev/tcp/10.20.30.50/554' && echo "rtsp port open"
rtsp port open

Значення: Порт 554 доступний на TCP‑рівні.
Рішення: Якщо TCP блокується, але ви очікували RTSP — відкрийте його лише для потрібних клієнтів або проксуйте через VMS, а не всім підряд.

Завдання 11: Шукайте проблеми MTU за допомогою ping з прапором «не фрагментувати»

cr0x@server:~$ ping -c 3 -M do -s 1420 10.20.30.50
PING 10.20.30.50 (10.20.30.50) 1420(1448) bytes of data.
ping: local error: message too long, mtu=1420

--- 10.20.30.50 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2032ms

Значення: Ефективний MTU менший, ніж очікувалося; великі пакети не проходять без фрагментації.
Рішення: Зменшіть MTU WireGuard (наприклад, 1280–1380) або обмежте TCP MSS на шлюзі. Це часто вирішує «UI завантажується, а відео — ні».

Завдання 12: Виміряйте втрати й джиттер за допомогою mtr

cr0x@server:~$ mtr -rwzc 50 10.20.30.50
Start: 2025-12-28T10:24:40+0000
HOST: server                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.60.0.10                     0.0%    50   32.1  34.9  31.8  78.2  8.6
  2.|-- 10.20.30.50                     2.0%    50   35.0  36.7  33.9  92.4  9.9

Значення: 2% втрат до NVR. Відео буде підгальмовувати; відтворення проклять над вами.
Рішення: Дослідіть якість лінка на сайті (Wi‑Fi бекхол, провайдер, LTE). Розгляньте зниження бітрейту або ввімкнення адаптивних субпотоків.

Завдання 13: Переконайтеся, що NVR дійсно слухає очікувані порти (з LAN NVR)

cr0x@server:~$ ssh admin@10.20.30.1 "sudo ss -lntp | head"
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128    0.0.0.0:80         0.0.0.0:*     users:(("uc-httpd",pid=1142,fd=5))
LISTEN 0      128    0.0.0.0:554        0.0.0.0:*     users:(("rtspd",pid=1188,fd=7))
LISTEN 0      128    0.0.0.0:8000       0.0.0.0:*     users:(("vendor_sdk",pid=1210,fd=9))

Значення: Сервіси звʼязані на всіх інтерфейсах. Якщо віддалені клієнти не підключаються, це не тому, що NVR не слухає.
Рішення: Зосередьтеся на маршрутах/фаєрволі/NAT. Якщо порти не слухають — виправляйте конфіг NVR або стан сервісу.

Завдання 14: Перевірте виснаження conntrack на шлюзі VPN (так, відео може це зробити)

cr0x@server:~$ sudo conntrack -S | egrep 'entries|max'
entries  28712
max  262144

Значення: Достатньо запасу. Якщо entries близькі до max, нові зʼєднання можуть періодично відкладатися.
Рішення: Якщо ви близькі до максимуму, підніміть ліміти conntrack і/або зменшіть «балаканину» (вимкніть виявлення, зменшіть опитування клієнта, обмежте одночасних глядачів).

Завдання 15: Перевірте синхронізацію часу на шлюзі VPN (потрібно для логів та валідації сертифікатів)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:28:11 UTC
           Universal time: Sun 2025-12-28 10:28:11 UTC
                 RTC time: Sun 2025-12-28 10:28:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Час синхронізований. Добре.
Рішення: Якщо ні — налаштуйте NTP. Неправильний час ускладнює відлагодження і може ламати TLS‑VPN.

Завдання 16: Захопіть трафік, щоб побачити, чи застосунок взагалі пробує підключитися (і до чого)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.20.30.50 and '(tcp port 80 or tcp port 554 or tcp port 8000)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:29:44.112233 IP 10.60.0.23.51234 > 10.20.30.50.80: Flags [S], seq 188231231, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0], length 0
10:29:44.145678 IP 10.20.30.50.80 > 10.60.0.23.51234: Flags [S.], seq 9981122, ack 188231232, win 65160, options [mss 1460,sackOK,TS val 456 ecr 123], length 0
10:29:44.145900 IP 10.60.0.23.51234 > 10.20.30.50.80: Flags [.], ack 1, win 64240, options [TS val 124 ecr 456], length 0

Значення: SYN/SYN‑ACK/ACK завершуються. Зʼєднання відбувається; клієнт намагається HTTP.
Рішення: Якщо бачите SYN без відповідей — це фаєрвол/маршрут. Якщо взагалі немає пакетів — це проблема маршрутизації/DNS клієнта або конфігурації split‑tunnel.

Підручник швидкої діагностики

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

Перше: підтвердіть, що тунель реально існує

• На сервері/шлюзі VPN: перевірте свіжість хендшейку (wg show або статус OpenVPN).
• На клієнті: підтвердіть, що він отримав очікувану VPN‑IP і маршрути.
• Рішення: якщо тунель не піднятий — зупиніться. Виправте ключі, досяжність ендпойнта, NAT/порт або автентифікацію.

Друге: підтвердіть маршрутизацію до підмережі CCTV

• Перевірте таблицю маршрутів на сервері й клієнті.
• Зробіть ping до IP NVR з відомо‑працюючого хоста у VPN.
• Рішення: якщо ping не працює — це не «проблема NVR». Це маршрутизація/фаєрвол/NAT.

Третє: підтвердіть порти й політику

• Скануйте лише очікувані порти з боку VPN (nmap).
• Перевірте правила фаєрволу і пересилання.
• Рішення: відкривайте лише необхідне; якщо застосунку потрібен порт SDK виробника — дозволяйте його лише з VPN‑клієнтів.

Четверте: підозрюйте MTU і втрати

• Запустіть DF‑ping і mtr до NVR.
• Рішення: якщо великі пакети не проходять або втрати значні — налаштуйте MTU/MSS, зменшіть бітрейт або виправте WAN‑лінк.

Пʼяте: дайте звинувачення застосунку, обережно

• Використовуйте tcpdump, щоб підтвердити, що клієнт пробує зробити.
• Спробуйте інший доступ (веб‑UI vs мобільний застосунок vs RTSP).
• Рішення: якщо мережа в порядку, проблема ймовірно в автентифікації, прошивці, налаштуваннях кодека або в баґу клієнта.

Типові помилки: симптом → корінна причина → виправлення

1) «VPN підключається, але я не можу дістатися NVR»

Симптоми: VPN показує підключено; застосунок таймаутиться; ping до NVR не проходить.

Корінна причина: Відсутній маршрут до підмережі CCTV або відсутнє пересилання на шлюзі VPN.

Виправлення: Додайте маршрут (або WireGuard AllowedIPs) і ввімкніть net.ipv4.ip_forward=1. Додайте правила форварду фаєрволу для wg0 → CCTV LAN.

2) «Веб‑UI завантажується, але живе відео чорне»

Симптоми: Вхід працює; меню завантажуються; потік не стартує або одразу зависає.

Корінна причина: Проблеми MTU/MSS або заблоковані порти трансляції/SDK.

Виправлення: Зменшіть MTU WireGuard (спробуйте 1380, потім 1320) і/або обмежте MSS. Підтвердіть RTSP/SDK порти за допомогою nmap і дозвольте їх лише з підмережі VPN.

3) «Працює на Wi‑Fi, не працює на мобільному»

Симптоми: З домашнього інтернету працює; на LTE — падає або дуже повільно.

Корінна причина: CGNAT оператора + обмеження MTU + агресивні оптимізації енергоспоживання/мережі на мобільних ОС.

Виправлення: Використовуйте VPN, що толерує NAT (WireGuard з persistent keepalive). Встановіть консервативний MTU. Переконайтеся, що мобільний VPN дозволено виконуватись у фоновому режимі.

4) «Випадково відключається кожні кілька хвилин»

Симптоми: Живий перегляд переривається періодично; повторне підключення вирішує.

Корінна причина: Тайм‑аут NAT‑мапінгу, відсутні keepalive або проблеми в таблиці стану upstream‑роутера.

Виправлення: Увімкніть WireGuard persistent keepalive (наприклад, 25 с) на роумінгових клієнтах і site‑peer. Перевірте таймаути UDP у роутері провайдера.

5) «Ми вимкнули P2P, але воно повертається»

Симптоми: DVR знову показує онлайн у хмарі постачальника; вихідні зʼєднання зʼявляються після оновлень.

Корінна причина: Оновлення прошивки скидає налаштування або кілька меню керують тією ж опцією.

Виправлення: Блокуйте вихідний трафік з VLAN CCTV в інтернет за замовчуванням, дозволяйте лише NTP (і, можливо, сервери оновлень, які ви явно дозволяєте). Розглядайте DVR як ненадійний пристрій.

6) «Відтворення непридатне, живий перегляд — ок»

Симптоми: Живий перегляд нормальний; при перемотуванні відтворення зависає; хронологія завантажується повільно.

Корінна причина: Відтворення виконує вибіркові запити та seeks; аплінк насичується або буферблоут на WAN‑шляху додає затримок.

Виправлення: Застосуйте QoS на аплінку сайту, обмежте бітрейт віддаленого відтворення і використовуйте субпотоки для превʼю. Якщо можливо — експортуйте кліпи на сервері замість передачі сирового відтворення.

7) «Підключається лише один користувач одночасно»

Симптоми: Другому користувачу не вдається підключитись; або перший викидається.

Корінна причина: Спільний VPN‑профіль/ключі або ліміти ліцензій/сесій NVR.

Виправлення: Видавайте унікальні VPN‑ключі на користувача/пристрій. Перевірте ліміти сесій NVR і створіть окремі NVR‑користувачі.

8) «Команда безпеки каже, що VPN норм, а команда камер каже, що винен VPN»

Симптоми: Пінг‑пінг звинувачень; немає чіткої відповідальності; інцидент тягнеться.

Корінна причина: Немає спільної спостережуваності: немає логів, пакетних дампів, визначених SLO.

Виправлення: Централізуйте логи VPN, фіксуйте відмови фаєрволу, визначте критерії «працює» (час до першого кадру, прийнятні втрати) і тестуйте з відомого хоста.

Три корпоративні міні‑історії з практики

Міні‑історія 1: Інцидент через хибне припущення

Середня компанія мала «тимчасову» конфігурацію: інсталятор переадресував порти на NVR, щоб керівники могли дивитися камери з дому.
IT‑команда припустила, що переадресовані порти — «екзотичні порти виробника» і тому невеликого ризику. Ніхто їх не записав.

Місяці потому аудит виявив підозрілий вихідний трафік з VLAN реєстраторів. NVR спілкувався з випадковими IP у випадковий час.
Інженер з безпеки зробив те, що робимо всі: перевірив фаєрвол. Нічого очевидного. Другим кроком — скан зовні.
Так вони побачили, що веб‑UI NVR вітає весь інтернет, як захоплений стажер.

Хибне припущення було тонким: «наш ISP блокує вхідні зʼєднання, якщо не замовляти». Раніше це було правдою для іншого тарифу.
Нинішній план дозволяв вхідні, а граничний роутер мав UPnP увімкнений. NVR відкрив порти після оновлення прошивки, яке скинуло налаштування.

Виправлення не було героїчним. Вимкнули UPnP, прибрали всі форварди, відключили P2P і поставили WireGuard‑шлюз попереду.
Справжня робота була в процесах: вони ввели правило, що CCTV‑пристрої ніколи не повинні мати прямого WAN‑доступу, і додали зовнішнє сканування у щомісячний чек‑ліст.

Міні‑історія 2: Оптимізація, яка обернулася проти

Рітейл‑мережа хотіла швидший віддалений перегляд з HQ. Хтось вирішив, що VPN — це «накладні витрати», і перейшов на split‑tunneling з агресивним звуженням маршрутів:
в VPN передавався тільки IP NVR, а не підмережа камер. Ідея — зменшити пропускну здатність і тримати інше сайту недоступним. На папері — розумно.

Потім мобільний застосунок почав поводитись непередбачувано. Живий перегляд іноді працював, відтворення майже ніколи, експорт кліпів — лотерея.
Команда ганялася за прошивкою NVR, звинувачувала провайдера і навіть міняла модель роутера на кількох сайтах.

Причина: застосунок не тільки спілкується з IP NVR. Після початкової домовленості він підключається безпосередньо до IP камер.
Коли підмережа камер не була прокинута, застосунок доходив до середини налаштування і падал. Різні версії застосунку поводилися по‑різному.

«Оптимізація» також порушила DNS: застосунок резолвив локальне імʼя на публічну IP поза VPN, тому іноді намагався достукатися до неіснуючої WAN‑адреси.
Виправлення означало маршрутизацію всієї підмережі CCTV через VPN, а потім обмеження доступу фаєрволом (дозволити підмережі користувачів до NVR + RTSP за потреби, заборонити все інше).
Менш хитро. Більш правильно.

Міні‑історія 3: Нудна практика, яка врятувала день

На логістичному обʼєкті вони тримали невеликий WireGuard‑шлюз зі строгими правилами: default drop, дозволити VPN‑клієнтам порти NVR і логувати відмови.
Також зафіксували IP NVR через DHCP‑резервацію і задокументували VLAN камер у односторінковому ранбуку.
Нічого надзвичайного. Просто дорослий нагляд.

Однієї ночі віддалений перегляд зламався під час перегляду інциденту. Інженер черговий не мав часу на чаклунство в застосунку.
Вони перевірили WireGuard‑хендшейк: добре. Ping до NVR: добре. Перевірка портів: 8000 раптово закрився.
Це вказувало не на VPN, а напряму на реєстратор.

Логи відмов не показували нових блоків. Шлюз був у порядку. NVR же перезавантажився після стрибка живлення і повернувся з напівзапущеною службою.
Оскільки команда мала базові порт‑чек‑и і відомий робочий шлях, діагностика зайняла хвилини замість години наради.

Вони перезапустили сервіс, додали NVR до невеликого UPS і налаштували шлюз, щоб сповіщати, коли NVR перестає відповідати на потрібні порти.
Нудна практика: базові показники, логи і UPS. Вона врятувала день, бо звузила поле пошуку.

Чек‑лісти / покроковий план

Покроково: побудуйте доступ до CCTV через VPN (без публічного доступу)

1. Опишіть, що маєте. Перелічіть модель NVR, підмережу камер, поточний метод віддаленого доступу та клієнтів, які мають працювати (мобільний застосунок, веб‑UI, VMS).
2. Приберіть WAN‑експозицію. Видаліть всі порт‑форварди до DVR/NVR. Вимкніть UPnP на граничному роутері. Перевірте зовні, що нічого не відповідає.
3. Оберіть архітектуру. Для одного сайту підходить road‑warrior VPN до шлюзу. Для багатьох сайтів hub‑and‑spoke зазвичай чистіше.
4. Створіть VLAN/підмережу CCTV. Помістіть туди камери і NVR, або хоча б NVR. Задокументуйте адресацію та шлюз за замовчуванням.
5. Розгорніть VPN‑шлюз. Віддавайте перевагу виділеному пристрою, який ви керуєте (апаратний фаєрвол або Linux‑міні‑ПК). Уникайте запуску «сервісів» на NVR.
6. Визначте маршрути. Переконайтеся, що клієнти VPN мають маршрут до підмережі CCTV. Уникайте перекриття підмереж між сайтами.
7. Застосуйте політику фаєрволу. За замовчуванням deny. Дозвольте VPN‑клієнтам лише потрібні порти NVR (та лише до підмережі CCTV).
8. Вирішіть маршрутизацію проти NAT. Віддавайте перевагу маршрутизації. Використовуйте NAT, якщо сторона CCTV не може маршрутизувати назад до VPN‑клієнтів.
9. Виправте DNS. Забезпечте стабільне імʼя для NVR і зробіть його резольвним через VPN. Поширюйте внутрішні DNS‑сервери до клієнтів VPN.
10. Зміцніть реєстратор. Вимкніть P2P, вимкніть WAN‑керування, створіть іменованих користувачів, зменшіть права, налаштуйте NTP.
11. Протестуйте з трьох мереж. Офісний Wi‑Fi, домашній інтернет і мобільний. Мобільний — це місце, де MTU‑мрії помирають.
12. Опрацюйте експлуатацію. Логи, періодичні скани з VPN, бекап конфігів і чітка процедура відключення ключів VPN та облікових записів NVR.

Чек‑ліст контролю змін (бо «воно працювало минулого тижня» — не метрика)

• Зробіть знімок/експорт конфігурації VPN‑шлюзу перед змінами.
• Запишіть поточні маршрути й правила фаєрволу.
• Плануйте оновлення прошивки DVR/NVR; не робіть їх під час інциденту.
• Після будь‑якого оновлення перевірте: UPnP вимкнено, P2P вимкнено, потрібні порти підняті, синхронізація часу в порядку.
• Майте план відкату: відомий‑робочий конфіг VPN і образ шлюзу для відновлення.

Чек‑ліст безпеки (мінімально серйозно)

• Індивідуальні VPN‑ідентичності; відкликати при звільненні.
• MFA для VPN, якщо можливо.
• Жодних спільних DVR‑адмін‑акаунтів для щоденного перегляду.
• Обмежити доступ VPN‑клієнтів лише до підмереж CCTV (найменший привілей).
• Блокуйте вихід в інтернет з VLAN CCTV за замовчуванням, дозволяйте лише необхідне (наприклад, NTP).
• Логуйте підключення VPN та відмови фаєрволу; зберігайте логи достатньо довго для розслідувань.

Запитання та відповіді

1) Чи справді мені потрібен VPN? Хіба не можна просто переадресувати порт і поставити міцний пароль?

Можна, але ви ставите ставку, що DVR/NVR не має віддалено експлуатованих вразливостей і що його автентифікація надійна. Це дорога ставка.
VPN зменшує експозицію і дає вам центральний контроль доступу. Використовуйте DVR як внутрішній сервіс — бо саме ним він і є.

2) WireGuard чи OpenVPN для CCTV?

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

3) Чи варто використовувати split‑tunneling?

Якщо ви керуєте багатьма різнорідними пристроями користувачів, split‑tunnel позбавляє вас ролі їхнього інтернет‑провайдера.
Але ви мусите уникати перекриттів підмереж і гарантувати, що DNS резолвить внутрішні адреси через VPN. Для керованих корпоративних пристроїв full‑tunnel частіше чистіший варіант.

4) Мій NVR‑застосунок працює локально, але не через VPN. Чому?

Типові причини: застосунок очікує доступу до IP камер напряму (не тільки до NVR), потрібний порт постачальника заблокований, або MTU ламає великі пакети.
Перевірте маршрути до всієї підмережі CCTV, підтвердіть порти цілеспрямованим скануванням і протестуйте MTU DF‑pingами.

5) Чи допустимо NAT‑ити VPN‑клієнтів у LAN камер?

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

6) Як не допустити, щоб DVR дзвонив у хмари постачальника?

Вимкніть P2P/хмару в UI, а потім зафіксуйте це на рівні мережі: блокуйте вихідний інтернет із VLAN CCTV за замовчуванням.
Дозвольте NTP, якщо потрібна синхронізація часу, і явно вкажіть усе інше, що дозволяєте.

7) Чи можна використовувати хмарний VPN‑концентратор, якщо на сайті немає публічної IP?

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

8) Який швидкий спосіб визначити, чи вузьке місце — аплінк провайдера?

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

9) Чи потрібно відкривати RTSP через VPN?

Лише якщо у вас клієнт або VMS, що використовує RTSP. Якщо NVR‑клієнт використовує пропрієтарний SDK‑порт, RTSP може й не знадобитись.
Виставляйте мінімальний набір потрібних портів і лише для мінімального кола VPN‑клієнтів.

10) А якщо використовувати Zero Trust інструменти замість VPN?

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

Висновок: практичні кроки далі

Якщо ваш DVR/NVR сьогодні доступний з публічного інтернету — вважайте це технічним боргом з відсотками.
Виправлення нескладне: приберіть експозицію, поставте керований VPN‑край перед ним, маршрутизуйте свідомо та звузьте політики до мінімуму.
Потім протестуйте на найгіршій мережі, яку знайдете (мобільній) і відрегулюйте MTU, перш ніж користувачі зроблять це за вас скаргами.

Наступні кроки, які ви можете зробити цього тижня:

• Аудитуйте та видаліть усі порт‑форварди і правила UPnP, повʼязані з CCTV.
• Розгорніть WireGuard‑шлюз і прокиньте через нього виділену підмережу CCTV.
• Впровадьте фаєрвол «deny by default» з явними дозволами для потрібних портів NVR.
• Вимкніть P2P постачальника і блокуйте вихідний інтернет із VLAN CCTV за замовчуванням.
• Прогоніть підручник швидкої діагностики один раз, задокументуйте базові виводи і зберігайте їх на випадок проблем.

Зробіть це нудним. Нудне — надійне. Надійне — це те, що ви хотіли, коли встановлювали камери спочатку.