Kill switch på ruteren som dekker FORWARD, OUTPUT og IPv6

Du logger på ruteren, limer inn et kill switch-regelsett fra et foruminnlegg, og LAN-et slutter å surfe i det øyeblikket tunnelen faller. To dager senere oppdaterer ruteren fortsatt sin dynamiske DNS-post over den vanlige WAN-en, og gjestelaptopen når fortsatt IPv6-sider. Begge atferdene er normale, fordi reglene som ble limt inn, dekket én kjede og én adressefamilie, og ingen av dem er hele ruteren. Å gå gjennom pakkeveiene i rekkefølge viser nøyaktig hva som ble oversett.

Start ved ruteren, ikke ved den bærbare

En policy på ruternivå er attraktiv for et lite kontor fordi hver enhet bak den arver samme atferd, og ingen kan glemme å slå på en klientbryter. Den gir deg også ett sted å teste etter hver fastvareoppdatering. Det den ikke gir deg, er automatisk dekning av ruterens egen trafikk eller av en annen adressefamilie, og det er de to hullene bak de fleste mislykkede utrullinger.

Før du redigerer noe, noter tre fakta på papir: navnet på WAN-grensesnittet, navnet på LAN-broen og VPN-endepunktets adresse og port. Du trenger alle tre i reglene, og gjetting på grensesnittnavn er den vanligste årsaken til at et regelsett som ser riktig ut, ikke gjør noe.

Gå gjennom de tre veiene en pakke kan ta

Trafikk fra en bærbar til internettet videresendes, så den passerer FORWARD-kjeden. Trafikk ruteren selv genererer, som DNS-videresending, NTP-spørringer, DDNS-oppdateringer og VPN-kontrollkanalen, passerer OUTPUT. Administrasjonstrafikk rettet mot ruteren kommer inn gjennom INPUT.

En kill switch bygget bare i FORWARD beskytter derfor klientene og ingenting annet. Tabellen viser hvorfor lekkasjen i åpningsscenen er forutsigbar og ikke mystisk.

I de fleste design trenger du ikke kill switch på INPUT, men du må holde administrasjonstilgangen i gang mens tunnelen er nede. Ellers kjører du til kontoret med en konsollkabel første gang VPN-en svikter.

Ordne reglene slik at tunnelen fortsatt kan komme opp

En fungerende kill switch er en tillatelsesliste som ender i en avvisning, og rekkefølgen er det som gjør den til en kill switch i stedet for en murstein. Tillat først loopback, VPN-endepunktet, svar for etablerte flyter og tunnelgrensesnittet; avvis 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

Endepunktet må på dette punktet være en adresse, ikke et vertsnavn. Når den endelige avvisningen blokkerer DNS, kan en regel som navngir leverandørens vertsnavn ikke lenger slås opp, og tunnelen starter aldri igjen etter en omstart. Hvis leverandøren roterer endepunkter, slå opp navnet før policyen brukes, og oppdater den regelen fra samme skript.

Speil formen i FORWARD for klienttrafikk, og plasser en eksplisitt administrasjonsregel over avvisningen. Hold den administrasjonsregelen smal, men tilgjengelig, og bekreft den ved å åpne en andre SSH-økt før du lukker den første. Å låse seg ute under en kill switch-endring er vanlig nok til å planlegge for. På en ruter som kjører WireGuard, bestemmer peerens allowed-ips hva som kommer inn i tunnelen, mens disse reglene bestemmer hva som får gå ut uten den.

IPv6 trenger sin egen dør

Alt over er IPv4. Hvis LAN-et ditt har fungerende IPv6 og tunnelen bare bærer IPv4, har hver dekket enhet fortsatt en direkte rute til internettet som de nye reglene dine aldri ser. En dual-stack-bærbar vil gjerne foretrekke den, og kill switchen vil bare se ødelagt ut for den som tester med IPv4.

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

Rekkefølgen betyr noe her også: loopback-tillatelsen må komme før WAN-avvisningen, ellers begynner lokale tjenester på ruteren å feile på rare måter. Hvis nettverket ikke bruker IPv6 i det hele tatt, er det enklere å deaktivere det på WAN og LAN, og det er ingenting å glemme.

Noen VPN-klienter installerer en standardrute bare for IPv4 og lar den eksisterende IPv6-standardruten være urørt. Sjekk rutingtabellen etter at tunnelen er tilkoblet, i stedet for å anta at klienten ordnet det.

Bevis det med tunnelen nede

Stopp tunnelen fra ruteren, og test fra tre steder i denne rekkefølgen:

# 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

Ruteoppslaget forteller deg hvor en pakke ville gå, og tellerne forteller deg om reglene dine noen gang traff. En regel med null pakker etter en mislykket test beskytter ingenting, og den vanlige årsaken er et grensesnittnavn som avviker fra det du skrev. Test rutergenerert trafikk eksplisitt, fordi en test fra LAN-siden ikke kan utøve OUTPUT.

Bestem feilmodusen før du trenger den. Fail-closed holder klientene offline til tunnelen kommer tilbake; fail-open gjenoppretter vanlig WAN-tilgang og undergraver formålet for trafikken du brydde deg om. En blackhole-rute til VPN-poolen med høy metrikk er et nyttig andre lag for fail-closed-design, siden den overlever når tunnelruten forsvinner i stedet for å falle tilbake til standardruten.

Godta oppsettet først når en LAN-klient, en rutergenerert forespørsel og en IPv6-forespørsel alle feiler med tunnelen nede, og alle tre virker igjen når den er oppe.