Klient-VLAN'er eller en tagged trunk: vælg den rigtige OpenVPN-tilstand

To anmodninger kommer med næsten samme ordlyd: sæt hver VPN-klient i et valgt VLAN, eller bær en eksisterende VLAN-trunk over VPN'et. Det er to forskellige produkter. OpenVPNs indbyggede VLAN-bevidste tilstand er en switch-model til den første anmodning, og den er ikke et synonym for transparent tag-transport. Vælger man den forkerte, får man et design, der ser konfigureret ud og i stilhed dropper de frames, du var interesseret i.

Hvad den VLAN-bevidste tilstand egentlig bygger

Når vlan-tagging er aktiveret på en TAP-opsætning kun med server, modellerer dæmonen sin TAP-enhed og hver tilsluttet klient som porte på en intern switch. Klientporte er utaggede, og deres VLAN-tilhørsforhold sættes på serveren via den per-klient vlan-pvid-kontekst, ikke af noget, klienten sender. Det er hele pointen med modellen: medlemskab er en beslutning på serversiden om en autentificeret peer. Intet i klientprofilen behøver at vide, hvilket VLAN den hører til.

Serverens TAP-side får sin egen taggede eller utaggede acceptpolitik via vlan-accept. Videresendelse inde i den switch sker kun mellem matchende VID'er, også når client-to-client er sat, så to klienter i forskellige VLAN'er kan ikke nå hinanden gennem serveren, selvom begge er tilsluttet den.

Den model er en access-port-model. Frames, der forlader en klient, er utaggede, og tilhørsforholdet påtvinges af serveren ud fra identitet. At bede laptoppen om selv at tagge sin trafik er at bede om et andet design.

Tildelinger skal følge den autentificerede klientidentitet, ikke en værdi, klienten tilbyder om sig selv. En udeladt tildeling er heller ikke en karantænetilstand: klienten lander på den standard PVID, så en manglende ccd-post er en stille politikbeslutning snarere end en neutral.

Hvad en transparent trunk i stedet kræver

At bære allerede taggede frames ende til ende begynder med at slå den VLAN-bevidste behandling fra. Switch-modellen og bevarelse af tags er alternativer, og at aktivere begge beder én funktion om at gøre den andens arbejde.

At slå det fra er kun begyndelsen. Broen i hver ende og de fysiske switchporte skal være enige om, hvilke VLAN'er der er tilladt, hvilket tag der er native, og hvordan utaggede frames behandles. At udvide en ubegrænset trunk blotlægger langt flere broadcast-domæner end de to, du ville forbinde.

Framestørrelse kræver sit eget budget. En tagget Ethernet-frame plus indkapsling er større end det nyttelasttal, folk kopierer fra en vejledning, og en MTU, der var fin til en routed tunnel, er ikke bevis for, at en trunk-vej virker.

Tre betingelser, der afgør svaret

For det første: understøtter klientplatformen overhovedet TAP? Android og iOS gør ikke, og macOS-understøttelsen er begrænset, så en flåde af mobile brugere udelukker begge TAP-designs, uanset hvordan VLAN'erne er arrangeret. En routed TUN-session bærer IP-pakker, ikke Ethernet-frames, og ingen mængde VLAN-konfiguration på serveren ændrer det. Tjek flåden, før du designer topologien, for denne betingelse er den, der ikke kan omgås. Det er også den betingelse, der oftest opdages, efter switch-arbejdet er færdigt.

For det andet: hvem tildeler VLAN'et? Hvis svaret er «serveren, ud fra hvem der autentificerede sig», passer switch-modellen. Hvis svaret er «den eksisterende switch-infrastruktur med tags, der allerede findes», har du brug for trunk-designet.

For det tredje: hvor meget af netværket skal være tilgængeligt? Switch-modellen holder per konstruktion hver klient i ét VLAN. Trunk-designet er en bro, og en bro, der er fejlkonfigureret, forbinder broadcast-domæner, som skulle have været adskilt.

Test det valg, du traf

Tilslut én klient, der bør være i det tilladte VLAN, og én, der ikke bør, og test derefter fra det rigtige endepunkt i stedet for fra serveren selv. Tilgængelighed fra serversiden beviser, at broen eller switchen findes; det beviser ikke, hvilket VLAN en klient landede i.

ip -d link show tap0
bridge vlan show

På serveren viser den anden kommando VLAN-medlemskabet for hver broport, inklusive om en port er tagget eller ej. Sammenlign det med den tildeling, du havde tænkt dig, før du fejlretter noget over lag to.

Notér, hvilket af de to designs installationen bruger. Et notat, der siger «VLAN-bevidst», er tvetydigt, og den næste ingeniør antager det, de lærte først. OpenVPNs VLAN-referencedefinerer switch-adfærden og den per-klient kontekst, og det er den korteste vej til at bekræfte, hvilken model du kører.