Как работает схема VLAN для гостевой сети и IP-камер

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

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

Ниже дана схема, которую можно перенести на маршрутизатор, межсетевой экран, управляемые коммутаторы и точки доступа любого производителя. Номера VLAN и подсети служат примером. Смысл схемы задают направления потоков, точные получатели и порядок правил.

VLAN отделяет кадры, а политику задает межсетевой экран

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

NIST SP 800-215 описывает традиционную сегментацию именно как пару механизмов: ресурсы с похожими требованиями помещают в сегменты, например с помощью идентификаторов VLAN, а шлюзы применяют правила по IP-адресам и портам. Это полезное уточнение. Тег 802.1Q отвечает на вопрос «к какому сегменту относится кадр», а межсетевой экран отвечает на вопрос «разрешен ли этот сеанс».

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

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

Я не использую правило «все VLAN могут ходить друг к другу, кроме нескольких запретов». Оно удобно только в день монтажа. Через год никто не помнит, какие новые подсети не попали в список исключений. Безопаснее явно разрешить нужные потоки, а остальное завершить запретом с журналированием.

Четыре зоны дают понятную адресацию

Для офиса без сложной филиальной структуры достаточно плана, в котором назначение видно по третьему октету. Не надо привязывать номер VLAN к числу рабочих мест или к номеру порта коммутатора. Такие значения меняются, а роль сегмента остается.

• Рабочая сеть: VLAN 20, подсеть 10.20.0.0/23, шлюз 10.20.0.1. Здесь находятся ПК, корпоративные ноутбуки и серверные сервисы по отдельным правилам.
• Гости: VLAN 40, подсеть 10.40.0.0/23, шлюз 10.40.0.1. Здесь находятся личные телефоны и ноутбуки посетителей.
• Камеры: VLAN 50, подсеть 10.50.0.0/24, шлюз 10.50.0.1. Здесь находятся IP-камеры и кодеры видео.
• Управление: VLAN 60, подсеть 10.60.0.0/24, шлюз 10.60.0.1. Здесь находятся коммутаторы, точки доступа, контроллеры и интерфейсы администрирования.

Диапазоны взяты из 10.0.0.0/8, одного из трех частных блоков RFC 1918. Частный адрес не дает защиты сам по себе: RFC 1918 регулирует адресацию и даже отдельно говорит, что вопросы безопасности в документе не рассматриваются. Защиту создают фильтры и отсутствие ненужных маршрутов.

Подсеть /23 для гостей дает запас без гигантского широковещательного домена, а /24 для камер проще учитывать. Но размер нужно считать по реальному числу клиентов, сроку аренды DHCP и росту. В конференц-центре гостевой пул может исчерпываться каждый час, хотя одновременно подключено мало людей: старые аренды еще заняты. Сокращение срока аренды там полезнее, чем случайное расширение до /16.

Регистратор не обязан жить вместе с камерами. Я предпочитаю адрес вроде 10.20.10.15 в серверной подсети или отдельный VLAN записи. Тогда правило «регистратор обращается к камерам» имеет одного известного инициатора. Если поместить регистратор в VLAN камер, рабочие места все равно должны получать доступ к его интерфейсу через отдельное правило, а компрометация регистратора сразу дает ему соседство второго уровня со всеми камерами.

DHCP должен выдавать гостям только их шлюз и подходящий DNS-сервис. Камерам лучше назначать резервирования DHCP или вести статические адреса в системе учета, но не смешивать оба метода без реестра. Адрес, подписанный как camera-12, который после замены достался другому устройству, превращает точечное правило в случайное разрешение.

Порт доступа не должен внезапно стать транком

На границе сети каждый порт получает одну понятную роль. Порт камеры работает как access-порт VLAN 50, порт точки доступа переносит только явно перечисленные VLAN, а не весь диапазон. Неиспользуемые порты отключаются и помещаются в нерабочий VLAN. Автоматическое согласование транка отключается там, где оно не требуется.

Для точки доступа обычно нужны VLAN управления и гостевой SSID, иногда еще корпоративный SSID. Нативный нетегированный трафик надо определить одинаково на обоих концах линии. Несовпадение нативного VLAN дает особенно неприятную неисправность: управление точкой может оказаться в пользовательском сегменте, а часть пакетов будет выглядеть исправной. Я предпочитаю тегировать все рабочие VLAN, если оборудование это поддерживает, и не использовать VLAN 1 для управления.

