Kill switch no router que cobre FORWARD, OUTPUT e IPv6

Vostede entra no router, pega un conxunto de regras de kill switch collido dunha mensaxe de foro, e a LAN deixa de navegar no momento en que o túnel cae. Dous días despois o router segue actualizando o seu rexistro DNS dinámico pola WAN normal, e o portátil de convidados segue chegando a sitios IPv6. Ambos comportamentos son normais, porque as regras pegadas cubrían unha cadea e unha familia de enderezos, e ningunha das dúas é todo o router. Percorrer as rutas dos paquetes en orde mostra exactamente que quedou fóra.

Comece polo router, non polo portátil

Unha política a nivel de router é atractiva para unha oficina pequena porque cada dispositivo detrás herda o mesmo comportamento e ninguén pode esquecer activar un interruptor no cliente. Tamén lle dá un único lugar onde probar tras cada actualización de firmware. O que non lle dá é cobertura automática do tráfico propio do router nin dunha segunda familia de enderezos, e esas son as dúas lagoas detrás da maioría dos despregamentos fallidos.

Antes de tocar nada, anote tres datos en papel: o nome da interface WAN, o nome da ponte LAN e o enderezo e o porto do extremo da VPN. Necesitaraos os tres nas regras, e adiviñar nomes de interfaces é a causa máis común de que un conxunto de regras que parece correcto non faga nada.

Percorra os tres camiños que pode tomar un paquete

O tráfico dun portátil a internet reenvíase, así que pasa pola cadea FORWARD. O tráfico que xera o propio router, como o reenvío de DNS, as consultas NTP, as actualizacións DDNS e a canle de control da VPN, pasa por OUTPUT. O tráfico de xestión dirixido ao router chega por INPUT.

Un kill switch construído só en FORWARD protexe, por tanto, os clientes e nada máis. A táboa mostra por que a fuga da escena inicial é previsible e non misteriosa.

Na maioría dos deseños non necesita un kill switch en INPUT, pero si debe manter funcionando o acceso de xestión mentres o túnel está caído. Se non, a primeira vez que falle a VPN irá á oficina cun cable de consola.

Ordene as regras para que o túnel aínda poida levantarse

Un kill switch que funciona é unha lista de permitidos que remata nun rexeitamento, e a orde é o que o converte nun kill switch en lugar de nun ladrillo. Permita primeiro loopback, o extremo da VPN, as respostas dos fluxos establecidos e a interface do túnel; rexeite o resto ao 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

O extremo debe ser un enderezo neste punto, non un nome de host. Unha vez que o rexeitamento final bloquea DNS, unha regra que nomea o host do provedor xa non se pode resolver, e o túnel non volve arrincar nunca tras un reinicio. Se o provedor rota os extremos, resolva o nome antes de que se aplique a política e refresque esa regra desde o mesmo script.

Reproduza a forma en FORWARD para o tráfico dos clientes e coloque unha regra de xestión explícita por riba do rexeitamento. Manteña esa regra de xestión estreita pero alcanzable, e confírmaa abrindo unha segunda sesión SSH antes de pechar a primeira. Quedar fóra durante un cambio de kill switch é abondo habitual para planificalo. Nun router con WireGuard, os allowed-ips do par deciden que entra no túnel, mentres que estas regras deciden que pode saír sen el.

IPv6 precisa a súa propia porta

Todo o anterior é IPv4. Se a súa LAN ten IPv6 funcionando e o túnel só transporta IPv4, cada dispositivo cuberto segue tendo unha ruta directa a internet que as súas novas regras nunca ven. Un portátil de dobre pila preferiraa sen dúbida, e o kill switch só parecerá roto a quen proba con IPv4.

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

Aquí a orde tamén importa: a aceptación de loopback debe preceder o rexeitamento da WAN, ou os servizos locais do router comezarán a fallar de xeitos estraños. Se a rede non usa IPv6 en absoluto, desactivalo na WAN e na LAN é máis sinxelo e non deixa nada que esquecer.

Algúns clientes de VPN instalan unha ruta por defecto só para IPv4 e deixan intacta a ruta por defecto IPv6 existente. Comprobe a táboa de encamiñamento despois de que o túnel se conecte en lugar de supoñer que o cliente se encargou diso.

Demóstreo co túnel caído

Detéña o túnel desde o router e probe desde tres lugares nesta orde:

# 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

A consulta de ruta dille a onde iría un paquete, e os contadores dinlle se as súas regras chegaron a coincidir. Unha regra con cero paquetes tras unha proba fallida non protexe nada, e a causa habitual é un nome de interface distinto do que escribiu. Probe explicitamente o tráfico xerado polo router, porque unha proba desde o lado da LAN non pode exercitar OUTPUT.

Decida o modo de fallo antes de necesitalo. Fail-closed mantén os clientes sen conexión ata que volve o túnel; fail-open restaura o acceso normal á WAN e arruína o propósito para o tráfico que lle importaba. Unha ruta blackhole cara ao pool da VPN cunha métrica alta é unha segunda capa útil para os deseños fail-closed, xa que sobrevive cando desaparece a ruta do túnel en lugar de volver á ruta por defecto.

Acepte a configuración só cando un cliente da LAN, unha petición xerada polo router e unha petición IPv6 fallen todas co túnel caído, e as tres volvan funcionar unha vez levantado.