Міст 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.