Kill switch no router que cobre FORWARD, OUTPUT e IPv6

Entra no router, cola um conjunto de regras de kill switch de um post de fórum, e a LAN deixa de navegar no momento em que o túnel cai. Dois dias depois, o router continua a atualizar o seu registo DNS dinâmico pela WAN normal, e o portátil dos convidados continua a chegar a sites IPv6. Ambos os comportamentos são normais, porque as regras coladas cobriam uma cadeia e uma família de endereços, e nenhuma delas é o router inteiro. Percorrer os caminhos dos pacotes por ordem mostra exatamente o que ficou de fora.

Comece pelo router, não pelo portátil

Uma política ao nível do router é atrativa para um escritório pequeno porque cada dispositivo atrás herda o mesmo comportamento e ninguém se pode esquecer de ativar um interruptor no cliente. Também lhe dá um único local para testar após cada atualização de firmware. O que não dá é uma cobertura automática do tráfego do próprio router nem de uma segunda família de endereços, e essas são as duas falhas por trás da maioria das implementações falhadas.

Antes de alterar seja o que for, anote três dados no papel: o nome da interface WAN, o nome da bridge LAN e o endereço e a porta do endpoint da VPN. Vai precisar dos três nas regras, e adivinhar nomes de interfaces é a razão mais comum para um conjunto de regras com bom aspeto não fazer nada.

Percorra os três caminhos que um pacote pode seguir

O tráfego de um portátil para a internet é encaminhado, por isso passa pela cadeia FORWARD. O tráfego que o router gera ele próprio, como o encaminhamento de DNS, os pedidos NTP, as atualizações DDNS e o canal de controlo da VPN, passa pela OUTPUT. O tráfego de gestão dirigido ao router chega pela INPUT.

Um kill switch construído apenas em FORWARD protege, portanto, os clientes e nada mais. A tabela mostra porque é que a fuga da cena inicial é previsível e não misteriosa.

Na maioria dos projetos não precisa de um kill switch na INPUT, mas tem de manter o acesso de gestão a funcionar enquanto o túnel está caído. Caso contrário, na primeira vez que a VPN falhar vai ao escritório com um cabo de consola.

Ordene as regras para que o túnel ainda possa subir

Um kill switch funcional é uma lista de permissões que termina numa rejeição, e é a ordem que o torna um kill switch em vez de um tijolo. Permita primeiro o loopback, o endpoint da VPN, as respostas dos fluxos estabelecidos e a interface do túnel; rejeite o resto em último.

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

Neste ponto, o endpoint tem de ser um endereço e não um nome de anfitrião. Assim que a rejeição final bloquear o DNS, uma regra que nomeie o nome de anfitrião do fornecedor deixa de poder ser resolvida, e o túnel nunca mais arranca depois de um reinício. Se o fornecedor rodar os endpoints, resolva o nome antes de a política ser aplicada e atualize essa regra a partir do mesmo script.

Reproduza a forma na FORWARD para o tráfego dos clientes e coloque uma regra de gestão explícita acima da rejeição. Mantenha essa regra de gestão estreita mas alcançável, e confirme-a abrindo uma segunda sessão SSH antes de fechar a primeira. Ficar trancado de fora durante uma alteração de kill switch é suficientemente comum para se planear. Num router com WireGuard, os allowed-ips do par decidem o que entra no túnel, enquanto estas regras decidem o que pode sair sem ele.

O IPv6 precisa da sua própria porta

Tudo acima é IPv4. Se a sua LAN tiver IPv6 a funcionar e o túnel transportar apenas IPv4, cada dispositivo coberto continua a ter uma rota direta para a internet que as suas novas regras nunca veem. Um portátil de dupla pilha vai preferi-la sem hesitar, e o kill switch só parecerá avariado a quem testa com IPv4.

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

Aqui a ordem também importa: a permissão do loopback tem de preceder a rejeição da WAN, ou os serviços locais no router começam a falhar de formas estranhas. Se a rede não usar IPv6 de todo, desativá-lo na WAN e na LAN é mais simples e não deixa nada para esquecer.

Alguns clientes de VPN instalam uma rota predefinida apenas para IPv4 e deixam a rota predefinida IPv6 existente intacta. Verifique a tabela de encaminhamento depois de o túnel ligar, em vez de assumir que o cliente tratou disso.

Prove-o com o túnel caído

Pare o túnel a partir do router e teste a partir de três locais por esta ordem:

# 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 rota diz-lhe para onde iria um pacote, e os contadores dizem-lhe se as suas regras alguma vez corresponderam. Uma regra com zero pacotes após um teste falhado não protege nada, e a causa habitual é um nome de interface diferente do que escreveu. Teste explicitamente o tráfego gerado pelo router, porque um teste do lado da LAN não consegue exercitar a OUTPUT.

Decida o modo de falha antes de precisar dele. O fail-closed mantém os clientes offline até o túnel regressar; o fail-open restaura o acesso normal à WAN e anula o propósito para o tráfego que lhe importava. Uma rota blackhole para o pool da VPN com uma métrica alta é uma segunda camada útil para projetos fail-closed, pois sobrevive quando a rota do túnel desaparece em vez de recair na rota predefinida.

Aceite a configuração apenas quando um cliente da LAN, um pedido gerado pelo router e um pedido IPv6 falharem todos com o túnel caído, e os três voltarem a funcionar assim que ele subir.