Klient-VLAN:er eller en taggad trunk: välj rätt OpenVPN-läge

Två förfrågningar kommer med nästan samma formulering: placera varje VPN-klient i en vald VLAN, eller bär en befintlig VLAN-trunk över VPN:et. Det är två olika produkter. OpenVPN:s inbyggda VLAN-medvetna läge är en växelmodell för den första förfrågan, och det är inte en synonym för transparent taggtransport. Fel val ger en design som ser konfigurerad ut och tyst släpper de ramar du brydde dig om.

Vad det VLAN-medvetna läget faktiskt bygger

Med vlan-tagging aktiverat i en TAP-distribution endast för server modellerar daemonen sin TAP-enhet och varje ansluten klient som portar på en intern växel. Klientportarna är otaggade, och deras VLAN-koppling sätts på servern via vlan-pvid-kontexten per klient, inte av något klienten skickar. Det är hela poängen med modellen: medlemskap är ett beslut på serversidan om en autentiserad motpart. Inget i klientprofilen behöver veta vilken VLAN den tillhör.

Serverns TAP-sida får sin egen taggade eller otaggade acceptpolicy via vlan-accept. Vidarebefordran inuti den växeln sker bara mellan matchande VID:er, även när client-to-client är satt, så två klienter i olika VLAN kan inte nå varandra genom servern trots att båda är anslutna till den.

Den modellen är en åtkomstportsmodell. Ramar som lämnar en klient är otaggade, och kopplingen påtvingas av servern utifrån identitet. Att be laptopen tagga sin egen trafik är att be om en annan design.

Tilldelningar måste följa den autentiserade klientidentiteten, inte ett värde som klienten erbjuder om sig själv. En utelämnad tilldelning är inte heller ett karantäntillstånd: klienten landar på standard-PVID, så en saknad ccd-post är ett tyst policybeslut snarare än ett neutralt.

Vad en transparent trunk kräver i stället

Att bära redan taggade ramar hela vägen börjar med att stänga av den VLAN-medvetna behandlingen. Växelmodellen och bevarandet av taggar är alternativ, och att aktivera båda ber en funktion göra den andras arbete.

Att stänga av är bara början. Bryggan i varje ände och de fysiska växelportarna måste enas om vilka VLAN som tillåts, vilken tagg som är inhemsk och hur otaggade ramar behandlas. Att förlänga en obegränsad trunk exponerar långt fler broadcast-domäner än de två du ville ansluta.

Rammens storlek behöver sin egen budget. En taggad Ethernet-ram plus inkapsling är större än den nyttolastsiffra folk kopierar från en guide, och en MTU som passade för en routad tunnel är inte bevis för att en trunk-väg fungerar.

Tre villkor som avgör svaret

För det första: stöder klientplattformen TAP över huvud taget? Android och iOS gör det inte, och macOS-stödet är begränsat, så en flotta mobila användare utesluter båda TAP-designerna, oavsett hur VLAN:en är ordnade. En routad TUN-session bär IP-paket, inte Ethernet-ramar, och ingen VLAN-konfiguration på serversidan ändrar det. Kontrollera flottan innan du designar topologin, eftersom detta villkor är det som inte går att kringgå. Det är också villkoret som oftast upptäcks först efter att växelarbetet är klart.

För det andra: vem tilldelar VLAN:et? Om svaret är «servern, utifrån vem som autentiserade sig» passar växelmodellen. Om svaret är «den befintliga växelinfrastrukturen, med taggar som redan finns» behöver du trunk-designen.

För det tredje: hur stor del av nätet som ska vara nåbar? Växelmodellen håller varje klient i en VLAN av konstruktion. Trunk-designen är en brygga, och en brygga som är felkonfigurerad kopplar ihop broadcast-domäner som skulle ha hållits åtskilda.

Att testa valet du gjorde

Anslut en klient som ska vara i det tillåtna VLAN:et och en som inte ska, och testa sedan från den verkliga änden i stället för från servern själv. Nåbarhet från serversidan bevisar att bryggan eller växeln finns; den bevisar inte vilken VLAN en klient hamnade i.

ip -d link show tap0
bridge vlan show

På servern visar det andra kommandot VLAN-medlemskapet för varje bryggport, inklusive om en port är taggad. Jämför det med den tilldelning du avsåg innan du felsöker något ovanför lager två.

Anteckna vilken av de två designerna distributionen använder. En anteckning som säger «VLAN-medveten» är tvetydig, och nästa ingenjör kommer att anta den de lärde sig först. OpenVPN:s VLAN-referensdefinierar växelns beteende och kontexten per klient, och det är den kortaste vägen till att bekräfta vilken modell du kör.