Warum die Adapterreihenfolge Ihre Labor-VPN-Route nicht bestimmt

Dass Adapter 1 in der Liste des Hypervisors an erster Stelle steht, ist eine Anzeigereihenfolge, und die Routing-Tabelle des Gasts liest sie nicht. Was den Pfad bestimmt, sind das Präfix, die Metrik und jede Policy-Regel, die vor beiden greift. Das Hinzufügen eines Bridge-Adapters zu einer Labor-VM kann daher einen zweiten Standardpfad erzeugen, während die alte NAT-Schnittstelle weiterhin als vorhanden und als zweite nummeriert angezeigt wird. Das Ergebnis ist eine VM, die manchmal den Tunnel nutzt und manchmal nicht, ohne dass eine Konfigurationsänderung das erklärt.

Drei Bedingungen bestimmen den Pfad

Die drei Bedingungen sind, welches Präfix spezifischer ist, was die Metriken tun, wenn Präfixe gleich sind, und welche Regeln der Gast nach der Hardware-Änderung angewendet hat. Jede lässt sich mit einem Befehl beantworten, und keine davon bezieht sich auf die Nummerierung des Hypervisors.

Genau dieser letzte Punkt ist die Entscheidung: Wenn Sie nicht sagen können, welches Präfix für die eigene Adresse des VPN-Endpunkts gewinnt, haben Sie keine Routing-Policy, sondern eine Topologie, die heute zufällig funktioniert.

Bedingung eins: welches Präfix gewinnt

Eine Route nach 10.8.0.0/24 schlägt eine Standardroute für eine Adresse darin, unabhängig von Metriken und unabhängig von der Adapterreihenfolge. Deshalb funktioniert ein VPN-Client, der eine spezifische Route installiert, weiter, selbst wenn ein zweiter Adapter mit niedrigerer Metrik erscheint: Spezifität gewinnt, bevor Kosten betrachtet werden. Prüfen Sie mit ip route show die Tabelle, die Sie für aktiv halten, und mit ip route get 203.0.113.9 die Antwort, die der Kernel für ein bestimmtes Ziel tatsächlich geben würde.

Die eigene Adresse des Endpunkts ist der Test, auf den es am meisten ankommt. Löst die Adresse des VPN-Servers über einen neu hinzugefügten Bridge-Adapter auf, kommt der Tunnel möglicherweise nie zustande, oder er kommt zustande und verliert danach seinen eigenen Transportpfad. Fragen Sie gezielt diese Adresse ab, statt anzunehmen, die Tunnel-Schnittstelle sei die Antwort.

Bedingung zwei: was die Metrik tut und was nicht

Ihre Rolle ist enger, als die meisten erwarten. Metriken entscheiden Gleichstände zwischen Routen zum selben Präfix; sie lassen eine breitere Route nicht eine spezifischere schlagen. Bei Gleichstand wird die kleinere Zahl bevorzugt, und verschiedene Betriebssysteme zählen in entgegengesetzte Richtungen, weshalb Ratschläge, die zwischen Linux und Windows kopiert werden, sich oft selbst widersprechen.

Im Gast gibt ip route show die Metrik neben jeder Route aus, und Get-NetRoute unter Windows gibt eine InterfaceMetric plus eine Routenmetrik aus. Lesen Sie beides, denn die wirksame Präferenz kann eine Summe statt eines einzelnen Feldes sein. Existieren zwei Standardrouten, ist das der Befund: Der Gast hat zwei Wege nach draußen, und welcher gewinnt, hängt von Zahlen ab, die eine Hardware-Änderung ändern kann.

Bedingung drei: was der Gast tatsächlich angewendet hat

Konfiguration ist nicht dasselbe wie angewendeter Zustand. Schnittstellennamen sind bei Hardware-Änderungen nicht auf jeder Plattform stabil, und eine Konfiguration, die über einen Namen passte, gilt jetzt vielleicht für nichts.

Prüfen Sie den angewendeten Zustand statt den beabsichtigten. ip -br link zeigt die Schnittstellen, die jetzt existieren, und auf einem NetworkManager-Host zeigt nmcli connection show, welches Profil an welches Gerät gebunden ist. Ein Profil, das nicht gebunden werden konnte, lässt die Schnittstelle oben ohne Adressierung, was wie ein Routing-Problem aussieht und ein Namensproblem ist. Wiederhergestellte Snapshots verschlimmern das, weil der gespeicherte Zustand des Gasts Adapteridentitäten referenzieren kann, die die neue Hardware nicht mehr bereitstellt.

Halten Sie die Labor-Topologie reproduzierbar

Speichern Sie die beabsichtigten virtuellen Netzwerkanbindungen zusammen mit der Konfiguration des Gasts, damit die Zuordnung von Rolle zu Adapter aufgeschrieben und nicht aus einer Listenposition abgeleitet wird.

Vier Rollen reichen normalerweise zum Benennen: private Verbindung, Verwaltung, Außentransport und Tunnel. Jede sollte in einer Datei einem bestimmten Adapter und einer bestimmten Gast-Schnittstelle zugeordnet sein.

Testen Sie danach die eigentliche Anwendung nach einer Hardware-Änderung, einem Neustart oder einem wiederhergestellten Snapshot und schließen Sie die Route zum VPN-Endpunkt in diesen Test ein. Wenn eine Gateway-VM der einzige Ausgang sein soll, prüfen Sie, dass die Test-VM keinen unbeabsichtigten zweiten Standardpfad hat, denn genau einen zweiten Standardpfad fügt ein Bridge-Adapter hinzu. Testen Sie aus dem Gast, nicht von der Hypervisor-Konsole, da beide darüber uneinig sein können, welche Schnittstelle welche ist.

Die VirtualBox-Netzwerkdokumentation beschreibt die Adaptermodi und womit jeder verbunden wird, und das ist der Teil, der sich vor dem Hinzufügen eines zweiten lohnt zu lesen. Ein Labor, das festhält, welcher Adapter welche Rolle bedient, macht eine Routenänderung erklärbar. Ein Labor, das sich auf die Nummerierung des Hypervisors verlässt, macht jede Änderung zu einem Experiment.