Что такое VLAN: разделение сети, теги 802.1Q, access и trunk

Что такое VLAN и зачем она компании

VLAN — виртуальная локальная сеть на втором уровне. Она позволяет разделить одну коммутируемую инфраструктуру на логические сегменты: сотрудники, гости, оборудование и управление используют общие коммутаторы, но относятся к разным широковещательным доменам.

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

VLAN не шифрует трафик и не заменяет firewall. Разделение на втором уровне создаёт границы сегментов, а доступ между ними задаётся маршрутизацией и правилами. Если маршрутизатор разрешает всё между VLAN, ожидаемой изоляции приложений не получится.

Что отделяет широковещательный домен

Например, ARP-запрос IPv4 распространяется в соответствующем VLAN, а не во все остальные сегменты коммутатора. Неизвестный unicast и multicast обрабатываются по собственным правилам устройства; для них также важны VLAN-контекст и настройки.

VLAN и IP-подсеть — разные сущности. Практичный типовой проект использует отдельную подсеть на VLAN, но номер VLAN не является частью IP-адреса. Совпадение VID 20 и адресации 10.10.20.0/24 — удобная договорённость в нашем плане, не техническое требование.

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

Тег 802.1Q: где находится номер VLAN

В распространённом одиночном C-tag используется TPID 0x8100. В TCI находятся PCP для приоритета, DEI и 12-битный VID. Номер VLAN отвечает за принадлежность кадра к сегменту; PCP не гарантирует нужную полосу без настроенной политики QoS.

Для обычных VLAN используют VID 1–4094. Значение 0 связано с приоритетной маркировкой без обычного VLAN ID, 4095 зарезервировано. Конкретное устройство может иметь дополнительные ограничения по ID, количеству VLAN и режимам. Наличие 12-битного поля не означает, что любая модель коммутатора поддерживает все возможные VLAN одновременно.

Тег добавляет четыре байта к формату кадра. При совместимости линков и туннелей учитывают допустимый размер Ethernet-кадра; это не означает, что IP MTU на каждом обычном VLAN обязательно нужно уменьшить на четыре. QinQ и другие инкапсуляции требуют отдельного расчёта.

Где тег добавляется и где снимается

Не нужно предполагать, что обычная рабочая станция сама добавляет VLAN-тег. На access-подключении это обычно задача коммутатора. А сервер виртуализации, точка Wi-Fi или другой VLAN-aware узел могут передавать несколько tagged-сегментов через один интерфейс.

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

Access, trunk и смешанный порт

• Access: типовое подключение обычного клиента к одному VLAN; кадры на проводе обычно untagged.
• Trunk: переносит согласованный набор VLAN между коммутаторами, шлюзом, сервером или точкой доступа.
• Смешанный режим: один VLAN может передаваться untagged, другие tagged. Термины hybrid, general и настройки различаются у вендоров.

Trunk не означает «пропускаем все VLAN». Явно определяют allowed-набор, обработку untagged и допустимые типы входящих кадров. Оба конца соединения должны одинаково понимать используемые VID и формат каждого сегмента.

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

PVID, native VLAN и untagged — разные вопросы

PVID определяет, к какому VLAN отнести нетегированный входящий кадр в соответствующем режиме порта. Это операция классификации на входе. Уже tagged-кадр обрабатывается по его VID и правилам приёма; PVID не является универсальной командой «переписать любой тег».

Untagged на выходе отвечает за формат кадра при передаче через конкретный порт. Этот параметр не следует путать с входным PVID, даже когда интерфейс устройства объединяет настройки в один access/native-профиль.

Native VLAN обычно связывает untagged-трафик на trunk с выбранным VLAN. Но возможность передавать native tagged, поддержка untagged и точный синтаксис зависят от платформы. В плане нужно записывать реальный входной и выходной режим, а не только слово native.

Несовпадение native/PVID на двух концах способно отнести один нетегированный кадр к разным сегментам. Для транзита без untagged-трафика можно проектировать приём только tagged, если это поддерживается и согласовано. Простое изменение PVID без проверки membership и egress — частая причина потери управления.

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

