Самостоятельный хостинг сервисов и приложений в Docker — отличный способ экономить, учиться и контролировать свои данные. Но даже если контейнеры формально изолированы, вся домашняя сеть часто представляет собой одну плоскую подсеть, где соседствуют ноутбуки, смартфоны, IoT‑устройства и «тяжёлые» сервисы.
Это повышает риски, особенно при использовании Wi‑Fi и публично доступных контейнеров. Простое и эффективное решение — вынести чувствительные контейнеры в выделенный VLAN и управлять доступом на уровне сети.
Выделенный VLAN добавляет ещё один барьер: даже при взломе одного узла злоумышленнику сложнее двигаться дальше по сети. На практике я всегда выношу самые важные контейнеры на отдельный VLAN и задаю явные правила, кто и к чему может подключаться. Хорошая новость — настроить это реально своими руками.
TL;DR
- Разделяйте сеть: выделенный VLAN для контейнеров снижает «взрывной радиус» инцидентов.
- В первую очередь изолируйте базы данных, Home Assistant, публичные сервисы (Nextcloud, Jellyfin, Immich), NVR/Frigate и LLM‑стек.
- Используйте macvlan/ipvlan для назначения контейнерам интерфейса в нужном VLAN и регулируйте доступ межсетевыми правилами.
- Ограничьте egress (исходящий трафик) для контейнеров, а discovery (mDNS/SSDP) включайте только там, где это нужно.
- Начните с одного «homelab» VLAN и базовых правил. При росте добавляйте DMZ для публичных сервисов, IoT‑VLAN и отдельный сегмент под камеры.
Зачем Docker‑контейнерам выделенный VLAN
VLAN — это логическая сегментация L2‑сети (802.1Q), позволяющая держать разные классы устройств и сервисов в отдельных «коридорах». Для домохостинга это значит:
- Снижение риска бокового перемещения: компрометация IoT‑устройства не даёт мгновенного доступа к БД или медиа‑серверу.
- Точная политика доступа: явные allow‑rules на межсетевом экране вместо «всё видит всё».
- Удобство сопровождения: диагностика трафика, чёткая адресация, разные политики NAT/DNS.
Плоская LAN особенно опасна, когда контейнеры доступны извне (через VPN, обратный прокси или туннели) — одна ошибка в конфигурации может открыть половину сети. VLAN добавляет «сухой док»: даже публичный сервис не увидит приватные хранилища по умолчанию.
Что в первую очередь уносить в отдельный VLAN
Базы данных (CouchDB и не только)
Сетевые БД — лакомая цель. Им не нужны прямые подключения с пользовательских устройств. Вынесите их в VLAN, дайте доступ только приложениям/контейнерам, которым это необходимо. Если вы, к примеру, синхронизируете заметки Obsidian через CouchDB, держите её отдельно от остальных БД, но в рамках общего «DB‑VLAN». Для контейнера назначайте интерфейс macvlan/ipvlan в этом VLAN и ограничивайте доступ правилами межсетевого экрана.
Home Assistant
Home Assistant — нервная система умного дома: управляет розетками, лампами, сенсорами и может интегрироваться с локальным LLM для голосового контроля. Это «краевой» сервис, который пересекается с множеством небезопасных вещей. Разместите HA в отдельном VLAN и разрешите к нему доступ лишь из основной домашней сети и от тех устройств, которые действительно должны с ним общаться. IoT‑гаджеты держите в своём VLAN и выдавайте им только необходимый минимум исходящих соединений.
Публично доступные контейнеры (Nextcloud, Jellyfin, Immich)
Всё, что торчит наружу через обратный прокси, VPN или туннели, — кандидат в выделенную «DMZ‑зону» (отдельный VLAN). Так вы отделяете внешнюю плоскость от приватных данных. Для Nextcloud (файлы, календари, контакты) это критично: даже при уязвимости веб‑стека злоумышленник не попадёт напрямую к БД или хранилищам в другом VLAN.
Frigate (NVR) и камеры
Видео — чувствительные данные. Разместите Frigate и камеры на отдельном VLAN, а доступ к Frigate дайте только тем клиентам, кому это необходимо, или транзитом через Home Assistant. Это сокращает риск утечки RTSP‑потоков и служебных страниц камер.
LLM‑стек
Локальные LLM требуют больших моделей, GPU и нередко тянут зависимости из интернета. Изолируйте их: ограничьте egress, дайте доступ только к репозиториям моделей (или вовсе запретите исходящий трафик), разрешите вход лишь из доверенной подсети. Так вы защититесь от утечек и нежелательного фонового трафика.
Архитектурные паттерны сегментации
- Один «homelab» VLAN: все контейнеры внутри, доступ — по «белым спискам». Простой старт.
- DMZ VLAN для публичных сервисов: отдельно от приватных данных и БД.
- IoT VLAN: устройства «умного дома» без прямого выхода ко внутренним хранилищам.
- Camera/NVR VLAN: камеры и NVR отдельно, доступ строго по whitelisting.
- Management VLAN: для администрирования (SSH/HTTPS к гипервизорам, свичам, контроллерам).
Как настроить: пошагово
- Спланируйте адресацию. Пример: VLAN 20 — 10.10.20.0/24 (homelab), шлюз 10.10.20.1. Заранее определите, что где живёт.
- Создайте VLAN на маршрутизаторе/фаерволе и свичах: пометьте trunk‑порты к гипервизору/хосту Docker, назначьте SSID‑к‑VLAN для Wi‑Fi при необходимости. Включите межVLAN‑маршрутизацию только там, где она нужна.
- На хосте Linux поднимите подинтерфейс VLAN. Пример без форматирования: ip link add link eth0 name eth0.20 type vlan id 20; ip addr add 10.10.20.10/24 dev eth0.20; ip link set eth0.20 up.
- Создайте сеть Docker. Вариант macvlan (контейнеры получают MAC и IP как отдельные хосты): docker network create -d macvlan -o parent=eth0.20 —subnet 10.10.20.0/24 —gateway 10.10.20.1 vlan20_net. Вариант ipvlan (меньше ARP, проще для некоторых свичей): docker network create -d ipvlan -o parent=eth0.20 -o ipvlan_mode=l2 —subnet 10.10.20.0/24 —gateway 10.10.20.1 vlan20_net.
- Подключите контейнеры к сети. В Compose это секция networks с именем vlan20_net и static ip при необходимости. Следите, чтобы БД слушала только адрес VLAN.
- Задайте правила фаервола: «по умолчанию — deny». Разрешайте:
- только нужные порты от конкретных подсетей/хостов (например, 8123 к Home Assistant из домашней LAN);
- минимальный egress (DNS/NTP/обновления — по списку, остальное — запрет);
- при необходимости — mDNS/SSDP ретрансляцию между VLAN (через mDNS‑ретранслятор или отражатель), иначе discovery может не работать; альтернативно — выключите discovery и пропишите интеграции вручную.
- Расположите обратный прокси. Безопасный вариант — в DMZ‑VLAN рядом с публичными сервисами. Внутрь — только нужные бэкенды по списку.
- Наблюдаемость и алерты: логи фаервола, системные метрики, байткоды IDS/IPS по желанию. Обновления — через регламенты и окна обслуживания.
Подводные камни и как их обойти
- macvlan и доступ к хосту: контейнер на macvlan по умолчанию не видит хост. Решения: дополнительный macvlan‑интерфейс на хосте в том же сегменте с статической маршрутной записью; либо используйте ipvlan, где взаимодействие с хостом проще.
- Мультикаст и discovery: mDNS/SSDP не ходят между VLAN без ретрансляции. Разрешайте только к целевым сервисам и только на время настройки, либо интегрируйте вручную.
- Wi‑Fi и VLAN: сопоставьте SSID отдельным VLAN, включите изоляцию клиентов на «гостевой» сети. IoT часто требует 2,4 ГГц — учитывайте это при дизайне.
- MTU и производительность: держите единый MTU по пути или тщательно тестируйте jumbo‑кадры.
- Автоправила Docker и системный фаервол: проверьте, не конфликтуют ли iptables/nftables от Docker с глобальной политикой. Иногда проще отключить автонатстройки Docker и управлять вручную.
- Безопасность БД: TLS, строгие учётные записи, отсутствие «гостя», бэкапы и чёткая ротация секретов. Следите, чтобы БД была доступна только в своём VLAN.
Мини‑сценарий: Home Assistant + IoT
IoT‑устройства в VLAN 30 без доступа в интернет, кроме NTP/DNS. Home Assistant в VLAN 20. Разрешаем из домашней LAN доступ к HA по веб‑интерфейсу и API, HA — доступ к устройствам в VLAN 30 по нужным протоколам. Опционально включаем ретрансляцию mDNS/SSDP только между VLAN 20 и 30. Все остальные межVLAN‑соединения — deny.
Итоги
Изоляция контейнеров в выделенном VLAN — простой способ добавить сетевой уровень защиты к Docker и снизить риски при самохостинге. Начните с одного «homelab»‑сегмента и базовых правил доступа. По мере роста вынесите публичные сервисы в DMZ, БД — в отдельный VLAN, а IoT и камеры — в свои сегменты. Так вы сохраните управляемость, повысите безопасность и получите предсказуемую инфраструктуру, не усложняя её сверх меры.
Сетевые вторжения — не шутка, но грамотная сегментация, минимально необходимые разрешения и дисциплина обновлений существенно усложняют жизнь злоумышленникам и сохраняют ваш домашний «облачно‑контейнерный» мир в безопасности.
