Vagrant-VM verschwindet beim Verbinden des VPN: wessen Route brach

Die Box antwortete vor einer Minute, das VPN verband sich, und nun läuft dieselbe Adresse in eine Zeitüberschreitung. Drei Fehler erzeugen dieses Symptom, und sie sitzen auf verschiedenen Maschinen. Der Host kann die Route in das private Netz verlieren, der NAT-Bereich des Gasts kann mit einem Bereich kollidieren, den der Tunnel jetzt ankündigt, oder ein Full-Tunnel kann das Eigentum an jeder Route auf dem Host übernehmen. Finden Sie heraus, welcher Fall eingetreten ist, bevor Sie irgendeine Konfiguration ändern, denn jede Behebung sitzt woanders.

Beobachten Sie die Route, nicht die Box

Sehen Sie sich die Routing-Entscheidung des Hosts für die Gastadresse an, während der Tunnel steht. Eine Route, die noch auf den Host-Only-Adapter zeigt, ist nicht das Problem. Eine Route, die jetzt auf den VPN-Adapter zeigt, ist das Problem, und der Client hat sie geändert, nicht Sie. Dass der Adapter seine Adresse behält, sagt, dass die Schnittstelle überlebt hat, was ein anderer Befund ist als ein überlebender Pfad.

Eine SSH-Sitzung, die genau im Verbindungsmoment abreißt, ist erwartetes Verhalten. Der Client recycelt Adapter und installiert Routen, deshalb stirbt die Verbindung für ein paar Sekunden. Der Fehler ist die Verbindung, die nie zurückkommt, nicht die, die nur kurz blinkte.

Erfassen Sie die Tabelle vor dem Tunnel und noch einmal danach, und vergleichen Sie dann diese beiden Ausgaben. Die Differenz ist die Diagnose, und sie ist zugleich der Beleg, den ein Netzwerkverantwortlicher anfordern wird.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Lesen Sie die Tabelle des Hosts vorher und nachher

Unter Linux ergibt sich der Vorrang zwischen überlappenden Routen aus Präfixlänge und Metrik, deshalb gewinnt eine spezifischere VPN-Route, auch wenn sie falsch ist. Unter Windows entscheidet die Schnittstellenmetrik den Gleichstand, und der Tunneladapter kommt meist mit einer niedrigeren Metrik an als der virtuelle. In beiden Fällen ist das sichtbare Symptom identisch: Pakete verlassen den Host über den Tunneladapter und verschwinden.

Geben Sie die Adapter und ihre Metriken neben der Route für das Gastpräfix aus. Dieses Ausgabepaar beantwortet die Eigentumsfrage mit einem Blick.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Hat sich die Route geändert, die Adaptermetrik aber nicht, hat der Client eine konkurrierende Route installiert. Hat sich die Metrik geändert, hat der Client die Adapter umsortiert. Beides ist behebbar, und beides wird an verschiedenen Stellen behoben.

Wenn der NAT-Bereich des Gasts die Kollision ist

VirtualBox NAT verwendet standardmäßig 10.0.2.0/24, und ein Tunnel, der denselben Bereich schiebt, bringt den Gast dazu, diesen Verkehr an sein NAT-Gateway statt an das echte Ziel zu schicken. Das Paket verlässt den Host nie, deshalb wird es kein Firewall-Log auf der anderen Seite zeigen. Docker Machine hat dieselbe Konfliktklasse in seinem Host-Only-Plan, und eine Änderung dieses Plans kann erfordern, die Maschine samt ihren Zertifikaten neu zu erzeugen.

Wählen Sie den Ersatz, indem Sie auflisten, was der Tunnel bereits ankündigt, dann was das Büronetz nutzt, dann was jeder virtuelle Adapter auf diesem Host beansprucht hat. Überlappung bricht das Routing, und Ähnlichkeit ist irrelevant. Ein Bereich kann vollständig in einem anderen liegen, während er auf den ersten Blick ganz anders aussieht.

Setzen Sie den neuen Bereich beim Erstellen der Maschine, oder ändern Sie ihn und laden Sie neu, und testen Sie dann die fehlschlagende Verbindung erneut vom Gast aus. Die eigene Tabelle des Gasts ist die Ansicht, auf die es ankommt.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Stellen Sie den Pfad wieder her, ohne mit dem Client zu kämpfen

Jede Plattform bietet einen Weg, das Host-Only-Präfix wieder nach vorn zu bringen. Unter macOS funktioniert eine statische Route zur Host-Only-Schnittstelle bis zur nächsten Verbindung. Unter Windows hält eine niedrigere Schnittstellenmetrik auf dem virtuellen Adapter ihn bevorzugt. Unter Linux deckt eine Ersetzungsoperation ein einzelnes Präfix ab. Alle drei sind Behelfe, denn ein Client, der seine Routen erneut durchsetzt, macht sie rückgängig.

Skripten Sie die Prüfung statt eines blinden Wiederverbindens beim Start. Ein kleines Skript, das nach jeder Verbindung die Route für das Gastpräfix ausgibt, macht aus einem Rätsel eine Zeile im Log.

Ist das Profil ein Full-Tunnel, bitten Sie den Netzwerkverantwortlichen um Split-Tunnelling oder eine dokumentierte Ausnahme. Routen still hinzuzufügen, die eine Sicherheitsrichtlinie umgehen, ist keine Behebung, sondern ein zweites Problem, das später mit einem Auditor im Schlepptau ankommt.

Prüfen Sie die Behebung auf beiden Seiten

Prüfen Sie nach der Änderung drei Pfade: Host zum Gast, Gast zum Firmenhost und Gast zum Internet. Eine Behebung, die einen davon wiederherstellt und einen anderen bricht, ist eine Konfigurationsänderung, die sich als Reparatur verkleidet. Erfassen Sie dieselben Ausgaben wie vor der Änderung, damit der Vergleich Gleiches mit Gleichem ist.

Notieren Sie die Schnittstelle, die Metrik und die geänderte Route zusammen mit dem Zeitpunkt, damit der nächste Fall ein Nachschlagen statt eines Neubaus ist. Diese Notiz ist mehr wert als ein langer Ticket-Thread.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Wenn der Host den Gast wieder erreicht und der Gast das LAN erreicht, haben Sie den Pfad wiederhergestellt, mit dem Sie begonnen haben. Wenn nur eines davon funktioniert, liegt der verbleibende Fehler im Revier des anderen Eigentümers, und die Differenz sagt Ihnen, welches Revier das ist.