Ein Gerät durch ein Router-VPN braucht drei Regeln, keinen Schalter

Auf einem Router-VPN gibt es keinen Schalter pro Gerät; der Schalter, den Sie suchen, ist eine Abkürzung, die Policy-Routing-Regeln für Sie schreibt. In dem Moment, in dem ein Laptop, ein Portbereich, eine Adressliste oder ein LAN-Segment durch den Tunnel muss, während alles andere im WAN bleibt, bauen Sie eine Policy-Route statt eine Funktion zu aktivieren. Die Aufgabe hat drei bewegliche Teile, und jedes scheitert anders: eine markierte Tabelle ohne Route sieht wie Stille aus, eine im falschen Chain gesetzte Marke sieht aus, als wäre nichts passiert, und eine fehlende NAT-Regel sieht wie ein Tunnel aus, der sich verbindet und nichts trägt. Zwei weitere Teile fehlen, weil sie nie in der Mangle-Regel auftauchen, nämlich DNS und IPv6.

Der Mythos: der Tunnel ist eine Client-Einstellung

Ein VPN-Client auf dem Router macht eine grobe Sache gut: er legt 0.0.0.0/0 in die Haupt-Routingtabelle und zeigt damit auf den Tunnel. WireGuard leitet das aus AllowedIPs ab, OpenVPN aus einem geschobenen redirect-gateway, und beide ändern den Pfad für jeden Host hinter dem Router. AllowedIPs zu verengen oder route-nopull hinzuzufügen ändert, was der Client installiert. Es ändert nicht, für wen die Installation gilt, denn der Client sieht nie Geräte. Er sieht nur Pakete.

Auswahl nach Quelle oder Ziel ist eine Routing-Entscheidung, gehört also zur Policy-Schicht des Routers: eine Mangle-Regel plus eine zweite Tabelle auf RouterOS, ein MARK plus eine ip rule auf OpenWrt oder DD-WRT, oder eine Firewall-Regel, deren Gateway der Tunnel ist, auf pfSense. Netgates WireGuard-Client-Rezept ist das, was Sie vor dem Raten lesen sollten, denn auf dieser Plattform müssen Gateway der Regel, Interface-Zuweisung und der Eintrag für ausgehendes NAT übereinstimmen, bevor ein einziger Client den Tunnel nutzt.

Die zweite Hälfte des Mythos ist der zweite Router. Eine weitere Box zu kaufen oder das Gerät in ein Gast-SSID zu verschieben funktioniert oft, und der Grund ist nicht die Hardware: es bringt das Gerät in sein eigenes Subnetz, was Ihnen den Quell-Selektor gibt, den die Firmware bereits versteht. Wenn Sie dieses Segment auf dem Router definieren können, den Sie besitzen, löst die Extra-Box ein Problem, das Sie nicht hatten.

Teil eins: ein Tunnel, der nicht die Standardroute ist

Fügen Sie auf RouterOS den Client ohne Standardroute hinzu und geben Sie dem Tunnel eine eigene Tabelle. Die erste Route ist die markierte Standardroute; die zweite ist die Fehlerhälfte.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

Die unreachable-Route ist der Grund, warum eine markierte Tabelle eine Ausnahmeliste in der Haupttabelle schlägt. Fällt der Tunnel aus, bekommen markierte Pakete sofort unreachable statt still auf das WAN zurückzufallen, sodass sich der Fehler in der Fehlermeldung der Anwendung zeigt und nicht auf einer Geolokalisierungsseite, die Sie eine Stunde später prüfen.

RouterOS 7 trennt, was 6.x zusammenhielt: Sie deklarieren die Tabelle mit /routing table add name=vpn fib und referenzieren sie dann per Name in der Route und in der Mangle-Regel. Ein 6.x-Snippet, das routing-mark inline setzt, ohne die Tabelle zu definieren, lädt sauber und trifft nichts. Der andere Klassiker sind zwei 0.0.0.0/1-Hälften oder zwei Standardrouten mit gleicher Distanz in einer Tabelle: der Kernel wählt eine, und das Verhalten kann sich nach einem Neustart ändern.

Teil zwei: markieren vor dem Routen-Lookup

Der Selektor entscheidet, welche Pakete in diese Tabelle gelangen. RouterOS beginnt meist mit einer Adressliste für Ziel-Policy oder einer Quelladresse für Geräte-Policy:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux-Firmware macht dasselbe mit einer Netfilter-Marke und einer Regel, die markierte Pakete in eine Tabelle lenkt, die Sie gefüllt haben:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Die Chain ist keine Stilfrage. Wenn ein Paket FORWARD erreicht, ist der Routen-Lookup bereits passiert, ein MARK oder DROP dort kann also nur umschreiben oder verwerfen. Die Marke muss in PREROUTING landen für weitergeleiteten Verkehr und in OUTPUT für Verkehr, den der Router selbst erzeugt, denn dort leben Router-DNS, NTP und Update-Prüfungen. Genau dieser Ausgangspfad ist der übliche Grund, warum ein vollständig getunnelter Aufbau in einem Leak-Test noch vom ISP-Resolver antwortet.

