Warum Ihre Split-Tunnel-Regel einen Dienst nicht mehr erfasst

Die Regel fixiert ein Präfix, und der Dienst ist umgezogen. Lesen Sie das Ziel, das die Anwendung wirklich nutzt, und reparieren Sie dann den Mechanismus, statt die Ausnahme zu erweitern.

Split-Tunneling scheitert meist auf eine von zwei Arten. Entweder umgeht Verkehr, der in den Tunnel gehört, diesen, oder Verkehr, der draußen bleiben soll, wird hineingezogen. Der Fehler mit der veralteten Regel ist die erste Art, und er ist die verwirrendere, weil die Regel genau wie geschrieben durchgesetzt wird. Geändert hat sich das Ziel: Der Dienst antwortet jetzt auf einer Adresse, die die Regel nie genannt hat, und am Tunnel ist nichts falsch.

Was die Regel festlegt und was DNS zurückgibt

Eine Split-Tunneling-Regel ist eine statische Aussage über Ziele, meist als Präfix, Route oder Adressliste formuliert. Sie wird beim Senden gegen das Ziel des Pakets geprüft. Ein Hostname ist eine Abfrage, die eine Menge von Adressen mit Lebensdauer und Cache zurückgibt, und die Antwort kann je nach Resolver, Abfragetyp und Minute abweichen.

Diese beiden Objekte verhandeln nie miteinander. Die Regel gleicht weiterhin das Präfix ab, das sie bekommen hat, der Dienst ändert weiterhin die Adresse, die er ausgibt, und die Lücke dazwischen wächst still. Deshalb zeigt sich das Symptom nach einer Anbietermigration oder einer Zertifikatserneuerung und nicht nach einer Konfigurationsänderung. Niemand hat den Tunnel bearbeitet, also schaut niemand auf den Tunnel, und die Diagnose wandert zur Anwendung statt zur Richtlinie.

Drei Wege, auf denen der Abgleich bricht

Der offensichtliche Fall ist ein umgezogener Dienst: Der Betreiber hat ihm eine neue Adresse gegeben, DNS ist gefolgt, die Ausnahme nicht. Der zweite ist eine Adressfamilie, die die Regel nie abgedeckt hat, was passiert, wenn ein Name plötzlich AAAA-Einträge liefert, die eine reine IPv4-Ausnahme ignoriert. Der dritte ist ein Unterschied beim Resolver: Eine interne Sicht und eine öffentliche Sicht können für denselben Namen verschiedene Adressen liefern, sodass die Adresse, die Ihre Anwendung nutzt, nicht die ist, mit der Sie getestet haben.

Eine zwischengespeicherte Verbindung ist eine vierte Variante und leicht zu übersehen. Die Anwendung spricht womöglich noch mit einer Adresse, die sie vor einer Stunde aufgelöst hat, was bedeutet, dass Ihre frische Abfrage und ihr offener Socket sich uneinig sind, wo der Dienst liegt.

Lesen Sie das Ziel, das die Anwendung tatsächlich nutzt

Fragen Sie das Betriebssystem und die Socket-Tabelle, nicht einen Browser-Tab. Die Abfrage beantwortet, worauf der Name gerade auflöst, und die Socket-Tabelle zeigt die Adresse, mit der der Prozess verbunden ist, die älter sein kann. Führen Sie beides aus, bevor Sie eine Theorie bilden, denn der Unterschied zwischen ihnen ist in etwa der Hälfte der Fälle selbst die Antwort.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Vergleichen Sie dann mit dem, was die Regel abdeckt. Fällt die aktuelle Adresse außerhalb der Ausnahme und schlägt die Anfrage weiterhin fehl, haben Sie die Ursache gefunden, ohne die Tunnelkonfiguration anzufassen. Ist die Anwendung mit einer Adresse verbunden, die zur Regel passt, und schlägt die Anfrage weiterhin fehl, liegt das Problem hinter dem Tunnel, und dies ist die falsche Untersuchung.

Reparieren Sie den Mechanismus, nicht das Symptom

Wenn das Produkt gepflegte, domainbasierte Steuerung unterstützt, nutzen Sie sie und befolgen Sie ihr dokumentiertes Aktualisierungs- und Geltungsverhalten. Das ersetzt eine statische Vermutung durch eine gepflegte Antwort, um den Preis, dass die Funktion wie dokumentiert funktionieren muss.

Wenn das Design auf einer statischen Liste beruht, geben Sie ihr einen Verantwortlichen und einen Aktualisierungsplan. Der Plan sollte sagen, wie die Adresse ermittelt wird, wer die Änderung genehmigt und wie schnell die Liste einer Anbietermigration folgen soll. Eine Liste ohne Verantwortlichen ist ein künftiger Ausfall mit bekannter Ursache.

Erweitern Sie die Ausnahme nicht auf ein großes benachbartes Netz, nur um jede Adresse zu erfassen, die Sie in einem kurzen Test gesehen haben. Das ist keine Reparatur; es ist eine dauerhafte Änderung der Sicherheitsgrenze, und sie lässt stillschweigend fremde Dienste den Tunnel umgehen, solange die Regel besteht.

Prüfen Sie beide Hälften der Absicht

Ein Split-Tunneling-Design hat zwei Absichten, und eine Reparatur sollte beide erhalten. Der geschützte Dienst muss durch den Tunnel gehen, und die ausgeschlossenen Kategorien müssen weiterhin außen herumgehen. Testen Sie eine frische Verbindung zum reparierten Ziel und dann eine Sache, die draußen bleiben soll.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Notieren Sie die neue Adresse, den gewählten Mechanismus und das Datum. Diese Notiz ist es, die die nächste Person davon abhält zu schlussfolgern, das VPN habe seine eigene Konfiguration willkürlich ignoriert.

Ähnliche Artikel