Kill switch sul router che copre FORWARD, OUTPUT e IPv6

Accedete al router, incollate un insieme di regole kill switch preso da un post di un forum, e la LAN smette di navigare nel momento in cui il tunnel cade. Due giorni dopo il router sta ancora aggiornando il proprio record DNS dinamico sulla WAN ordinaria, e il portatile degli ospiti raggiunge ancora siti IPv6. Entrambi i comportamenti sono normali, perché le regole incollate coprivano una catena e una famiglia di indirizzi, e nessuna delle due è l’intero router. Percorrere i percorsi dei pacchetti in ordine mostra esattamente che cosa è stato trascurato.

Partite dal router, non dal portatile

Una politica a livello di router è attraente per un piccolo ufficio perché ogni dispositivo dietro eredita lo stesso comportamento e nessuno può dimenticare di attivare un interruttore sul client. Offre anche un unico posto per provare dopo ogni aggiornamento del firmware. Quello che non offre è una copertura automatica del traffico del router stesso o di una seconda famiglia di indirizzi, e sono le due lacune dietro la maggior parte delle distribuzioni fallite.

Prima di modificare qualcosa, annotate tre dati su carta: il nome dell’interfaccia WAN, il nome del bridge LAN e l’indirizzo e la porta dell’endpoint VPN. Vi serviranno tutti e tre nelle regole, e indovinare i nomi delle interfacce è il motivo più comune per cui un insieme di regole dall’aspetto corretto non fa nulla.

Percorrete i tre percorsi che un pacchetto può seguire

Il traffico da un portatile a internet viene inoltrato, quindi passa attraverso la catena FORWARD. Il traffico che il router genera da sé, come l’inoltro DNS, le query NTP, gli aggiornamenti DDNS e il canale di controllo della VPN, passa attraverso OUTPUT. Il traffico di gestione indirizzato al router arriva tramite INPUT.

Un kill switch costruito solo in FORWARD protegge quindi i client e nient’altro. La tabella mostra perché la fuga della scena iniziale è prevedibile e non misteriosa.

Nella maggior parte dei progetti non serve un kill switch su INPUT, ma bisogna mantenere funzionante l’accesso di gestione mentre il tunnel è abbassato. Altrimenti la prima volta che la VPN fallisce andate in ufficio con un cavo console.

Ordinate le regole perché il tunnel possa ancora salire

Un kill switch che funziona è un elenco di autorizzazioni che termina con un rifiuto, ed è l’ordine che lo rende un kill switch invece di un mattone. Autorizzate prima il loopback, l’endpoint VPN, le risposte dei flussi stabiliti e l’interfaccia del tunnel; rifiutate il resto per ultimo.

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

A questo punto l’endpoint deve essere un indirizzo, non un nome host. Una volta che il rifiuto finale blocca il DNS, una regola che nomina il nome host del provider non può più essere risolta, e il tunnel non riparte mai più dopo un riavvio. Se il provider ruota gli endpoint, risolvete il nome prima che la politica venga applicata e aggiornate quella regola dallo stesso script.

Riproducete la forma in FORWARD per il traffico dei client e mettete una regola di gestione esplicita sopra il rifiuto. Mantenete quella regola di gestione stretta ma raggiungibile, e confermatela aprendo una seconda sessione SSH prima di chiudere la prima. Chiudersi fuori durante un cambio di kill switch è abbastanza comune da pianificarlo. Su un router che esegue WireGuard, gli allowed-ips del peer decidono che cosa entra nel tunnel, mentre queste regole decidono che cosa può uscire senza di esso.

IPv6 ha bisogno della propria porta

Tutto quanto sopra è IPv4. Se la vostra LAN ha IPv6 funzionante e il tunnel trasporta solo IPv4, ogni dispositivo coperto ha ancora una rotta diretta verso internet che le nuove regole non vedono mai. Un portatile dual-stack la preferirà volentieri, e il kill switch sembrerà rotto solo a chi prova con IPv4.

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

Anche qui l’ordine conta: l’autorizzazione del loopback deve precedere il rifiuto della WAN, altrimenti i servizi locali sul router iniziano a fallire in modi strani. Se la rete non usa affatto IPv6, disattivarlo su WAN e LAN è più semplice e non lascia nulla da dimenticare.

Alcuni client VPN installano una rotta predefinita solo per IPv4 e lasciano intatta la rotta predefinita IPv6 esistente. Controllate la tabella di routing dopo che il tunnel si è connesso invece di dare per scontato che il client se ne sia occupato.

Dimostratelo con il tunnel abbassato

Fermate il tunnel dal router e provate da tre punti in questo 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

La ricerca della rotta vi dice dove andrebbe un pacchetto, e i contatori vi dicono se le vostre regole hanno mai trovato corrispondenza. Una regola con zero pacchetti dopo un test fallito non protegge nulla, e la causa abituale è un nome di interfaccia diverso da quello digitato. Provate esplicitamente il traffico generato dal router, perché un test dal lato LAN non può esercitare OUTPUT.

Decidete la modalità di guasto prima di averne bisogno. Fail-closed tiene i client offline finché il tunnel non torna; fail-open ripristina l’accesso WAN ordinario e vanifica lo scopo per il traffico che vi interessava. Una rotta blackhole verso il pool VPN con una metrica alta è un secondo strato utile per i progetti fail-closed, dato che sopravvive quando la rotta del tunnel scompare invece di ricadere su quella predefinita.

Accettate la configurazione solo quando un client della LAN, una richiesta generata dal router e una richiesta IPv6 falliscono tutte con il tunnel abbassato, e tutte e tre funzionano di nuovo una volta che è alzato.