Se você observar algum dos sintomas abaixo mesmo depois de ligar a VPN, suspeite de um vazamento de DNS ou de WebRTC. Um vazamento ocorre quando as informações que deveriam passar pelo caminho da VPN saem desse caminho (também chamado de exfiltração).
- O IP do servidor VPN é exibido na página de verificação de IP, mas o servidor DNS da empresa de telecomunicações ou roteador é exibido no teste de DNS.
- O endereço IPv4 mudou, mas o endereço IPv6 é o mesmo de antes de desligar a VPN.
- Na página de teste do WebRTC, o IP público aparece como estava antes de desligar a VPN.
- O IP original só é visível imediatamente após mudar de Wi-Fi para dados móveis ou sair do modo de suspensão.
- Ativei o StageVPN para Chrome, mas outros navegadores e programas de PC se conectam usando o IP original.
- Mesmo com a VPN ativada, o site exibe o idioma e o conteúdo com base na região original (isso pode ser devido às configurações da conta/cookies).
O vazamento de DNS é um fenômeno em que a comunicação da web passa pelo túnel quando a VPN está ligada, mas apenas as consultas de DNS saem do túnel e o nome de domínio fica visível para o servidor DNS da empresa de telecomunicações ou Wi-Fi. O vazamento de WebRTC é um fenômeno no qual o WebRTC do navegador envia uma solicitação STUN diretamente da VPN/proxy, permitindo que a página da web descubra o IP público real. Nenhum dos fenômenos significa que o conteúdo da página está vazando. No entanto, revela ‘quem está acessando onde’. Este artigo começa com sintomas e prossegue através de seis estágios de diagnóstico, resolução por causa e reexame.
Diagnóstico: como verificar se há vazamento em 6 etapas
O princípio da verificação de vazamentos é comparar os valores com a VPN desligada e com ela ligada. Compare o IP mostrado no site, o servidor que recebeu a consulta DNS e o endereço do candidato WebRTC. Se os valores originais estiverem visíveis mesmo depois de ligar a VPN, é um vazamento. O teste só faz sentido nos dispositivos e navegadores que você realmente usa. Mesmo que você não tenha um site de teste específico, você pode verificar a maioria das coisas apenas usando um navegador. A página de verificação de IP é uma página da web que exibe o endereço IP público da pessoa conectada na tela. Você pode encontrá-lo em um mecanismo de busca como ‘Verificar IP’. Encontre a página de teste de vazamento de DNS e a página de teste WebRTC da mesma maneira. O princípio é o mesmo, independentemente da página que você usa, então você não precisa depender de um site específico.
- Desligue a VPN e registre seu IP. Abra a página de verificação de IP e anote o endereço IPv4 público e, se houver, o endereço IPv6. Este valor é a base para todas as comparações subsequentes.
- Ligue sua VPN e compare IPs. Após verificar o indicador de conclusão da conexão no aplicativo StageVPN ou o indicador verde LIGADO no ícone StageVPN for Chrome, abra a mesma página novamente. O IPv4 deve ser substituído pelo endereço do seu servidor VPN.
- Verifique seu servidor DNS. Abra a página Teste de vazamento de DNS. Essas páginas consultam subdomínios aleatórios e mostram o servidor DNS que enviou a consulta. Se você conseguir ver os servidores da sua operadora ou roteador, é um vazamento de DNS.
- Abra chrome://webrtc-internals. Inserir este endereço na barra de endereço do Chrome exibirá conexões WebRTC em andamento e endereços de candidatos. O item aparecerá se você tiver a página de teste WebRTC ou a página de videochamada aberta em outra aba.
- Verifique o IP do candidato. Se o endereço do candidato srflx (reflexão do servidor) for igual ao IP público original da etapa 1, então é um vazamento de WebRTC. Se for o IP do servidor VPN ou apenas o nome .local e o IP privado estiverem visíveis, o IP público não será exposto.
- Verifique o IPv6. Se você tinha um endereço IPv6 na etapa 1, ligue a VPN e veja se esse endereço desapareceu ou mudou. Se for esse o caso, o IPv6 está saindo do túnel. Alterne entre Wi-Fi e dados móveis e repita para ver se os resultados são os mesmos após reiniciar o navegador.
| Resultados de observação | significado | Próxima causa |
|---|---|---|
| IP do servidor VPN visível no site | As comunicações pela Web passam pelo caminho VPN | Normal, próximo passo |
| O IPv4 mudou, mas o IPv6 é o endereço original | IPv6 sai do túnel | Causa 2 |
| O servidor DNS é da empresa de telecomunicações ou roteador. | Vazamento de DNS | Causas 1, 3, 4, 5 |
| O servidor DNS é um provedor DNS público | DNS na sua configuração VPN ou um DNS seguro que você mesmo especifica. | Não presuma que é um vazamento apenas com base no nome da empresa, verifique a causa 4 |
| O IP público original é visível no WebRTC | Vazamento de WebRTC | Causas 6 e 7 |
| Apenas nomes .local ou IPs privados são visíveis no WebRTC | IP público não está exposto | geralmente normal |
| IP original somente imediatamente após a troca de rede | lacuna no momento da transição | Causa 8 |
Os resultados podem variar de acordo com o local de teste. Existem locais que visualizam apenas IPv4 e locais que visualizam IPv6, e os métodos para localizar servidores DNS também são diferentes. Compare em mais de um lugar e mude para várias redes.
O que uma consulta DNS revela?
As consultas DNS contêm nomes de domínio. O conteúdo da página ou os valores inseridos não estão incluídos. DNS é o sistema de catálogo de endereços da Internet que converte nomes de domínio lidos por humanos em endereços IP usados por computadores. Cada vez que você digita um endereço em seu navegador ou um aplicativo entra em contato com um servidor, seu dispositivo primeiro pergunta ao servidor DNS 'qual é o endereço deste nome?' Assim, apenas olhando o histórico de consultas, você pode saber muito sobre quando e qual serviço você tentou acessar.
- meu dispositivoAplicativo/navegador
- Consultas DNS de texto simples
- Wi-Fi públicoroteador de café
- Consultas DNS de texto simples
- DNS da operadoraservidor existente
- Áreas que podem ficar expostas
- meu dispositivoAplicativo/navegador
- DNS no túnel
- Wi-Fi públicoroteador de café
- DNS no túnel
- Servidor VPNStageVPN
- Consulta por IP do servidor VPN
- Servidor DNSEspecifique na configuração VPN
- Criptografia VPN
As consultas DNS tradicionais vão para a porta UDP 53 sem criptografia. Para compensar isso, foram criados o DoH (RFC 8484), que agrupa consultas em HTTPS, e o DoT (RFC 7858), que agrupa consultas em TLS. No entanto, mesmo se você usar DNS criptografado, o nome do servidor (SNI) enviado ao se conectar a um site via HTTPS poderá ficar visível na rede se o site e o navegador não suportarem ECH (Encrypted Client Hello).
| método de entrega | Observador no mesmo Wi-Fi | Operadora/empresa de comunicação Wi-Fi | Servidor DNS recebendo a consulta |
|---|---|---|---|
| DNS simples (texto não criptografado) | posso ver | posso ver | Visível, com meu IP público |
| DoH/DoT (DNS criptografado) | não consigo ver | Não visível, os endereços dos servidores DNS estão visíveis | Visível, com meu IP público |
| DNS dentro de um túnel VPN | não consigo ver | Não visível, apenas vê que está se comunicando com o servidor VPN | Visível, com IP do servidor VPN |
| Status de vazamento de DNS | Se for texto simples, você poderá vê-lo. | posso ver | Visível, com meu IP público |
DNS seguro (DoH) e VPN têm finalidades diferentes. DoH criptografa apenas consultas DNS; o próprio acesso do site e os IPs que o site vê permanecem os mesmos. Uma VPN criptografa toda a comunicação entre o seu dispositivo ou navegador e o servidor VPN e altera o IP que os sites veem. O modo de navegação anônima também não impede vazamentos. O modo de navegação anônima é uma função que não deixa histórico ou cookies no dispositivo e não altera consultas DNS ou rotas WebRTC.
Como o WebRTC determina um endereço IP?
O WebRTC encontra seu próprio endereço de várias maneiras para conectar dois dispositivos pelo caminho mais curto e passa os resultados para o script na página da web. WebRTC é uma tecnologia padrão da web que permite fazer chamadas de vídeo, chamadas de voz e transferências de arquivos sem plug-ins no navegador. O processo de coleta de endereços é denominado ICE (RFC 8445). Mesmo páginas que não fazem videochamadas podem iniciar esse processo com um script.
- Criar objeto de conexãoO script da página da Web cria RTCPeerConnection
- Reúna candidatos locaisSeu navegador coleta os endereços dos dispositivos de rede do seu dispositivo
- Consulta STUNPergunte ao servidor STUN 'como é meu endereço' com UDP
- Entrega do candidatoUma lista de candidatos incluindo endereços públicos fornecidos pelo servidor STUN é entregue na página.
| Tipo de candidato | algo | Informações que podem ser reveladas | Proteção de navegadores recentes |
|---|---|---|---|
| hospedar | Endereço do dispositivo de rede da máquina | IP privado (192.168.x, etc.) | Mascarado com um nome .local aleatório (mDNS), mas pode ser visto em sites que concederam permissões de câmera e microfone. |
| srflx (reflexão do servidor) | Meu endereço público visto pelo servidor STUN | IP público, IP real se você ignorar o proxy | Pode ser restringido pela política de processamento de IP WebRTC |
| relé | TURN Endereço do servidor de retransmissão | IP do servidor de retransmissão | Se você usar retransmissão, a outra parte verá o endereço do servidor em vez do seu IP. |
O problema é a consulta STUN na etapa 3. Os proxies do navegador encaminham solicitações da web, mas as comunicações UDP do WebRTC não passam pelo proxy nas configurações padrão do navegador. Portanto, o endereço fornecido pelo servidor STUN não é o servidor proxy, mas meu IP público original. As coisas são diferentes com VPNs para todo o dispositivo. Como toda a comunicação UDP, incluindo solicitações STUN, vai para o túnel, o endereço visto pelo servidor STUN também é o IP do servidor VPN.
Proxy do navegador e política padrão
- As solicitações da Web passam por um proxy
- Solicitações STUN vão diretamente para UDP
- A página pode ver IP público real
Proxy do navegador e disable_non_proxied_udp
- Impedir que o UDP passe pelo proxy
- WebRTC usa apenas caminhos de proxy
- Algumas chamadas têm diferentes métodos de conexão ou qualidade
VPN para todo o dispositivo
- As solicitações STUN também passam pelo túnel.
- O candidato a endereço público é o IP do servidor VPN
- A desconexão e o tratamento do IPv6 exigem confirmação
O Chrome tem uma ‘política de tratamento de IP WebRTC’ que determina qual endereço o WebRTC usará e as extensões podem alterar esse valor. Cada valor corresponde a quatro métodos descritos na Recomendação de Tratamento de Endereço IP WebRTC da IETF (RFC 8828).
| valor da política | movimento | faixa de exposição |
|---|---|---|
| padrão | Colete candidatos de todos os dispositivos de rede | Mais amplo (endereços locais mascarados por mDNS) |
| default_public_and_private_interfaces | Use apenas dispositivos na rota padrão, use endereços públicos e privados | Não expõe endereços de outros dispositivos |
| default_public_interface_only | Use apenas endereços públicos da rota padrão | Endereços privados não são expostos |
| desativar_não_proxied_udp | Sem UDP por meio de proxy, use TCP por meio de proxy se o proxy não suportar UDP | Não exponha endereços de rotas fora do proxy |
Solução: como verificar e corrigir por causa
A maioria dos vazamentos tem uma das oito causas: Geralmente é causada por configurações sobrepostas. Comece verificando o número da causa apontada na tabela de diagnóstico e, cada vez que corrigir uma, repita o passo 6 da imagem acima para ver se o resultado mudou. Se você alterar várias configurações de uma vez, não saberá o que funcionou.
Causa 1 · Não há servidor DNS na configuração VPN ou o dispositivo utiliza um DNS diferente.
verificar Com a VPN ativada, o teste de DNS mostra o roteador Wi-Fi ou o servidor DNS da operadora. Muitas vezes você tem DNS manual nas configurações de Wi-Fi do seu dispositivo.
resolver O aplicativo StageVPN inclui um servidor DNS na configuração VPN e envia consultas para o túnel. Reverta o DNS manual para automático nas configurações de rede do seu dispositivo, desconecte e reconecte à VPN. Se o problema persistir, verifique as causas 3 e 5.
Causa 2 IPv6 sai do túnel
verificar O IPv4 foi alterado para o endereço do servidor VPN, mas o IPv6 permanece o mesmo que o valor anotado na etapa 1. Se a VPN apenas encapsular IPv4, as consultas e comunicações IPv6 sairão da rota original.
resolver O aplicativo StageVPN também está configurado para enviar comunicações IPv6 para o túnel (AllowedIPs 0.0.0.0/0, ::/0), portanto, geralmente não há necessidade de desligá-lo. Se o IPv6 ainda aparecer como deveria, primeiro verifique se outro aplicativo VPN ou configurações do dispositivo estão alterando a rota. Alguns sites de teste não suportam IPv6, portanto compare em mais de um site.
Causa 3 · O sistema operacional consulta o DNS de vários dispositivos de rede simultaneamente.
verificar Especialmente durante uma conexão VPN em um PC com Windows, o teste de DNS mostra o DNS da VPN e o DNS da sua operadora. Isso é causado por um recurso que solicita todos os dispositivos de rede simultaneamente, como a resolução de nomes Smart Multi-Homed do Windows.
resolver Mantenha seu sistema operacional e software VPN atualizados e repita os testes. Esse fenômeno é relatado principalmente com VPNs em todo o dispositivo em PCs e não ocorre da mesma forma no aplicativo StageVPN em smartphones e no StageVPN para Chrome no Chrome devido a estruturas diferentes.
Causa 4 · O DNS seguro (DoH) é especificado separadamente no navegador ou dispositivo
verificar O teste DNS mostra servidores de provedores DNS públicos. Nesse caso, pode não ser um vazamento, mas uma configuração que você mesmo especificou. Se você tiver uma VPN para todo o dispositivo, essa consulta também passará pelo túnel, mas será recebida pelo provedor especificado, e não pelo DNS na sua configuração VPN.
resolver Se esta for a configuração pretendida, você pode deixá-la como está. Se você quiser usar DNS para sua configuração de VPN, isso alterará automaticamente as configurações de DNS seguro em seu navegador e dispositivo. É importante não presumir que se trata de um vazamento apenas olhando o nome da empresa.
Causa 5 · Outros aplicativos de VPN, proxy e segurança também estão ativados
verificar Os recursos de rede de outros aplicativos VPN, extensões de proxy, filtros de anúncios ou programas de segurança são ativados ao mesmo tempo. As configurações de rota se sobrepõem, fazendo com que algumas consultas sigam para a rota original.
resolver Ligue apenas um de cada vez. Desligue outros aplicativos e extensões, desconecte e reconecte o StageVPN e repita a etapa 6. As configurações de proxy do Chrome só podem controlar uma extensão por vez, portanto, se outra extensão estiver usando um proxy, o StageVPN para Chrome não se conectará e lhe dirá o porquê.
Causa 6 · Somente proxy do navegador é usado, mas é esperada comunicação fora do navegador
verificar Ativei o StageVPN para Chrome, mas outros navegadores, mensageiros de PC e programas de e-mail se conectam usando o IP original e o DNS original. Isto não é um vazamento, esta é a faixa projetada. A extensão cobre apenas a comunicação no Chrome.
resolver Se você precisar proteger programas fora do Chrome, use uma VPN que se aplique a todo o dispositivo. Nos smartphones, o aplicativo StageVPN faz exatamente isso. A diferença de escopo entre os dois métodos é VPN de navegador versus VPN de aplicativoEu organizei em .
Causa 7 Política WebRTC não aplicada
verificar Ativei o StageVPN para Chrome e posso ver o IP público original no teste WebRTC ou no candidato srflx em chrome://webrtc-internals. Se outra extensão ou política de gerenciamento de empresa/organização controlar primeiro as configurações do WebRTC, o StageVPN for Chrome não alterará a política e a deixará como está.
resolver Desative quaisquer outras extensões que controlem as configurações do WebRTC e reconecte o StageVPN for Chrome. Se a causa for a política de gerenciamento, entre em contato com seu administrador. Para escrever em uma janela anônima, você deve ativar ‘Permitir modo anônimo’ na tela de gerenciamento de extensões. Quando desativado, as comunicações em janelas anônimas não passam pelo proxy.
Causa 8 · No momento em que a conexão VPN é perdida
verificar O IP original fica visível apenas imediatamente após trocar de rede ou sair do modo de suspensão e, depois de um tempo, volta ao normal. Durante a desconexão, todas as consultas e comunicações saem pela rota normal.
resolver Antes de realizar qualquer trabalho delicado, verifique se o indicador de conclusão de conexão do aplicativo ou o ícone da extensão estão LIGADOS. O WireGuard, usado pelo aplicativo StageVPN, não restabelece um túnel mesmo ao mudar de Wi-Fi para LTE, mas o protocolo não consegue compensar desconexões temporárias na própria rede. A capacidade de bloquear automaticamente as comunicações quando a VPN é desconectada não é um recurso fornecido pelo StageVPN. O princípio é Explicando os princípios do WireGuardEstá em
Como os aplicativos StageVPN e StageVPN para Chrome impedem vazamentos?
O aplicativo StageVPN reduz o vazamento ao encapsular toda a comunicação, enquanto o StageVPN para proxies Chrome faz pesquisas de nomes e ajusta as políticas WebRTC. Dado que o âmbito da protecção é diferente, a forma como é tratada também é diferente.
| item | Aplicativo StageVPN (iPhone·iPad·Android) | StageVPN para Chrome |
|---|---|---|
| faixa de proteção | Todos os dispositivos | Navegador Chrome |
| Comunicações enviadas via rota VPN | IPv4·IPv6 Todos (IPs permitidos 0.0.0.0/0, ::/0) | As solicitações da Web passam por proxy (excluindo bandas de IP privadas e localhost) |
| Consultas DNS | Encaminhe dentro do túnel para o servidor DNS especificado na configuração da VPN. | As solicitações que passam por um proxy não são pesquisadas pelo Chrome, mas pelo servidor proxy. |
| WebRTC | Toda a comunicação UDP passa pelo túnel. | disable_non_proxied_udp é aplicado durante a conexão e retorna à configuração original quando desconectado. |
| O que você vê atualmente na rede | O fato de haver comunicação criptografada com o servidor VPN e a quantidade de dados | Pesquisa de nomes de endereços de servidores proxy, conexões criptografadas com o proxy e comunicação de aplicativos fora do Chrome |
| Casos que podem não se aplicar | Enquanto a conexão VPN for perdida, quando outro aplicativo VPN redirecionar | Janela anônima com Permitir modo de navegação anônima desativada quando outra extensão ou política de gerenciamento controla as configurações de proxy/WebRTC |
| Histórico de acesso (93 dias) | Domínios visualizados não são registrados | O nome do host de destino conectado é registrado, mas o caminho ou termo de pesquisa não é registrado. |
StageVPN não orienta você através de um menu separado de configurações de proteção contra vazamento de DNS como um recurso de suas ofertas. O comportamento acima depende da configuração VPN padrão do aplicativo e do método de conexão da extensão. O âmbito da disposição é Recursos e escopo da ofertaVocê pode conferir aqui.
Nenhum vazamento significa que as consultas e comunicações passam pelo caminho da VPN em vez da operadora. Isso não significa que nenhum registro será mantido. StageVPN retém registros de acesso por 93 dias de acordo com a Lei de Proteção de Segredos de Comunicações e não registra conteúdo de comunicação. O item é Acesse o aviso de armazenamento de registrosBem, a razão pela qual estou revelando isso é Por que divulgamos nossa política de retenção de registros de acesso?explicou.
Verifique novamente a lista de verificação: O que você verifica novamente depois de fazer alterações?
Cada vez que você corrigir uma causa, verifique novamente os itens abaixo desde o início. Se tudo passar, não há vazamento. Se algum item falhar, ele retorna para a carta de causa correspondente.
- Depois de desconectar e reconectar a VPN, verifiquei se o aplicativo mostrava conclusão da conexão ou se o ícone de expansão estava LIGADO.
- Na página de verificação de IP, você verá o endereço do servidor VPN para IPv4 e IPv6 ou não verá IPv6.
- O teste DNS não mostra o servidor DNS da empresa de telecomunicações ou roteador.
- O candidato srflx em chrome://webrtc-internals não possui o IP público original.
- Os recursos de rede de outros aplicativos VPN, proxies/extensões VPN e programas de segurança estão desativados.
- Se você configurou DNS manual ou DNS seguro para seu dispositivo e navegador, você verificou que esta é a configuração pretendida.
- Seu sistema operacional, navegador e aplicativos e extensões StageVPN estão atualizados.
- O mesmo resultado mesmo depois de alternar entre Wi-Fi e dados móveis e reiniciar o navegador.
- Se precisar proteger programas fora do Chrome, você pode usar uma VPN para todo o dispositivo em vez de uma extensão.
Também é uma boa ideia determinar quando a reinspeção é necessária. Isso ocorre após uma grande atualização em seu sistema operacional ou navegador, após instalar uma nova extensão ou aplicativo de segurança ou antes de realizar qualquer trabalho confidencial em uma rede à qual você está se conectando pela primeira vez. Se as configurações forem as mesmas, mas os resultados tiverem mudado, uma dessas três coisas geralmente é a causa. Depois de pegar o jeito, as 6 etapas do diagnóstico podem ser concluídas em apenas alguns minutos.
Se o problema persistir, organize o modelo do dispositivo, o sistema operacional e a versão do aplicativo, o horário da ocorrência e os resultados dos testes. suporte ao clienteEntre em contato conosco. Por favor, não envie sua senha ou código de verificação. As configurações do dispositivo a serem verificadas juntamente com a verificação de vazamentos são: 10 configurações de privacidade do smartphoneBem, existem riscos que não podem ser resolvidos apenas com uma VPN. O que as VPNs impedem e não podem impedirBem, seus hábitos em redes públicas são Regras de segurança de Wi-Fi públicoEu organizei em .
material de referência
- RFC 1034: Nomes de Domínio – Conceitos e Instalações — Estrutura do DNS e o papel dos resolvedores (IETF)
- RFC 8484: Consultas DNS sobre HTTPS (DoH) — Como criptografar consultas DNS sobre HTTPS (IETF)
- RFC 7858: DNS sobre TLS — Como criptografar consultas DNS com TLS (IETF)
- RFC 8445: Estabelecimento de conectividade interativa (ICE) — Tipos de candidatos a conexão WebRTC e procedimentos de coleta (IETF)
- RFC 8828: Requisitos de tratamento de endereço IP WebRTC — Faixa de endereços que os navegadores expõem ao WebRTC (IETF)
- API chrome.privacy — Valores da política de tratamento de IP WebRTC do Chrome (Chrome para desenvolvedores)
- API chrome.proxy — Configurações de proxy de extensão, lista de ignorados e prioridades de controle (Chrome for Developers)
- API WebRTC — RTCPeerConnection e o conceito de candidatos ICE (MDN Web Docs)
