Nutzt Ihre VM das VPN des Hosts? Testen Sie es im Gast

Sie prüfen die öffentliche IP des Hosts, sie zeigt das VPN, und Sie schließen daraus, dass die VM abgedeckt ist. Diese Schlussfolgerung trägt der Test nicht. Ein Gast hat seine eigene Routing-Tabelle, seinen eigenen Resolver und seine eigenen Schnittstellen, und die Exit-Adresse des Hosts sagt nichts über sie aus.

Der Test muss im Gast laufen und benennen, was er gemessen hat.

Fangen Sie im Gast an, nicht im Browser des Hosts

Halten Sie zuerst den Netzwerkmodus des Hypervisors fest: NAT, bridged, host-only oder macvtap. Im NAT-Modus routet der Host den Verkehr des Gasts, der Tunnel des Hosts kann also gelten oder nicht, je nachdem, wie der Client Routen installiert. Im bridged-Modus ist der Gast ein gleichberechtigter Teilnehmer im physischen LAN, und der Tunnel des Hosts ist irrelevant. Diese beiden Modi liefern bei derselben Host-Konfiguration entgegengesetzte Antworten.

Schreiben Sie den Modus auf, bevor Sie etwas ändern, denn er bestimmt, was das Ergebnis bedeuten kann.

Stellen Sie eine Anfrage, deren Ziel Sie kennen

Nutzen Sie eine harmlose Anfrage an einen Dienst, der die gesehene Quelladresse meldet. Prüfen Sie dann die Routing-Entscheidung des Gasts selbst für dieses Ziel: ip route get 203.0.113.5 gibt die Schnittstelle und das Gateway aus, die der Gast verwenden wird.

Ist die Schnittstelle die normale NIC des Gasts, läuft der Verkehr nicht durch einen Tunnel im Gast.

Ein zweiter Adapter, eine Proxy-Einstellung oder ein VPN-Client auf der Gastseite können die Antwort für eine Anwendung ändern und für eine andere nicht. Testen Sie die Anwendung, die Ihnen wirklich wichtig ist, nicht eine allgemeine Anfrage aus einer Shell.

Prüfen Sie den Resolver getrennt

Eine geänderte Exit-Adresse sagt nicht, welcher Resolver den Hostnamen aufgelöst hat. Fragen Sie den Namen ausdrücklich mit dem Werkzeug ab, das zur Plattform passt, und notieren Sie, welcher Server geantwortet hat. Split-DNS bedeutet, dass die Resolver-Frage und die Routing-Frage unterschiedliche Antworten haben.

Beide können in jede Richtung auseinanderlaufen, und die Abweichung ist oft der eigentliche Fehler.

Auf einem systemd-Host resolvectl query benennt die Schnittstelle und den DNS-Server hinter der Antwort. Ältere Setups zeigen den Server in der Ausgabe von dig — in jedem Fall geht es darum zu sehen, welcher Server geantwortet hat, nicht nur ob eine Antwort kam.

Testen Sie die Fehlerrichtlinie, nicht nur den Erfolg

Wenn die Anforderung ist, dass kein Verkehr außerhalb des Tunnels das Gerät verlässt, beweist eine erfolgreiche Anfrage nichts. Nutzen Sie den unterstützten kontrollierten Fehlertest des Clients: Stoppen Sie den Tunnel auf die unterstützte Weise und prüfen Sie, ob eine neue Anfrage des Gasts blockiert wird. Gehen Sie nicht davon aus, dass der Kill-Switch des Host-Clients jede virtuelle Weiterleitungskonstellation abdeckt. Nur sein dokumentierter Umfang ist verlässlich.

Ein Gast, der bei einem Tunnelausfall auf die physische NIC zurückfällt, tut genau das, was der NAT-Modus erlaubt.

Halten Sie Modus und Umfang fest

Notieren Sie den Hypervisor-Modus, die Schnittstelle und Route des Gasts, den Resolver und die Anwendung, die Sie getestet haben. Fügen Sie das Datum hinzu, denn eine Snapshot-Wiederherstellung oder ein Hypervisor-Update kann alle vier ändern.

Wenn IPv4 dem Tunnel gefolgt ist, sagen Sie das. Dehnen Sie die Aussage nicht auf IPv6, einen anderen Namespace oder eine andere VM in einem anderen Netz aus.