• VLAN 10 — сотрудники: 10.10.10.0/24, шлюз 10.10.10.1.
• VLAN 20 — гости: 10.10.20.0/24, шлюз 10.10.20.1.
• VLAN 30 — оборудование: 10.10.30.0/24, шлюз 10.10.30.1.
• VLAN 99 — управление: 10.10.99.0/24, шлюз 10.10.99.1.

Это учебные непересекающиеся подсети. Перед внедрением их сверяют с офисами, VPN, облачными сетями и планом адресации. Шлюзы должны существовать на соответствующих L3-интерфейсах: запись адреса в таблице проекта их не создаёт.

Для каждого VLAN указывают владельца, назначение, DHCP-диапазон или статические назначения, DNS и необходимые связи. Для оборудования полезны учёт и контролируемые резервации; для управления важнее узкий доступ, чем красивый номер 99.

Если устройство должно иметь несколько сетей, отдельно определите, где именно завершаются VLAN: на NIC, гипервизоре, виртуальном коммутаторе или внутри гостевой ОС. Иначе легко получить двойную маркировку или неподходящий VLAN для виртуальной машины.

Портовый план: что согласовать на каждой стороне

• p1 → сотрудник: вход untagged, PVID 10, выход VLAN 10 untagged.
• p2 → гость: вход untagged, PVID 20, выход VLAN 20 untagged.
• p3 → устройство: вход untagged, PVID 30, выход VLAN 30 untagged.
• p4 → точка Wi-Fi: управление 99 untagged/PVID 99; клиентские VLAN 10 и 20 tagged.
• p5 → шлюз: VLAN 10/20/30/99 tagged; нетегированные кадры не принимаются в этой модели.

У схемы p4 есть явное условие: сама точка должна ожидать управление untagged и сопоставлять SSID с tagged VLAN 10/20. Если её management VLAN настроен tagged 99, обе стороны меняют согласованно. Нельзя копировать такой mixed-порт к любой точке без чтения её настроек.

На p5 шлюз должен принимать те же tagged VID и иметь необходимые VLAN-интерфейсы. Клиентский access-порт в учебной модели принимает только untagged: отправленный клиентом произвольный тег не даёт ему право попасть в соседний сегмент.

CSV с этим планом и JSON находятся в архиве. Это описание намерений, не команды конкретного коммутатора.

Как разные VLAN общаются между собой

Маршрутизацию между VLAN выполняет маршрутизатор, firewall или L3-коммутатор. На шлюзе используются VLAN-подинтерфейсы, SVI, IRB или другая модель платформы. Если используется общий trunk, устройство различает сегменты по тегам и передаёт разрешённый трафик в нужный L3-контекст.

Не любая маршрутизация проходит через программный CPU медленно: современные устройства могут выполнять часть L3-функций аппаратно. Но аппаратный маршрут, поддержка ACL, stateful firewall и видимость в захвате зависят от модели и режима. Производительность проверяют с реально нужными функциями, а не только по скорости портов.

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

Матрица доступа: VLAN сама ничего не разрешает

• Гости: только необходимые DHCP/DNS и согласованный выход в Интернет; корпоративные сети закрыты.
• Сотрудники: доступ к конкретным сервисам оборудования, например TCP 445 к согласованному файловому серверу, если это требуется.
• Оборудование: новые соединения в пользовательский сегмент по умолчанию не разрешаются без необходимости.
• Управление: только с контролируемых административных узлов по нужным протоколам.

Правила для DHCP/DNS и других инфраструктурных зависимостей определяют до общих запретов так, чтобы не сломать получение адреса. Допустимые ответы stateful-соединения и новые инициированные потоки различают. Управление самим шлюзом и проходящий через него трафик могут попадать в разные цепочки или зоны.

Проверьте IPv6 и все реальные внутренние маршруты: запрет только нескольких IPv4-подсетей не является полной гостевой изоляцией. Также отдельно проверяют связь клиентов внутри одной VLAN — межвлановый firewall может её вообще не видеть.

