Сегментація VPN + VLAN для офісу, складу і камер (без жалю)

Ментальна модель: VPN — транспорт, VLAN — обмеження

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

Якщо запам’ятати одне правило, нехай це буде: VLAN потрібні для обмеження площі ураження; правила файрвола — для обмеження намірів; VPN — для доступності.
«Сегментація» без файрвола — це просто витончена організація кабелів.

У мультисайтних налаштуваннях (офіс + склад) VLAN створюються в кожному сайті, а VPN переносить вибране трафік між сайтами.
Зазвичай ви не хочете розтягувати VLAN через VPN, якщо у вас немає дуже конкретної, перевірної причини та апетиту для страждань.
L2 через VPN — це місце, де помирає надія.

Суб’єктивна порада: маршрутизуйте між VLAN на Layer 3 (файрвол або L3-комутатор), застосовуйте політику там і маршрутизируйте між сайтами через VPN.
Залишайте все нудним. Нудні мережі працюють.

Цитата, яку варто приклеїти на стікер: «Надія — не стратегія.» — часто приписується операційній культурі (формулювання різниться).
Трактуйте як парафразу, якщо бачили іншу версію. Сенс незмінний.

Цікаві факти та історичний контекст (що пояснює сучасний хаос)

• 802.1Q VLAN tagging став стандартом наприкінці 1990-х; до того «VLAN» часто були вендор-залежними і несумісними.
• IPsec існує з 1990-х, спочатку розроблявся для IPv6, потім адаптувався до всього іншого, бо реальність робить своє.
• NAT став за замовчуванням не тому, що це елегантно, а тому, що вичерпання IPv4 було передбачуване і його ігнорували.
• Spanning Tree Protocol (STP) існує, бо люди фізично не вміють не створювати петлі кабелями.
• PoE (Power over Ethernet) зробив камери надзвичайно популярними: один кабель для живлення і мережі — і команда інфраструктури починає «займатися мережами».
• ONVIF створили, щоб стандартизувати взаємодію IP-камер; це допомогло, але не зробило безпеку камер ідеальною.
• «Air-gapped» старше за сучасне ІТ; це концепт з класифікованих середовищ. У корпоративних мережах зазвичай означає «інколи підключається до Wi‑Fi».
• WPA2-Enterprise з’явився в середині 2000-х і зробив аутентифікацію Wi‑Fi по користувачу практичною; на складах його досі часто не використовують.
• WireGuard новіший порівняно з IPsec/OpenVPN (спроектований у середині 2010-х), має менший код і розумні налаштування за замовчуванням.

Тут одна тема: стандарти зрілі. А провали зазвичай людські, організаційні або «ми поспішали з закупівлею».

Еталонний дизайн, що працює в реальних приміщеннях

Сайти та ролі

Припустимо два фізичних сайти: Офіс і Склад. Можуть бути ще віддалені користувачі (IT/адміни) і, можливо, керований постачальник безпеки,
якому потрібен обмежений доступ до камер/NVR.

На кожному сайті вам потрібні:

• Пристрій маршрутизації/файрвола (може бути виділений файрвол або маршрутизатор з функціями файрвола).
• Керований комутатор, здатний до VLAN і транків; бажано з PoE для камер/AP.
• Точки доступу Wi‑Fi, що підтримують кілька SSID, відображених у VLAN (гість vs корп vs сканери).

Шаблон сегментації: «за замовчуванням відхилити, дозволити за сервісом»

Створіть окремі VLAN для кожної зони довіри. Звичайний мінімальний набір:

• Corp: користувацькі пристрої, ноутбуки, десктопи.
• Servers: AD/DNS/NVR/ERP — усе, що ваша організація вважає «критичним».
• Cameras: IP-камери та суміжні контролери дверей.
• Warehouse/OT: сканери, етикеткові принтери, портативні термінали, обладнання поруч з PLC.
• Guest: лише інтернет. Ніякого доступу до внутрішніх ресурсів.
• Management: інтерфейси управління комутаторів/AP, виділена мережа, якщо можете організувати.

Далі застосовуйте доступ між VLAN на вашому файрволі/маршрутизаторі. Якщо ваш L3-комутатор може маршрутизувати — чудово, але централізуйте політику,
якщо вам важлива аудитованість. «Розподілені ACL скрізь» — це шлях до племінних знань і однієї людини, яка не може піти у відпустку.

Де має бути VPN

Помістіть site-to-site VPN між пограничними файрволами/маршрутизаторами офісу і складу. Маршрутизуйте лише ті підмережі, які потрібні.
Якщо вас тягне проставити 0.0.0.0/0 через тунель заради «простоти», зупиніться. Це не простота, це відкладання складності до моменту, коли все загориться.

