TAP-bridge voor één VLAN: koppel de subinterface aan

Een TAP-client die de LAN vóór VLAN's bereikte en daarna stopte, heeft meestal nog een bridge die de verkeerde interface bevat. Frame-forwarding voegt geen VLAN-tag toe, dus een ongetagd clientframe dat naar de fysieke uplink wordt gestuurd, komt ongetagd aan op een trunkpoort en wordt ofwel weggegooid of belandt in de native VLAN. Dat de subinterface ergens op de host bestaat, verandert niets aan de ledenlijst van de bridge. Dat is de mythe die je eerst moet doden: de tag wordt gezet door de interface die hem bezit, niet doordat de host er toevallig een heeft.

Eén VLAN-uitbreiding betekent één layer-2-domein, en de bridge moet bij dat domein horen, niet bij de trunk die ze allemaal draagt.

De tag verschijnt niet omdat je de trunk hebt gebrugd

Neem een Linux-uplink eno1 die VLAN 120 naar een beheerde switch draagt. Het ontwerp dat voor één VLAN werkt, is tap_vpn gebrugd naar br_vpn, waarbij br_vpn eno1.120 bevat en niet eno1. De VLAN-subinterface zet de tag bij egress en haalt hem er bij ingress af, dus de bridge ziet alleen ongetagde frames voor dat ene VLAN. Zet in plaats daarvan de fysieke interface in de bridge, en dezelfde frames verlaten ongetagd een trunkpoort, wat je niet had gepland.

De trunk bruggen met VLAN-filtering uit is geen kortere weg naar hetzelfde resultaat. Het geeft de bridge elk VLAN op die draad, inclusief de VLAN's die clients niet horen te zien.

Twee legitieme ontwerpen, één tageigenaar

Een VLAN-bewuste bridge is de andere geldige opzet: de trunk komt een bridgepoort binnen, en lidmaatschap per poort, PVID en getagde egress-instellingen bepalen welke VLAN's passeren. Daar bezit de bridge het taggen, en een VLAN-subinterface eronder toevoegen zou een tweede eigenaar voor één taak installeren. Beide ontwerpen werken; fragmenten van beide niet. Bepaal welk object de tag zet voordat je een ledenlijst bewerkt.

De switchpoort moet overeenkomen met welk ontwerp je ook kiest. Een access-poort die het VLAN ongetagd draagt, past bij de fysieke interface als aansluiting, terwijl een trunkpoort bij een getagde subinterface past. Een subinterface aan een niet-passende access-poort toevoegen repareert niets.

Verplaats het adres mee met het lidmaatschap

In het subinterface-ontwerp hoort het hostadres voor het gebrugde subnet op br_vpn, niet op de ondergeschikte VLAN-poort waar het eerder kan hebben gezeten. Het op de poort laten staan kan lijken te werken en zich daarna vreemd gedragen, omdat de bridge op layer 2 doorstuurt terwijl het adres op een lid staat. Verplaats het als onderdeel van de lidmaatschapswijziging, niet als apart experiment.

Een adres verplaatsen kan het beheerpad afsnijden. Zet een onafhankelijke herstelroute op, sla de bestaande configuratie op via de eigen netwerkbeheerder van de distributie, en vermijd een concurrerend opstartscript dat er na de volgende upgrade tegen vecht.

Clientadressering vraagt dezelfde zorg. Een gebrugde VPN plaatst clients in het uitgebreide subnet, dus een pool mag niet overlappen met andere leases of statische toewijzingen, en een DHCP-geleverde opzet moet degene zijn die de LAN echt verwacht. Een werkend layer-2-pad zegt niets over dubbele adressen.

Controleer het lidmaatschap voordat je routes de schuld geeft

Lees de huidige toestand in plaats van de bedoelde: ip -d link show dev eno1.120 drukt het VLAN-id en zijn ouder af, ip link show master br_vpn somt bridgeleden op, en bridge vlan show rapporteert lidmaatschap per poort en egress-behandeling. Bevestig in het subinterface-ontwerp dat het TAP-apparaat en het VLAN-apparaat de leden zijn. Controleer in een VLAN-bewuste bridge het poortbeleid zelf, want een bestaande bridge bewijst niet wat hij toestaat.

Test dan één toegestane client tegen een dienst in dat VLAN, en bedenk dat ARP, firewallbeleid en het antwoordpad losstaan van lidmaatschap. Als je pakketten opvangt, merk dan op dat hardware-offload kan veranderen waar VLAN-tags in een trace verschijnen. Houd ook de reikwijdte eerlijk: een gerouteerde TUN-client wordt door geen enkele bridgewijziging VLAN-lid, en client-naar-client-verkeer vervangt de host-naar-VLAN-aansluiting niet.