Gast-VPN und Host-VPN: Welche Route tatsächlich gewinnt

Zwei Clients laufen gleichzeitig, jeder überzeugt, die Standardroute zu besitzen, und das Symptom kommt als etwas Merkwürdiges: Eine Gast-Anwendung funktioniert, eine andere wird an die falsche Stelle aufgelöst. Ein VPN im Gast und ein VPN auf dem Host können koexistieren, aber nur wenn der äußere Pfad und die innere Richtlinie darin übereinstimmen, wer was trägt. Beide zu starten erzeugt nicht von sich aus eine Kette. Halten Sie zuerst die Anbindung fest und ändern Sie dann jeweils eine Sache.

Halten Sie zuerst die Anbindung des Gasts fest

Der Gast erreicht seinen VPN-Server über den Pfad, den ihm der Hypervisor gegeben hat: NAT hinter dem Host, eine Bridge auf das physische Segment oder ein reines Host-Netzwerk mit zusätzlichem Routing darüber. Jede Anbindung verändert, was der Gast sehen kann und was der Host mit seinem Verkehr tun kann. Unter NAT scheinen die Pakete des Gasts vom Host zu kommen, sodass der eigene Tunnel des Hosts sie tragen kann, ohne dass der Gast davon etwas weiß. Unter einer Bridge hat der Gast seine eigene Präsenz im Segment und sein eigenes Standard-Gateway.

Halten Sie die Anbindung fest, bevor Sie irgendeine Konfiguration anfassen, zusammen damit, welcher Client welche Anwendung tragen soll. Dieser Satz löst die meisten dieser Fälle, weil die beiden Clients meist auf unterschiedlichen Annahmen gebaut sind. Ein Gast, der den Tunnel des Hosts nutzen soll, darf nicht zugleich eine konkurrierende Standardroute besitzen.

Verfolgen Sie den Endpunkt des Gasts nach außen

Ein Gast-VPN braucht einen brauchbaren Pfad zu seinem eigenen Server, bevor irgendetwas anderes funktionieren kann. Wenn der Tunnel des Hosts steht und der Gast hinter NAT sitzt, verlässt der Handshake des Gasts den Tunnel des Hosts, was entweder das Design oder ein Unfall ist, den niemand dokumentiert hat. Wenn der Tunnel des Hosts wegfällt und der Gast von ihm abhing, verliert der Gast die Konnektivität ohne eine einzige Änderung auf seiner Seite. Den Endpunkt nach außen zu verfolgen sagt Ihnen, welchen dieser beiden Fälle Sie tatsächlich haben.

Eine breite Route fängt in beiden Kontexten Verkehr ab, den der andere Client erwartet hat. Eine Route 0.0.0.0/0 im Gast und ein Host-Client mit vollem Tunnel beanspruchen beide alles, und wer zuletzt gilt, gewinnt. Überschneidungen zwischen den virtuellen Netzen des Gasts, dem lokalen LAN und entfernten Netzen erzeugen denselben Effekt für private Präfixe, mit Fehlern, die wie Authentifizierungsprobleme aussehen; das Verhalten der Adressübersetzung ist dasselbe, das für Container-Netzwerke beschrieben wird.

Vergleichen Sie eine Aufzeichnung vorher und nachher

Nehmen Sie eine Basislinie mit ausgeschaltetem Tunnel des Hosts auf, oder in welchem kontrollierten Zustand Ihre Richtlinie auch immer erlaubt, und halten Sie Route und Resolver des Gasts fest. Wenden Sie dann die kombinierte Konfiguration an und vergleichen Sie die beiden Aufzeichnungen, wobei die Datenschutzanforderungen intakt bleiben. Wenn eine direkte Basislinie nicht angemessen ist, schreiben Sie diese Einschränkung in die Aufzeichnung, statt den Vergleich auszulassen.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Die Routenabfrage nennt die Schnittstelle und die Quelladresse, die ein bestimmtes Ziel tragen würden, und sie ist die nützlichste einzelne Zeile in dieser Untersuchung. Die Regelliste zeigt, ob Policy-Routing einige Ziele über eine zweite Tabelle schickt. Die Ausgabe des Resolvers zeigt, ob DNS dem Tunnel des Gasts gefolgt ist oder auf dem Pfad des Hosts geblieben ist. Führen Sie dieselben drei Befehle vor und nach der Änderung aus, und das Delta benennt den Schuldigen.

Halten Sie die Zuständigkeit über Neustarts hinweg klar

Die Lokalzugriffs-Beschränkung eines Host-Clients kann Verkehr zu einem virtuellen NAT oder einer Bridge blockieren, und diese Einschränkung wird regelmäßig für ein Problem mit den Anmeldedaten des Gasts gehalten. Lesen Sie das dokumentierte Verhalten des Clients, statt die Einschränkung zu deaktivieren, damit ein Test besteht. Testen Sie nach einer unterstützten Korrektur die Gast-Anwendung und die Fehlerrichtlinie, die Sie verlangen, erneut. Ein Host, der sich erfolgreich neu verbindet, beweist nichts über die Route oder den Resolver des Gasts.

Entscheiden Sie, welche Seite die Standardroute besitzt, und schreiben Sie das in das Betriebshandbuch. Ein Neustart des Gasts oder ein Netzwerkwechsel am Host, der die Zuständigkeit still umkehrt, erzeugt einen Fehlerbericht über ein VPN, das nie schuld war. Die Anordnung sollte einen Neustart überstehen, ohne dass sich jemand daran erinnert, warum sie funktionierte.