Downstream-Subnetz vs. Desktop-VPN: Transit ausschließen, nicht Apps
Eine Ausnahme pro Anwendung klassifiziert nur den lokalen Ausgang. Geräte hinter der Workstation brauchen ihre eigene Richtlinie für Eingang, Weiterleitung und Rückweg.
Eine Maschine, zwei Aufgaben, eine Firewall: ein Wi-Fi-Uplink, ein kleines Ethernet-Subnetz dahinter und ein Desktop-VPN-Client, der annimmt, alles, was die Maschine verlässt, sei lokal. Lokal gestartete Anwendungen verlassen die Maschine über den lokalen Ausgangspfad. Geräte hinter der Workstation kommen am Ethernet-Port an und brauchen eine Weiterleitungsentscheidung. Eine Ausnahme, die für den ersten Pfad geschrieben wurde, sieht den zweiten nie, und deshalb umgeht ein Browser den Tunnel, die Geräte aber nicht.
Zwei Paketpfade, eine Richtlinie
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
Die erste Zeile ist das, was die meisten Split-Tunneling-Anleitungen beschreiben. Die zweite ist eine Routerkonfiguration, die zufällig auf derselben Maschine liegt. Beides in ein mentales Modell zu verschmelzen ist der Fehler; sie teilen einen Kernel, aber keine Richtlinie. Zeichnen Sie beide Pfade, bevor Sie eine Regel ändern, und der Rest des Entwurfs folgt daraus, welcher Pfad fehlt.
Die Tabelle erklärt auch, warum eine Maschine einen Test bestehen und einen anderen nicht bestehen kann. Ein Browser auf der Workstation belegt den lokalen Pfad; ein Laptop am Ethernet-Port belegt den Weiterleitungspfad. Prüfen Sie eine Änderung mit beidem, sonst bleibt der zweite ungetestet, egal wie oft der Browser neu geladen wird.
Was eine Anwendungsausnahme tatsächlich klassifiziert
Eine Ausnahme pro Anwendung funktioniert meist dadurch, dass Pakete eines Prozesses oder eines Benutzers markiert werden und die markierten Daten dann außerhalb des Tunnels geroutet werden. Das ist ein Konstrukt für den lokalen Ausgang. Ein Paket von einem nachgelagerten Gerät hat keinen lokalen Prozess, also trifft es nie den Selektor, wie der Selektor auch aussieht.
Wie der Selektor auch aussieht: Die beiden Listen sind nicht dieselbe Liste, und genau das ist der Punkt. Der Linux-Leitfaden von Mullvad beschreibt Markierungen, die seine Firewall und Routing-Richtlinie verbrauchen, und seine Beispiele zielen auf den lokalen Ausgang; sie sind keine unterstützte Beschreibung eines Downstream-Routers. Wer sie kopiert, erhält eine Maschine, die glaubt, eine Ausnahme zu haben, während sie alles in den Tunnel weiterleitet.
Den Transitvertrag schreiben
Benennen Sie das Downstream-Quellpräfix und das Eingangsinterface gemeinsam und beschränken Sie dann dieses Präfix am Eingang. Ohne die Beschränkung kann jedes Gerät, das den Port erreicht, eine ausgenommene Adresse beanspruchen und über die Umgehung verlassen. Behandeln Sie es als zwei Fragen: Dürfen diese Hosts diesen Uplink überhaupt nutzen, und dürfen sie die Workstation oder die privaten Bereiche des Tunnels erreichen? Das sind zusätzliche Berechtigungen, keine Nebenwirkungen der Uplink-Wahl.
Weiterleitung erlauben, dann filtern. Das Linux-Gateway braucht aktivierte Weiterleitung, Regeln, die den beabsichtigten Verkehr in beide Richtungen zulassen, und entweder eine Rückroute stromaufwärts oder eine bewusst begrenzte Quellübersetzung. NAT allein wählt den Uplink nicht aus und gewährt keinen Durchgang durch einen Filter; es schreibt eine Adresse erst nach diesen Entscheidungen um.
Die Klassifizierung für Transit muss vor der Weiterleitungsrouten-Entscheidung erfolgen, also in der prerouting-Stufe und nicht in output. Eine nach der Entscheidung gesetzte Regel kann das Paket noch ändern, aber nicht mehr, wohin es bereits gesendet wurde.
Markierungen gehören der Anwendung, der sie gehören
Markierungswerte, Tabellennummern und Kettenprioritäten sind Teil der Richtlinie der VPN-Anwendung, keine zeitlosen Konstanten. Ein dauerhaftes Netz, das davon abhängt, eine Regel in eine Tabelle einzufügen, die ein anderes Programm neu erzeugt, bricht beim nächsten Update, meist während einer Neuverbindung und nicht zu einem günstigen Zeitpunkt.
Eine zweite Basiskette mit einem accept-Urteil hinzuzufügen hebt nicht zwangsläufig das drop einer späteren Kette auf. Basisketten haben Hooks und Prioritäten, und das erste Urteil in der Reihenfolge gewinnt; ein accept in einer Kette hebt kein drop auf, das eine andere Kette zuerst erreicht. Sehen Sie sich das vollständige Regelset und die Reihenfolge der Routing-Richtlinie an, nicht den einen Zähler, der gestiegen ist. Ein Zähler beweist, dass eine Regel lief, nie, dass ihr Urteil das angewandte war.
Integrieren oder das Subnetz verlegen
Die beiden Entwürfe unterscheiden sich darin, wer die Umgehung besitzt. Ein integrierter Entwurf hält eine Maschine und eine Richtlinie, zum Preis der Abhängigkeit vom Tabellen-Lebenszyklus der VPN-Anwendung und von Markierungen, die ihre Dokumentation ändern kann. Ein eigener Router für das nachgelagerte Netz beseitigt diese Abhängigkeit vollständig: Das Subnetz hat seinen eigenen Uplink, und die Workstation bleibt ein Client ohne Weiterleitungsrolle.
Wählen Sie den zweiten, wenn das nachgelagerte Netz durch VPN-Updates hindurch weiterlaufen muss, oder wenn niemand die integrierte Richtlinie nach jeder Veröffentlichung testen kann. Wählen Sie den ersten nur, wenn die Integration dokumentiert ist und jemand sie verantwortet.
Prüfen Sie die Grenze in vier Zuständen: verbunden, neu verbindend, bewusst blockiert und gestoppt. Prüfen Sie Namensauflösung und beide Adressfamilien in jedem davon, denn eine Umgehung, die DNS leakt, ist nicht die Ausnahme, die Sie entworfen haben. Der Test soll die genaue Grenze belegen, nicht nur, dass eine Seite geladen wurde.