Kill switch pe router care acoperă FORWARD, OUTPUT și IPv6

Vă conectați la router, lipiți un set de reguli kill switch dintr-o postare de forum, iar LAN-ul nu mai navighează în momentul în care tunelul cade. Două zile mai târziu routerul își actualizează încă înregistrarea DNS dinamică prin WAN-ul obișnuit, iar laptopul oaspeților ajunge încă pe site-uri IPv6. Ambele comportamente sunt normale, pentru că regulile lipite acopereau un lanț și o familie de adrese, iar niciuna dintre ele nu este întregul router. Parcurgerea căilor pachetelor în ordine arată exact ce a fost omis.

Începeți de la router, nu de la laptop

O politică la nivel de router este atractivă pentru un birou mic pentru că fiecare dispozitiv din spate moștenește același comportament și nimeni nu poate uita să activeze un comutator pe client. Vă oferă și un singur loc de testat după fiecare actualizare de firmware. Ceea ce nu oferă este acoperirea automată a traficului propriu al routerului sau a unei a doua familii de adrese, iar acestea sunt cele două lacune din spatele majorității implementărilor eșuate.

Înainte de a modifica ceva, notați trei fapte pe hârtie: numele interfeței WAN, numele podului LAN și adresa și portul punctului final VPN. Veți avea nevoie de toate trei în reguli, iar ghicirea numelor de interfețe este cel mai frecvent motiv pentru care un set de reguli care arată corect nu face nimic.

Parcurgeți cele trei căi pe care poate merge un pachet

Traficul de la un laptop către internet este redirecționat, deci trece prin lanțul FORWARD. Traficul generat de router însuși, cum ar fi redirecționarea DNS, interogările NTP, actualizările DDNS și canalul de control VPN, trece prin OUTPUT. Traficul de administrare adresat routerului sosește prin INPUT.

Un kill switch construit doar în FORWARD protejează așadar clienții și nimic altceva. Tabelul arată de ce scurgerea din scena de deschidere este previzibilă și nu misterioasă.

În majoritatea proiectelor nu aveți nevoie de kill switch pe INPUT, dar trebuie să mențineți accesul de administrare funcțional cât timp tunelul este oprit. Altfel, prima dată când VPN-ul eșuează mergeți la birou cu un cablu de consolă.

Ordonați regulile astfel încât tunelul să poată totuși porni

Un kill switch funcțional este o listă de permisiuni care se termină cu o respingere, iar ordinea este cea care îl face kill switch în loc de cărămidă. Permiteți mai întâi loopback, punctul final VPN, răspunsurile pentru fluxurile stabilite și interfața tunelului; respingeți restul la final.

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

Punctul final trebuie să fie o adresă în acest moment, nu un nume de gazdă. Odată ce respingerea finală blochează DNS, o regulă care numește numele de gazdă al furnizorului nu mai poate fi rezolvată, și tunelul nu mai pornește niciodată după o repornire. Dacă furnizorul rotește punctele finale, rezolvați numele înainte de aplicarea politicii și reîmprospătați acea regulă din același script.

Reflectați forma în FORWARD pentru traficul clienților și plasați o regulă explicită de administrare deasupra respingerii. Țineți acea regulă de administrare îngustă dar accesibilă și confirmați-o deschizând o a doua sesiune SSH înainte de a o închide pe prima. Să te blochezi afară în timpul unei modificări de kill switch este suficient de obișnuit încât să planificați. Pe un router care rulează WireGuard, allowed-ips ale peerului decid ce intră în tunel, în timp ce aceste reguli decid ce are voie să iasă fără el.

IPv6 are nevoie de propria ușă

Tot ce este mai sus este IPv4. Dacă LAN-ul dumneavoastră are IPv6 funcțional și tunelul transportă doar IPv4, fiecare dispozitiv acoperit are în continuare o rută directă către internet pe care regulile noi nu o văd niciodată. Un laptop dual-stack o va prefera bucuros, iar kill switch-ul va părea stricat doar persoanei care testează cu IPv4.

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

Și aici ordinea contează: permisiunea pentru loopback trebuie să precedă respingerea WAN, altfel serviciile locale de pe router încep să eșueze în moduri ciudate. Dacă rețeaua nu folosește deloc IPv6, dezactivarea lui pe WAN și LAN este mai simplă și nu lasă nimic de uitat.

Unii clienți VPN instalează o rută implicită doar pentru IPv4 și lasă ruta implicită IPv6 existentă neatinsă. Verificați tabelul de rutare după ce tunelul se conectează, în loc să presupuneți că clientul s-a ocupat de asta.

Demonstrați cu tunelul oprit

Opriți tunelul de pe router și testați din trei locuri în această ordine:

# 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

Căutarea rutei vă spune unde ar merge un pachet, iar contoarele vă spun dacă regulile dumneavoastră s-au potrivit vreodată. O regulă cu zero pachete după un test eșuat nu protejează nimic, iar cauza obișnuită este un nume de interfață diferit de cel tastat. Testați explicit traficul generat de router, pentru că un test din partea LAN nu poate exercita OUTPUT.

Decideți modul de eșec înainte de a avea nevoie de el. Fail-closed ține clienții offline până când tunelul revine; fail-open restaurează accesul WAN obișnuit și anulează scopul pentru traficul care vă conta. O rută blackhole către pool-ul VPN cu o metrică mare este un al doilea strat util pentru proiectele fail-closed, deoarece supraviețuiește când ruta tunelului dispare, în loc să revină la cea implicită.

Acceptați configurația doar când un client din LAN, o cerere generată de router și o cerere IPv6 eșuează toate cu tunelul oprit, și toate trei funcționează din nou după ce acesta pornește.