Kill switch al router que cobreix FORWARD, OUTPUT i IPv6

Inicieu sessió al router, enganxeu un conjunt de regles de kill switch d’una publicació d’un fòrum, i la LAN deixa de navegar en el moment que el túnel cau. Dos dies després, el router encara actualitza el seu registre DNS dinàmic per la WAN normal, i l’ordinador portàtil dels convidats encara arriba a llocs IPv6. Tots dos comportaments són normals, perquè les regles enganxades cobrien una cadena i una família d’adreces, i cap de les dues és tot el router. Recórrer els camins dels paquets en ordre mostra exactament què es va oblidar.

Comença pel router, no per l’ordinador portàtil

Una política a nivell de router és atractiva per a una oficina petita perquè cada dispositiu que hi ha darrere hereta el mateix comportament i ningú no pot oblidar activar un commutador al client. També us dona un sol lloc on provar després de cada actualització de firmware. El que no us dona és una cobertura automàtica del trànsit propi del router ni d’una segona família d’adreces, i aquests són els dos buits darrere de la majoria de desplegaments fallits.

Abans de modificar res, anoteu tres dades en paper: el nom de la interfície WAN, el nom del pont LAN i l’adreça i el port del punt final de la VPN. Us caldran les tres a les regles, i endevinar els noms de les interfícies és la causa més habitual que un conjunt de regles que sembla correcte no faci res.

Recorre els tres camins que pot prendre un paquet

El trànsit d’un ordinador portàtil a internet es reenvia, així que passa per la cadena FORWARD. El trànsit que genera el router mateix, com el reenviament DNS, les consultes NTP, les actualitzacions DDNS i el canal de control de la VPN, passa per OUTPUT. El trànsit de gestió adreçat al router arriba per INPUT.

Per tant, un kill switch construït només a FORWARD protegeix els clients i res més. La taula mostra per què la fuita de l’escena inicial és previsible i no pas misteriosa.

En la majoria de dissenys no necessiteu un kill switch a INPUT, però sí que heu de mantenir l’accés de gestió funcionant mentre el túnel està caigut. En cas contrari, la primera vegada que la VPN falla aneu a l’oficina amb un cable de consola.

Ordena les regles perquè el túnel encara pugui aixecar-se

Un kill switch que funciona és una llista d’autoritzacions que acaba en un rebuig, i l’ordre és el que el converteix en un kill switch i no en un maó. Permeteu primer el loopback, el punt final de la VPN, les respostes per als fluxos establerts i la interfície del túnel; rebutgeu la resta al 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

En aquest punt, el punt final ha de ser una adreça, no un nom d’amfitrió. Un cop el rebuig final bloqueja el DNS, una regla que anomeni el nom d’amfitrió del proveïdor ja no es pot resoldre, i el túnel no torna a arrencar mai després d’un reinici. Si el proveïdor rota els punts finals, resoleu el nom abans que s’apliqui la política i actualitzeu aquella regla des del mateix script.

Reproduïu la forma a FORWARD per al trànsit dels clients i col·loqueu una regla de gestió explícita per sobre del rebuig. Manteniu aquesta regla de gestió estreta però assolible, i confirmeu-la obrint una segona sessió SSH abans de tancar la primera. Quedar-vos fora durant un canvi de kill switch és prou habitual per planificar-ho. En un router amb WireGuard, els allowed-ips del parell decideixen què entra al túnel, mentre que aquestes regles decideixen què pot sortir sense ell.

IPv6 necessita la seva pròpia porta

Tot el de dalt és IPv4. Si la vostra LAN té IPv6 funcionant i el túnel només transporta IPv4, cada dispositiu cobert encara té una ruta directa a internet que les vostres regles noves no veuen mai. Un ordinador portàtil de doble pila la preferirà sense dubtar, i el kill switch només semblarà trencat a qui prova amb IPv4.

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

Aquí l’ordre també importa: l’autorització del loopback ha de precedir el rebuig de la WAN, o els serveis locals del router comencen a fallar de maneres estranyes. Si la xarxa no fa servir IPv6 de cap manera, desactivar-lo a la WAN i a la LAN és més senzill i no deixa res per oblidar.

Alguns clients de VPN instal·len una ruta per defecte només per a IPv4 i deixen la ruta per defecte IPv6 existent intacta. Comproveu la taula d’encaminament després que el túnel es connecti en lloc de suposar que el client ho ha gestionat.

Demostra-ho amb el túnel aturat

Atureu el túnel des del router i proveu-ho des de tres llocs en aquest ordre:

# 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 consulta de ruta us diu on aniria un paquet, i els comptadors us diuen si les vostres regles han coincidit mai. Una regla amb zero paquets després d’una prova fallida no protegeix res, i la causa habitual és un nom d’interfície que difereix del que heu escrit. Proveu explícitament el trànsit generat pel router, perquè una prova des del costat de la LAN no pot exercitar OUTPUT.

Decidiu el mode de fallada abans de necessitar-lo. Fail-closed manté els clients fora de línia fins que el túnel torna; fail-open restaura l’accés normal a la WAN i anul·la el propòsit per al trànsit que us importava. Una ruta blackhole cap a la pool de la VPN amb una mètrica alta és una segona capa útil per als dissenys fail-closed, ja que sobreviu quan la ruta del túnel desapareix en lloc de tornar a la ruta per defecte.

Accepteu la configuració només quan un client de la LAN, una petició generada pel router i una petició IPv6 fallin tots amb el túnel caigut, i els tres tornin a funcionar un cop aixecat.