Kill switch på routern som täcker FORWARD, OUTPUT och IPv6

Du loggar in på routern, klistrar in en kill switch-regeluppsättning från ett foruminlägg, och LAN:et slutar surfa i samma stund som tunneln faller. Två dagar senare uppdaterar routern fortfarande sin dynamiska DNS-post över den vanliga WAN:en, och gästlaptopen når fortfarande IPv6-webbplatser. Båda beteendena är normala, eftersom reglerna som klistrades in täckte en kedja och en adressfamilj, och ingen av dem är hela routern. Att gå igenom paketvägarna i ordning visar exakt vad som missades.

Börja vid routern, inte vid den bärbara datorn

En policy på routernivå är attraktiv för ett litet kontor eftersom varje enhet bakom den ärver samma beteende och ingen kan glömma att slå på en klientbrytare. Den ger dig också en enda plats att testa på efter varje firmwareuppdatering. Det den inte ger dig är automatisk täckning av routerns egen trafik eller av en andra adressfamilj, och det är de två luckorna bakom de flesta misslyckade utrullningar.

Innan du ändrar något, skriv ner tre fakta på papper: namnet på WAN-gränssnittet, namnet på LAN-bron och VPN-slutpunktens adress och port. Du behöver alla tre i reglerna, och att gissa gränssnittsnamn är den vanligaste orsaken till att en regeluppsättning som ser korrekt ut inte gör något.

Gå igenom de tre vägar ett paket kan ta

Trafik från en bärbar dator till internet vidarebefordras, så den passerar FORWARD-kedjan. Trafik som routern själv genererar, som DNS-vidarebefordran, NTP-frågor, DDNS-uppdateringar och VPN:ens kontrollkanal, passerar OUTPUT. Administrationstrafik som riktas till routern kommer in genom INPUT.

En kill switch byggd bara i FORWARD skyddar därför klienterna och ingenting annat. Tabellen visar varför läckan i öppningsscenen är förutsägbar och inte mystisk.

I de flesta konstruktioner behöver du ingen kill switch på INPUT, men du måste hålla administrationsåtkomsten igång medan tunneln är nere. Annars kör du till kontoret med en konsolkabel första gången VPN:en misslyckas.

Ordna reglerna så att tunneln fortfarande kan komma upp

En fungerande kill switch är en tillåtelselista som slutar i en avvisning, och ordningen är det som gör den till en kill switch i stället för en tegelsten. Tillåt först loopback, VPN-slutpunkten, svar för etablerade flöden och tunnelgränssnittet; avvisa resten sist.

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

Slutpunkten måste vid det här laget vara en adress, inte ett värdnamn. När den slutliga avvisningen blockerar DNS kan en regel som namnger leverantörens värdnamn inte längre slås upp, och tunneln startar aldrig igen efter en omstart. Om leverantören roterar slutpunkter, slå upp namnet innan policyn tillämpas och uppdatera den regeln från samma skript.

Spegla formen i FORWARD för klienttrafik, och placera en explicit administrationsregel ovanför avvisningen. Håll den administrationsregeln smal men nåbar, och bekräfta den genom att öppna en andra SSH-session innan du stänger den första. Att låsa ut sig under en kill switch-ändring är vanligt nog att planera för. På en router som kör WireGuard avgör peerens allowed-ips vad som kommer in i tunneln, medan dessa regler avgör vad som får gå ut utan den.

IPv6 behöver sin egen dörr

Allt ovan är IPv4. Om ditt LAN har fungerande IPv6 och tunneln bara bär IPv4, har varje täckt enhet fortfarande en direkt väg till internet som dina nya regler aldrig ser. En dual-stack-bärbar dator föredrar den gärna, och kill switchen kommer bara att se trasig ut för den som testar med IPv4.

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

Ordningen spelar roll här också: loopback-tillåtelsen måste komma före WAN-avvisningen, annars börjar lokala tjänster på routern att misslyckas på märkliga sätt. Om nätverket inte använder IPv6 alls är det enklare att inaktivera det på WAN och LAN, och det finns ingenting att glömma.

Vissa VPN-klienter installerar en standardrutt bara för IPv4 och lämnar den befintliga IPv6-standardrutten orörd. Kontrollera routingtabellen efter att tunneln anslutits i stället för att anta att klienten hanterade det.

Bevisa det med tunneln nere

Stoppa tunneln från routern och testa från tre platser i den här ordningen:

# 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

Rutuppslaget berättar vart ett paket skulle ta vägen, och räknarna berättar om dina regler någonsin matchade. En regel med noll paket efter ett misslyckat test skyddar ingenting, och den vanliga orsaken är ett gränssnittsnamn som skiljer sig från det du skrev. Testa rutergenererad trafik uttryckligen, eftersom ett test från LAN-sidan inte kan utöva OUTPUT.

Bestäm felmoden innan du behöver den. Fail-closed håller klienterna offline tills tunneln återkommer; fail-open återställer vanlig WAN-åtkomst och undergräver syftet för trafiken du brydde dig om. En blackhole-rutt till VPN-poolen med hög metrik är ett användbart andra lager för fail-closed-konstruktioner, eftersom den överlever när tunnelrutten försvinner i stället för att falla tillbaka på standardrutten.

Acceptera uppsättningen först när en LAN-klient, en rutergenererad begäran och en IPv6-begäran alla misslyckas med tunneln nere, och alla tre fungerar igen när den är uppe.