Klient-VLAN-er eller en tagget trunk: velg riktig OpenVPN-modus

To forespørsler kommer med nesten samme ordlyd: sett hver VPN-klient i et valgt VLAN, eller bær en eksisterende VLAN-trunk over VPN-et. Det er to forskjellige produkter. OpenVPNs innebygde VLAN-bevisste modus er en svitsjmodell for den første forespørselen, og den er ikke et synonym for transparent tagg-transport. Feil valg gir et design som ser konfigurert ut og stille slipper de rammene du brydde deg om.

Hva den VLAN-bevisste modusen faktisk bygger

Når vlan-tagging er aktivert i en TAP-utrulling kun for server, modellerer daemonen TAP-enheten sin og hver tilkoblet klient som porter på en intern svitsj. Klientportene er utaggede, og VLAN-tilknytningen deres settes på serveren via vlan-pvid-konteksten per klient, ikke av noe klienten sender. Det er hele poenget med modellen: medlemskap er en beslutning på serversiden om en autentisert motpart. Ingenting i klientprofilen trenger å vite hvilket VLAN den hører til.

Serverens TAP-side får sin egen taggede eller utaggede akseptpolicy via vlan-accept. Videresending inne i den svitsjen skjer bare mellom samsvarende VID-er, også når client-to-client er satt, så to klienter i forskjellige VLAN-er kan ikke nå hverandre gjennom serveren selv om begge er tilkoblet den.

Den modellen er en tilgangsportmodell. Rammene som forlater en klient er utaggede, og tilknytningen påtvinges av serveren basert på identitet. Å be laptopen tagge sin egen trafikk er å be om et annet design.

Tildelinger må følge den autentiserte klientidentiteten, ikke en verdi klienten tilbyr om seg selv. En utelatt tildeling er heller ikke en karantenetilstand: klienten lander på standard-PVID-en, så en manglende ccd-oppføring er en stille policybeslutning snarere enn en nøytral.

Hva en transparent trunk krever i stedet

Å bære allerede taggede rammer ende til ende begynner med å slå av den VLAN-bevisste behandlingen. Svitsjmodellen og bevaring av tagger er alternativer, og å aktivere begge ber én funksjon gjøre den andres arbeid.

Å slå det av er bare begynnelsen. Broen i hver ende og de fysiske svitsjportene må bli enige om hvilke VLAN-er som er tillatt, hvilken tagg som er innfødt og hvordan utaggede rammer behandles. Å utvide en ubegrenset trunk eksponerer langt flere kringkastingsdomener enn de to du ville koble sammen.

Rammestørrelse trenger sitt eget budsjett. En tagget Ethernet-ramme pluss innkapsling er større enn nyttelasttallet folk kopierer fra en veiledning, og en MTU som passet for en ruttet tunnel er ikke bevis for at en trunk-vei fungerer.

Tre betingelser som avgjør svaret

For det første: støtter klientplattformen TAP i det hele tatt? Android og iOS gjør det ikke, og macOS-støtten er begrenset, så en flåte med mobile brukere utelukker begge TAP-designene, uansett hvordan VLAN-ene er ordnet. En ruttet TUN-økt bærer IP-pakker, ikke Ethernet-rammer, og ingen VLAN-konfigurasjon på serversiden endrer det. Sjekk flåten før du designer topologien, for denne betingelsen er den som ikke kan omgås. Det er også betingelsen som oftest oppdages etter at svitsjarbeidet er ferdig.

For det andre: hvem tildeler VLAN-et? Hvis svaret er «serveren, basert på hvem som autentiserte seg», passer svitsjmodellen. Hvis svaret er «den eksisterende svitsjinfrastrukturen, med tagger som allerede finnes», trenger du trunk-designet.

For det tredje: hvor mye av nettverket som skal være nåbart? Svitsjmodellen holder hver klient i ett VLAN av konstruksjon. Trunk-designet er en bro, og en bro som er feilkonfigurert kobler sammen kringkastingsdomener som skulle ha holdt seg atskilt.

Å teste valget du tok

Koble til én klient som skal være i det tillatte VLAN-et og én som ikke skal, og test deretter fra det virkelige endepunktet i stedet for fra serveren selv. Nåbarhet fra serversiden beviser at broen eller svitsjen finnes; det beviser ikke hvilket VLAN en klient havnet i.

ip -d link show tap0
bridge vlan show

På serveren viser den andre kommandoen VLAN-medlemskapet til hver broport, inkludert om en port er tagget. Sammenlign det med tildelingen du hadde tenkt, før du feilsøker noe over lag to.

Noter hvilket av de to designene utrullingen bruker. Et notat som sier «VLAN-bevisst» er tvetydig, og den neste ingeniøren vil anta det de lærte først. OpenVPNs VLAN-referansedefinerer svitsjens oppførsel og konteksten per klient, og det er den korteste veien til å bekrefte hvilken modell du kjører.