Kill switch på routeren, der dækker FORWARD, OUTPUT og IPv6

Du logger ind på routeren, indsætter et regelsæt til kill switch fra et forumindlæg, og LAN’et holder op med at browse i det øjeblik, tunnelen falder. To dage senere opdaterer routeren stadig sin dynamiske DNS-post over den almindelige WAN, og gæstelaptoppen når stadig IPv6-sider. Begge adfærdsmønstre er normale, fordi de indsatte regler dækkede én kæde og én adressefamilie, og ingen af dem er hele routeren. At gå pakkernes veje igennem i rækkefølge viser præcis, hvad der blev overset.

Begynd ved routeren, ikke ved den bærbare

En politik på router-niveau er attraktiv for et lille kontor, fordi hver enhed bagved arver samme adfærd, og ingen kan glemme at slå en klientkontakt til. Den giver dig også ét sted at teste efter hver firmwareopdatering. Det, den ikke giver dig, er automatisk dækning af routerens egen trafik eller af en anden adressefamilie, og det er de to huller bag de fleste mislykkede implementeringer.

Før du redigerer noget, skal du notere tre fakta på papir: WAN-interfacets navn, LAN-broens navn og VPN-endepunktets adresse og port. Du får brug for alle tre i reglerne, og gætteri på interfacenavne er den mest almindelige årsag til, at et regelsæt, der ser korrekt ud, ikke gør noget.

Gå gennem de tre veje, en pakke kan tage

Trafik fra en bærbar til internettet videresendes, så den passerer FORWARD-kæden. Trafik, som routeren selv genererer, fx DNS-videresendelse, NTP-forespørgsler, DDNS-opdateringer og VPN-kontrolkanalen, passerer OUTPUT. Administrationstrafik rettet mod routeren ankommer gennem INPUT.

En kill switch, der kun er bygget i FORWARD, beskytter derfor klienter og intet andet. Tabellen viser, hvorfor lækagen i åbningsscenen er forudsigelig og ikke mystisk.

I de fleste design har du ikke brug for en kill switch på INPUT, men du skal holde administrationsadgangen kørende, mens tunnelen er nede. Ellers kører du til kontoret med et konsolkabel, første gang VPN’en svigter.

Ordne reglerne, så tunnelen stadig kan komme op

En fungerende kill switch er en tilladelsesliste, der ender i et afvis, og rækkefølgen er det, der gør den til en kill switch i stedet for en mursten. Tillad først loopback, VPN-endepunktet, svar for etablerede flows og tunnelinterfacet; afvis resten sidst.

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 skal på dette tidspunkt være en adresse, ikke et værtsnavn. Når den endelige afvisning blokerer DNS, kan en regel, der navngiver udbyderens værtsnavn, ikke længere slås op, og tunnelen starter aldrig igen efter en genstart. Hvis udbyderen roterer endepunkter, skal du slå navnet op, før politikken anvendes, og opdatere den regel fra samme script.

Spejl formen i FORWARD for klienttrafik, og placér en eksplicit administrationsregel over afvisningen. Hold den administrationsregel smal men tilgængelig, og bekræft den ved at åbne en anden SSH-session, før du lukker den første. At låse sig selv ude under en kill-switch-ændring er almindeligt nok til at planlægge for. På en router, der kører WireGuard, bestemmer peerens allowed-ips, hvad der kommer ind i tunnelen, mens disse regler bestemmer, hvad der må gå ud uden den.

IPv6 har brug for sin egen fordør

Alt ovenstående er IPv4. Hvis dit LAN har fungerende IPv6, og tunnelen kun bærer IPv4, har hver dækket enhed stadig en direkte rute til internettet, som dine nye regler aldrig ser. En dual-stack-bærbar vil med glæde foretrække den, og kill switchen vil kun se i stykker ud for den person, der 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

Rækkefølgen betyder også noget her: loopback-tilladelsen skal komme før WAN-afvisningen, ellers begynder lokale tjenester på routeren at fejle på sære måder. Hvis netværket slet ikke bruger IPv6, er det enklere at deaktivere det på WAN og LAN, og der er intet at glemme.

Nogle VPN-klienter installerer kun en standardrute for IPv4 og lader den eksisterende IPv6-standardrute være urørt. Kontrollér routingtabellen, efter tunnelen er forbundet, i stedet for at antage, at klienten klarede det.

Bevis det med tunnelen nede

Stop tunnelen fra routeren, og test fra tre steder i denne rækkefølge:

# 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

Ruteopslaget fortæller dig, hvor en pakke ville gå hen, og tællerne fortæller dig, om dine regler nogensinde matchede. En regel med nul pakker efter en mislykket test beskytter intet, og den sædvanlige årsag er et interfacenavn, der afviger fra det, du skrev. Test router-genereret trafik eksplicit, fordi en test fra LAN-siden ikke kan udøve OUTPUT.

Beslut fejltilstanden, før du får brug for den. Fail-closed holder klienter offline, indtil tunnelen vender tilbage; fail-open genopretter almindelig WAN-adgang og undergraver formålet for den trafik, du var bekymret for. En blackhole-rute til VPN-puljen med en høj metrik er et nyttigt andet lag til fail-closed-designs, da den overlever, når tunnelruten forsvinder, i stedet for at falde tilbage til standardruten.

Accepter opsætningen, først når en LAN-klient, en router-genereret anmodning og en IPv6-anmodning alle fejler med tunnelen nede, og alle tre virker igen, når den er oppe.