TAP клијент који је стизао до LAN-а пре VLAN-ова и након тога престао обично има мост који још увек садржи погрешно сучеље. Прослеђивање оквира не додаје VLAN ознаку, па неозначен клијентски оквир послат на физички uplink долази без ознаке на trunk порт и бива одбачен или заврши у изворном VLAN-у. То што подсучеље постоји негде на хосту ништа не мења у списку чланова моста. То је мит који треба прво убити: ознаку поставља сучеље које је поседује, а не хост који је једноставно има.

Једно проширење VLAN-а значи једну домену слоја 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 порт где је можда раније живела. Остављање на порту може изгледати да ради, а затим се чудно понашати, јер мост прослеђује на слоју 2 док адреса седи на члану. Преместите је као део промене чланства, а не као засебан експеримент.

Премештање адресе може прекинути административни пут. Успоставите независну руту опоравка, сачувајте постојећу конфигурацију кроз сопствени мрежни менаџер дистрибуције и избегните конкурентну почетну скрипту која ће се с њом борити након следећег ажурирања.

Адресирање клијената тражи исту пажњу. Премошћени VPN смешта клијенте у проширену подмрежу, па се pool не сме преклапати са другим најмовима или статичким доделама, а поставка коју служи DHCP мора бити она коју LAN заиста очекује. Радни пут слоја 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.

Повезани чланци