Матрица в ZIP — отправная точка обсуждения. Она не является готовым набором ACL, не учитывает автоматически все сервисы и не применена к оборудованию.

DHCP, DNS, Wi-Fi и телефония

Для каждого клиентского сегмента нужен подходящий DHCP-сервис или обоснованная статическая адресация. Если DHCP находится вне VLAN, используется корректно настроенный relay и разрешённый путь. Проверяют не только выдачу адреса, но и маску, шлюз, DNS, аренду и отсутствие чужого DHCP.

SSID сам по себе не создаёт сетевую изоляцию. Нужны согласованные SSID→VLAN, trunk до точки и правила на шлюзе. Если гостевой SSID попал в native management VLAN, красивое имя Wi-Fi не спасает архитектуру.

Телефон с компьютером за встроенным портом может использовать voice VLAN с отдельной маркировкой и механизмом назначения. Это уже не обычный access-пример «один клиент — один untagged VLAN»: режимы согласуют по документации телефона и коммутатора.

Поиск принтеров и других сервисов через mDNS или широковещательные механизмы может перестать работать между VLAN. Это ожидаемая граница L2. Вместо бесконтрольного объединения сегментов выбирают нужный relay/proxy или прямую настройку сервиса с ограниченным доступом.

Switch chip, CPU и аппаратная обработка

Коммутатор учитывает VLAN при выборе домена коммутации и выходного порта. Изученная MAC-информация относится к соответствующему контексту; одинаковый MAC в разных сегментах не стоит диагностировать как одну общую запись без проверки VLAN.

Hardware offload может передавать кадры внутри switch chip без прохода каждого пакета через программный стек. Трафик к собственному адресу устройства, маршрутизация, фильтры и зеркалирование имеют отдельные пути и ограничения. Поэтому отсутствие кадра в CPU-захвате не доказывает, что он не прошёл через чип.

CPU-port или bridge self на некоторых платформах — логическая связь VLAN-домена с самим устройством. Не надо «пускать CPU ко всем VLAN»: определяют, где нужны управление и L3-сервисы, и настраивают только эти связи. Модель CPU-порта, условия offload и поддержка фильтрации проверяются по конкретному оборудованию.

Защита, петли и ошибки сегментации

• Ограничить allowed VLAN на транзитах, а клиентским портам задать подходящий режим приёма кадров.
• Не оставлять ненужные VLAN и управление доступными на всех портах.
• Контролировать конфигурацию trunk/native на обеих сторонах и отключать ненужное автоматическое согласование, где оно существует.
• Учитывать STP/RSTP/MSTP, LAG и физическую топологию: VLAN не является защитой от L2-петли.
• При необходимости использовать DHCP snooping, защиту портов и другие механизмы, проверив поддержку и влияние на схему.

VLAN hopping — не повод отказаться от сегментации, а причина правильно ограничить режимы и не доверять маркировке от любого клиента. Условия атак и защит зависят от платформы; отдельная management VLAN и контроль доступа важнее одной смены native ID.

Изменение номера VLAN не шифрует кадры. И если всем разрешена маршрутизация ко всем, раздельные L2-домены не заменят реальную политику безопасности.

Как диагностировать VLAN без случайных изменений

ip -br address
ip -d link show
bridge vlan show
bridge fdb show

Команды предназначены для Linux с iproute2 и читают состояние. ip -br address показывает адреса интерфейсов. ip -d link show раскрывает подробности, включая VLAN ID для соответствующих подинтерфейсов. bridge vlan show показывает таблицу VLAN Linux bridge, а bridge fdb show — его MAC-записи.

Они не запрашивают автоматически конфигурацию любого внешнего коммутатора. На другом оборудовании используют его интерфейс или show/print-команды для membership, PVID, tagged/untagged, FDB и offload. Пустая Linux-таблица на обычном ПК не говорит, что VLAN не существует на сетевом устройстве.

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Get-NetNeighbor -AddressFamily IPv4

