Kann man zwei VPNs auf demselben Heimserver ohne Routing-Konflikte verwenden?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Can You Use Two VPNs on the Same Home Server Without Route Conflicts? - Zima Store Online

Ja, zwei VPNs können sich einen Heimserver teilen, wenn ihre Adressen, Routen, Standardrouten, Firewall-Regeln und Rückwegpfade ausdrücklich getrennt sind.

Probleme entstehen, wenn beide Tunnel dasselbe private Subnetz beanspruchen, konkurrierende Standardrouten installieren, doppelte Schnittstellen- oder Tabellenkennungen verwenden, DNS global umschreiben oder Antworten über einen anderen Tunnel als die Anfrage senden. Ein sicheres Design weist jedem VPN zunächst eine eindeutige Aufgabe zu – wie Fernzugriff und kommerzieller Ausgang – und testet dann jeweils einen Tunnel allein, den anderen allein und beide zusammen, während die aktive Route für jede Arbeitslast protokolliert wird.

Definieren Sie die Aufgabe jedes VPN, bevor Sie beide starten

Schreiben Sie auf, welche Clients, Ziele, Protokolle und Anwendungen zu VPN A und VPN B gehören. Übliche Designs umfassen einen eingehenden WireGuard-Server für den Fernzugriff auf NAS und einen ausgehenden kommerziellen VPN für ausgewählte Container.

Die OpenVPN-Community erklärt, dass mehrere Tunnel gleichzeitig laufen können, aber jede Instanz einen separaten virtuellen Adapter, Port und ein eindeutiges, sich nicht überschneidendes Subnetz benötigt.

Wenn beide Tunnel den gesamten Serververkehr tragen sollen, entscheiden Sie, welcher primär und welcher als Backup oder verschachtelt dient. Zwei unabhängige „alles senden“-Richtlinien können nicht beide dieselben Pakete ohne explizite Reihenfolge steuern.

Halten Sie Tunnel- und Remote-LAN-Subnetze eindeutig

Vergleichen Sie beide Tunnel-Adresspools, jedes beworbene Remote-LAN, das Heim-LAN, Container-Netzwerke und gängige Remote-Client-Netzwerke. Kein Ziel sollte im gleichen Routing-Kontext auf zwei verschiedene Orte verweisen.

Das OpenVPN-HOWTO erklärt, dass sich überschneidende private Netzwerke Routing-Mehrdeutigkeiten erzeugen, weil das System nicht weiß, welche Site eine doppelte Adresse repräsentiert. Unterschiedliche Präfixe beseitigen die Mehrdeutigkeit bei überlappenden Adressen, bevor Routinenmetriken berücksichtigt werden.

Nummerieren Sie einen Tunnel oder LAN nach Möglichkeit um. Wenn Überlappungen unvermeidbar sind, verwenden Sie kontrollierte NAT-Übersetzung, separate Netzwerk-Namespaces, VRFs oder Richtlinientabellen, anstatt sich darauf zu verlassen, welcher Tunnel zuletzt startet.

Verhindern Sie, dass beide VPNs die Standardroute ersetzen

Untersuchen Sie die Routentabelle ohne VPN, nur mit VPN A, nur mit VPN B und mit beiden aktiv. Protokollieren Sie Standardrouten, Split-Default-Routen wie 0.0.0.0/1 und 128.0.0.0/1, Metriken und Hostrouten zu beiden VPN-Servern.

Ein OpenVPN-Ticket weist darauf hin, dass das Umleiten des Standard-Gateways über mehrere gleichzeitige VPNs nicht sinnvoll ist, es sei denn, der Administrator entscheidet sich für konkurrierende Standardrouten.

Deaktivieren Sie die automatische Installation der Standardroute bei dem Tunnel, der nur für ausgewählte Subnetze dienen soll. Erhalten Sie eine Route zu jedem VPN-Anbieter-Endpunkt über das zugrundeliegende WAN, damit das Hochfahren des zweiten Tunnels seine Steuerverbindung nicht in den ersten Tunnel sendet.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Verwenden Sie Richtlinienrouting für quell- oder anwendungsspezifischen Verkehr

Erstellen Sie separate Routingtabellen für Verkehr, der über jedes VPN geleitet werden muss, und wählen Sie diese dann nach Quellsubnetz, Container-Adresse, Firewall-Markierung, Benutzer oder Schnittstelle aus. Behalten Sie die Haupttabelle für den normalen Heimserververkehr bei.

Ein Unix- und Linux-Beispiel für mehrere VPN-Verbindungen empfiehlt Regeln, damit Verkehr von jeder Schnittstelle seine eigene Routingtabelle verwendet und über das korrekte Modem oder den richtigen Tunnel zurückkehrt.

Fügen Sie Regeln in dokumentierter Reihenfolge hinzu und testen Sie die Routenabfrage für repräsentative Quell- und Zielpaare. Eine Richtlinientabelle ohne das verbundene LAN und Rückrouten kann die ausgewählte Anwendung vom restlichen Heimnetz isolieren.

Richten Sie NAT, Firewall, DNS und Rückwegpfade aus

Dokumentieren Sie für jedes VPN, welche Schnittstelle den Verkehr weiterleitet, welche Quelladressen maskiert werden, welche eingehenden Subnetze erlaubt sind und welchen DNS-Resolver die Clients erhalten. Wenden Sie NAT nur dort an, wo die entfernte Seite keine Rückroute hat.

Ein Server Fault-Fall, der WireGuard-Clients über eine OpenVPN-Verbindung routet, erklärt, dass Verkehr möglicherweise maskiert werden muss, weil das entfernte VPN nur die OpenVPN-Client-Adresse kennt, nicht das entfernte WireGuard-Client-Subnetz.

Vergewissern Sie sich, dass Antworten über den Tunnel zurückgehen, der die Sitzung empfangen oder initiiert hat. Asymmetrische Antworten können ein VPN als verbunden erscheinen lassen, während TCP-, DNS- oder SMB-Verkehr stillschweigend fehlschlägt.

Testen Sie Ausfall- und Neustartreihenfolge vor dem produktiven Einsatz

Starten Sie VPN A, dann B; kehren Sie die Reihenfolge um; starten Sie jeden Dienst unabhängig neu; und starten Sie den Server neu. Protokollieren Sie Routen, Regeln, DNS, Firewall-Zustand und ob der bestehende Fernzugriff erhalten bleibt.

Der ZimaSpace-Leitfaden zum Beheben einer fehlenden VPN-Route bietet die Wiederherstellungssequenz, wenn ein Tunnel versehentlich den Verkehr des anderen einfängt.

Die Konfiguration ist nur dann sicher, wenn sich beide Tunnel in beliebiger unterstützter Reihenfolge wieder verbinden, jede Arbeitslast ihrem vorgesehenen Pfad folgt, DNS vorhersehbar bleibt und das Deaktivieren eines VPNs den Verwaltungsverkehr nicht blockiert. Halten Sie vor der Automatisierung beider Dienste beim Booten eine lokale Konsole oder einen Nicht-VPN-Wiederherstellungspfad bereit.