Гостевой SSID отображается только в VLAN 40. Настройка «изоляция клиентов», «peer blocking» или аналогичная функция запрещает двум беспроводным гостям общаться напрямую. Межсетевой экран не видит обмен между клиентами одного VLAN, потому что точка доступа или коммутатор передает кадры локально. Поэтому запрет GUEST -> INTERNAL никак не остановит сканирование соседнего гостевого телефона.

Для проводных гостевых портов и камер действует та же физика. Если камеры не должны обращаться друг к другу, нужны защищенные порты, private VLAN, ACL на портах либо отдельные малые сегменты. Полная изоляция камер иногда ломает схему, где одна камера отправляет события другой, поэтому сначала фиксируют потоки, потом включают ограничение.

Защита от поддельного DHCP-сервера и ARP-подмены тоже ставится на уровне доступа. DHCP snooping, Dynamic ARP Inspection и защита IPv6 Router Advertisement полезны, если коммутатор поддерживает их и команда умеет сопровождать привязки. Включать эти функции вслепую опасно: неверно отмеченный доверенный uplink оставит весь этаж без адресов. Сначала проверьте путь DHCP, затем применяйте защиту по одному типу портов.

Гости получают интернет, а не обзор офиса

Гостевой политике нужны три свойства: клиент получает сетевые параметры, открывает публичные ресурсы и не начинает сеансы к адресам организации. Порядок правил имеет значение. Сначала разрешаются DHCP и DNS к назначенным сервисам, затем запрещаются внутренние диапазоны, после этого разрешается выход в WAN. Если поставить широкое «гости в интернет» выше запрета частных сетей, результат зависит от того, что конкретный производитель понимает под зоной WAN.

Пример ниже не синтаксис определенного продукта, а проверяемая спецификация. Ее удобно положить рядом с конфигурацией и сверять при переносе на другой межсетевой экран.

objects:
  GUEST_NET = 10.40.0.0/23
  CAMERA_NET = 10.50.0.0/24
  NVR = 10.20.10.15
  ADMIN_NET = 10.60.10.0/24
  INTERNAL_V4 = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
  INTERNAL_V6 = fc00::/7
  DNS = 10.20.0.53
  NTP = 10.20.0.123

policy, ordered:
  allow GUEST_NET -> gateway : DHCP
  allow GUEST_NET -> DNS : DNS
  deny  GUEST_NET -> INTERNAL_V4 : any, log
  deny  GUEST_NET -> INTERNAL_V6 : any, log
  allow GUEST_NET -> WAN_PUBLIC : any, stateful

  allow CAMERA_NET -> DNS : DNS
  allow CAMERA_NET -> NTP : NTP
  allow NVR -> CAMERA_NET : INVENTORIED_CAMERA_PORTS, stateful
  allow ADMIN_NET -> CAMERA_NET : HTTPS, SSH, stateful
  deny  CAMERA_NET -> WAN : any, log
  deny  CAMERA_NET -> INTERNAL : any, log

  deny any -> any : any, log

Объект WAN_PUBLIC должен означать маршруты к публичным адресам, а не просто физический внешний интерфейс. Гость может обратиться к внутреннему адресу через VPN, второй канал провайдера или маршрут до филиала. Блокировка RFC 1918 закрывает типичные частные IPv4-сети, но организация может использовать публично маршрутизируемый диапазон внутри. Его тоже нужно включить в объект внутренних ресурсов. Отдельно запретите адреса управления самого шлюза, если локальные сервисы обрабатываются другой цепочкой правил.

Разрешать гостям только TCP 80 и 443 кажется аккуратным, но часто ломает VPN, голосовые приложения, игры и диагностический ICMP. Если гостевой сервис обещает обычный интернет, разумнее разрешить исходящий трафик к публичным адресам и ограничивать злоупотребления скоростью, числом сеансов и политикой DNS. Фильтр между гостями и внутренними сетями должен оставаться точным и жестким.

DNS создает еще одну границу. Гостям не нужен внутренний DNS, если он раскрывает имена серверов или принимает рекурсивные запросы без ограничения. Можно использовать резолвер на шлюзе с отдельным представлением зоны либо публичные резолверы согласно политике организации. Если вы принудительно отправляете DNS на свой сервис, заблокируйте прямые запросы на внешние TCP/UDP 53; зашифрованный DNS потребует другой политики и не сводится к одному порту.

Камера должна говорить только с известными получателями

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