На Windows эти команды показывают полученную адресацию, маршруты и соседей IPv4. Это полезно для проверки клиента после переноса, но они не доказывают VLAN ID на access-порту: сам клиент может получать только untagged-кадры. Для IPv6 проверку выполняют отдельно.

При захвате учитывайте место измерения, зеркалирование и offload NIC. Аппаратная обработка может скрывать или представлять тег иначе; нельзя делать вывод об отсутствии 802.1Q на проводе только по одному захвату конечного хоста.

Если после разделения перестало работать

1. Нет адреса DHCP: проверить access/PVID, membership по пути, scope, relay и разрешения.
2. Адрес из чужой подсети: искать неправильный PVID/native, ошибочное подключение или чужой DHCP.
3. Свой VLAN работает, другой нет: проверить шлюз, маршруты, обратный путь и firewall.
4. Управление пропало: сверить формат management VLAN на каждом транзите, L3-интерфейс и доступ к самому устройству.
5. Wi-Fi подключился без доступа: проверить не только пароль, но и SSID→VLAN, trunk, DHCP и DNS.
6. Маленькие пакеты проходят, большие нет: проверить MTU, инкапсуляции и ошибки линка.

Не переключайте все порты в trunk и не разрешайте все VID как первый шаг. Сначала проследите один конкретный кадр: какой он на входе, в какой VLAN классифицирован, разрешена ли она на выходе и с каким тегом передаётся.

Наглядная модель PVID и выхода кадра

В ZIP есть маленькая программа Python, которая рассматривает ровно описанные p1–p5. Она проверяет классификацию untagged по PVID, admission, членство VLAN и формат кадра на выходе. Пример: кадр от p1 получает внутреннюю VLAN 10; p5 отдаёт его с тегом 10, p1 — без тега, а p2 не является выходом VLAN 10.

# Windows, после распаковки архива
py -3 vlan-model.py
# Linux: соответствующая команда вместо Windows-варианта
python3 vlan-model.py

Запускают команду своей ОС из папки архива. Ожидается PASS_OFFLINE_MODEL для 15 проверок. Никаких команд маршрутизатору программа не посылает. В модели специально исключены priority-only VID 0, QinQ, обучение MAC, STP, DHCP, маршрутизация, firewall и производительность чипа.

Успех модели доказывает согласованность этого учебного алгоритма и файлов, а не правильность настройки вашего железа. Для реализации на MikroTik используйте отдельную подробную инструкцию по VLAN, сверяя устройство и RouterOS. Здесь рассматриваются универсальные принципы, а не второй набор универсальных set-команд.

Как внедрять и принимать сегментацию

1. Сохранить конфигурацию, адресацию, схему подключений и способ возврата.
2. Подготовить VLAN/IP/портовый план и матрицу доступа.
3. Создать нужные L3-сервисы, DHCP/DNS и правила; согласовать trunk на обеих сторонах.
4. Проверить на одном тестовом порту и клиенте, затем переносить группы поэтапно.
5. Испытать разрешённые и запрещённые потоки, включая гостей, управление и IPv6.
6. Проверить сохранение, перезагрузку, резервные связи, offload и фактическую нагрузку.
7. Обновить документацию, мониторинг и порядок добавления новых портов.

Не включайте VLAN filtering на рабочем bridge через единственный удалённый доступ без консоли или безопасного возврата. Особенно опасно одновременно менять membership управления и его адрес.

Приёмка включает реальные операции: сотрудник работает с сервисом, гость не достигает внутренних адресов, администратор сохраняет управляемость. Отсутствие ping не равно доказанному запрету всех протоколов, а успешный ping не подтверждает исправность приложения.

Первичные источники: VLAN и bridging Juniper, формат 802.1Q, Linux switchdev, bridge. Сверены 14 ноября 2026 года; вендорские особенности не выдаются за одинаковое поведение всех платформ.

Скачать проект и карточку приёмки

Архив не содержит паролей и готовых команд изменения рабочей сети. CSV и модель нужно адаптировать к задаче и проверить на целевом оборудовании.

Поможем спроектировать сеть и сопровождать её

Вопросы и ответы