Nur Einschluss oder nur Ausschluss: Welche Vorgabe?
Wählen Sie die Vorgabe, bevor Sie die Liste aufbauen: nur tunneln, was Sie benennen, oder alles tunneln und Ausnahmen herausschneiden. Testen Sie danach die App, die niemand eingetragen hat.
Öffnen Sie den Routing-Abschnitt Ihres VPN-Clients, und Sie sehen zwei unterschiedlich geformte Steuerelemente, die oft dieselbe Bezeichnung tragen. Das eine fordert Sie auf, die Ziele aufzulisten, die in den Tunnel gehören, und alles andere nutzt weiterhin das lokale Netzwerk. Das andere setzt voraus, dass alles getunnelt wird, und fragt, was wieder herausgenommen werden soll. Beide liefern beim ersten Test einen funktionierenden Tunnel, und beide werden gepflegt, indem man Zeilen zu einer Liste hinzufügt, weshalb der Unterschied unsichtbar bleibt, bis jemand etwas Neues installiert.
Die Wahl ist eine Vorgabe, keine Funktion. Legen Sie sie fest, bevor die Liste zwanzig Einträge hat.
Die Vorgabe am Client ablesen, nicht im Prospekt
WireGuard macht die Entscheidung ungewöhnlich sichtbar, weil AllowedIPs eine Einschlussliste und sonst nichts ist. Ein Peer mit 0.0.0.0/0, ::/0 tunnelt alles; ein Peer mit 10.20.0.0/16 tunnelt nur das. Eine Ausschlusssyntax gibt es nicht, wer also ein Subnetz auslassen will, muss entweder alle anderen Präfixe aufzählen oder außerhalb der Schnittstelle Policy-Routing ergänzen.
OpenVPN erreicht dasselbe Ziel aus der anderen Richtung: redirect-gateway def1 baut einen vollständigen Tunnel auf, und explizite route-Direktiven fügen bestimmte Präfixe hinzu oder überschreiben sie. Kommerzielle Clients verbergen beides meist hinter einem Kontrollkästchen und einer Zieltabelle, lesen Sie also, welche der beiden die Tabelle tatsächlich bearbeitet, bevor Sie der Bezeichnung trauen.
Die Frage ist nicht, wie das Kontrollkästchen heißt. Die Frage ist, was mit einem Paket geschieht, dessen Ziel in keiner der beiden Listen steht. Beantworten Sie das schriftlich, und der Rest der Konfiguration ergibt sich daraus. Wer die Frage überspringt, überlässt die erste unerklärte Störung demjenigen, der an diesem Tag gerade am nächsten am Client sitzt.
Einer Anwendung folgen, die niemand eingetragen hat
In einem reinen Einschluss-Design geht diese Anwendung direkt über das lokale Netzwerk, mit dem lokalen DNS. In einem reinen Ausschluss-Design läuft sie durch den Tunnel, soweit der Server es zulässt, und genau das entscheidet oft darüber, ob ein neues SaaS-Werkzeug am ersten Tag funktioniert oder ob ein Ticket eingeht, dass das VPN es kaputt gemacht habe.
Keine der beiden Vorgaben ist für sich sicherer. Einschluss verengt, was der Tunnel trägt, und macht das lokale Netz zum Weg des geringsten Widerstands; Ausschluss nimmt den Tunnel als Normalfall und behandelt Ausnahmen als Ausnahmen, was dem näher kommt, was die meisten Unternehmensrichtlinien tatsächlich beabsichtigen.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Achten Sie darauf, welche Art von Objekt die Plattform auflistet
Die VpnService.Builder von Android stellt eine Liste erlaubter und eine Liste unerlaubter Anwendungen als zwei getrennte Modelle bereit, und App-Regeln wählen nach Paket statt nach Ziel. Ein Browser in einer solchen Liste trägt jedes Ziel mit, das er öffnet, was eine andere Granularität als eine Routentabelle ist und eine einzelne kaputte Website innerhalb einer funktionierenden App nicht reparieren kann.
Desktop-Clients mischen beide Arten meist in einer Oberfläche, prüfen Sie also, ob die Zeile, die Sie hinzufügen, ein Paket, ein Hostname oder ein Präfix ist. Sie scheitern auf verschiedene Weise, und sie werden an verschiedenen Stellen aufgelöst. Eine Hostname-Zeile wird meist zu einer Route plus einem Namen, während eine Paketzeile zu einer Richtlinienentscheidung im Client wird. Notieren Sie, welche der beiden Sie hinzugefügt haben, denn wer das später debuggt, wird die jeweils andere annehmen.
Den Fehlerfall testen, nicht nur den Normalfall
Eine Anwendung, die vom Tunnel ausgenommen ist, bekommt nicht automatisch sauberen direkten Zugang. Erzwingt der Client zusätzlich eine Regel, die ohne VPN blockiert, kann der ausgenommene Verkehr ganz verworfen werden, was wie eine kaputte App aussieht und nicht wie eine Routing-Entscheidung. Testen Sie diesen Fall gezielt, statt ihn aus einer Nutzermeldung zu erfahren.
Prüfen Sie dann DNS und IPv6 als getrennte Punkte. Ein Tunnel, der nur IPv4 trägt, lässt einer v6-fähigen Anwendung einen Weg daran vorbei, und Split-DNS entscheidet, ob interne Namen für Verkehr aufgelöst werden, der gar nicht getunnelt wird. Führen Sie eine gelistete App, eine nicht gelistete App, eine Namensauflösung und eine Wiederverbindung aus, und bewahren Sie die Ergebnisse zusammen mit der Konfiguration auf.
Die Vorgabe dort notieren, wo die nächste Person sie findet
Halten Sie die gewählte Vorgabe, die Ausnahmen und ihre Verantwortlichen am selben Ort wie das Client-Profil fest, denn die nächste Administration trägt einen Eintrag ein, ohne diese Begründung zu lesen. Notieren Sie Datum und Grund jeder Ausnahme, damit eine veraltete Ausnahme für eine inzwischen reparierte Website sicher entfernt werden kann. Eine Liste ohne Begründungen wächst ewig.
Wenn jemand ein einziges kaputtes Ziel meldet, ändern Sie die Ausnahme und nicht die Grundlage. Die Vorgabe umzudrehen, um eine einzelne Website zu retten, verschiebt stillschweigend jede nicht gelistete Anwendung auf die andere Seite des Tunnels.