Ist vollständiges Tunneling einfacher als eine lange Split-Tunnel-Liste?

Eine Split-Tunnel-Liste beginnt mit drei Anwendungen und deckt am Ende den größten Teil des Rechners ab, und jede neue Zeile ist jemandes Ausnahme. An diesem Punkt ist die Liste still zu einer Voreinstellung mit zusätzlichen Schritten geworden. Vollständiges Tunneling kehrt die Anordnung um: Alles geht in den Tunnel, sofern eine dokumentierte Ausnahme nichts anderes sagt. Ob das einfacher ist, hängt vom Gateway und von den lokalen Diensten ab, die Sie kaputt machen würden.

Zählen Sie zuerst die Regeln, die Sie pflegen

Zählen Sie die Einträge und dann, wie viele davon einen benannten Eigentümer und ein Datum der letzten Prüfung haben. Die zweite Zahl ist die entscheidende, denn eine Ausnahme, die niemand besitzt, lässt sich nicht bewerten, wenn die Software, auf die sie verweist, umbenannt oder ersetzt wird. Regeln, die an einen ausführbaren Pfad gebunden sind, versagen nach einem Update stillschweigend, und der Fehler sieht nach einem unzuverlässigen VPN aus statt nach einer veralteten Regel. Schreiben Sie die Liste auf, bevor Sie sich eine Meinung dazu bilden.

Jeder Eintrag sollte drei Fragen beantworten: Was bricht ohne ihn, wer hat das entschieden, und wie würden Sie merken, dass der Grund entfallen ist. Einträge, die nicht alle drei beantworten können, sind Löschkandidaten statt Migrationskandidaten, und sie zuerst zu löschen macht den späteren Vergleich ehrlich.

Wenn die meisten Einträge einen großen Anteil des Verkehrs routen, betreiben Sie bereits einen vollen Tunnel mit angehängtem Wartungsaufwand. Die Entscheidung geht dann darum, wo die Voreinstellung lebt, nicht darum, ob es eine geben soll.

Prüfen Sie, ob das Gateway die Voreinstellung tragen kann

Vollständiges Tunneling schickt jedes Paket zu einem Gerät, was gleichzeitig dessen CPU-Last, die conntrack-Tabelle, die Adressübersetzung und den Bedarf an Upstream-Bandbreite verändert. Ein Gateway, das einige interne Subnetze bequem bediente, ist vielleicht nicht für das gesamte Browsing eines Nutzers dimensioniert. Schauen Sie auf die größte erwartete Zahl gleichzeitiger Sitzungen statt auf den Durchschnitt, denn die Spitze bricht zuerst.

ip -s link show dev tun0
conntrack -C
ss -s

Messen Sie die gleiche Last vor und nach der Änderung, statt aus Spezifikationen zu schließen. Ein einzelner Nachmittag gewöhnlicher Nutzung auf einem Rechner zeigt, ob das Gateway nahe an einer Grenze liegt, und das kostet nichts im Vergleich dazu, es an einem Montagmorgen zu entdecken.

Prüfen Sie auch die Pfad-MTU von Ende zu Ende, denn eine volle Voreinstellung setzt jede Anwendung der maximalen Paketgröße des Tunnels aus. Anwendungen, die außerhalb des Tunnels funktionierten, hängen nun vielleicht von Fragmentierungsverhalten ab, über das Sie nie nachdenken mussten.

Bestätigen Sie, dass lokale Dienste und privates DNS noch funktionieren

Zählen Sie auf, was lokal bleiben muss, und zwar nach Protokoll statt nach Anwendungsnamen: Discovery-Protokolle für Drucker und Displays, eine Smart-Home-Brücke, die Verwaltungsseite eines Routers, ein lokaler Entwicklungsserver, der über einen Namen erreichbar ist, der nur im LAN aufgelöst wird. Das bricht, wenn die Standardroute beginnt, in einen Tunnel zu zeigen, und es bricht leise, weil beim Client nichts einen Fehler protokolliert.

Privates DNS ist die andere Abhängigkeit. Wurden interne Namen bisher vom Resolver des Tunnels aufgelöst, ändert sich nichts; wurden sie lokal aufgelöst, muss eine volle Voreinstellung sie zu einem Resolver bringen, der die Zonen kennt. Testen Sie nach der Änderung einen internen und einen öffentlichen Namen, statt anzunehmen, die Resolverliste habe überlebt.

Schreiben Sie die lokalen Ausnahmen in das Profil, dem sie gehören. Eine Ausnahme, die nur im Kopf von jemandem steht, ist das Erste, was die nächste Migration verliert.

Migrieren Sie ein Profil und verifizieren Sie die Grenzen

Ändern Sie das Profil über seine eigene Konfiguration, statt eine neue Voreinstellung über manuelle Routen zu legen, die frühere Experimente hinterlassen haben. Diese Restrouten sind die übliche Ursache einer Migration, die zu funktionieren scheint und sich einen Tag später inkonsistent verhält. Halten Sie das alte Profil verfügbar, damit ein Rollback eine Auswahl ist und kein Neubau.

Prüfen Sie dann zwei Grenzen getrennt: dass öffentliche und private Ziele beide funktionieren und dass unerwünschter Verkehr den Tunnel nicht verlässt. Ein erfolgreicher Seitenaufruf beweist das Erste und sagt nichts über das Zweite.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Wiederholen Sie die Prüfung nach einem Reconnect und nach einem Ausfall, denn ein Kill Switch, der Verkehr während eines Ausfalls blockiert, ist eine andere Eigenschaft als eine Route, die danach korrekt wiederhergestellt wird. Das einfachere Design ist das, dessen tatsächliche Abdeckung Sie noch erklären können, nachdem sich eine Anwendung oder ein Netz geändert hat.