VPN an, VM nicht erreichbar? Die Route war wahrscheinlich nie das Problem

Schalten Sie das VPN ein, und die Entwicklungs-VM, die vor einer Minute noch antwortete, verstummt. Die naheliegende Geschichte schreibt sich selbst: Der Tunnel hat die Route übernommen, der Host schickt den Gastverkehr nun ins Firmennetz, und die Lösung ist, eine statische Route hinzuzufügen oder den Adapter auf Bridge-Modus umzustellen. Diese Geschichte stimmt manchmal. Aber sie ist nicht die übliche Ursache, und wer zuerst danach handelt, beschädigt meist etwas anderes.

Host-only-Netzwerke sind ein Softwarenetz, das dem Host gehört und mit seinen Gästen geteilt wird, getrennt von jeder physischen Anbindung. Nichts an der eigenen Schnittstelle eines VPN-Clients ändert dieses Netz, also finden Sie heraus, welche der vier Schichten tatsächlich versagt hat, bevor Sie es anfassen.

Die Route bleibt meist weiterhin lokal

Fragen Sie den Kernel statt die Titelseite der Routing-Tabelle. Unter Linux meldet ip route get 192.168.56.10 die genaue Route, Schnittstelle und Quelladresse, die verwendet würden, was eine andere Antwort ist als das Lesen einer Standardroute und Raten. Wenn die Ausgabe die Host-only-Schnittstelle nennt, ist der Tunnel an diesem Pfad überhaupt nicht beteiligt.

Zwei Dinge können es wirklich kaputt machen, und beide sind Adressprobleme und keine VPN-Probleme. Ein entferntes Subnetz, das sich mit dem Host-only-Präfix überschneidet, lässt die spezifischere Route gewinnen, und ein VPN-Client, der eine breite Route mit niedrigerer Metrik installiert, kann das Präfix wegziehen. Beides ist im selben Befehl sichtbar: Die in der Ausgabe genannte Schnittstelle wird der Tunnel sein, und die Korrektur gehört demjenigen, dem dieser Adressplan gehört.

Routenauswahl und Paketannahme sind verschiedene Entscheidungen

Das ist der Teil, den das mentale Modell meist auslässt. Selbst mit einer perfekten lokalen Route kann ein VPN-Client das Paket ablehnen. Viele Clients erzwingen eine Richtlinie für lokalen Netzwerkzugriff, die entscheidet, welche Ziele außerhalb des Tunnels erlaubt sind, und ein verbundenes Subnetz aktualisiert diese Liste nicht automatisch.

Der Fehler sieht also aus Anwendungssicht identisch aus wie ein Routingproblem und aus Client-Sicht völlig anders. Wenn ip route get die richtige Schnittstelle nennt und die Verbindung trotzdem ausläuft, hören Sie auf, Routen zu bearbeiten, und lesen Sie stattdessen das dokumentierte Verhalten des Clients für lokalen Zugriff. Manche Clients bieten eine Allow-List für lokale Subnetze, manche blockieren alles, was nicht der Tunnel ist, und manche blockieren nur, wenn ein Kill-Switch aktiv ist.

Diese Unterscheidung ist wichtig, weil die Korrekturen nicht austauschbar sind. Eine Route hinzuzufügen kann einen Filter nicht erfüllen, und einen Filter abzuschalten, um einen Gast zu erreichen, ist eine viel größere Entscheidung, als das Symptom vermuten lässt.

Der Gast hat drei Arten, nein zu sagen

Ein Gast, der im Internet surfen kann, hat nichts über den Dienst bewiesen, den Sie wollen. Der Listener kann im Gast an 127.0.0.1 gebunden sein, und dann kann keine Anfrage vom Host ankommen, so gut der Pfad auch ist. Prüfen Sie es mit ss -ltn im Gast und sehen Sie sich die Spalte der lokalen Adresse an, nicht nur den Port.

Als Nächstes kommt die eigene Firewall des Gastes. Ein Entwicklungsimage mit restriktiver Voreinstellung kann die Pakete des Hosts annehmen und sie an der Dienstgrenze verwerfen, was einen Timeout erzeugt, der genau wie ein Routing-Schwarzes-Loch aussieht. Schließlich gibt es die eigene Konfiguration des Dienstes: Eine Web-App, die an einen bestimmten Hostnamen gebunden ist, oder eine Allow-List mit Client-Adressen lehnt eine Anfrage aus dem Host-only-Subnetz ab, selbst wenn jedes Paket ankommt.

Arbeiten Sie diese drei ab, bevor Sie erwägen, den Netzwerkmodus der VM zu ändern. Jede ist eine kleinere Änderung als eine Neuarchitektur der Gastanbindung, und jede hat einen klaren Test.

Was eine Bridge wirklich ist und was sie kostet

Den Adapter auf Bridge-Modus umzustellen ist keine Reparatur des Host-only-Pfads. Es ist die Entscheidung, den Gast in ein anderes Netz zu setzen, meist das physische LAN, wo er für alles andere dort sichtbar wird. Das kann genau das sein, was Sie wollen. Aber es ist nicht das, was die ursprüngliche Konfiguration getan hat.

Verwenden Sie es, wenn der Gast wirklich ein Peer in diesem LAN sein muss und die Exposition genehmigt ist. Verwenden Sie es nicht, weil ein einzelner Dienst nicht mehr antwortet, denn die Änderung kann den Gast aus der Isolation holen, die ihn für die Entwicklung sicher gemacht hat.

Testen Sie nach jeder genehmigten Korrektur in fester Reihenfolge: eine neue Anfrage vom Host zum Gast, eine erforderliche Unternehmensressource durch den Tunnel und das beabsichtigte verweigerte Verhalten bei abgeschaltetem Tunnel. Wenn das letzte nicht mehr gilt, ging die Korrektur über das Problem hinaus.

Der VirtualBox-Abschnitt zum Host-only-Netzwerk beschreibt die Software-Schnittstelle auf der Hostseite und wie sie sich von einer Bridge-Anbindung unterscheidet, was die Referenz ist, die man lesen sollte, bevor man annimmt, die beiden Modi seien austauschbar.