TAP-bro for én VLAN: koble til undergrensesnittet

En TAP-klient som nådde LAN-et før VLAN og stoppet etterpå, har vanligvis en bro som fortsatt inneholder feil grensesnitt. Rammeforwarding legger ikke til en VLAN-tagg, så en utagget klientramme som sendes til den fysiske uplinken, ankommer utagget på en trunkport og blir enten forkastet eller havner i den native VLAN-en. At undergrensesnittet finnes et sted på verten, endrer ingenting i broens medlemsliste. Det er myten som må drepes først: taggen settes av grensesnittet som eier den, ikke av at verten bare har et.

Én VLAN-utvidelse betyr ett domene på lag 2, og broen må bli med i det domenet, ikke i trunklenken som bærer alle sammen.

Taggen vises ikke fordi du broet trunklenken

Ta en Linux-uplink eno1 som bærer VLAN 120 til en administrert svitsj. Designet som fungerer for én VLAN, er tap_vpn broet til br_vpn, der br_vpn inneholder eno1.120 i stedet for eno1. VLAN-undergrensesnittet setter taggen på utgang og fjerner den på inngang, så broen ser bare utaggede rammer for den ene VLAN-en. Legg det fysiske grensesnittet i broen i stedet, og de samme rammene går ut utagget på en trunkport, noe du ikke hadde planlagt.

Å bro trunklenken med VLAN-filtrering slått av er ingen snarvei til samme resultat. Det gir broen hver VLAN på den ledningen, også de klientene ikke skal se.

To legitime design, én taggeier

En VLAN-bevisst bro er den andre gyldige ordningen: trunklenken går inn i en broport, og medlemskap per port, PVID og taggede utgangsinnstillinger avgjør hvilke VLAN-er som slipper gjennom. Der eier broen taggingen, og å legge et VLAN-undergrensesnitt under den ville installere en andre eier for én jobb. Begge designene virker; fragmenter av begge gjør det ikke. Bestem hvilket objekt som setter taggen før du redigerer noen medlemsliste.

Svitsjporten må stemme med det designet du velger. En access-port som bærer VLAN-en utagget, passer med det fysiske grensesnittet som tilkobling, mens en trunkport passer med et tagget undergrensesnitt. Å legge et undergrensesnitt til en access-port som ikke passer, reparerer ingenting.

Flytt adressen sammen med medlemskapet

I undergrensesnittdesignet hører vertens adresse for det broede subnettet til på br_vpn, ikke på den slaved VLAN-porten der den kan ha bodd før. Å la den bli på porten kan se ut som det virker og deretter oppføre seg rart, fordi broen videresender på lag 2 mens adressen sitter på et medlem. Flytt den som en del av medlemskapsendringen, ikke som et separat eksperiment.

Å flytte en adresse kan kutte administrasjonsveien. Etabler en uavhengig gjenopprettingsvei, lagre den eksisterende konfigurasjonen gjennom distribusjonens egen nettverksbehandler, og unngå et konkurrerende oppstartsskript som vil kjempe mot den etter neste oppgradering.

Klientadressering trenger samme omhu. En broet VPN plasserer klientene i det utvidede subnettet, så en pool må ikke overlappe andre leases eller statiske tildelinger, og en DHCP-betjent ordning må være den LAN-et faktisk forventer. En fungerende vei på lag 2 sier ingenting om dupliserte adresser.

Bekreft medlemskapet før du skylder på rutene

Les den gjeldende tilstanden i stedet for den tiltenkte: ip -d link show dev eno1.120 skriver ut VLAN-id-en og dens forelder, ip link show master br_vpn lister broens medlemmer, og bridge vlan show rapporterer medlemskap per port og utgangsbehandling. I undergrensesnittdesignet, bekreft at TAP-enheten og VLAN-enheten er medlemmene. I en VLAN-bevisst bro, sjekk portpolicyen selv, siden en bro som finnes ikke beviser hva den tillater.

Test deretter én tillatt klient mot en tjeneste i den VLAN-en, og husk at ARP, brannmurpolicy og returvei er separate hensyn fra medlemskap. Hvis du fanger pakker, merk at maskinvareavlasting kan endre hvor VLAN-tagger vises i et spor. Hold omfanget ærlig også: en rutet TUN-klient blir ikke VLAN-medlem av noen broendring, og klient-til-klient-trafikk erstatter ikke vertens tilkobling til VLAN-en.