App an eine Schnittstelle gebunden? Ihr VPN-Weg ist nicht der Standard

Eine Anwendung auf dem Rechner geht über das VPN hinaus, eine andere nicht, und beide Nutzer schwören, nichts geändert zu haben. Der Unterschied ist oft eine Bindungsentscheidung der Anwendung selbst: ein Socket an ein Gerät gebunden, eine vor der Verbindung gewählte Quelladresse oder ein Namespace mit eigener Routing-Tabelle. Jede ändert, welcher Weg gilt, und keine erscheint in einem allgemeinen IP-Check im Browser.

Drei verschiedene Bindungen, drei verschiedene Wirkungen

Die Bindung an ein Gerät und die Bindung an eine Quelladresse sind verwandte Vorgänge mit unterschiedlichen Folgen. Eine Gerätebindung kann Datenverkehr aus einer Schnittstelle zwingen und die normale Routensuche für diesen Socket umgehen. Eine Quelladressbindung durchläuft weiterhin die Routenauswahl, aber die gewählte Quelle kann einer policybasierten Regel entsprechen und das Paket woandershin schicken. Der Unterschied klingt akademisch, bis eine Regel nach Quelle routet. Dann entscheidet sie alles.

Ein Netzwerk-Namespace ist der dritte Fall. Er hat eigene Schnittstellen und eine eigene Routing-Tabelle, daher wird eine Anwendung darin vom Standard des Hosts gar nicht beeinflusst. Behandelt man alle drei als dasselbe, entstehen selbstsichere Erklärungen, die den ersten Test nicht überstehen.

Feststellen, was die App tatsächlich setzt

Lesen Sie die Netzwerkkonfiguration der Anwendung oder ihr dokumentiertes Verhalten, bevor Sie Routen anfassen. Bietet sie eine Schnittstellenwahl, ein Feld für die Quelladresse oder eine Namespace-Option, ist diese Einstellung das Erste, was zu prüfen ist. Andernfalls kann die Bindung intern sein und nur über Tracing oder ihre eigene Diagnose sichtbar werden.

Unter Linux haben Socket-Optionen wie SO_BINDTODEVICE einen dokumentierten Umfang und Berechtigungsanforderungen, und ein unprivilegierter Prozess kann sie möglicherweise gar nicht setzen. Diese Einschränkung ist ein nützlicher Hinweis: Lässt sich die Option nicht anwenden, ist die Anwendung wahrscheinlich nicht die Ursache des Unterschieds.

Politik-Routing liest die Quelle

Ist Politik-Routing konfiguriert, kann eine Regel eine Tabelle anhand der Paketquelle wählen. Ein Socket, der eine Quelladresse bindet, kann daher einer Regel folgen, die der Standardweg nie berührt, selbst wenn keine Schnittstelle ausdrücklich genannt ist.

Wiederholen Sie die Suche mit derselben Adressfamilie, Quelle und demselben Namespace, die die Anwendung verwendet. Eine allgemeine Routensuche aus einer Shell im Namespace des Hosts beantwortet eine andere Frage, und diese Diskrepanz ist der häufigste Grund, warum eine funktionierende Route defekt aussieht.

Split-Tunneling und Hilfsprozesse

Split-Tunneling pro App fügt eine weitere Ebene hinzu. Der Client kann das Paket oder den Prozess der Anwendung abgleichen, und ein Helfer, der einen eigenen Socket öffnet, ist ein eigenes Subjekt. Ein Launcher und sein Hintergrunddienst können unter demselben sichtbaren Namen unterschiedliche Verbindungen erzeugen.

Prüfen Sie, ob die Split-Tunnel-Regel den Prozess abdeckt, der tatsächlich verbindet. Bindet die App an eine bestimmte Schnittstelle und gleicht der VPN-Client nach Paket ab, können die beiden Entscheidungen auseinandergehen, ohne dass eine falsch ist.

Den eigenen Weg der App testen

Starten Sie nach jeder Änderung eine neue Anfrage aus der Anwendung. Ein Browser, der den gewünschten Ausgang zeigt, ist kein gleichwertiger Beleg für ein anderes Programm, das an eine andere Schnittstelle gebunden ist, und zwischengespeicherte Verbindungen können den alten Weg noch lange nach einer Einstellungsänderung nutzen. Schließen Sie die alte Sitzung, bevor Sie die neue Regel beurteilen. Sonst misst der Test die Vergangenheit.

Die Linux-Socket-Referenz dokumentiert SO_BINDTODEVICE und seine Anforderungen. Lesen Sie zuerst die eigene Konfiguration der Anwendung, wiederholen Sie die Suche im selben Kontext und entscheiden Sie erst dann, ob die Route oder die Bindung geändert werden muss.