VPN для віддалених користувачів повинен завершуватися в офісі (або в центральному хабі) і підлягати тій самій політиці:
користувачі потрапляють у виділену VPN-підмережу/VLAN, потім їм дозволяють доступ до конкретних сервісів.

Жарт №1: Якщо ваша VLAN для камер може дістатися до VLAN бухгалтерії — вітаємо, ви винайшли дорогий спосіб зберігати відео й програму-вимагальник в одному місці.

IP-план і карта VLAN, яку не захочеться міняти

Хороші IP-плани нудні. Нудне — надійне. Оберіть RFC1918 блок і послідовно його підрозділіть по сайтах.
Один шаблон, що масштабується без надмірностей:

• Офіс: 10.10.0.0/16
• Склад: 10.20.0.0/16

Всередині кожного сайту використовуйте /24 на VLAN:

• VLAN 10 Corp: 10.10.10.0/24 (Офіс), 10.20.10.0/24 (Склад)
• VLAN 20 Servers: 10.10.20.0/24, 10.20.20.0/24
• VLAN 30 Cameras: 10.10.30.0/24, 10.20.30.0/24
• VLAN 40 Warehouse/OT: 10.10.40.0/24 (можливо не використовується), 10.20.40.0/24
• VLAN 50 Guest: 10.10.50.0/24, 10.20.50.0/24
• VLAN 99 Management: 10.10.99.0/24, 10.20.99.0/24

Чому такий шаблон працює

Мережами керують люди. Вони не «оптимізують» їх. З передбачуваною адресацією ви можете поглянути на IP і одразу знати
сайт + зону довіри. Це важливо, коли ви дивитесь логи вночі.

Розміщення DNS і DHCP

Розміщуйте авторитетний DNS та DHCP у VLAN серверів (або в окремому інфраструктурному VLAN). Використовуйте DHCP relay (IP helper) на інтерфейсах VLAN,
якщо централізуєте DHCP. Камери часто не люблять складні опції DHCP; тримайте мінімум, якщо не знаєте особливостей моделі.

Статичні IP для камер і інфраструктури зазвичай того варті. Якщо ви робите DHCP-резервації, експортуйте/бекапте їх.
«Ми пам’ятаємо IP» — міф, який розповідають молодим адміністратам, як Санта.

Політика файрвола: хто з ким говорить (і навіщо)

Базові правила (суб’єктивно)

• Guest → будь-яке внутрішнє: заборонено. Завжди. Без винятків.
• Cameras → інтернет: за замовчуванням заборонено. Дозвольте NTP до вашого NTP і, можливо, кінцеві точки оновлень вендора, тільки якщо не можете робити офлайн-оновлення.
• Cameras → NVR: дозвольте тільки потрібні порти (часто RTSP, ONVIF, специфічні порти вендора). Віддавайте перевагу потокам, ініційованим камерою до NVR, якщо можливо.
• Corp → Cameras: зазвичай заборонено. Якщо користувачам потрібен живий перегляд, робіть це через веб-додаток NVR/VMS, а не прямим доступом до камер.
• Warehouse/OT → Servers: дозволяйте тільки потрібні порти додатку (ERP, друк, сервіси сканерів). Ніякого «any/any бо сканери».
• Management VLAN: лише VPN-підмережа IT та невеликий набір адміністративних робочих станцій повинні мати доступ (SSH/HTTPS/SNMP).

Між сайтами (через VPN)

Вам не потрібна «повна довіра між сайтами». Потрібні конкретні сервіси:

• Сканери на складі до ERP-додатків в офісі
• NVR складу до сховища в офісі (якщо ви централізували архів)
• IT-адміни для управління комутаторами/AP/файрволом складу

Маршрутуйте і дозволяйте лише ті підмережі/порти. Якщо пізніше знадобиться більше — додавайте це свідомо. Кожне правило повинно мати власника і причину.

Логування: що логувати, щоб не потонути

Логируйте відмови між VLAN деякий час після впровадження; це допомагає виявити забутий сервіс.
Але не логируйте кожне дозвілля. Ви заплатите за диск і нічого не дізнаєтесь.
Логувати варто:

• Відхилені спроби від Cameras/Guest до внутрішніх ресурсів
• Нові зовнішні напрямки з VLAN камер (мають бути рідкісними)
• Події підключення/відключення VPN-тунелю
• Відхилення між VLAN, що впливають на критичні додатки (Warehouse/OT → Servers)

Топології VPN: hub-and-spoke, full mesh і «будь ласка, не треба»

Hub-and-spoke (рекомендовано для більшості організацій)

Офіс — хаб; склад — спок. Віддалені користувачі завершуються в хабі.
Переваги: одне місце для управління політикою, менше тунелів, простіша діагностика.
Недоліки: трафік йде через хаб (hairpin) якщо склад має звертатись до третього сайту; пропускна здатність хаба критична.