Geräte-Policy braucht einen Treffer, der nicht wandert. Reservieren Sie die Adresse im DHCP, oder treffen Sie ein Interface für ein dediziertes Segment; eine Adresse, die später auf ein anderes Gerät wandert, wendet den Tunnel still auf den falschen Client an. Eine Bridge pro SSID mit eigenem Subnetz ist die haltbarere Version derselben Idee, und sie gibt den IPv6-Regeln einen Ort zum Leben.

Teil drei: NAT, DNS und die LAN-Ausnahme

Verkehr, der durch den Tunnel hinausgeht, braucht eine Quelladresse, die die Gegenseite beantwortet. Begrenzen Sie die Übersetzung auf das Tunnel-Interface: out-interface=VPN_NAME auf RouterOS, -o tun0 auf Linux, ein passender Eintrag für ausgehendes NAT auf pfSense. Eine masquerade-Regel ohne diese Begrenzung schreibt Verkehr um, den Sie in Ruhe lassen wollten, und das Symptom ist, dass das nicht getunnelte Gerät seine öffentliche Adresse verliert.

Die LAN-Ausnahme erzeugt mehr Support-Threads als der Tunnel selbst. Hält die markierte Tabelle nur eine Standardroute, trifft ein Drucker- oder NAS-Ziel des ausgewählten Geräts diese Standardroute und verschwindet im Tunnel. Fügen Sie die LAN-Route derselben Tabelle hinzu oder schließen Sie das lokale Subnetz im Selektor aus; beides funktioniert, und die Ausnahme bleibt leichter korrekt, wenn Sie später VLANs hinzufügen.

DNS nimmt einen eigenen Weg. Abfragen, die der Router weiterleitet, stammen vom Router und folgen OUTPUT, nicht der Weiterleitungsmarke, sodass ein vollständig getunnelter Laptop weiterhin über den ISP auflösen kann. Richten Sie Clients auf einen über den Tunnel erreichbaren Resolver, oder markieren Sie den Port-53-Verkehr des Routers selbst, und prüfen Sie dann die aufgelöste Adresse, statt anzunehmen, die Antwort sei mit der Web-Anfrage gereist.

Wenn die Regel trifft, die App aber weiter das WAN nutzt

Ziellisten altern schlecht. Ein Name löst zu einer Adresse auf, die nicht auf der Liste steht, also nimmt die Anfrage das WAN, während jeder Test gegen die gelistete Adresse funktionierte. Aktualisieren Sie die Liste vom selben Resolver, den der Client nutzt, und bevorzugen Sie einen quellbasierten Selektor, wenn Sie wirklich den gesamten Verkehr eines Geräts wollen.

IPv6 ist der stille Bypass. Das Gerät hat eine zweite Adressfamilie mit eigener Standardroute und eigenem Regelsatz, und nur die IPv4-Adresse zu treffen ist halbe Politik. Wenden Sie denselben Selektor auf ip6tables oder das nftables-Äquivalent an, oder deaktivieren Sie IPv6 in diesem Segment bewusst statt zufällig.

Etablierte Verbindungen zählen ebenfalls. Ein conntrack-Eintrag, der vor der Änderung entstand, folgt dem alten Pfad, bis er abläuft, ein während der Bearbeitung offen gebliebener Browser sieht also genau wie eine Regel aus, die nie angewendet wurde. Öffnen Sie eine neue Verbindung oder leeren Sie den Zustand, bevor Sie die Policy beurteilen.

Mit zwei Geräten und einem Neustart prüfen

Testen Sie das Gerät, das getunnelt werden soll, und das, das nicht soll, und vergleichen Sie den zweiten Hop statt einer Geschwindigkeitszahl. Ein traceroute von jedem zeigt am zweiten Hop entweder das Tunnel-Gateway oder das ISP-Gateway; sehen beide gleich aus, tut die Marke oder die Tabelle nicht, was die Regel sagt. Verwenden Sie für den Test neue Verbindungen.

Dann starten Sie neu. Die Startreihenfolge ist der Punkt, an dem eine funktionierende Policy zu einer kaputten wird, denn der Client muss laufen, bevor die unreachable-Route installiert wird, und ein gespeicherter Snapshot, der den alten Regelsatz wiederherstellt, überschreibt Ihre Tabelle. Prüfen Sie, dass jede Regel in der gespeicherten Konfiguration steht und die markierte Standardroute nach dem Booten existiert, nicht nur nachdem Sie sie getippt haben.

Wenn etwas fehlschlägt, entfernen Sie zuerst die Marke und sehen Sie, ob normaler Verkehr zurückkehrt, dann entfernen Sie die Tabelle. Diese Reihenfolge sagt Ihnen, ob Sie ein Routing- oder ein Firewall-Problem jagen, und sie lässt den Haushalt mit einem funktionierenden Drucker zurück, während Sie die Arbeit beenden.