Ein TAP-Server oder mehrere? OpenVPN-Clients an einer Bridge

Mehrere TAP-Clients benötigen nicht je einen Serverprozess, einen UDP-Port und ein TAP-Gerät auf dem Host. Ein OpenVPN-Server im Ethernet-Modus kann viele authentifizierte Clients aufnehmen und sie an eine einzige Bridge anhängen, und genau so wird ein Layer-2-Segment laut Dokumentation erweitert. Das Design mit einem Prozess ist das dokumentierte, und es ist meist die richtige Voreinstellung.

Die eigentliche Frage ist, ob diese Clients sich dieses Segment teilen sollten. Die Prozessanzahl beantwortet sie nicht, denn die Isolationseigenschaften ergeben sich aus der Topologie und nicht daraus, wie viele Daemons laufen. Der Rest dieses Vergleichs handelt von den beiden Topologien und davon, was jede erleichtert.

Zwei Architekturen, nicht zwei Einstellungen

Ein geroutetes TUN-Deployment gibt jedem Client eine Punkt-zu-Punkt-Verbindung in die Routingdomäne des Servers. Broadcasts enden am Server, Clients sehen die Frames der anderen nicht, und Verkehr zwischen Clients muss, falls vorhanden, ausdrücklich geroutet und gefiltert werden.

Ein gebrücktes TAP-Deployment macht Clients zu Mitgliedern eines Ethernet-Segments. Sie sehen Broadcasts, können sich gegenseitig per ARP auflösen und sind zur Trennung auf Bridge- und Firewall-Richtlinien statt auf Routing angewiesen. Das ist nützlich, wenn die Clients so erscheinen müssen, als wären sie am selben Switch angeschlossen.

Der Vergleich dreht sich also darum, was die Clients erreichen müssen, nicht um Leistung. Wählen Sie zuerst die Schicht und entscheiden Sie dann, wie viele Prozesse sie bedienen.

Was der server-bridge-Helfer tut

Der Helfer server-bridge konfiguriert den Ethernet-Modus für mehrere Clients. Seine Adresspool-Form nimmt das Gateway, die Netzmaske und einen festen Bereich innerhalb des gebrückten Subnetzes, zum Beispiel ein Gateway bei 192.168.50.1 mit einem Pool von 192.168.50.160 bis 192.168.50.199.

Halten Sie diesen Bereich von jeder anderen DHCP- oder statischen Zuweisung frei. Der Helfer vergibt Adressen daraus, koordiniert sich aber nicht mit einem anderen Verteiler im selben Segment, und zwei überlappende Pools erzeugen doppelte Adressen, die wie zufällige Verbindungsfehler aussehen. Schreiben Sie den reservierten Bereich in den Adressplan des Standorts, damit die nächste Person ihn nicht wiederverwendet. Ein Kommentar in der Serverkonfiguration ist ein schlechter Ersatz für diesen Eintrag.

Für Umgebungen, in denen ein externer Server Adressen ausgibt, gibt es eine DHCP-Proxy-Form. Sie hat ihre eigenen Voraussetzungen, und das Mischen beider Formen erzeugt genau den Konflikt, vor dem die Dokumentation warnt. Wählen Sie einen Verteiler für das gebrückte Subnetz.

Isolation entsteht nicht aus der Prozessanzahl

Acht OpenVPN-Prozesse an derselben uneingeschränkten Bridge teilen sich weiterhin eine Broadcast-Domäne. Clients können über die Bridge ARP für einander senden, und die Zahl der Listener hat daran nichts geändert.

Soll die Anforderung sein, dass Client-Gruppen sich auf Layer 2 nicht sehen, braucht das Design getrennte Bridges oder VLAN-Anbindungen samt den zugehörigen Zugriffsregeln. Das ist eine Netzwerkdesign-Entscheidung, und sie ist dieselbe, ob ein Serverprozess oder acht beteiligt sind. Bridge-Filterung kann Verkehr einschränken, erzeugt aber keine getrennten Broadcast-Domänen. Behandeln Sie sie als Ergänzung zur Segmentierung, nicht als Ersatz.

Ist die Anforderung nur, dass Clients bestimmte IP-Dienste erreichen, ist ein geroutetes TUN-Design meist einfacher als Bridging plus Filterung. Jeder Client bekommt seine eigene Verbindung, und die Richtlinie lebt in Routing- und Firewall-Regeln statt im Inneren der Bridge.

Wann mehrere Prozesse dennoch richtig sind

Getrennte Prozesse lassen sich mit betrieblichen Anforderungen begründen: verschiedene Authentifizierungs-Backends, verschiedene Zertifizierungsstellen, getrennte Upgrade-Zyklen oder unvereinbare Optionssätze. Das sind echte Gründe, und sie sind unabhängig von der Clientzahl.

Wenn Sie mehrere verwenden, geben Sie jedem einen eigenen Listener und Gerätebesitz und stimmen Sie die Adressbereiche ab. Zwei Server, die beide glauben, denselben Pool an derselben Bridge zu besitzen, werden irgendwann dieselbe Adresse ausgeben.

Prüfen Sie das Design dann mit mehreren Clients gleichzeitig. Kontrollieren Sie, dass Adressen eindeutig sind, dass der beabsichtigte Verkehr zwischen Clients funktioniert und dass ein Paar, das nicht kommunizieren darf, es nicht kann. Ein erfolgreicher Ping eines einzelnen Clients prüft nichts vom Mehrclient-Design.

Lesen Sie Bridge und Servermodus auf dem laufenden Host ab, bevor Sie dem Diagramm trauen. Die Konfiguration, auf die es ankommt, ist die, die Kernel und Daemon tatsächlich geladen haben, und genau die kann ein Prüfer nachsehen.