Full mesh (тільки якщо є кілька складів і потужна автоматизація)

Mesh працює, коли у вас є надійне управління конфігураціями і моніторинг. Якщо ви робите це вручну в веб-GUI,
ви будуєте майбутній інцидент.

Розширення L2 через VPN (уникати)

Розтягування VLAN між сайтами робить широкомовні та фейлові домени спільними для будівель. STP не стає чемним через тунель.
Якщо ви намагаєтесь зробити «один великий LAN», зупиніться і спитайте, яку проблему ви справді вирішуєте — зазвичай це старий механізм виявлення або вендор, який не вміє маршрутизувати.

WireGuard проти IPsec (практичні компроміси)

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

Камери та NVR: не ставте їх як принтери

Модель загроз, простою мовою

Камери — це комп’ютери з об’єктивами. Багато з них постачаються з слабкими налаштуваннями за замовчуванням, довготривалими багами у прошивці і значною кількістю вихідного «phone home».
Ваша мета — не зробити камери ідеальними. Ваша мета — зробити компрометацію камер нудною: ізольованою, залогованою і такою, що не дає змоги перескакувати на інші системи.

Практики, які реально працюють

• Жодного прямого входу з інтернету до камер або NVR. Якщо потрібен віддалений перегляд — використовуйте VPN або загартований relay.
• Блокуйте вихід камерам, крім NTP/DNS до внутрішніх резольверів і тих кінцевих точок, які ви явно затвердили.
• Використовуйте NVR/VMS у VLAN серверів або в окремому безпековому VLAN, а не всередині VLAN камер, ніби він пінаята.
• Вимкніть UPnP скрізь. Особливо на пограничних пристроях. UPnP — це механізм «сюрпризного відкриття портів».
• Синхронізація часу важлива: якщо часові мітки логів і відео дрейфують, розслідування перетворюються на фанфікшен.

Жарт №2: UPnP — як дати тостеру головний ключ від будівлі, бо він пообіцяв «господарювати порти відповідально».

Планування пропускної здатності для відео

Камери постійно «жеруть» пропускну здатність. Зробіть розрахунок. Декілька 4K камер з пристойним бітрейтом можуть наситити аплінки і Wi‑Fi.
Тримайте трафік камер локально на сайті, якщо можливо (камери складу до NVR складу). Якщо треба централізувати архів, розгляньте заплановану реплікацію або підпотоки нижчої якості через WAN.

Пастки з multicast і виявленням

Деякі розгортання камер покладаються на multicast для виявлення. Multicast не проходить через VLAN автоматично.
Уникайте дизайнів, що вимагають «дозволити multicast скрізь». Натомість визначте, де потрібно виявлення (зазвичай лише під час налаштування),
і потім закрийте доступ. Якщо вендор вимагає L2-сусідства для постійної роботи, розглядайте це як ризик продукту, а не як «мережеву проблему».

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

Наступні завдання передбачають наявність Linux-боксів на кожному сайті (або на файрволі, якщо він на Linux), плюс керовані комутатори і файрвол.
Команди навмисно загальні і переносимі. Сенс — операційний: що ви запускаєте, чого очікуєте і яке рішення приймаєте.

Завдання 1: Підтвердити, що інтерфейси VLAN існують і підняті

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eth0             UP             52:54:00:aa:bb:cc
eth0.10          UP             52:54:00:aa:bb:cc
eth0.30          UP             52:54:00:aa:bb:cc
eth0.99          DOWN           52:54:00:aa:bb:cc

Значення: VLAN-субінтерфейси існують; VLAN 99 вимкнено.
Рішення: якщо VLAN 99 — це management і має бути активним, підніміть його і перевірте, чи транк на комутаторі дозволяє VLAN 99.
Якщо він не використовується — видаліть його, щоб зменшити плутанину.

Завдання 2: Перевірити IP-адресацію на кожному інтерфейсі VLAN

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24
eth0.10          UP             10.10.10.1/24
eth0.30          UP             10.10.30.1/24

Значення: маршрутизатор має IP-шлюзи для VLAN 10 і 30.
Рішення: впевніться, що у кожного VLAN є рівно один шлюз; якщо бачите кілька пристроїв, що рекламують шлюз (без VRRP), ви запрошуєте асиметричну маршрутизацію.

Завдання 3: Перевірити таблицю маршрутів на наявність очікуваних підмереж сайту та маршрутів VPN

cr0x@server:~$ ip route
default via 203.0.113.1 dev eth0
10.10.10.0/24 dev eth0.10 proto kernel scope link src 10.10.10.1
10.10.30.0/24 dev eth0.30 proto kernel scope link src 10.10.30.1
10.20.40.0/24 via 10.255.0.2 dev wg0
10.20.30.0/24 via 10.255.0.2 dev wg0

