O kill switch só bloqueia IPv4: por que o IPv6 ainda escapa

O túnel cai, o kill switch informa que atuou e um download continua. Nada está quebrado nas regras de IPv4. A aplicação simplesmente mudou para um caminho para o qual essas regras nunca foram escritas.

Dispositivos de pilha dupla têm duas saídas independentes. Um bloqueio numa delas é meio bloqueio.

Dois conjuntos de regras, dois padrões

No Linux, iptables e ip6tables são tabelas separadas com políticas separadas. Definir as cadeias INPUT e OUTPUT da tabela IPv4 como DROP não muda nada na tabela IPv6, onde o padrão costuma ser ACCEPT. A mesma divisão existe no nftables, onde é possível inspecionar uma família e descobrir que apenas uma delas carrega as suas regras. Essa assimetria é normal, e é todo o problema.

Por isso um kill switch pode parecer completo e se comportar parcialmente. O script que escreveu as regras de IPv4 foi executado, os contadores aumentam, a linha de log aparece e um pacote IPv6 sai pela interface física completamente intacto.

Leia o que o seu cliente realmente instala em vez do que a página de marketing promete. Alguns clientes roteiam IPv6 para o túnel, outros o bloqueiam deliberadamente, e outros o deixam em paz enquanto um bloqueio no nível da plataforma aplica outra regra. A documentação do fornecedor é a única fonte em que vale a pena confiar aqui.

O que a configuração da interface lhe diz

A página do manual do wg-quick inclui regras IPv6 na configuração de exemplo, e a razão é exatamente esta lacuna. O exemplo não é decoração. Ele existe porque apenas as regras de IPv4 deixariam a segunda família aberta.

Copiar metade de um exemplo produz metade de uma política. Essa é a origem mais comum desse vazamento. Um post de blog encurtou o exemplo por questões de tamanho. A versão encurtada então se tornou o modelo que todo mundo reutilizou.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Se o segundo comando imprime uma política permissiva enquanto o primeiro imprime DROP, você encontrou a resposta sem tocar no cliente. Essa assimetria é o defeito.

Por que uma única consulta não é a história toda

Um único nome pode retornar tanto um registro A quanto um registro AAAA, e as aplicações não escolhem todas da mesma forma. Um navegador pode preferir IPv6 quando a rede o oferece e recuar em caso de falha, enquanto uma sincronização em segundo plano ou um atualizador usa o próprio resolvedor e a própria preferência. Portanto, um teste bem-sucedido sobre IPv4 prova um caminho, não a política.

As transições de rede também mudam a resposta. Entrar noutra rede Wi-Fi, retomar da suspensão ou passar para a rede móvel pode dar ao dispositivo um novo prefixo IPv6, e a política que parecia adequada na LAN do escritório pode não cobri-lo.

Teste o estado em que o túnel está desligado

Testar enquanto está conectado diz que o túnel funciona. O teste interessante é o estado indisponível, porque é aí que o kill switch deveria aguentar. Pare o túnel de propósito e depois experimente os destinos que importam a partir da aplicação que você protege.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

As duas famílias devem falhar fechadas. Se o pedido IPv4 expirar e o pedido IPv6 devolver um código de estado, a política está incompleta, e nenhuma quantidade de novo teste do túnel mudará isso.

Mantenha também as exceções documentadas nesse teste. A descoberta da rede local, uma renovação de DHCP ou o caminho de inicialização até o endpoint da VPN podem precisar continuar alcançáveis, e essas exceções devem ser nomeadas na política em vez de descobertas durante uma interrupção. Um teste de vazamento que falha porque o túnel não consegue voltar não é um achado de segurança, é um achado de conectividade.