Направление видеопотока часто понимают неверно. Во многих системах регистратор подключается к RTSP или ONVIF-службе камеры и забирает поток. Тогда инициатором выступает NVR, а не камера. В других системах камера отправляет поток или события на сервер сама. Правило надо строить по наблюдаемому сеансу, а не по стрелке на презентации. Состояние соединения разрешит обратные пакеты независимо от того, какая сторона передает больше данных.

Не открывайте «стандартные порты камер» на весь VLAN по списку из интернета. RTSP часто использует TCP 554, ONVIF-службы могут работать поверх HTTP или HTTPS на портах производителя, а медиаданные могут идти по UDP на согласованных динамических портах. Сначала добавьте камеру в лабораторный сегмент, запустите запись, просмотр, синхронизацию времени, события и обновление. Снимите потоки на шлюзе и составьте перечень вида «источник, получатель, протокол, порт, назначение». Только этот перечень превращается в разрешения.

Полный запрет интернета для камер стоит вводить осознанно. Облачное мобильное приложение, push-уведомления, проверка лицензии или получение прошивки могут перестать работать. Это не аргумент в пользу полного исходящего доступа. Решите, нужна ли функция, и дайте ей посредника: внутренний NTP, внутренний DNS, локальный сервер обновлений или временное правило по окну обслуживания. Когда производитель требует постоянное соединение с меняющимся набором облачных адресов, риск и эксплуатационная цена должны попасть в решение о закупке.

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

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

Обнаружение устройств пересекает границу только по решению

Автоматический поиск камер обычно не проходит через VLAN, и это нормальное следствие сегментации. ONVIF Core Client Test Specification описывает WS-Discovery: клиент отправляет Probe на multicast-адрес 239.255.255.250 и UDP-порт 3702, после чего устройство отвечает непосредственно клиенту. Маршрутизатор обычно не переносит такой локальный multicast в другой сегмент.

Из этого не следует, что надо объединить рабочие места и камеры. Для первичной настройки временно подключите административную станцию к VLAN камер, задайте адреса и учетные данные, затем управляйте известными IP через точечное правило. Второй вариант состоит в прокси обнаружения или reflector, который переносит только нужный протокол между конкретными VLAN. Такой сервис увеличивает поверхность доступа, поэтому его нельзя направлять в гостевую сеть.

mDNS ведет себя сходным образом. RFC 6762 задает link-local multicast 224.0.0.251 и UDP 5353 для IPv4, а также FF02::FB для IPv6. Если принтер или экран должен обнаруживаться из рабочей сети, отражайте только требуемые типы сервисов между рабочими сегментами. Не включайте общий mDNS-reflector между гостями, управлением и камерами ради удобства одного устройства.

Когда приложение «видит камеру только в одном VLAN», это не доказательство неисправности маршрутизации. Проверьте, пытается ли оно открыть известный unicast-адрес или полагается только на локальное обнаружение. В первом случае исправляют правило и маршрут, во втором меняют процедуру ввода в эксплуатацию либо добавляют узкий прокси.

IPv6 и управление закрывают обходные пути

Политика только для IPv4 оставляет второй сетевой путь, если точки доступа, клиенты и шлюз уже используют IPv6. Устройство может получить глобальный IPv6-адрес через Router Advertisement и выйти в интернет без IPv4 NAT. Гость может обратиться к внутреннему глобальному или ULA-адресу, хотя проверка 10.0.0.0/8 честно показывает блокировку.

Выберите один из двух вариантов. Либо полноценно настройте IPv6 для каждого VLAN с теми же границами, журналами и запретом новых входящих сеансов, либо отключите IPv6 и рассылку RA в тех сегментах, где команда пока не может его контролировать. Полумера, при которой IPv6 «вроде не используется», обычно означает отсутствие наблюдения.

RFC 4193 определяет fc00::/7 как пространство уникальных локальных IPv6-адресов, которое не ожидается в глобальной маршрутизации, но может маршрутизироваться внутри площадки. Поэтому ULA надо включить в объект внутренних сетей для гостевого запрета. Link-local fe80::/10 не проходит через обычный маршрутизатор, однако остается доступным соседям в том же VLAN. Изоляция клиентов нужна и для IPv6.

Плоскость управления должна жить отдельно от пользовательского трафика. Веб-интерфейсы коммутаторов, точек доступа, межсетевого экрана и камер доступны только с административной подсети или через jump host. Запретите управление на гостевом SSID и на обычных рабочих портах, отключите старые HTTP и Telnet, если оборудование поддерживает HTTPS и SSH, и ограничьте SNMP адресами системы мониторинга.