Значення: VLANи складу 30/40 доступні через wg0.
Рішення: якщо бачите надто широкі маршрути (наприклад 10.20.0.0/16), хоча ви планували лише доступ до камер/NVR, звузьте AllowedIPs / phase2 селектори й політику файрвола.

Завдання 4: Перевірити стан тунелю WireGuard і час останнього рукостискання

cr0x@server:~$ sudo wg show
interface: wg0
  public key: rJc...redacted
  listening port: 51820

peer: 9hS...redacted
  endpoint: 198.51.100.20:51820
  allowed ips: 10.20.30.0/24, 10.20.40.0/24, 10.255.0.2/32
  latest handshake: 32 seconds ago
  transfer: 1.23 GiB received, 2.01 GiB sent

Значення: тунель живий; трафік передається.
Рішення: якщо рукостискання застаріле і лічильники передачі не змінюються, підозрюйте NAT/проброс портів, блоку UDP файрволом або невідповідні ключі.

Завдання 5: Виявити проблеми MTU контрольним ping

cr0x@server:~$ ping -M do -s 1420 10.20.30.10 -c 3
PING 10.20.30.10 (10.20.30.10) 1420(1448) bytes of data.
1428 bytes from 10.20.30.10: icmp_seq=1 ttl=63 time=18.2 ms
1428 bytes from 10.20.30.10: icmp_seq=2 ttl=63 time=18.5 ms
1428 bytes from 10.20.30.10: icmp_seq=3 ttl=63 time=18.4 ms

--- 10.20.30.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Значення: 1420-байтовий payload працює; MTU, ймовірно, підходить для типового накладного витрату WireGuard.
Рішення: якщо це не працює, але менші розміри проходять, зменшіть MTU на wg0 (або на WAN-інтерфейсі) і повторно протестуйте відеопотоки.

Завдання 6: Підтвердити DHCP-оренди для VLAN (і виявити «чужий» DHCP)

cr0x@server:~$ sudo journalctl -u isc-dhcp-server -n 10 --no-pager
dhcpd[1123]: DHCPDISCOVER from 3c:84:6a:11:22:33 via eth0.30
dhcpd[1123]: DHCPOFFER on 10.10.30.51 to 3c:84:6a:11:22:33 via eth0.30
dhcpd[1123]: DHCPREQUEST for 10.10.30.51 from 3c:84:6a:11:22:33 via eth0.30
dhcpd[1123]: DHCPACK on 10.10.30.51 to 3c:84:6a:11:22:33 via eth0.30

Значення: DHCP-сервер відповідає на VLAN камер.
Рішення: якщо клієнти отримують дивні адреси і ви не бачите логів, підозрюйте чужий DHCP на VLAN; увімкніть DHCP snooping на комутаторах або зафіксуйте порти під MAC камер.

Завдання 7: Перевірити політику між-VLAN з лічильниками

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "eth0.30" oifname "eth0.20" tcp dport { 554, 8000 } accept
    iifname "eth0.10" oifname "eth0.30" drop
    iifname "eth0.50" drop
  }
}

Значення: за замовчуванням drop; камери можуть дістатися серверів на RTSP/портах вендора; corp до камер заблоковано; гість заблокований.
Рішення: якщо відео не записується, переконайтеся, що дозвіл задано в правильному напрямку (camera→NVR або NVR→camera) залежно від вашої архітектури.

Завдання 8: Прослідкувати шлях пакета через VLAN і VPN

cr0x@server:~$ traceroute -n 10.20.30.10
traceroute to 10.20.30.10 (10.20.30.10), 30 hops max, 60 byte packets
 1  10.10.30.1  0.401 ms  0.322 ms  0.310 ms
 2  10.255.0.2  17.901 ms  17.872 ms  17.841 ms
 3  10.20.30.10  18.309 ms  18.292 ms  18.266 ms

Значення: хоп 2 — віддалений WireGuard-пір; маршрутизація адекватна.
Рішення: якщо бачите, що трафік йде на інтернет-шлюз за замовчуванням, у вас відсутні маршрути або AllowedIPs; виправте маршрутизацію перед тим, як звинувачувати камеру.

Завдання 9: Перевірити поведінку DNS з обмеженого VLAN

cr0x@server:~$ dig @10.10.20.53 nvr.office.local +short
10.10.20.20

Значення: внутрішній DNS резолвить ім’я NVR.
Рішення: якщо камери/NVR залежать від імен і DNS не працює між VLAN, дозвольте DNS з того VLAN до вашого резольвера — або відмовтесь від імен для камер і використовуйте статичні IP.

