Fuga de IPv6 com VPN: o seu sistema prefere IPv6, e é exatamente por isso que há fuga

A sua VPN está ligada. O túnel está ativo, o cliente diz protegido, e o seu tráfego IPv4 passa mesmo por ele. E um site que visita regista na mesma o seu endereço real, porque o alcançou por IPv6.

Não há aqui qualquer avaria para encontrar. São dois sistemas corretos que não concordam, e esse desacordo está escrito numa norma.

O seu sistema não se está a portar mal, está a aplicar a RFC 6724

Quando um destino é acessível tanto por IPv4 como por IPv6, algo tem de escolher. Esse algo é a RFC 6724, que define uma tabela de política por omissão para a seleção de endereços. Três das suas linhas contam aqui:

Prefix        Precedence Label
::1/128               50     0
::/0                  40     1
::ffff:0:0/96         35     4

::/0 é o IPv6 em geral. ::ffff:0:0/96 é a forma como os endereços IPv4 são representados nessa tabela. Quarenta ganha a trinta e cinco, e a regra de seleção de destino é explícita: se Precedence(DA) > Precedence(DB), então prefere-se DA.

A RFC enuncia a consequência em linguagem clara em vez de o deixar deduzi-la: outro efeito da tabela de política por omissão é preferir a comunicação com endereços IPv6 à comunicação com endereços IPv4, se houver endereços de origem correspondentes disponíveis.

Assim, para cada site de dupla pilha que visita, o seu sistema operativo procura primeiro o IPv6. É um comportamento correto, e é muito anterior à sua VPN.

Porque é que isso se torna uma fuga

Ponha agora por cima uma VPN que só transporta IPv4.

A sua máquina mantém um endereço IPv6 nativo do seu operador. O túnel não reclama o tráfego IPv6, portanto nada o interceta. O seu sistema, seguindo a regra acima, prefere o IPv6 para qualquer destino que o ofereça. O resultado é que o seu caminho preferido é o que contorna o túnel, e o caminho protegido só recebe aquilo que o IPv6 não conseguiu servir.

É por isso que a fuga passa tão facilmente despercebida. Não parece uma avaria. A sua VPN indica ligado porque está. As suas verificações IPv4 passam porque passam mesmo. O tráfego que escapa é precisamente aquele que o seu sistema julgou melhor.

Verificar, e o erro que torna a verificação inútil

A verificação é simples: com a VPN ligada, veja o que um site vê realmente, e leia especificamente a linha IPv6 em vez de dar uma olhadela à IPv4 e seguir em frente.

Se o endereço IPv6 apresentado pertencer à sua ligação em vez de ao fornecedor de VPN, o IPv6 está fora do túnel. Se não aparecer nenhum endereço IPv6, ou a sua rede não tem ou está bloqueado, e ambos os casos são sãos do ponto de vista das fugas.

Duas coisas arruínam esta verificação na prática:

Testar antes de ligar. A questão não é o aspeto que tem sem proteção. É o que escapa enquanto se julga protegido.

Testar uma só vez. Uma configuração que hoje transporta IPv6 pode deixar de o fazer após uma reconexão, uma mudança de rede ou a passagem do Wi-Fi para os dados móveis, porque os endereços disponíveis mudam com a rede. Um único resultado limpo prova que a configuração estava correta numa rede, num momento.

A linha que decide, no WireGuard

O WireGuard torna a causa invulgarmente legível, porque a mesma definição decide ao mesmo tempo o que entra e para onde as coisas saem. O manual wg define AllowedIPs como uma lista de endereços IP (v4 ou v6) separados por vírgulas, com máscaras CIDR, a partir dos quais o tráfego de entrada para este par é permitido e para os quais o tráfego de saída deste par é dirigido, e acrescenta que o coringa 0.0.0.0/0 pode ser indicado para todos os endereços IPv4, e ::/0 para todos os endereços IPv6.

Leia isto como uma instrução de encaminhamento, porque é o que é. Um par configurado apenas com 0.0.0.0/0 dirige o IPv4 para o túnel e nada diz sobre o IPv6, que continua portanto a usar a rota normal. Acrescentar ::/0 encaminha também o IPv6 para lá.

Aplica-se uma condição: o túnel precisa de um endereço IPv6 próprio para que isto sirva. Se o seu fornecedor não atribuir nenhum, encaminhar ::/0 para um túnel sem extremidade IPv6 não cria conectividade IPv6. É nessa altura que bloquear o IPv6 passa a ser o recuo honesto e não um atalho.

Bloquear o IPv6 funciona, e custa alguma coisa

Desativar o IPv6 na máquina elimina o caminho preferido, pelo que tudo recai no IPv4 e entra no túnel. É eficaz, e é o que fazem vários clientes de VPN sob a designação proteção contra fugas de IPv6.

O custo é real, ainda assim. Perde o IPv6 para tudo o resto nessa máquina, incluindo redes onde é o único transporte utilizável, e a definição sobrevive ao motivo que o levou a alterá-la. Seis meses depois, um problema de conectividade sem qualquer relação torna-se dificílimo de diagnosticar porque já ninguém se lembra de que o IPv6 estava desligado.

Encaminhar o IPv6 pelo túnel mantém a capacidade e resolve o mesmo problema. Prefira-o sempre que o seu fornecedor o permita, e trate o bloqueio como o recuo para quando não permitir.

O kill switch não cobre este caso

Convém dizê-lo à parte, porque os dois se confundem no mesmo ecrã de definições.

Um kill switch vigia a queda do túnel e corta o tráfego quando ela ocorre. Uma fuga de IPv6 acontece com o túnel ativo. Não há queda a detetar, nem evento de falha, nem nada a que o interruptor possa reagir. Um kill switch a funcionar na perfeição ficará ali a fazer o seu trabalho impecavelmente enquanto o tráfego IPv6 lhe passa à frente.

Se o seu cliente oferecer proteção contra fugas de IPv6 como interruptor separado, é um mecanismo diferente, e ter um não lhe dá o outro.

Em resumo

Uma fuga de IPv6 não é a sua VPN a avariar. É a RFC 6724 a dizer ao seu sistema para preferir o IPv6, um túnel que só transporta IPv4, e a consequência perfeitamente lógica destes dois factos.

Verifique com a VPN ligada, leia a linha IPv6, e repita depois de mudar de rede. No WireGuard, é AllowedIPs que decide, e ::/0 é o que encaminha o IPv6 para o túnel. Onde o túnel não tiver IPv6 próprio, bloquear o IPv6 é um recuo legítimo, com um custo que convém anotar nalgum sítio onde o volte a encontrar.

A tabela de política por omissão, os valores de precedência, a regra de seleção de destino e a afirmação de que a tabela prefere a comunicação IPv6 à IPv4 provêm da RFC 6724. A definição de AllowedIPs e a notação coringa para 0.0.0.0/0 e ::/0 provêm da página de manual wg(8). Ambas foram consultadas no momento da redação.

Guias relacionados

• Auditoria de segurança VPN completa - as sete verificações que vale a pena fazer uma vez, e esta é uma delas.
• O kill switch de VPN explicado - o mecanismo que trata o caso inverso, quando o túnel cai de verdade.