Client-VLAN's of een getagde trunk: kies de juiste OpenVPN-modus

Er komen twee verzoeken binnen met bijna dezelfde formulering: zet elke VPN-client in een gekozen VLAN, of vervoer een bestaande VLAN-trunk over de VPN. Het zijn verschillende producten. De ingebouwde VLAN-bewuste modus van OpenVPN is een switchmodel voor het eerste verzoek, en het is geen synoniem voor transparant tagtransport. De verkeerde keuze levert een ontwerp op dat geconfigureerd lijkt en de frames die u belangrijk vond stilzwijgend laat vallen.

Wat de VLAN-bewuste modus werkelijk bouwt

Met vlan-tagging aan in een TAP-implementatie alleen voor de server modelleert de daemon zijn TAP-apparaat en elke verbonden client als poorten op een interne switch. Clientpoorten zijn ongetagd, en hun VLAN-koppeling wordt op de server ingesteld via de per-client vlan-pvid-context, niet door iets wat de client stuurt. Dat is het hele punt van het model: lidmaatschap is een beslissing aan de serverkant over een geauthenticeerde peer. Niets in het clientprofiel hoeft te weten bij welke VLAN het hoort.

De TAP-kant van de server krijgt zijn eigen getagde of ongetagde acceptatiebeleid via vlan-accept. Doorsturen binnen die switch gebeurt alleen tussen overeenkomende VID's, ook wanneer client-to-client is ingesteld, dus twee clients in verschillende VLAN's kunnen elkaar niet bereiken via de server, hoewel beide ermee verbonden zijn.

Dat model is een access-poortmodel. Frames die een client verlaten zijn ongetagd, en de koppeling wordt door de server opgelegd op basis van identiteit. De laptop vragen zijn eigen verkeer te taggen is om een ander ontwerp vragen.

Toewijzingen moeten de geauthenticeerde clientidentiteit volgen, niet een waarde die de client over zichzelf aanbiedt. Een weggelaten toewijzing is ook geen quarantainetoestand: de client belandt op de standaard-PVID, dus een ontbrekende ccd-regel is een stil beleidsbesluit en niet neutraal.

Wat een transparante trunk in plaats daarvan vereist

Al getagde frames van begin tot eind vervoeren begint met het uitschakelen van de VLAN-bewuste verwerking. Het switchmodel en behoud van tags zijn alternatieven, en beide inschakelen vraagt van de ene functie het werk van de andere te doen.

Uitschakelen is slechts het begin. De bridge aan elk uiteinde en de fysieke switchpoorten moeten het eens zijn over welke VLAN's zijn toegestaan, welke tag native is en hoe ongetagde frames worden behandeld. Een onbeperkte trunk uitbreiden stelt veel meer broadcast-domeinen bloot dan de twee die u wilde verbinden.

Framegrootte vraagt een eigen budget. Een getagd Ethernet-frame plus inkapseling is groter dan het payloadgetal dat mensen uit een handleiding kopiëren, en een MTU die goed was voor een gerouteerde tunnel is geen bewijs dat een trunkpad werkt.

Drie voorwaarden die het antwoord bepalen

Ten eerste, ondersteunt het clientplatform TAP ueberhaupt? Android en iOS niet, en macOS-ondersteuning is beperkt, dus een vloot mobiele gebruikers sluit beide TAP-ontwerpen uit, hoe de VLAN's ook zijn ingedeeld. Een gerouteerde TUN-sessie vervoert IP-pakketten, geen Ethernet-frames, en geen enkele VLAN-configuratie aan de serverkant verandert dat. Controleer de vloot voordat u de topologie ontwerpt, want deze voorwaarde is degene die niet te omzeilen valt. Het is ook de voorwaarde die het vaakst pas ontdekt wordt nadat het switchwerk klaar is.

Ten tweede, wie wijst de VLAN toe? Als het antwoord «de server, op basis van wie zich authenticeerde» is, past het switchmodel. Als het antwoord «de bestaande switchinfrastructuur, met tags die al bestaan» is, hebt u het trunkontwerp nodig.

Ten derde, hoeveel van het netwerk bereikbaar moet zijn? Het switchmodel houdt elke client per constructie in een VLAN. Het trunkontwerp is een bridge, en een verkeerd geconfigureerde bridge verbindt broadcast-domeinen die gescheiden hadden moeten blijven.

De gemaakte keuze testen

Verbind een client die in de toegestane VLAN hoort en een die dat niet hoort, en test dan vanaf het echte eindpunt in plaats van vanaf de server zelf. Bereikbaarheid aan de serverkant bewijst dat de bridge of switch bestaat; het bewijst niet in welke VLAN een client is beland.

ip -d link show tap0
bridge vlan show

Op de server toont de tweede opdracht het VLAN-lidmaatschap van elke bridgepoort, inclusief of een poort getagd is. Vergelijk dat met de toewijzing die u bedoelde voordat u iets boven laag twee debugt.

Noteer welk van de twee ontwerpen de implementatie gebruikt. Een notitie «VLAN-bewust» is dubbelzinnig, en de volgende engineer gaat uit van degene die hij het eerst leerde. De OpenVPN VLAN-referentiedefinieert het switchgedrag en de context per client, en het is de kortste weg om te bevestigen welk model u draait.