Отдельная сеть управления бесполезна, если администратор подключается к ней с повседневного ноутбука, где открывает почту и запускает случайные файлы. Для небольшого офиса приемлем выделенный администраторский узел с многофакторным доступом к VPN или jump host. Для крупной площадки нужны учетные записи по ролям, журнал команд и резервный доступ вне основной сети. Эти меры не меняют таблицу VLAN, но определяют, кто способен менять ее правила.

Проверка должна доказывать и разрешение, и запрет

Схема считается рабочей после тестов из гостевой сети, VLAN камер, административной сети и внешней точки. Проверка только с ноутбука администратора подтверждает, что администратор все видит. Она ничего не говорит о том, что видит гость.

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

1. Подключитесь к гостевому SSID и убедитесь, что адрес, маршрут и DNS относятся к VLAN 40.
2. Проверьте публичный сайт и DNS. Затем попытайтесь открыть шлюзы, сервер, регистратор и несколько адресов управления.
3. Подключите тестовую камеру в VLAN 50. Проверьте запись, время и события, затем посмотрите, какие исходящие попытки попали в запрет.
4. С административного узла откройте разрешенный интерфейс камеры. С обычной рабочей станции повторите запрос и убедитесь в отказе.
5. Из внешней сети проверьте отсутствие опубликованных портов камер и NVR, кроме специально утвержденного VPN-шлюза.

$ ip -br address
wlan0    UP    10.40.0.27/23

$ ip route
default via 10.40.0.1 dev wlan0
10.40.0.0/23 dev wlan0 proto kernel scope link src 10.40.0.27

$ dig @10.40.0.1 example.net +short
203.0.113.20

$ curl -I -m 5 https://example.net
HTTP/2 200

$ nc -vz -w 3 10.20.10.15 443
nc: connect to 10.20.10.15 port 443 (tcp) timed out

$ nmap -Pn -p 22,80,443,445,3389 10.20.0.10
PORT     STATE    SERVICE
22/tcp   filtered ssh
80/tcp   filtered http
443/tcp  filtered https
445/tcp  filtered microsoft-ds
3389/tcp filtered ms-wbt-server

Адрес 203.0.113.20 в примере относится к TEST-NET-3 и показывает только форму вывода, а не реальный сайт. Для фактической проверки используйте разрешенный внешний ресурс. Состояние filtered означает, что сканер не получил ответа и предполагает фильтрацию; оно не доказывает, какое именно устройство отбросило пакет. Свяжите попытку с ростом счетчика нужного deny-правила и записью журнала по адресу 10.40.0.27.

Тайм-аут удобен для сокрытия внутренней топологии, но усложняет диагностику. Я допускаю административно запрещенные ответы ICMP там, где они не раскрывают чувствительную информацию, и проверяю результат по журналу. Важно не слово в выводе, а совпадение четырех свидетельств: клиент получил правильный VLAN, разрешенный поток прошел, запрещенный поток не прошел, счетчик ожидаемого правила изменился.

Проверьте IPv6 отдельно командами ip -6 address, ip -6 route и соединением к известному внутреннему IPv6-адресу. Проверьте соседнего гостя, потому что этот трафик может не дойти до шлюза. Наконец, перезапустите камеру и точку доступа: некоторые ошибки появляются только после нового DHCP-сеанса или повторного согласования порта.

Не запускайте широкое сканирование производственной сети без согласованного окна. Для приемки достаточно небольшого набора заранее выбранных адресов и портов. Цель теста состоит в доказательстве границы, а не в создании нагрузки на старые камеры.

Схема остается безопасной, пока правила имеют владельца

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

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

Журналы запретов надо смотреть после ввода в эксплуатацию. Повторяющиеся обращения камеры к неизвестному внешнему адресу могут означать облачную функцию, ошибочный DNS, проверку обновлений или компрометацию. Не открывайте адрес автоматически. Сначала сопоставьте его с документацией и захватом трафика, затем решите, нужна ли функция.

При проектировании площадок GSE может связать серверную и сетевую инфраструктуру с требованиями к эксплуатации и поддержке, не привязывая схему к одному производителю. Но даже хорошо собранное оборудование не исправит правило allow any: приемочная матрица потоков должна оставаться частью проекта и после передачи заказчику.

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