Клиентские VLAN или тегированный trunk: выберите правильный режим OpenVPN

Приходят два запроса почти с одинаковой формулировкой: поместить каждого клиента VPN в выбранный VLAN или протянуть существующий VLAN trunk через VPN. Это разные продукты. Встроенный режим OpenVPN с поддержкой VLAN — это модель коммутатора для первого запроса, и он не является синонимом прозрачной передачи тегов. Неверный выбор даёт проект, который выглядит настроенным и молча отбрасывает кадры, которые были вам важны.

Что на самом деле строит режим с поддержкой VLAN

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

Сторона TAP сервера получает собственную политику приёма тегированных или нетегированных кадров через vlan-accept. Пересылка внутри этого коммутатора происходит только между совпадающими VID, в том числе когда задан client-to-client, поэтому два клиента в разных VLAN не могут достучаться друг до друга через сервер, хотя оба к нему подключены.

Эта модель — модель порта доступа. Кадры, покидающие клиента, не тегированы, а привязку навязывает сервер на основе идентичности. Просить ноутбук самостоятельно тегировать свой трафик — значит просить другой проект.

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

Что вместо этого требует прозрачный trunk

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

Отключение — только начало. Мост на каждом конце и физические порты коммутатора должны договориться, какие VLAN разрешены, какой тег является нативным и как обрабатываются нетегированные кадры. Расширение неограниченного trunk открывает гораздо больше широковещательных доменов, чем те два, которые вы хотели соединить.

Размер кадра требует собственного бюджета. Тегированный кадр Ethernet плюс инкапсуляция больше числа полезной нагрузки, которое люди копируют из руководства, а MTU, подходивший для маршрутизируемого туннеля, не доказывает, что путь trunk работает.

Три условия, которые определяют ответ

Во-первых, поддерживает ли клиентская платформа TAP вообще? Android и iOS — нет, а поддержка macOS ограничена, поэтому парк мобильных пользователей исключает оба проекта TAP, как бы ни были устроены VLAN. Маршрутизируемый сеанс TUN передаёт IP-пакеты, а не кадры Ethernet, и никакая настройка VLAN на сервере этого не меняет. Проверьте парк до проектирования топологии, потому что это условие обойти нельзя. Это также условие, которое чаще всего обнаруживается уже после завершения работ с коммутатором.

Во-вторых, кто назначает VLAN? Если ответ «сервер, по тому, кто аутентифицировался», подходит модель коммутатора. Если ответ «существующая инфраструктура коммутаторов, с тегами, которые уже есть», нужен проект trunk.

В-третьих, какая часть сети должна быть доступна? Модель коммутатора по построению держит каждого клиента в одном VLAN. Проект trunk — это мост, а неправильно настроенный мост соединяет широковещательные домены, которые должны были оставаться раздельными.

Проверка сделанного выбора

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

ip -d link show tap0
bridge vlan show

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

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