Мост TAP для одного VLAN: подключите субинтерфейс

Клиент TAP, который добирался до LAN до VLAN и после этого перестал, обычно имеет мост, всё ещё содержащий не тот интерфейс. Пересылка кадров не добавляет тег VLAN, поэтому нетегированный кадр клиента, отправленный в физический аплинк, приходит без тега на транковый порт и либо отбрасывается, либо попадает в нативный VLAN. То, что субинтерфейс существует где-то на хосте, ничего не меняет в списке участников моста. Именно этот миф и нужно убить первым: тег ставит интерфейс, которому он принадлежит, а не хост, у которого он просто есть.

Одно расширение VLAN — это один домен уровня 2, и мост должен войти в этот домен, а не в транк, несущий их все.

Тег не появляется, потому что вы смостовали транк

Возьмите Linux-аплинк eno1, несущий VLAN 120, к управляемому коммутатору. Схема, которая работает для одного VLAN, — tap_vpn, смостованный с br_vpn, где br_vpn содержит eno1.120, а не eno1. Субинтерфейс VLAN ставит тег на выходе и снимает его на входе, поэтому мост видит только нетегированные кадры для этого одного VLAN. Поместите вместо этого физический интерфейс в мост, и те же кадры уйдут без тега в транковый порт, что вы не планировали.

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

Две законные схемы, один владелец тега

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

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

Перенесите адрес вместе с принадлежностью

В схеме с субинтерфейсом адрес хоста для смостованной подсети принадлежит br_vpn, а не подчинённому VLAN-порту, где он мог жить раньше. Оставить его на порту может выглядеть работающим, а затем вести себя странно, потому что мост пересылает на уровне 2, пока адрес сидит на участнике. Перенесите его как часть изменения принадлежности, а не как отдельный эксперимент.

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

Адресация клиентов требует такой же аккуратности. Смостованный VPN помещает клиентов в расширенную подсеть, поэтому пул не должен пересекаться с другими арендами или статическими назначениями, а схема, обслуживаемая DHCP, должна быть той, которую LAN действительно ожидает. Работающий путь уровня 2 ничего не говорит о дублирующихся адресах.

Проверьте принадлежность, прежде чем винить маршруты

Читайте текущее состояние, а не предполагаемое: ip -d link show dev eno1.120 печатает id VLAN и его родителя, ip link show master br_vpn перечисляет участников моста, а bridge vlan show сообщает принадлежность по портам и обработку выхода. В схеме с субинтерфейсом убедитесь, что устройства TAP и VLAN являются участниками. В мосте, знающем о VLAN, проверьте саму политику порта, поскольку существующий мост не доказывает, что он разрешает.

Затем проверьте одного разрешённого клиента против службы в этом VLAN, помня, что ARP, политика фаервола и обратный путь — отдельные вопросы от принадлежности. Если вы снимаете пакеты, учтите, что аппаратный offload может изменить, где теги VLAN появляются в трассировке. Держите и рамки честными: маршрутизируемый клиент TUN не становится участником VLAN ни от какого изменения моста, а трафик клиент-клиент не заменяет подключение хоста к VLAN.