Objetivos de aprendizado
Após ler este artigo, você será capaz de:
- Entender por que o WebRTC reúne candidatos de rede
- Distinguir observações locais, públicas e de relay
- Investigar endereços públicos inesperados junto com a conexão web normal
Por que o WebRTC reúne endereços
Participantes em tempo real precisam de uma forma de encontrar uma rota funcional entre si.
O ICE avalia caminhos candidatos. O STUN pode ajudar a descobrir um endereço visível de fora da rede, enquanto o TURN pode retransmitir o tráfego. Os candidatos disponíveis refletem a configuração da conexão e a política do navegador.
A coleta de candidatos é diferente de gravar microfone ou câmera. Se um determinado teste consegue reunir informações sem permissão de mídia depende do navegador e de como o teste é implementado.
O que significam os tipos de candidato
Leia o tipo e a categoria do endereço antes de tirar uma conclusão.
| Observação | Significado | Próxima verificação útil |
|---|---|---|
| Endereço privado, como 192.168.x.x | Um endereço de rede interna | Distinguir a informação local da saída pública |
| Hostname mDNS | Um hostname usado para ocultar um endereço local | Verificar como o navegador representa candidatos de host |
| Candidato público server-reflexive | Um endereço observado por descoberta de endereços | Comparar com a rota de rede pretendida |
| Candidato relay | Uma rota por um servidor de retransmissão | Interpretar como infraestrutura de relay |
Uma página pode receber apenas um subconjunto desses candidatos, ou nenhum candidato utilizável. Um relatório vazio precisa de sua própria explicação: a coleta pode ter sido bloqueada, estar indisponível ou ter falhado.
O que fazer quando WebRTC e HTTP mostram IPs públicos diferentes
Trate a diferença como um motivo para inspecionar o roteamento e as famílias de endereços.
Registre o IP público da requisição web normal, o tipo de candidato e se cada endereço é IPv4 ou IPv6. Um proxy só do navegador, túnel dividido, múltiplas interfaces ou uma conexão dual-stack podem produzir caminhos diferentes.
Depois compare a observação com a configuração que você pretendia. Se o tráfego deveria usar uma única rota de VPN, um candidato fora dessa rota merece investigação. Um endereço privado sozinho não é a mesma observação que um endereço público inesperado.
Execute novamente a verificação de WebRTC dentro do perfil afetado depois de alterar uma configuração relevante. Use a consulta de IP e o teste de DNS separadamente para inspecionar as outras rotas.
Por que testes de rede separados ajudam
Um carregamento de página bem-sucedido prova que uma rota funciona. WebRTC e DNS podem envolver componentes diferentes, então verificá-los separadamente dá uma visão mais clara de qual conexão mudou.
Como interpretar o resultado
- A visibilidade dos candidatos depende da política do navegador e das condições da rede.
- Uma diferença de IP público precisa de contexto de roteamento; não é automaticamente uma medição de localização física.
- Um resultado de WebRTC não audita todas as requisições de rede que um aplicativo faz.
Perguntas frequentes
Um endereço 192.168 é meu IP público?
Não. É um endereço privado usado dentro de uma rede local. Ele deve ser distinguido de um endereço público visível para um serviço externo.
Por que vejo um hostname terminado em .local?
Alguns navegadores usam hostnames mDNS para ocultar endereços locais nos candidatos de WebRTC. Interprete isso como uma escolha de representação, não como um IP de saída público.
Minha página pode usar um proxy enquanto o WebRTC segue outra rota?
Isso é possível dependendo da cobertura do proxy, da configuração do navegador e da política de rede. Compare as observações reais no mesmo perfil.