Split-Tunnel-Dokumentation braucht eine DNS-Regel neben jeder Route
Eine Route entscheidet nach Adresse, ein Resolver nach Name. Dokumentieren Sie beide Selektoren pro Fluss, jeden mit einem Test, sonst scheitert die Notiz, wenn sich DNS verschiebt.
Eine Split-Tunnel-Notiz, die sagt "Office-Verkehr geht durch das VPN", hat eine Entscheidung dokumentiert und drei weitere impliziert. Auf der Paketebene wählt eine Routing-Tabelle eine Schnittstelle nach Zieladresse; auf der Namensebene wählt ein Resolver einen Server nach Abfrage, und die beiden Entscheidungen werden unabhängig getroffen. Deshalb kann ein korrekt dokumentiertes Präfix immer noch eine Maschine erzeugen, die einen internen Namen zu einer öffentlichen Adresse auflöst oder gar nichts auflöst, während die Route perfekt aussieht.
Zwei Selektoren, ein Verbindungsversuch
Wenn eine Anwendung eine Verbindung zu files.corp.example aufbaut, finden zwei Abfragen statt, bevor ein Paket existiert. Der Resolver entscheidet, welcher Server die Abfrage erhält, anhand von Suchdomänen, Routing-Domänen pro Link oder einer expliziten Profilregel. Die Routing-Tabelle entscheidet dann, wohin die resultierende Adresse geht, anhand der längsten Präfixübereinstimmung mit dem Ziel.
Nichts verbindet diese beiden Entscheidungen. Eine private Zone kann mit 10.20.4.11 antworten, während die Routing-Tabelle 10.20.0.0/16 in den Tunnel schickt, und die Verbindung funktioniert. Drehen Sie eines von beiden um, und es scheitert auf eine Weise, die wie das andere aussieht: richtige DNS-Richtlinie plus fehlende Route ergibt einen aufgelösten Namen und einen Timeout, während eine richtige Route plus öffentlicher Resolver eine Adresse ergibt, die sauber an die falsche Stelle routet.
Split-Horizon-DNS macht das schärfer. Derselbe Name kann eine private Adresse vom internen Resolver und eine öffentliche Adresse vom internetzugewandten zurückgeben, sodass eine Notiz, die nur das Präfix festhält, nicht vorhersagen kann, welche Adresse der Client tatsächlich verwendet. Schreiben Sie den Resolver-Pfad auf, sonst ist die Adresse eine Vermutung.
Was eine Notiz nur über die Route auslässt
Ein Eintrag nur über die Route ist für den häufigsten Split-Tunnel-Fehler unbrauchbar: Namen. Der Benutzer meldet, dass das Intranet nicht lädt, der Tunnel steht und das Präfix vorhanden ist. Wer das Ticket übernimmt, hat keinen Eintrag, welcher Resolver hätte antworten sollen, keine Möglichkeit, ein falsches Suchsuffix von einem blockierten Server zu unterscheiden, und keine Vergleichsgrundlage.
Die zweite Auslassung ist die Ausnahmeliste. Ein Split-Tunnel-Design wird ebenso sehr dadurch definiert, was außerhalb des Tunnels bleibt, wie dadurch, was hineingeht, und die ausgeschlossenen Bereiche sind meist die, die zuerst brechen, weil eine spezifischere lokale Route oder ein clientseitiger Filter die Absicht überschreiben kann, ohne das Profil zu berühren.
Die dritte ist die ferne Seite des Tunnels. Eine Client-Route bringt das Paket nur auf die Leitung; das Gateway muss es weiterhin weiterleiten und einen Rückweg haben. strongSwans Anleitung zum Weiterleiten erinnert daran, dass Weiterleitungs- und Firewall-Regeln am Gateway Teil der Funktion sind, nicht Teil der Sanitärinstallation, die man voraussetzen kann.
Die Felder, die die Notiz ausführbar machen
Eine Zeile pro Fluss, und ein Fluss ist ein Ziel plus ein Name plus ein Eigentümer. Das sind die Felder, die den Kontakt mit einem echten Vorfall überstehen:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Die Zeile "wo sie lebt" ist die, die Leute überspringen. Ein vom Server geschobenes Präfix, eine vom Client-Profil hinzugefügte Route und eine in eine Shell getippte Route unterscheiden sich darin, wer sie ändern kann und ob sie eine Neuverbindung überstehen. Ohne dieses Feld kann der nächste Ingenieur nicht sagen, welche der drei er vor sich hat.
Ein Test pro Regel, nicht einer pro Tunnel
Jede Zeile braucht zwei harmlose Prüfungen: eine, die die Route ausübt, und eine, die den Namen ausübt. Für die Route fordern Sie etwas an, das den Tunnel überqueren muss, und bestätigen Sie den Pfad statt der Erreichbarkeit, zum Beispiel tracert -d 10.20.4.11 unter Windows oder ip route get 10.20.4.11 unter Linux. Für den Namen fragen Sie den privaten Namen ab und halten Sie fest, welcher Server geantwortet hat, mit resolvectl query files.corp.example oder dig files.corp.example gegen den Resolver, den die Notiz nennt.
Fügen Sie auch eine negative Erwartung hinzu: was passieren soll, wenn der Tunnel down ist. Eine ausgeschlossene Anwendung auf einem Android- oder iOS-Gerät mit aktiviertem Blockieren ohne VPN hat möglicherweise überhaupt keine Konnektivität, und ein Desktop-Client kann dieselbe App weiterlaufen lassen, während der Tunnel neu verbindet. Die beabsichtigte Antwort festzuhalten macht aus "das VPN hat meine App kaputt gemacht" eine prüfbare Aussage.
Bewahren Sie den Eintrag bei der Konfiguration auf
Speichern Sie die Notiz neben dem Profil, das sie beschreibt, und versionieren Sie sie mit diesem Profil. Ein Dokument in einem Wiki, das niemand aktualisiert, ist ein Gerücht; eine Tabelle im selben Repository wie die geschobenen Routen und die Resolver-Richtlinie kann in derselben Änderung geprüft werden.
Wenn etwas kaputtgeht, vergleichen Sie die angewendete Route und den effektiven Resolver mit dem Eintrag, bevor Sie eine weitere Ausnahme hinzufügen. Zwei der drei häufigen Ursachen — eine alte Namespace-Regel und ein Hilfsprozess außerhalb der App-Richtlinie — sehen genau wie ein VPN-Fehler aus und sind unsichtbar, wenn die Notiz nur Präfixe auflistet.
Bevor Sie die Notiz als fertig bezeichnen, bestätigen Sie, dass sie diese Punkte schriftlich beantwortet: welches Präfix, für welche Adressfamilie; welcher private Namespace, von welchem Resolver beantwortet; welche Namen bewusst öffentlich bleiben; wo jede Regel konfiguriert ist und wem sie gehört; und der eine Befehl, der die Route beweist, und der, der den Namen beweist. Fehlt etwas davon, wird der nächste Vorfall von Grund auf diagnostiziert.