TAP-bru for éin VLAN: kople til undergrensesnittet

Ein TAP-klient som nådde LAN-et før VLAN og stoppa etterpå, har vanlegvis ei bru som framleis inneheld det gale grensesnittet. Rammevideresending legg ikkje til ein VLAN-tagg, så ei utagga klientramme som blir send til den fysiske uplinken, kjem utagga fram på ein trunkport og blir anten forkasta eller hamnar i den native VLAN-en. At undergrensesnittet finst ein stad på verten, endrar ingenting i medlemslista til brua. Det er myten som må drepast først: taggen blir sett av grensesnittet som eig han, ikkje av at verten berre har eitt.

Éi VLAN-utviding tyder eitt domene på lag 2, og brua må bli med i det domenet, ikkje i trunklenkja som ber alle saman.

Taggen viser seg ikkje fordi du brua trunklenkja

Ta ein Linux-uplink eno1 som ber VLAN 120 til ein administrert svitsj. Designet som verkar for éin VLAN, er tap_vpn brua til br_vpn, der br_vpn inneheld eno1.120 i staden for eno1. VLAN-undergrensesnittet set taggen på utgang og fjernar han på inngang, så brua ser berre utaggede rammer for den eine VLAN-en. Legg det fysiske grensesnittet i brua i staden, og dei same rammene går ut utagga på ein trunkport, noko du ikkje hadde planlagt.

Å bru trunklenkja med VLAN-filtrering slått av er inga snarveg til same resultat. Det gir brua kvar VLAN på den leidninga, også dei klientane ikkje skal sjå.

To legitime design, éin taggeigar

Ei VLAN-medviten bru er den andre gyldige ordninga: trunklenkja går inn i ein bruport, og medlemskap per port, PVID og tagga utgangsinnstillingar avgjer kva VLAN som slepp gjennom. Der eig brua taggginga, og å leggje eit VLAN-undergrensesnitt under ho ville installere ein andre eigar for éi oppgåve. Båe designa verkar; fragment av båe gjer det ikkje. Avgjer kva objekt som set taggen før du redigerer noka medlemsliste.

Svitsjporten må stemme med det designet du vel. Ein access-port som ber VLAN-en utagga, passar med det fysiske grensesnittet som tilkopling, medan ein trunkport passar med eit tagga undergrensesnitt. Å leggje eit undergrensesnitt til ein access-port som ikkje passar, reparerer ingenting.

Flytt adressa saman med medlemskapet

I undergrensesnittdesignet høyrer adressa til verten for det brua subnettet til på br_vpn, ikkje på den slava VLAN-porten der ho kan ha budd før. Å la ho bli på porten kan sjå ut som det verkar og så oppføre seg rart, fordi brua varelegg på lag 2 medan adressa sit på eit medlem. Flytt ho som ein del av medlemskapsendringa, ikkje som eit separat eksperiment.

Å flytte ei adresse kan kutte administrasjonsvegen. Set opp ein uavhengig attopprettingsveg, lagre den eksisterande konfigurasjonen gjennom distribusjonen sin eigen nettverkshandsamar, og unngå eit konkurrerande oppstartsskript som vil kjempe mot han etter neste oppgradering.

Klientadressering treng same omsut. Ein brua VPN plasserer klientane i det utvida subnettet, så ein pool må ikkje overlappe andre leasar eller statiske tildelingar, og ei DHCP-tenest ordning må vere den LAN-et faktisk ventar. Ein fungerande veg på lag 2 seier ingenting om dupliserte adresser.

Stadfest medlemskapet før du skuldar på rutene

Les den gjeldande tilstanden i staden for den tiltenkte: ip -d link show dev eno1.120 skriv ut VLAN-id-en og forelderen hans, ip link show master br_vpn listar medlemmene i brua, og bridge vlan show rapporterer medlemskap per port og utgangshandsaming. I undergrensesnittdesignet, stadfest at TAP-eininga og VLAN-eininga er medlemmene. I ei VLAN-medviten bru, sjekk portpolitikken sjølv, sidan ei bru som finst ikkje beviser kva ho tillèt.

Test så éin tillaten klient mot ein teneste i den VLAN-en, og hugs at ARP, brannmurpolitikk og returvegen er separate omsyn frå medlemskap. Viss du fangar pakkar, merk at maskinvareavlasting kan endre kvar VLAN-taggar viser seg i eit spor. Hald òg omfanget ærleg: ein ruta TUN-klient blir ikkje VLAN-medlem av noka bruendring, og klient-til-klient-trafikk erstattar ikkje tilkoplinga til verten mot VLAN-en.