OpenVPN-Routenmetrik: Warum die gewählte Route trotzdem verliert

Sie haben einer Route im Profil eine Metrik hinzugefügt, sich neu verbunden, und der Verkehr verlässt das System immer noch über die falsche Schnittstelle. Die Zahl ist selten das Problem. Eine Metrik ordnet nur Kandidaten, die das Betriebssystem bereits vergleicht, und ein spezifischeres Präfix oder eine frühere Policy-Tabelle entscheidet, bevor überhaupt eine Metrik gelesen wird.

Arbeiten Sie zuerst das Profil durch, dann die installierte Tabelle, dann die Auswahlregeln. Diese Reihenfolge entspricht der Art, wie der Client die Route aufbaut, und bewahrt Sie davor, einen Wert zu justieren, der nie in den Vergleich eingeht.

Lesen Sie die Routenzeile in Feldreihenfolge

Ein Community-Client von OpenVPN 2.6 akzeptiert vier Felder in einer IPv4-route-Zeile: Netzwerk, Netzmaske, Gateway und eine optionale Metrik. Die Gateway-Position ist der Platz, an den das besondere Schlüsselwort vpn_gateway gehört. Es bezeichnet den nächsten Hop auf der VPN-Seite für diese Verbindung, keine Nummer einer Routingtabelle und nicht Ihren physischen Router. Übersehen Sie das, wird der Rest der Zeile mit einer falschen Vorstellung davon gelesen, was er tut. Referenz zu den Netzwerkoptionen dokumentiert alle vier Felder.

Für ein privates Ziel kann die Zeile so lauten:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Die ausdrückliche 30 gilt für diese Route, und die 50 bleibt der Standard für jede andere Route im Profil, die keine Zahl angibt. Die Zeile von links nach rechts zu lesen genügt, um zu erkennen, welcher Wert wo gilt.

route-metric ist ein Standard, kein Rang

route-metric legt den Rückfallwert für Routen fest, die keine eigene Zahl tragen. Es hebt keine Route über etwas anderes und ordnet keine Routen um, die mit ausdrücklichen Metriken installiert wurden.

Dieser Unterschied zählt, wenn ein Profil beide Formen mischt. Eine einzelne route-metric-Zeile nahe oben wirkt maßgeblich und ist leicht zu beschuldigen, während die Route, die den Verkehr tatsächlich trägt, ihre eigene Metrik drei Zeilen weiter unten tragen kann.

Wenn eine Route einen Weg bevorzugen soll, setzen Sie die Zahl an diese Route. Wenn Sie einen einheitlichen Standard über ein erzeugtes Profil hinweg wollen, verwenden Sie route-metric und lassen Sie die einzelnen Zeilen in Ruhe. Beides ohne Grund zu mischen, ist der Weg, auf dem ein Profil mit einer Route endet, die niemand erklären kann.

Prüfen Sie, was der Client installiert hat

Fragen Sie nach Abschluss der Wiederverbindung den Kernel, nicht das Profil.

ip route show listet die Routen auf, die der Client hinzugefügt hat, und ip route get 172.20.5.10 beantwortet die nützlichere Frage: welche Route dieses Ziel tatsächlich nutzen würde und mit welcher Quelladresse. Fehlt das Ziel in der Tabelle, hat der Client es nicht installiert.

Eine lokale Direktive, ein Server-Push oder ein anderer Netzwerkmanager können dasselbe Präfix hinzufügen oder entfernen, und der letzte Schreiber gewinnt. Behalten Sie die Endpunkt-Route im Blick, während Sie arbeiten, denn die Verbindung braucht einen Weg zum entfernten Server, der nicht durch den Tunnel läuft, den sie gerade aufbaut.

Warum eine kleinere Metrik trotzdem verliert

Metriken vergleichen Routen zu demselben Ziel. Sie machen ein breites Präfix nicht spezifischer. Wenn redirect-gateway def1 im Spiel ist, installiert der Client 0.0.0.0/1 und 128.0.0.0/1, und diese beiden Präfixe decken den gesamten IPv4-Raum spezifischer ab als 0.0.0.0/0. Eine Metrik von 1 auf der Standardroute übertrumpft sie nicht.

Dieselbe Logik gilt für jedes überlappende Paar. Ein /24 schlägt ein /16 für eine Adresse darin, unabhängig von den angehängten Zahlen, weil die Suche zuerst den spezifischsten Treffer wählt und erst dann Metriken unter Gleichen vergleicht.

Das ist der Teil, der wie ein Metrikfehler aussieht und keiner ist. Prüfen Sie die Präfixlänge bei beiden Kandidaten, bevor Sie irgendeine Zahl ändern.

Policy-Regeln laufen vor der Tabelle

Unter Linux entscheidet ip rule, welche Routingtabelle herangezogen wird. Regeln werden in Prioritätsreihenfolge ausgewertet, sodass eine frühere Tabelle eine Route zurückgeben kann, bevor die Haupttabelle überhaupt gelesen wird. Eine Metrik innerhalb von main kann keinen Treffer in einer Tabelle übertrumpfen, die zuerst herangezogen wurde.

Verwenden Sie ip rule show und fragen Sie dann die konkrete Tabelle ab, zum Beispiel ip route show table 100, um zu sehen, was diese Regel zurückgeben würde. Hat ein VPN-Client oder eine Container-Laufzeit eine Regel hinzugefügt, kann die Antwort dort stehen statt in der Tabelle, die Sie gelesen haben. Auch die Quelladresse zählt, denn eine Regel kann auf die Quelle passen und dasselbe Ziel für Tunnelverkehr und LAN-Verkehr unterschiedlich auflösen.

Prüfen Sie das Ziel, nicht die Rangfolge

Der Test, der die Diskussion beendet, ist eine einzige Abfrage an einen Host im vorgesehenen Subnetz plus eine Prüfung der Quelladresse, die der Kernel gewählt hat. Passen die beiden zum Entwurf, erfüllt die Metrik ihre Aufgabe, auch wenn die Liste nicht wie eine saubere Rangfolge aussieht.

Lassen Sie IPv6 und DNS aus dieser Prüfung heraus. Sie werden durch andere Direktiven konfiguriert und durch andere Mechanismen aufgelöst, und eine funktionierende IPv4-Route sagt über keines von beiden etwas aus. Ändern Sie jeweils eine Schicht und führen Sie die Abfrage erneut aus.