Eine an die VPN-Adresse gebundene Anwendung nutzt trotzdem die falsche Route

Eine Anwendung bindet an die Adresse des VPN, und die Verbindung verlässt den Host trotzdem über die gewöhnliche Standardroute. Am Bind ist nichts gescheitert; er hat genau das getan, was ein Bind tut. Einen Socket an eine lokale Adresse zu binden, wählt die Quelladresse, die der Kernel in den Header schreibt. Es installiert keine Route und erzeugt keine Policy-Regel, die Pakete mit dieser Quelle in einen bestimmten Tunnel schickt.

Der Rest dieses Runbooks ist die Prüfreihenfolge, die ich verwende, samt dem Befehl, der die jeweilige Beobachtung liefert.

Was ein Bind tatsächlich entscheidet

Ein Bind weist dem Socket eine lokale Adresse zu. Der Kernel führt danach dieselbe Routensuche aus, die er auch sonst ausgeführt hätte, sofern keine Policy-Regel ändert, welche Tabelle diese Suche liest.

Deshalb kann ein Paket mit einer VPN-Quelladresse auf einer physischen Schnittstelle hinausgehen. Auf der Gegenseite kommt es aus einem privaten Bereich, den das Netzwerk auf diesem Weg nie erwartet hat, der Rückverkehr hat keine Route zurück, und die Verbindung hängt oder wird zurückgesetzt.

Die Linux-Referenz zu IP-Sockets dokumentiert die Bind-Semantik. Die Routing-Hälfte lebt in ip-rule und ip-route, und das sind aus gutem Grund getrennte Handbuchseiten.

Bestätigen Sie, dass die Adresse zu diesem Namespace gehört

Eine Adresse, an die Sie binden können, muss auf einer Schnittstelle innerhalb des Netzwerk-Namespace existieren, in dem die Anwendung läuft. Eine Peer-Adresse, eine Gateway-Adresse oder eine Adresse, die nur in einem anderen Namespace existiert, ist nicht bindbar, und der Aufruf schlägt mit EADDRNOTAVAIL fehl.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Führen Sie diese drei im selben Kontext wie die Anwendung aus: derselbe Namespace und, wenn Sie ihn bekommen, derselbe Benutzer. Ein altes net30-Diagramm ist kein Beleg dafür, welche Adresse Ihre aktuelle Topologie dem Client zugewiesen hat. Lesen Sie die Schnittstelle, die tatsächlich aktiv ist.

Lesen Sie die Suche für diese Quelle und dieses Ziel

Ein einziger Befehl beantwortet die Frage, die der Bind nicht beantwortet hat:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Die erste Zeile gibt die Route aus, die ein Paket von dieser Quelle zu diesem Ziel nehmen würde, einschließlich der Ausgangsschnittstelle und der bevorzugten Quelle. Wenn sie die physische Schnittstelle nennt, widersprechen sich Bind und Route, und das Paket geht mit einer Quelle hinaus, zu der der Pfad nicht zurückfindet.

ip rule show sagt Ihnen dann, ob irgendeine Regel eine andere Tabelle gewählt hätte. Prioritäten zählen hier, denn die erste passende Regel gewinnt, und eine Auffangregel oberhalb Ihrer Regel macht Ihre Regel unsichtbar.

Installieren Sie eine Policy-Regel nur, wenn das das Design ist

Quellenbasiertes Routing ist ein bewusstes Design, keine Reparatur für eine einzelne Anwendung. Will der Policy-Eigentümer, dass Verkehr aus dem Tunnel-Subnetz den Tunnel nutzt, gehört die Regel in dessen Konfiguration und nicht in einen einmaligen Befehl auf Ihrem Laptop.

Eine tragfähige Form ist eine eigene Tabelle mit einer Standardroute durch den Tunnel plus einer Regel, die den VPN-Quellbereich in diese Tabelle schickt. Fügen Sie die Ausnahmen hinzu, die das Design braucht, denn eine Tabelle, die nur einen Tunnel-Standard enthält, fängt Ziele ab, die lokal bleiben oder über den physischen Pfad erreichbar sein sollen.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Machen Sie es mit ip rule del und ip route flush table 100 rückgängig. Alles so Hinzugefügte verschwindet beim Neustart, sofern es kein Manager schreibt, was sowohl eine Sicherheitseigenschaft ist als auch ein Grund, die einzige Kopie nicht in Ihrer Shell-Historie zu halten.

Prüfen Sie mit drei Beobachtungen

Notieren Sie die Quelle, die die Anwendung angefordert hat, die Route, die die Suche gewählt hat, und die Quelle, die der Server tatsächlich gesehen hat.

Diese drei können auseinandergehen, und jede Abweichung zeigt woandershin. Ein Mitschnitt auf der Tunnelschnittstelle belegt, dass das Paket mit der richtigen Quelle hinausging. Ein Mitschnitt auf der physischen Schnittstelle belegt, dass es den falschen Weg nahm. Nur die Sicht auf Serverseite belegt den Pfad von Ende zu Ende.

Bietet die Anwendung eine Bind-to-Device-Option oder einen Routing-Modus pro Anwendung, behandeln Sie das als anderen Mechanismus mit anderen Einschränkungen. Ähnlich aussehende Einstellungen führen nicht alle zur selben Kernel-Entscheidung.