Client-VLANs oder ein getaggter Trunk: den richtigen OpenVPN-Modus wählen

Zwei Anfragen kommen fast gleich formuliert: jeden VPN-Client in ein gewähltes VLAN stecken oder einen bestehenden VLAN-Trunk über das VPN führen. Das sind verschiedene Produkte. Der eingebaute VLAN-fähige Modus von OpenVPN ist ein Switch-Modell für die erste Anfrage und kein Synonym für transparenten Tag-Transport. Die falsche Wahl erzeugt ein Design, das konfiguriert aussieht und die Frames, die Ihnen wichtig waren, stillschweigend verwirft.

Was der VLAN-fähige Modus tatsächlich baut

Mit aktiviertem vlan-tagging in einem reinen Server-TAP-Deployment modelliert der Daemon sein TAP-Gerät und jeden verbundenen Client als Ports eines internen Switches. Client-Ports sind ungetaggt, und ihre VLAN-Zuordnung wird auf dem Server über den vlan-pvid-Kontext pro Client gesetzt, nicht durch etwas, das der Client sendet. Das ist der ganze Sinn des Modells: Mitgliedschaft ist eine serverseitige Entscheidung über einen authentifizierten Peer. Nichts im Clientprofil muss wissen, zu welchem VLAN es gehört.

Die TAP-Seite des Servers erhält ihre eigene Annahmepolitik für getaggte oder ungetaggte Frames über vlan-accept. Weiterleitung innerhalb dieses Switches findet nur zwischen passenden VIDs statt, auch wenn client-to-client gesetzt ist, sodass zwei Clients in unterschiedlichen VLANs einander über den Server nicht erreichen können, obwohl beide mit ihm verbunden sind.

Dieses Modell ist ein Access-Port-Modell. Frames, die einen Client verlassen, sind ungetaggt, und die Zuordnung erzwingt der Server anhand der Identität. Vom Laptop zu verlangen, seinen eigenen Verkehr zu taggen, heißt ein anderes Design zu verlangen.

Zuweisungen müssen der authentifizierten Client-Identität folgen, nicht einem Wert, den der Client über sich selbst anbietet. Eine ausgelassene Zuweisung ist auch kein Quarantänezustand: der Client landet auf der Standard-PVID, ein fehlender ccd-Eintrag ist also eine stille Richtlinienentscheidung statt einer neutralen.

Was ein transparenter Trunk stattdessen verlangt

Bereits getaggte Frames durchgehend zu übertragen beginnt damit, die VLAN-fähige Verarbeitung abzuschalten. Switch-Modell und Tag-Erhalt sind Alternativen, und beides zu aktivieren verlangt von einer Funktion, die Arbeit der anderen zu tun.

Das Abschalten ist nur der Anfang. Die Bridge an jedem Endpunkt und die physischen Switch-Ports müssen sich einig sein, welche VLANs erlaubt sind, welches Tag nativ ist und wie ungetaggte Frames behandelt werden. Einen unbeschränkten Trunk auszudehnen legt weit mehr Broadcast-Domänen offen als die zwei, die Sie verbinden wollten.

Die Framegröße braucht ihr eigenes Budget. Ein getaggter Ethernet-Frame plus Kapselung ist größer als die Nutzlastzahl, die Leute aus einer Anleitung kopieren, und eine MTU, die für einen gerouteten Tunnel passte, ist kein Beweis, dass ein Trunk-Pfad funktioniert.

Drei Bedingungen, die die Antwort entscheiden

Erstens: Unterstützt die Client-Plattform überhaupt TAP? Android und iOS nicht, und die macOS-Unterstützung ist begrenzt, also schließt eine Flotte mobiler Nutzer beide TAP-Designs aus, egal wie die VLANs angeordnet sind. Eine geroutete TUN-Sitzung überträgt IP-Pakete, keine Ethernet-Frames, und keine serverseitige VLAN-Konfiguration ändert daran etwas. Prüfen Sie die Flotte, bevor Sie die Topologie entwerfen, denn diese Bedingung lässt sich nicht umgehen. Sie ist auch die Bedingung, die am häufigsten erst nach Abschluss der Switch-Arbeiten entdeckt wird.

Zweitens: Wer weist das VLAN zu? Lautet die Antwort „der Server, anhand dessen, wer sich authentifiziert hat“, passt das Switch-Modell. Lautet sie „die bestehende Switch-Infrastruktur, mit Tags, die es bereits gibt“, brauchen Sie das Trunk-Design.

Drittens: wie viel des Netzes erreichbar sein soll? Das Switch-Modell hält jeden Client konstruktiv in einem VLAN. Das Trunk-Design ist eine Bridge, und eine falsch konfigurierte Bridge verbindet Broadcast-Domänen, die getrennt bleiben sollten.

Die getroffene Wahl testen

Verbinden Sie einen Client, der im erlaubten VLAN sein soll, und einen, der es nicht sein soll, und testen Sie dann vom echten Endpunkt statt vom Server selbst. Erreichbarkeit von der Serverseite beweist, dass die Bridge oder der Switch existiert; sie beweist nicht, in welchem VLAN ein Client gelandet ist.

ip -d link show tap0
bridge vlan show

Auf dem Server zeigt der zweite Befehl die VLAN-Mitgliedschaft jedes Bridge-Ports, einschließlich ob ein Port getaggt ist. Vergleichen Sie das mit der beabsichtigten Zuweisung, bevor Sie irgendetwas oberhalb von Schicht zwei debuggen.

Halten Sie fest, welches der beiden Designs das Deployment nutzt. Eine Notiz „VLAN-fähig“ ist mehrdeutig, und der nächste Ingenieur wird das annehmen, was er zuerst gelernt hat. Die OpenVPN-VLAN-Referenzdefiniert das Switch-Verhalten und den Kontext pro Client, und sie ist der kürzeste Weg zu bestätigen, welches Modell Sie fahren.