Kill switch på rutaren som dekkjer FORWARD, OUTPUT og IPv6

Du loggar på rutaren, limer inn eit kill switch-regelsett frå eit foruminnlegg, og LAN-et sluttar å surfe i det augneblinken tunnelen fell. To dagar seinare oppdaterer rutaren framleis sin dynamiske DNS-post over den vanlege WAN-en, og gjestelaptopen når framleis IPv6-sider. Begge åtferdene er normale, fordi reglane som vart limte inn, dekte éi kjede og éin adressefamilie, og ingen av dei er heile rutaren. Å gå gjennom pakkevegane i rekkjefølgje viser nøyaktig kva som vart oversett.

Start ved rutaren, ikkje ved den berbare

Ein policy på rutarnivå er attraktiv for eit lite kontor fordi kvar eining bak han arvar same åtferd, og ingen kan gløyme å slå på ein klientbrytar. Han gjev deg òg ein stad å teste etter kvar fastvareoppdatering. Det han ikkje gjev deg, er automatisk dekning av rutaren sin eigen trafikk eller av ein annan adressefamilie, og det er dei to hola bak dei fleste mislukka utrullingane.

Før du redigerer noko, noter tre fakta på papir: namnet på WAN-grensesnittet, namnet på LAN-brua og VPN-endepunktet si adresse og port. Du treng alle tre i reglane, og gjetting på grensesnittnamn er den vanlegaste årsaka til at eit regelsett som ser riktig ut, ikkje gjer noko.

Gå gjennom dei tre vegane ein pakke kan ta

Trafikk frå ein berbar til internettet vert vidaresend, så han passerer FORWARD-kjeda. Trafikk rutaren sjølv genererer, som DNS-vidaresending, NTP-spurnader, DDNS-oppdateringar og VPN-kontrollkanalen, passerer OUTPUT. Administrasjonstrafikk retta mot rutaren kjem inn gjennom INPUT.

Ein kill switch bygd berre i FORWARD vernar derfor klientane og ingenting anna. Tabellen viser kvifor lekkasjen i opningsscena er føreseieleg og ikkje mystisk.

I dei fleste design treng du ikkje kill switch på INPUT, men du må halde administrasjonstilgangen i gang medan tunnelen er nede. Elles køyrer du til kontoret med ein konsollkabel første gongen VPN-en sviktar.

Ordne reglane slik at tunnelen framleis kan kome opp

Ein fungerande kill switch er ei tillatingsliste som endar i ei avvising, og rekkjefølgja er det som gjer han til ein kill switch i staden for ein murstein. Tillat først loopback, VPN-endepunktet, svar for etablerte flytar 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 vere ei adresse, ikkje eit vertsnamn. Når den endelege avvisinga blokkerer DNS, kan ein regel som namngjev vertsnamnet til leverandøren ikkje lenger slåast opp, og tunnelen startar aldri igjen etter ein omstart. Viss leverandøren roterer endepunkt, slå opp namnet før policyen vert brukt, og oppdater den regelen frå same skript.

Spegle forma i FORWARD for klienttrafikk, og plasser ein eksplisitt administrasjonsregel over avvisinga. Hald den administrasjonsregelen smal, men tilgjengeleg, og stadfest han ved å opne ein andre SSH-økt før du lukkar den første. Å låse seg ute under ei kill switch-endring er vanleg nok til å planleggje for. På ein rutar som køyrer WireGuard, avgjer allowed-ips til peeren kva som kjem inn i tunnelen, medan desse reglane avgjer kva som får gå ut utan han.

IPv6 treng si eiga dør

Alt over er IPv4. Viss LAN-et ditt har fungerande IPv6 og tunnelen berre ber IPv4, har kvar dekt eining framleis ei direkte rute til internettet som dei nye reglane dine aldri ser. Ein dual-stack-berbar vil gjerne føretrekkje henne, og kill switchen vil berre sjå øydelagd ut for 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

Rekkjefølgja har noko å seie her òg: loopback-tillatinga må kome før WAN-avvisinga, elles byrjar lokale tenester på rutaren å svikte på rare måtar. Viss nettverket ikkje brukar IPv6 i det heile, er det enklare å deaktivere det på WAN og LAN, og det er ingenting å gløyme.

Nokre VPN-klientar installerer ei standardrute berre for IPv4 og lèt den eksisterande IPv6-standardruta vere urørt. Sjekk rutetabellen etter at tunnelen er tilkopla, i staden for å anta at klienten ordna det.

Prov det med tunnelen nede

Stopp tunnelen frå rutaren, og test frå tre stader i denne rekkjefølgja:

# 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 fortel deg kvar ein pakke ville gå, og teljarane fortel deg om reglane dine nokon gong trefte. Ein regel med null pakkar etter ein mislukka test vernar ingenting, og den vanlege årsaka er eit grensesnittnamn som avvik frå det du skreiv. Test rutargenerert trafikk eksplisitt, fordi ein test frå LAN-sida ikkje kan utøve OUTPUT.

Bestem feilmodusen før du treng han. Fail-closed held klientane offline til tunnelen kjem tilbake; fail-open gjenopprettar vanleg WAN-tilgang og undergrev føremålet for trafikken du brydde deg om. Ei blackhole-rute til VPN-poolen med høg metrikk er eit nyttig andre lag for fail-closed-design, sidan ho overlever når tunnelruta forsvinn i staden for å falle tilbake til standardruta.

Godta oppsettet først når ein LAN-klient, ein rutargenerert førespurnad og ein IPv6-førespurnad alle feilar med tunnelen nede, og alle tre verkar igjen når han er oppe.