Split-Tunnel schließt den Browser aus, nicht seine DNS-Anfragen

Browser vom Tunnel ausgeschlossen, die Seite mit der öffentlichen IP bestätigt, dass sein Verkehr über die Heimverbindung hinausgeht, und das interne Wiki öffnet sich trotzdem nicht. Die Namensauflösung ging woandershin, und dieses Woanders ist meist der Resolver, den das VPN eingerichtet hat. Datenpfad und Resolverpfad sind in den meisten Split-Tunnel-Entwürfen getrennte Entscheidungen. Prüfen Sie, welchen der Browser tatsächlich benutzt hat, bevor Sie den Ausschluss als defekt bezeichnen.

Datenpfad und Resolverpfad trennen sich

Ein Ausschluss entfernt die Pakete einer Anwendung aus dem Tunnel, was eine Routing- und Firewall-Entscheidung auf dem Datenpfad ist. Namensauflösung ist ein anderer Nachschlag: Ein Prozess fragt den Resolver des Systems, und dieser Resolver entscheidet, welcher Server die Frage erhält.

Beides kann absichtlich und verschieden sein. Ein Arbeits-Deployment kann interne Namensräume beim Unternehmens-Resolver belassen, während ausgewähltes öffentliches Surfen außerhalb des Tunnels gesendet wird, gerade weil interne Namen nirgendwo sonst aufgelöst werden. Der verwirrende Fall ist der umgekehrte: Eine öffentliche Website scheitert, weil der Browser nie den Resolver fragte, den das Deployment erwartete. Notieren Sie Route und Resolver getrennt, und die Hälfte der Diskussionen verschwindet.

Finden Sie, welcher Prozess die Frage stellt

Ein Browser kann den Resolver des Systems, seinen eigenen verschlüsselten DNS-Dienst oder einen Resolver nutzen, den das Betriebssystem pro Netzwerk zuweist. Der erste folgt der Plattformrichtlinie, der zweite umgeht diese Richtlinie vollständig, und der dritte hängt davon ab, auf welche Verbindung die Anfrage geroutet wird.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Lesen Sie die wirksame Konfiguration, bevor Sie testen: welche Verbindungen DNS-Server tragen, welche Namensräume sie beanspruchen und ob eine Richtlinie pro Name den Standard überschreibt. Unter Linux nutzt Split-DNS Routing-Domänen; unter Windows leistet die Namensauflösungs-Richtlinientabelle dasselbe für Namensräume. Beides ist auf einer Leak-Test-Seite nicht sichtbar.

Entscheiden Sie, welcher Resolver welchen Namen sieht

Schreiben Sie die beabsichtigte Zuordnung auf, bevor Sie etwas ändern: interne Namen zum Unternehmens-Resolver, öffentliche Namen zu dem Dienst, den die Richtlinie erlaubt, und Ausnahmen mit einem Verantwortlichen. Ohne diese Liste wird jedes Etikett des Leak-Tests zu einer Richtlinienfrage, die niemand entscheiden kann.

Prüfen Sie dann die eigene Einstellung des Browsers, denn verschlüsseltes DNS im Browser wird angewendet, bevor das Betriebssystem die Anfrage erhält. Ein Nutzer, der es aktivierte, um ein Captive Portal zu umgehen, hat still den Resolver überschrieben, den das Deployment gewählt hat. Das ist eine Konfigurationsentscheidung und kein Leck, und sie verdient eine Entscheidung statt einer Sperrliste.

Schreiben Sie nicht jedes DNS-Feld neu, damit ein Testetikett grün wird. Das Etikett beschreibt eine Anfrage eines Prozesses zu einem Zeitpunkt.

Prüfen Sie Anfrage und Verbindung getrennt

Testen Sie beide Pfade unabhängig. Der Verbindungstest zeigt die Datenroute, und der Resolver-Test zeigt, wer den Namen erhielt.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Fragen Sie den Resolver auch ausdrücklich, damit ein Fehler dem Server und nicht dem Pfad zugeschrieben werden kann. Starten Sie dann den Browser neu und wiederholen Sie, denn Anwendungen cachen negative Antworten, und ein alter Fehler wirkt dauerhaft.

Notieren Sie nach einer genehmigten Änderung die Datenroute und den Empfänger des Resolvers als zwei getrennte Zeilen mit dem Datum. Kehrt das Verhalten bei der nächsten Verbindung zurück, ist das Profil zu korrigieren, das es liefert, nicht der Browser.