TAP мост за един VLAN: прикачете подинтерфейса

TAP клиент, който е достигал LAN преди VLAN и е спрял след това, обикновено има мост, който все още съдържа грешния интерфейс. Препредаването на кадри не добавя VLAN етикет, така че неетикетиран клиентски кадър, изпратен към физическия uplink, пристига неетикетиран на trunk порт и или се изхвърля, или попада в native VLAN. Съществуването на подинтерфейс някъде на хоста не променя нищо в списъка с членове на моста. Това е митът, който трябва да убием първо: етикетът се прилага от интерфейса, който го притежава, а не от хоста, само защото има такъв.

Едно разширение на VLAN означава един домейн от layer-2 и мостът трябва да се присъедини към този домейн, а не към trunk, който носи всички.

Етикетът не се появява, защото мостнахте trunk

Вземете Linux uplink eno1, който носи VLAN 120 към управляем суич. Дизайнът, който работи за един VLAN, е tap_vpn, мостнат към br_vpn, като br_vpn съдържа eno1.120, а не eno1. VLAN подинтерфейсът прилага етикета на изход и го сваля на вход, така че мостът вижда само неетикетирани кадри за този един VLAN. Поставете вместо това физическия интерфейс в моста и същите кадри излизат неетикетирани на trunk порт, което не е това, което сте планирали.

Мостнането на trunk с изключена VLAN филтрация не е пряк път към същия резултат. Това дава на моста всеки VLAN по този проводник, включително тези, които клиентите не бива да виждат.

Два законни дизайна, един собственик на етикета

VLAN-осъзнатият мост е другата валидна подредба: trunk влиза в порт на моста и членството по портове, PVID и настройките за етикетиран изход решават кои VLAN преминават. Там мостът притежава етикетирането и добавянето на VLAN подинтерфейс под него би инсталирало втори собственик за една задача. И двата дизайна работят; фрагменти от двата — не. Решете кой обект прилага етикета, преди да редактирате който и да е списък с членове.

Портът на суича трябва да съответства на избрания дизайн. Access порт, който носи VLAN неетикетиран, се свързва с физическия интерфейс като прикачване, докато trunk портът се свързва с етикетиран подинтерфейс. Добавянето на подинтерфейс към несъответстващ access порт не поправя нищо.

Преместете адреса заедно с членството

В дизайна с подинтерфейс адресът на хоста за мостната подмрежа принадлежи на br_vpn, а не на поробения VLAN порт, където може да е бил преди. Оставянето му на порта може да изглежда работещо и после да се държи странно, защото мостът препраща на layer 2, докато адресът седи на член. Преместете го като част от промяната на членството, а не като отделен експеримент.

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

Адресирането на клиентите изисква същото внимание. Мостнатият VPN поставя клиентите в разширената подмрежа, така че пулът не бива да се застъпва с други наеми или статични назначения, а подредбата с DHCP трябва да е тази, която LAN действително очаква. Работещ път от layer-2 не казва нищо за дублирани адреси.

Проверете членството, преди да обвинявате маршрутите

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

След това тествайте един разрешен клиент срещу услуга в този VLAN, като помните, че ARP, политиката на защитната стена и пътят на отговора са отделни въпроси от членството. Ако прихващате пакети, имайте предвид, че хардуерното offload може да промени къде се появяват VLAN етикетите в следата. Пазете и обхвата честен: маршрутизиран TUN клиент не става VLAN член чрез никаква промяна на моста и трафикът клиент-към-клиент не замества прикачването хост-към-VLAN.