Завдання 10: Перевірити симптоми L2-петлі (broadcast storms) через статистику інтерфейсу

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    987654321 1234567      0   12345       0  987654
    TX:  bytes packets errors dropped carrier collsns
    876543210 1122334      0       0       0       0

Значення: високий multicast/broadcast (mcast) і падіння пакетів можуть свідчити про петлю або «шумні» пристрої.
Рішення: перевірте статус STP на комутаторах, знайдіть порт у петлі і вимкніть його. Якщо падіння на WAN — можливо, аплінк насичений відео.

Завдання 11: Захопити трафік на VLAN камер, щоб підтвердити, хто ініціює RTSP

cr0x@server:~$ sudo tcpdump -ni eth0.30 host 10.10.20.20 and port 554 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
IP 10.10.30.51.49210 > 10.10.20.20.554: Flags [S], seq 120033, win 64240, options [mss 1460,sackOK,TS val 1200 ecr 0,nop,wscale 7], length 0
IP 10.10.20.20.554 > 10.10.30.51.49210: Flags [S.], seq 99321, ack 120034, win 65160, options [mss 1460,sackOK,TS val 2200 ecr 1200,nop,wscale 7], length 0

Значення: камера ініціює з’єднання до NVR на 554; ваше правило файрвола має дозволяти camera→NVR.
Рішення: якщо бачите зворотне (NVR ініціює), відкоригуйте напрямок правила відповідно.

Завдання 12: Переконатися, що NAT не застосовано випадково до міжсайтового трафіку

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth0" masquerade
  }
}

Значення: masquerade застосовано лише на WAN-інтерфейсі eth0, що правильно.
Рішення: якщо NAT застосовано до wg0 або внутрішніх VLAN, ви зламаєте політику за адресами і отримаєте дивні односпрямовані проблеми. Виправте область NAT.

Завдання 13: Перевірити, чи камера намагається звертатись до інтернету

cr0x@server:~$ sudo nft add rule inet filter forward iifname "eth0.30" oifname "eth0" log prefix "CAMERA-EGRESS " drop
cr0x@server:~$ sudo journalctl -k -n 5 --no-pager
kernel: CAMERA-EGRESS IN=eth0.30 OUT=eth0 SRC=10.10.30.51 DST=93.184.216.34 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=2244 DF PROTO=TCP SPT=51233 DPT=80 WINDOW=64240 SYN

Значення: камера спробувала вихідний HTTP до публічної IP-адреси.
Рішення: залиште це правило drop (без логування, коли переконаєтеся), потім вирішіть, чи потрібен камері контрольований egress для оновлень — переважно робіть оновлення вручну.

Завдання 14: Перевірити тегування транка на боці Linux (VLAN бачить трафік)

cr0x@server:~$ sudo tcpdump -eni eth0 vlan 30 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
02:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype ARP (0x0806), Request who-has 10.10.30.1 tell 10.10.30.51, length 46

Значення: теги VLAN 30 присутні; транк працює, принаймні для цього VLAN.
Рішення: якщо не бачите тегів для очікуваних VLAN, виправте режим порту на комутаторі (trunk vs access) і список дозволених VLAN.

Швидкий план діагностики

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

Перше: локально, між-VLAN чи через VPN?

• З хоста в тому ж VLAN, ping до цільового IP. Якщо не відповідає — локальна проблема (комутація, DHCP, пристрій вимкнений).
• З хоста в іншому VLAN на тому самому сайті, ping до шлюзу, потім до цілі. Якщо шлюз відповідає, а ціль — ні, то проблема в файрволі/маршрутизації/політиці.
• З офісу до складу (або навпаки), ping через VPN. Якщо локально працює, але між сайтами — ні, фокус на VPN/маршрутизації/MTU.

Друге: підтвердьте маршрути і політику перед тим, як заглядати в пакети

• Перевірте таблиці маршрутів на маршрутизаторах (локально і віддалено). Відсутній маршрут з’їдає багато часу.
• Перевірте лічильники/логи файрвола на відмови. Якщо не логувати відмови під час впровадження — ви працюєте в сліпу.
• Переконайтеся, що NAT не застосовується до внутрішнього/VPN трафіку.

Третє: перевірте MTU і фрагментацію через VPN

• Використовуйте PMTU-ping з -M do і відрегулюйте MTU на тунельних інтерфейсах за потреби.
• Відеопотоки, що падають при успішних ping — класичний симптом MTU: малі пакети працюють, великі — чорна діра.

Четверте: тільки потім захоплюйте трафік

• Захоплюйте на інтерфейсі VLAN і на тунельному інтерфейсі. Якщо бачите його на VLAN, але не на тунелі — маршрутизація/політика його блокує.
• Якщо бачите на тунелі, але не на цілі — проблема на віддалій стороні (політика/маршрутизація) або ціль «бреше», що вона доступна.

