Confira IPv4 e IPv6 ao verificar sua VPN

Uma página de endereço público pode mostrar um IPv4 diferente depois que você conecta a VPN e ainda deixar uma pergunta importante sem resposta: o que acontece quando um aplicativo usa IPv6? Muitas conexões do dia a dia podem usar mais de uma família de endereços, enquanto algumas redes fornecem apenas uma. Uma verificação útil considera o que está disponível e o que a configuração escolhida deve fazer. O objetivo não é forçar IPv6 em todo lugar nem desativá-lo sempre. É evitar tratar uma solicitação bem-sucedida como descrição completa de todas as rotas possíveis no dispositivo.

Comece a verificação IPv6 pelo resultado esperado

Pergunte se o cliente e a configuração devem transportar IPv6, bloqueá-lo fora do túnel ou seguir outro arranjo documentado. São políticas diferentes. A falta de resultado IPv6 pode ser esperada em uma configuração e representar falha em outra. Sem o comportamento pretendido, fica difícil interpretar o teste.

O endereço do servidor e o tráfego dentro do túnel também são conceitos distintos. Conectar ao servidor VPN por um endereço IPv4 não estabelece, sozinho, quais famílias o túnel transporta. Da mesma forma, ver um servidor IPv6 não prova que todos os aplicativos usarão IPv6 depois. A capacidade depende da configuração completa e da rede ao redor.

Leia as orientações do protocolo e do cliente antes de editar qualquer coisa. A comparação entre VLESS e WireGuard ajuda a identificar o tipo de configuração, mas o nome de um protocolo não é uma política de roteamento. Registre aplicativo, versão, configuração escolhida e a existência de túnel dividido ou exceções locais.

Descubra o que a rede comum oferece

Quando for adequado fazer uma comparação sem VPN e sem atividade sensível, determine se a rede de acesso tem IPv4, IPv6 ou ambos funcionando. Não desconecte um túnel de trabalho obrigatório nem exponha atividades sensíveis só para criar uma referência. Se a política não permite a comparação, registre essa limitação e peça ao administrador um método aprovado.

Use um diagnóstico que apresente as famílias separadamente. Uma página com apenas um endereço pode ter usado simplesmente o primeiro caminho funcional. A especificação Happy Eyeballs do IETF descreve como aplicativos tentam endereços ou famílias alternativos para reduzir a demora da conexão. Isso ajuda a usabilidade, mas significa que carregar uma página não demonstra necessariamente que os dois caminhos funcionam.

Vincule a observação à rede real. Um resultado no Wi-Fi de casa não descreve os dados móveis, e um notebook conectado ao hotspot não equivale necessariamente ao telefone que fornece a conexão. Anote o método de acesso e o horário. Se o teste disser que IPv6 está indisponível, não invente um endereço nem classifique a ausência como vazamento só para preencher a tabela.

Repita as observações com o túnel ativo

Conecte a configuração pretendida e faça solicitações novas usando o mesmo dispositivo e aplicativo. Registre o resultado IPv4 e, quando disponível, IPv6 separadamente. Anote falhas como falhas, em vez de descartá-las porque outra página carregou. Mantenha o mesmo servidor durante a comparação.

Um teste no navegador mede as solicitações do navegador. Se outro aplicativo importa, use um diagnóstico adequado ou peça um ao suporte. Exceções, proxies do sistema e comportamento de rede próprio do aplicativo podem mudar o alcance. O guia de status da VPN explica por que o indicador de conexão é um ponto de partida, não a prova de todas as conexões seguintes.

Se um resultado parecer mostrar o endereço do provedor comum onde você esperava um caminho protegido, pare de usar essa configuração para tarefas sensíveis até conferir a política. Preserve a observação de forma privada e descreva-a com precisão. Não publique configurações completas nem chaves junto com o teste de endereço. Em geral, o suporte precisa primeiro do cliente e do comportamento esperado, antes de qualquer segredo de acesso.

Interprete endereços com mais cuidado que rótulos de país

Uma consulta pode associar uma organização ou um país ao endereço observado. Esses rótulos oferecem contexto, mas não são uma medição definitiva da localização física. Bases diferentes podem discordar, e IPv4 e IPv6 do mesmo serviço podem receber classificações distintas.

Para verificar o roteamento, compare os endereços observados com o que o provedor espera daquela configuração. Trate o comportamento de localização como outra questão. Nosso artigo sobre país da VPN e idioma do site explica por que a preferência de idioma não resolve o problema sozinha. Uma interface russa ou uma página de busca em inglês não substitui a verificação das famílias de endereços.

Use um registro simples com quatro entradas: IPv4 comum, IPv6 comum, IPv4 no túnel e IPv6 no túnel. Marque explicitamente itens indisponíveis ou não testados. Acrescente a política pretendida logo abaixo. Assim fica mais fácil diferenciar uma família não suportada, uma rota direta inesperada e uma divergência no rótulo geográfico, sem resumir tudo a “a VPN está quebrada”.

Não repare rotas adivinhando campos de configuração

Não adicione nem remova rotas amplas só porque aparecem em um exemplo de fórum. A documentação de VPN do Android, por exemplo, descreve rotas separadas que abrangem todos os destinos IPv4 e IPv6. Essas opções afetam quais destinos entram na interface virtual; não são linhas decorativas para copiar sem compreender o restante da configuração.

O mesmo cuidado vale para arquivos importados manualmente. Uma mudança de roteamento pode afetar a disponibilidade do DNS, os serviços locais e a capacidade de reconectar. Guarde com segurança o arquivo original funcional e use a configuração suportada pelo provedor para seu cliente. Nunca publique uma configuração para perguntar se uma linha parece correta.

Se a solução suportada bloqueia de propósito uma família indisponível, confirme esse comportamento pelos controles documentados do cliente. Desativar IPv6 de forma geral no sistema ou no roteador pode afetar outros aplicativos e usuários. Faça isso apenas com uma razão clara e autorização adequada, não como solução universal para um resultado inexplicado em um único site.

Verifique novamente quando a rede de acesso mudar

O resultado do Wi-Fi de ontem não garante o mesmo comportamento na rede móvel de hoje. Repita a pequena observação após uma atualização importante do cliente, troca de configuração ou mudança no método de acesso de que depende. Não é preciso testar sem parar uma configuração inalterada; foque nas transições que podem modificar os caminhos disponíveis.

Se o caso continuar sem solução, envie à Ajuda da Lumeraya a versão do cliente, o tipo de rede, a política esperada e os resultados separados das duas famílias. Informe se foi possível obter a referência sem VPN. Não inclua chaves privadas nem afirme uma falha geral quando apenas um aplicativo foi testado.

Uma verificação clara das duas famílias termina com uma conclusão delimitada: o caminho IPv4 observado se comportou como esperado, o IPv6 também ou estava intencionalmente indisponível, e as dúvidas restantes estão identificadas. Isso é mais útil do que um único endereço tranquilizador, pois liga o resultado à configuração real e ao tráfego que você pretende proteger.