Kill-Switch auf dem Router für FORWARD, OUTPUT und IPv6

Sie melden sich am Router an, fügen einen Kill-Switch-Regelsatz aus einem Forenbeitrag ein, und im LAN ist kein Surfen mehr möglich, sobald der Tunnel ausfällt. Zwei Tage später aktualisiert der Router seinen dynamischen DNS-Eintrag noch immer über das gewöhnliche WAN, und das Gästelaptop erreicht weiterhin IPv6-Seiten. Beides ist normal, denn die eingefügten Regeln deckten eine Kette und eine Adressfamilie ab, und keine davon ist der ganze Router. Geht man die Paketpfade der Reihe nach durch, zeigt sich genau, was fehlte.

Am Router ansetzen, nicht am Laptop

Eine Richtlinie auf Routerebene ist für ein kleines Büro attraktiv, weil jedes Gerät dahinter dasselbe Verhalten erbt und niemand vergessen kann, einen Client-Schalter zu aktivieren. Sie bietet außerdem eine einzige Stelle zum Testen nach jedem Firmware-Update. Was sie nicht bietet, ist eine automatische Abdeckung des eigenen Verkehrs des Routers oder einer zweiten Adressfamilie, und genau das sind die zwei Lücken hinter den meisten gescheiterten Einsätzen.

Notieren Sie vor jeder Änderung drei Angaben auf Papier: den Namen der WAN-Schnittstelle, den Namen der LAN-Bridge und die Adresse und den Port des VPN-Endpunkts. Sie brauchen alle drei in den Regeln, und das Raten von Schnittstellennamen ist der häufigste Grund, warum ein korrekt aussehender Regelsatz nichts bewirkt.

Die drei Wege eines Pakets durchgehen

Verkehr von einem Laptop ins Internet wird weitergeleitet und passiert daher die FORWARD-Kette. Verkehr, den der Router selbst erzeugt, etwa DNS-Weiterleitung, NTP-Abfragen, DDNS-Aktualisierungen und der VPN-Kontrollkanal, passiert OUTPUT. Verwaltungsverkehr, der an den Router adressiert ist, kommt über INPUT an.

Ein nur in FORWARD gebauter Kill-Switch schützt also die Clients und sonst nichts. Die Tabelle zeigt, warum das Leck aus der Eingangsszene vorhersehbar und nicht rätselhaft ist.

In den meisten Entwürfen brauchen Sie keinen Kill-Switch auf INPUT, aber Sie müssen den Verwaltungszugang am Laufen halten, während der Tunnel unten ist. Sonst fahren Sie beim ersten VPN-Ausfall mit einem Konsolenkabel ins Büro.

Regeln so ordnen, dass der Tunnel noch hochkommt

Ein funktionierender Kill-Switch ist eine Positivliste, die mit einem Reject endet, und die Reihenfolge macht ihn zum Kill-Switch statt zum Ziegelstein. Erlauben Sie zuerst Loopback, den VPN-Endpunkt, Antworten für bestehende Flüsse und die Tunnel-Schnittstelle; verwerfen Sie den Rest zuletzt.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Der Endpunkt muss an dieser Stelle eine Adresse sein, kein Hostname. Sobald das abschließende Reject DNS blockiert, lässt sich eine Regel, die den Hostnamen des Anbieters nennt, nicht mehr auflösen, und der Tunnel startet nach einem Neustart nie wieder. Wenn der Anbieter Endpunkte wechselt, lösen Sie den Namen auf, bevor die Richtlinie angewendet wird, und aktualisieren Sie diese Regel aus demselben Skript.

Spiegeln Sie die Form in FORWARD für den Client-Verkehr und setzen Sie eine ausdrückliche Verwaltungsregel über das Reject. Halten Sie diese Verwaltungsregel eng, aber erreichbar, und bestätigen Sie sie, indem Sie eine zweite SSH-Sitzung öffnen, bevor Sie die erste schließen. Sich während einer Kill-Switch-Änderung auszusperren ist häufig genug, um es einzuplanen. Auf einem Router mit WireGuard entscheiden die allowed-ips des Peers darüber, was in den Tunnel gelangt, während diese Regeln entscheiden, was ohne ihn hinausdarf.

IPv6 braucht eine eigene Tür

Alles oben ist IPv4. Wenn Ihr LAN funktionierendes IPv6 hat und der Tunnel nur IPv4 transportiert, hat jedes abgedeckte Gerät weiterhin eine direkte Route ins Internet, die Ihre neuen Regeln nie sehen. Ein Dual-Stack-Laptop bevorzugt sie ohne Zögern, und der Kill-Switch wirkt nur für die Person defekt, die mit IPv4 testet.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Auch hier zählt die Reihenfolge: Das Loopback-Accept muss vor dem WAN-Reject stehen, sonst beginnen lokale Dienste auf dem Router auf seltsame Weise zu scheitern. Wenn das Netzwerk überhaupt kein IPv6 nutzt, ist das Abschalten an WAN und LAN einfacher und lässt nichts zu vergessen übrig.

Manche VPN-Clients installieren eine Standardroute nur für IPv4 und lassen die vorhandene IPv6-Standardroute unberührt. Prüfen Sie die Routingtabelle, nachdem der Tunnel verbunden ist, statt anzunehmen, der Client habe das erledigt.

Den Nachweis mit gestopptem Tunnel führen

Stoppen Sie den Tunnel vom Router aus und testen Sie in dieser Reihenfolge von drei Stellen aus:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Die Routensuche zeigt, wohin ein Paket gehen würde, und die Zähler zeigen, ob Ihre Regeln jemals gegriffen haben. Eine Regel mit null Paketen nach einem fehlgeschlagenen Test schützt nichts, und die übliche Ursache ist ein Schnittstellenname, der von dem eingegebenen abweicht. Testen Sie den vom Router erzeugten Verkehr ausdrücklich, denn ein Test von der LAN-Seite kann OUTPUT nicht auslösen.

Entscheiden Sie den Fehlermodus, bevor Sie ihn brauchen. Fail-closed hält die Clients offline, bis der Tunnel zurückkehrt; Fail-open stellt den gewöhnlichen WAN-Zugang wieder her und untergräbt den Zweck für den Verkehr, der Ihnen wichtig war. Eine Blackhole-Route zum VPN-Pool mit hoher Metrik ist eine nützliche zweite Schicht für Fail-closed-Entwürfe, da sie überlebt, wenn die Tunnelroute verschwindet, statt auf die Standardroute zurückzufallen.

Akzeptieren Sie die Einrichtung erst, wenn ein LAN-Client, eine vom Router erzeugte Anfrage und eine IPv6-Anfrage bei gefallenem Tunnel alle scheitern und alle drei wieder funktionieren, sobald er steht.