П’яте: перевірте, чи «мережа — не мережа»

• Завантаження CPU камери, заповнене сховище NVR або зламаний DNS можуть виглядати як мережеві проблеми.
• Завжди перевіряйте стан сервісу: відкритий RTSP-порт, чи NVR записує, чи правильний час?

Поширені помилки: симптом → корінь → виправлення

1) «Камери раптово зникають онлайн»

Симптом: переривчасті зникнення камер, особливо коли на складі багато активності.

Корінь: насичення аплінку або bufferbloat; відео й трафік сканерів конкурують на одному лінку/черзі.

Виправлення: тримайте відео локально; застосуйте QoS для OT/сканерів; апгрейдьте аплінки; обмежте бітрейти камер; уникайте Wi‑Fi для фіксованих камер.

2) «VPN піднятий, але нічого не маршрутується»

Симптом: тунель рукопожатий, але підмережі недосяжні.

Корінь: відсутні маршрути, неправильні AllowedIPs/phase2 селектори або асиметрична маршрутизація.

Виправлення: переконайтесь, що обидві сторони мають маршрути до VLAN підмереж через тунель; перевірте, що файрвол дозволяє форвард між wg0 і VLAN-інтерфейсами.

3) «Все працює, крім веб-інтерфейсу NVR з віддалення»

Симптом: ping працює, але HTTPS/HTTP тайм-аутить або завантажується частково.

Корінь: MTU-чорна діра через VPN або відсутня MSS-clamping.

Виправлення: зменшіть MTU тунелю; увімкніть MSS-clamping на файрволі; повторно протестуйте великий payload ping і реальний браузерний трафік.

4) «Гостьовий Wi‑Fi бачить принтери/сервери»

Симптом: гості можуть дістатися внутрішніх IP.

Корінь: гостьовий SSID бриджений до corp VLAN або порядок правил файрвола дозволяє доступ.

Виправлення: відобразіть гостьовий SSID в гостевий VLAN; примусьте deny на шлюзі; перевірте транкове тегування AP і конфіг VLAN на комутаторі.

5) «Нова інсталяція камер ламає половину мережі»

Симптом: раптовий broadcast storm, високий CPU на комутаторах, втрата пакетів скрізь.

Корінь: введена петля (два порти з’єднані), або дешевий комутатор робить креативні речі.

Виправлення: увімкніть STP (і BPDU guard на краєвих портах); вимкніть флапаючі порти; забороніть невідкриті комутатори на лініях камер без схвалення.

6) «Сканери на складі стали повільні після сегментації»

Симптом: затримки в додатку сканера після переміщення сканерів у OT VLAN.

Корінь: відсутній доступ до DNS, заблоковані порти до сервесів додатку або залежність від широкомовного виявлення, що не проходить через VLAN.

Виправлення: явно дозвольте DNS/NTP і потрібні порти додатку; замініть широкомовне виявлення на DNS-записи або невеликий допоміжний сервіс; документуйте залежності.

7) «Ми більше не можемо оновити прошивку камер»

Симптом: оновлення прошивки не вдаються після блокування інтернет-доступу камер.

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

Виправлення: оновлюйте через NVR/VMS, якщо підтримується; тимчасово дозволяйте egress до конкретних кінцевих точок у вікна техобслуговування; логируйте і після видаляйте правило.

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

Інцидент через хибне припущення: «VPN шифрує — значить безпечно»

Середня компанія додала склад і розгорнула site-to-site VPN. План був простий: «підключити мережі».
Вони проспублікували весь офісний /16 до складу і навпаки. Ніякої сегментації. Ніякого значущого файрволінгу. VPN вважали межою безпеки.

Все працювало чудово, доки ПК на складі — який використовували для друку етикеток і інколи «перегляду пошти» — не підхопив звичайного інформаційного шкідника.
Малваре зробило своє: просканувало мережу, знайшло шарги і старий RDP-ендпоінт і пройшло в офісне середовище.
VPN не викликав порушення; він лише зняв перешкоди.

Найболючіше було не очищення. А післяінцидентна нарада, де всі усвідомили, що вони сприймали «зашифрований транспорт»
як «сегментацію». Це різні проблеми. Шифрування захищає пакети від підслуховування; воно не зупиняє скомпрометований хост.

Виправлення було не гламурне: розбили склад на VLAN OT, cameras і admin; заблокували між-VLAN потоки; обмежили VPN лише необхідними підмережами;
і змусили віддалену адміністрацію проходити через виділену VPN-підмережу з MFA. Нічого складного. Просто межі, що відповідають намірам.

Оптимізація, що вистрілила собі в ногу: «Централізуємо запис камер через WAN»

Інша організація захотіла «єдину панель» для відео. Вони помістили NVR/VMS у офісну серверну і стримили всі камери складу через VPN.
На папері: простіше керування, одне сховище, одна політика бекапу.

На практиці: WAN-лінк став критичним шляхом для фізичної безпеки. Коли на складі було багато активності, потоки камер деградували.
Коли провайдер мав перебої, запис на складі зупинявся. Ніхто не був задоволений, включно з командою безпеки, якій обіцяли «більшу надійність».

Вони намагались «оптимізувати» через компресію VPN і підлаштовували шифри. CPU зріс, латентність погіршилась і відео не покращилось.
Вони налаштовували тунель, коли реальне обмеження було простим фізичним фактом: пропускна здатність і черги на аплінку.

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

Нудна, але правильна практика, що врятувала: «Документуйте VLAN і тестуйте серйозно»

Роздрібний дистриб’ютор мав офіс, два склади і постачальника безпеки, якому інколи треба було доступ до камер.
Їхній мережевий лід наполягав на письмовій матриці: VLANи, підмережі, шлюзи, DHCP-скоупи і проста таблиця дозволених потоків.
Нікому не було весело. Здавалося бюрократією з додатковими кроками.

Через кілька місяців помер комутатор у Складі A і його треба було швидко замінити. Контрактор встановив заміну і — бо контрактори люди —
неправильно налаштував транк: камери опинилися в corp VLAN. Все «працювало», але було неправильно.

Причина, чому це швидко помітили: задокументована матриця потоків і базовий скрипт валідації, який команда запускала після будь-якої зміни.
Скрипт перевіряв, що пристрої з VLAN камер не можуть дістатися інтернету і що corp VLAN не може напряму потрапити на IP камер.
Тест одразу провалився. Вони виправили конфіг транка до того, як відео стало тихим каналом ексфільтрації.

Урок не в тому, що «контрактори погані». Урок у тому, що нудні контролі — документація, повторювані тести і політика default-deny — перетворюють помилки на алерти, а не на інциденти.

Контрольні списки / поетапний план

Фаза 1: Рішення про дизайн (зробіть це перед тим, як торкатися кабелів)

1. Визначте зони довіри: Corp, Servers, Cameras, Warehouse/OT, Guest, Management.
2. Обирайте послідовний IP-план по сайтах (наприклад, 10.10/16 офіс, 10.20/16 склад) і /24 на VLAN.
3. Вирішіть, де живе NVR/VMS (бажано локальний запис на сайті; центральний перегляд — опціонально).
4. Вирішіть модель VPN: hub-and-spoke, якщо немає вагомих причин інакше.
5. Напишіть allowlist-матрицю: який VLAN може дістатися до якого сервісу (порти) в якому напрямку.

Фаза 2: Побудова комутації (L2)

1. Створіть VLAN на комутаторах; дайте їм зрозумілі імена (CAMERAS, GUEST, MGMT).
2. Налаштуйте транки між комутатором і файрволом/маршрутизатором; дозволяйте лише потрібні VLAN.
3. Налаштуйте access-порти: камери на access VLAN 30, сканери на VLAN 40 тощо.
4. Увімкніть STP і BPDU guard на крайових портах, щоб зменшити площу ураження петлі.
5. Якщо підтримується, увімкніть DHCP snooping і dynamic ARP inspection на користувацьких/камера VLAN.

Фаза 3: Побудова маршрутизації + файрволінгу (L3)

1. Призначте IP-шлюзи інтерфейсам VLAN на файрволі/маршрутизаторі.
2. Встановіть політику форварду за замовчуванням — deny.
3. Додайте явні дозволи:
   • Cameras → порти NVR
   • Corp → серверні додатки (ERP, пошта, файлові служби)
   • Warehouse/OT → конкретні серверні порти + друк
   • VPN-користувачі → інтерфейси управління (обмежено)
4. Блокуйте вихід VLAN камер в інтернет; дозвольте NTP/DNS до внутрішніх сервісів.
5. Увімкніть логування відмов між ключовими VLAN під час впровадження.

Фаза 4: Інтеграція VPN

1. Підніміть site-to-site тунель між файрволами сайтів.
2. Маршрутуйте лише необхідні підмережі через VPN.
3. Підтвердіть MTU за допомогою ping без фрагментації; встановіть MTU/MSS clamp для тунелю, якщо потрібно.
4. Протестуйте критичні бізнес-потоки: сканери→ERP, NVR↔камери, IT→management VLAN.

Фаза 5: Операційна гігієна (те, що тримає систему в роботі)

1. Резервуйте конфігурації файрвола і комутаторів після змін.
2. Тримайте карту IP/VLAN у системі контролю версій (навіть якщо це просто текстовий файл).
3. Моніторте стан тунелю VPN і помилки/втрати інтерфейсів.
4. Раз на квартал переглядайте доступи: видаляйте старі правила, вендорів і винятки.
5. Патчте камери/NVR за графіком; обертайте паролі; вимикайте невикористані сервіси.

FAQ

1) Чи справді потрібна окрема VLAN для камер?

Так. Камери — високоризикові та високопропускні. Виділена VLAN для камер зменшує ризик латерального руху і робить керування пропускною здатністю можливим.
Помістіть NVR/VMS за межу файрвола, а не в ту ж зону довіри, що й усе інше.

2) Чи можна просто поставити камери в гостьову мережу?

Ні. Гостьові мережі зазвичай призначені лише для інтернету і не орієнтовані на стабільні внутрішні сервіси. Також ви не хочете, щоб камери мали доступ до інтернету.
Камери підходять у обмежений внутрішній VLAN з явним доступом до NVR і сервісів часу/DNS.

3) Чи маршрутизувати між VLAN на L3-комутаторі чи на файрволі?

Якщо потрібна велика пропускна здатність на east-west і проста політика, L3-switch підходить. Якщо потрібна централізована, аудитована політика безпеки,
маршрутуйте на файрволі. Багато організацій роблять обидва: L3-комутатор для ядра, файрвол для міжзональної політики через VRF або transit VLAN.
Для малих і середніх організацій найпростіше оперувати маршрутизацією на файрволі.

4) Чи WireGuard «безпечніший» за IPsec?

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

5) Чи треба шифрувати трафік у LAN, якщо є VLAN?

VLAN не шифрують; вони відокремлюють широкомовні домени. Якщо у вас є чутливий трафік (облікові дані, доступ до відео), використовуйте TLS/HTTPS і захищені протоколи.
Для доступу до управління використовуйте SSH/HTTPS і розгляньте management VPN-підмережу.

6) Чому не розширювати офісну VLAN на склад, щоб «усе працювало»?

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

7) Як дати постачальнику безпеки доступ до перегляду камер, не давши ключі від мережі?

Заведіть доступ постачальника через виділений VPN-профіль/підмережу. Дозвольте цій підмережі доступ лише до UI VMS/NVR (можливо через jump host),
не до VLAN камер. Логуйте доступ. Обмежуйте час, якщо можливо. Постачальнику не потрібна вся мережа — лише вузький прохід.

8) Як найпростіше забезпечити коректні часові мітки у камерах?

Забезпечте внутрішній NTP і дозвольте VLAN камер до нього. Блокуйте довільний інтернет NTP. Якщо є кілька сайтів, синхронізуйте їхні NTP-джерела і уніфікуйте часові пояси в VMS і камерах.

9) Як уникнути інцидентів «хтось включив випадковий комутатор на складі»?

Використовуйте port security (ліміти MAC), DHCP snooping і BPDU guard на доступних портах. Маркуйте порти. Навчайте команди обслуговування.
І прийміть, що це все одно станеться — тому моніторьте і робіть з цього невелику подію, а не заголовок у новинах.

10) Що робити, якщо потрібно дивитися камери складу з офісу?

Краще, щоб офісні користувачі підключалися до UI VMS/NVR складу через VPN, а не мали прямий доступ до камер. Якщо пропускна здатність — проблема,
використовуйте підпотоки низької якості для перегляду в реальному часі і тримайте повне розділення записів локально.

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

Якщо хочете, щоб офіс + склад + камери співіснували безпечно, робіть нудні речі навмисно:
сегментуйте VLAN, застосовуйте політику файрвола для втілення намірів, і використовуйте VPN як транспорт — не як магічний ковдру безпеки.
Тримайте трафік камер локально. Маршрутуйте між сайтами. Логуйте відмови під час впровадження. Зменшуйте зони довіри, поки вони не відображатимуть реальність.

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

1. Напишіть план VLAN/підмереж (навіть односторінковий документ) і зарезервуйте ID VLAN для росту.
2. Створіть VLAN камер і перемістіть дві камери як пілот; заблокуйте egress камер в інтернет і переконайтеся, що NVR все ще записує.
3. Обмежте site-to-site VPN лише потрібними підмережами; приберіть будь-які «маршрути все» ярлики.
4. Запустіть MTU-тест через VPN і усуньте проблеми фрагментації до того, як користувачі помітять зламане відео.
5. Увімкніть логування відмов між зонами на два тижні, а потім почистіть правила за результатами.

Мета не в досконалості. Мета — мережа, де відмови ізольовані, зміни передбачувані, і камери не мають думки щодо вашої безпекової позиції.