Qual camada de IP a página de consulta mostra?
Ao abrir a página Consulta de IP, você vê o endereço de saída visível para esse serviço na solicitação atual. Se o serviço usar um proxy reverso confiável, ele geralmente também resolve o endereço do cliente encaminhado conforme sua própria configuração. Isso não necessariamente equivale ao endereço da placa de rede do computador: em redes IPv4 domésticas, normalmente há uma tradução de endereço de rede (NAT), e pode haver outra camada de NAT, proxy ou VPN a montante. É preciso registrar separadamente o "endereço do terminal", o "endereço WAN do roteador" e o "valor observado na web", em vez de chamá-los todos de seu IP público.
Se proxies e VPNs alteram a saída web depende das regras específicas de roteamento e divisão de tráfego. Um proxy de navegador pode encaminhar apenas solicitações web, e uma VPN de sistema também pode transportar somente segmentos de rede internos da empresa; apenas a configuração de túnel completo envia o tráfego de internet correspondente para o gateway VPN. Portanto, diferentes aplicativos no mesmo dispositivo, assim como conexões IPv4 e IPv6, podem usar saídas diferentes. Uma consulta web sozinha não pode determinar quem atribui o endereço, se ele é exclusivo ou se o dispositivo está usando VPN; é preciso combinar com a configuração de rede efetivamente ativa no momento.
Endereços privados ou compartilhados normalmente devem ser procurados no status da placa de rede local, do modem ou do WAN do roteador. Uma consulta normal à internet pública não deve tratar endereços RFC 1918 ou RFC 6598 como saída de cliente roteável globalmente; se a página exibir esses valores, verifique primeiro se são informações locais ou um problema de configuração de encaminhamento. Se o endereço é público não é o mesmo que reputação: endereços roteáveis podem ter histórico de abuso, e endereços privados não podem participar diretamente da comparação de reputação pública. Para detalhes, consulte Reputação de IP: como interpretar riscos e bloqueios.
Dispositivo, roteador e operadora: relações de endereços em quatro camadas
Primeiro, entenda os endereços em quatro posições. A primeira camada é o endereço usado pelo terminal na rede local, por exemplo 192.168.50.8; a segunda camada é a interface WAN do roteador doméstico, que pode obter um endereço público ou um endereço privado atribuído pelo modem a montante; a terceira camada é a rede da operadora, onde em implantações de CGNAT o endereço do lado do usuário passa por tradução da operadora e se comunica externamente com um endereço público, podendo o lado do usuário usar 100.64.0.0/10; a quarta camada é a origem da solicitação observada pelo serviço de destino. Se houver proxy, o destino verá a saída do proxy.
Abaixo está um caso claramente marcado como ilustrativo de NAT duplo doméstico. Suponha que o modem de um usuário esteja configurado pela operadora em modo roteador, com endereço LAN 192.168.1.1, e a operadora atribuiu à interface WAN o IP público 203.0.113.10 (endereço ilustrativo, não um endereço real de usuário). O usuário também conectou um roteador sem fio, cujo WAN obtém 192.168.1.100 do modem e cuja LAN é 192.168.50.1. O celular do usuário recebeu o endereço 192.168.50.8. Quando o celular acessa um site de consulta de IP, os pacotes passam primeiro pelo roteador sem fio, que altera o endereço de origem para 192.168.1.100, e depois o modem o altera para 203.0.113.10; o servidor final vê 203.0.113.10. O celular do usuário vê localmente o IP da LAN 192.168.50.8, e o painel do roteador mostra o IP WAN 192.168.1.100; nenhum dos dois é um endereço público, mas a saída final é um endereço público. Este caso serve apenas para ilustrar a ordem de tradução de endereços e não representa nenhum ambiente real de usuário.
Se o WAN do roteador for 100.64.0.2 e a saída web for outro IPv4 roteável globalmente, isso é consistente com tradução de endereços a montante, mas ainda é preciso confirmar a arquitetura específica com a operadora. Se o WAN for 192.168.1.2, pode ser modo roteador no modem, um segundo roteador ou um gateway corporativo; esse valor por si só não informa qual dispositivo fez o NAT. Registrar a topologia e as funções de cada interface é mais útil para o diagnóstico do que capturar apenas um endereço.
Identificação precisa de endereços privados e espaço de endereçamento compartilhado
A RFC 1918 define três faixas de IPv4 privado: 10.0.0.0/8, ou seja, de 10.0.0.0 a 10.255.255.255; 172.16.0.0/12, ou seja, de 172.16.0.0 a 172.31.255.255; 192.168.0.0/16, ou seja, de 192.168.0.0 a 192.168.255.255. Todos os IPv4 que começam com 10 estão na primeira faixa, mas nem todo endereço que começa com 172 ou 192 deve ser tratado como privado. Não estar nessas três faixas também não significa automaticamente que pode ser usado na internet pública; é preciso verificar outras faixas de endereços de uso especial.
A RFC 6598 define o espaço de endereçamento compartilhado 100.64.0.0/10, que vai de 100.64.0.0 a 100.127.255.255, destinado a cenários específicos dentro da rede do provedor de serviços e não é um endereço roteável globalmente. O WAN do roteador dentro dessa faixa é um indício importante de rede compartilhada a montante, mas não prova sozinho que a operadora implementou um tipo específico de CGNAT. Por outro lado, não ver essa faixa não exclui NAT a montante, pois o planejamento de endereços internos da operadora pode ser diferente.
Ao julgar, é preciso comparar as faixas completas, não rotular todos os endereços que começam com 100 como CGNAT. O endereço compartilhado normalmente fica antes da tradução, e a consulta pública vê a saída roteável globalmente após a tradução; os dois não são resultados contraditórios. Confirme também se a consulta passou por proxy e se usa o mesmo WAN e a mesma família de endereços. Somente fixando essas condições as diferenças de endereço se tornam indícios explicáveis; a disponibilidade de um IPv4 público atribuído diretamente no plano ainda depende da confirmação da operadora e da configuração de rede real.
Como comparar o endereço WAN com a saída web
Sempre que possível, registre o IPv4 de saída da página no mesmo horário, no mesmo terminal e na mesma rede, e depois compare com o IPv4 WAN do roteador que realmente transporta a solicitação. Rediscar, trocar de Wi-Fi, usar WAN dupla ou dividir tráfego por proxy afeta a comparação. A verificação do IPv6 é diferente: o terminal normalmente tem seu próprio endereço IPv6 global e não se deve exigir que seja igual ao IPv6 WAN do roteador. É preciso verificar o endereço de origem usado pelo terminal naquele momento, o prefixo delegado pela operadora e a rota esperada; endereços IPv6 temporários também podem mudar com o tempo.
Em redes domésticas, priorize consultar a página de status e a topologia existente; não restaure os padrões de fábrica do equipamento apenas para ver um endereço. Usuários de redes corporativas ou de campus podem entregar o resultado da consulta do terminal ao administrador da rede, que verificará a saída e a conversão upstream. Se o dispositivo tiver múltiplas interfaces, indique o nome e a função de cada uma, distinguindo endereço de gerenciamento do modem, endereço LAN do roteador, endereço WAN e endereço de interface virtual de VPN; caso contrário, vários valores corretos juntos podem levar a conclusões erradas.
Na mesma solicitação IPv4, sem proxy e com a WAN correta, a WAN é igual à saída da página; normalmente não se sustenta a inferência de que “este caminho ainda passa por CGNAT adicional que altera o IPv4 de origem”. Porém, endereços iguais não garantem alocação estática, uso exclusivo ou permissão de conexões de entrada; políticas da operadora e firewalls do host e do roteador ainda podem restringir o acesso. A capacidade de entrada deve ser testada a partir de uma rede externa independente, testando um serviço que você gerencia, e registrando separadamente protocolo, porta e etapa de falha.
WAN e saída diferentes: quais outros motivos?
Se o endereço WAN difere da saída da página, primeiro considere a topologia real. Quando o modem está em modo roteador, o roteador inferior pode obter um endereço privado dele, criando NAT duplo; uma VPN de sistema também pode fazer a página acessar a Internet por um gateway remoto. Confirme primeiro o modo de operação do modem, a divisão de tráfego da VPN e a interface que realmente transporta a solicitação, para depois determinar em qual camada está a diferença. Alterações em configurações de bridge, discagem ou túnel devem ser confirmadas pela operadora ou pelo administrador conforme a necessidade da rede; não se deve ajustar o método de conexão apenas para igualar dois números.
O proxy do navegador também altera a saída da página, enquanto outros aplicativos no mesmo dispositivo podem conectar diretamente. A janela anônima normalmente não ignora o proxy do sistema e não garante a desativação de todas as extensões; a configuração do navegador usada para comparação deve ter proxy e extensões confirmados. Gateways de segurança corporativos, serviços de navegação remota e escalonamento de múltiplas saídas também podem causar diferenças. Em dispositivos gerenciados, peça diretamente ao administrador para verificar as políticas; geralmente é mais eficaz do que desativar túneis corporativos por conta própria.
A exclusão por camadas precisa ser feita em ordem. Primeiro confirme que não há VPN ou proxy ativo no dispositivo; depois verifique se o endereço WAN do roteador está dentro das faixas RFC 1918 ou RFC 6598. Se a WAN for um endereço privado, o modem pode ainda estar em modo roteador; se a WAN for 100.64.x.x, a operadora pode estar usando CGNAT; se a WAN for um endereço público, mas a saída da página for diferente, pode haver proxy ou gateway corporativo. Não tire conclusões com base em uma única captura de tela, pois endereços podem mudar dinamicamente e softwares de proxy podem iniciar com o sistema. Mantenha registros de observações em vários momentos e compare com mudanças na topologia da rede para aumentar a precisão do diagnóstico.
IPv4 e IPv6 devem ser verificados separadamente
IPv4 e IPv6 geralmente são implantados em paralelo, mas têm alocação de endereços, roteamento e políticas de firewall próprios. O terminal pode usar NAT para IPv4 e, ao mesmo tempo, obter diretamente um endereço IPv6 global. O sucesso no acesso IPv6 indica apenas que esse caminho e serviço IPv6 estão disponíveis; a falha no acesso IPv4 pode envolver DNS, roteamento, proxy ou escuta no servidor. CGNAT é especialmente relevante para conexões de entrada IPv4 sem mapeamento estabelecido; não pode ser usado para explicar todas as falhas de saída IPv4.
Verificação do ambiente do navegador pode ajudar a observar a saída da solicitação e o comportamento de rede do navegador, mas não prova que hosts externos possam se conectar ativamente ao seu serviço IPv6. A verificação de entrada exige um serviço realmente escutando, regras de firewall correspondentes e testes a partir de uma rede externa independente. As regras de permissão dos dois protocolos podem ser diferentes; portanto, “a página consegue conectar” e “outros conseguem entrar” devem ser aceitos separadamente, sem afirmar que a entrada está aberta apenas porque a página exibe um endereço IPv6 global.
Ao investigar, registre separadamente destino, endereço de origem e etapa de falha para IPv4 e IPv6. Se suspeitar que o caminho não corresponde ao esperado para proxy ou VPN, leia Teste de vazamento de WebRTC, DNS e IPv6: como interpretar. Os candidatos WebRTC refletem pistas de interfaces ou saídas que o navegador pode coletar; testes de DNS geralmente observam a origem do resolvedor recursivo quando a consulta chega ao servidor autoritativo, não o IP de destino da resolução do domínio como sua saída. Desativar o IPv6 pode mascarar o fenômeno; primeiro esclareça qual caminho específico não corresponde ao esperado.
Como analisar falhas no encaminhamento de portas
Quando o encaminhamento de portas falhar, primeiro confirme que o serviço local está em execução e escutando na interface e porta esperadas. Se estiver vinculado apenas a 127.0.0.1 ou ::1, dispositivos externos não podem se conectar diretamente; conforme a necessidade do serviço, vincule à interface interna designada e restrinja o acesso com o firewall do host. Mudar o serviço para escutar em todas as interfaces não é a única solução e pode ampliar a exposição. Comece validando a resposta do aplicativo a partir de outro dispositivo na LAN e depois investigue camada por camada o roteador e a rede upstream.
Se a escuta local e o firewall do host estiverem normais, o próximo passo é verificar as regras de encaminhamento de portas no roteador. Erros comuns incluem: encaminhamento para o IP interno errado, porta interna e externa incompatíveis, ou protocolo selecionado como TCP enquanto o serviço real usa UDP. Alguns roteadores também exigem liberar a porta separadamente no firewall e reiniciar para que a regra tenha efeito. Nesse momento, teste se o serviço é acessível a partir de outra máquina na rede interna para isolar problemas de configuração do roteador.
Se o roteador estiver configurado corretamente, mas a entrada ainda falhar, compare o IPv4 WAN com a saída da página e verifique NAT upstream e políticas da operadora. Teste de conexão TCP pode fornecer observação externa dentro da faixa de destinos e portas públicas permitidas pela ferramenta; se a entrada for rejeitada pela política da ferramenta, isso não é evidência de falha na conexão de destino. O teste TCP também não substitui a verificação de serviços UDP. Em testes externos com falha, preserve o motivo original; não atribua tudo genericamente a CGNAT.
Se o teste externo mostrar porta inacessível, considere também se a operadora bloqueou portas de entrada comuns, como 80, 25, 445 etc. Algumas operadoras bloqueiam todas as conexões de entrada por padrão, a menos que o usuário solicite IP público ou liberação de portas específicas. Nesse caso, entre em contato com a operadora para confirmar a política, em vez de modificar repetidamente a configuração local. A ordem de investigação pode ser organizada como: escuta local, firewall do host, encaminhamento no roteador, NAT upstream, restrições da operadora — altere apenas uma variável por etapa para diagnosticar com precisão.
Como saídas compartilhadas afetam captchas e reputação de IP
Ao usar um IP de saída compartilhado, o comportamento de outros usuários pode afetar a reputação desse endereço, desencadeando mais captchas ou restrições de acesso. É necessário distinguir entre observação no nível do endereço e o usuário específico. Observações no nível do endereço só podem indicar que um determinado IP já apresentou solicitações automáticas ou tráfego anômalo, mas não podem determinar quem as originou, nem provar que o usuário atual tem más intenções. Sob CGNAT da operadora, centenas ou até mais usuários podem compartilhar o mesmo endereço IPv4, e qualquer anormalidade de um deles pode ser registrada no site para esse endereço.
A página de ajuda sobre tráfego anômalo do Google explica que consultas automáticas de outros usuários em redes compartilhadas ou VPNs podem desencadear avisos de tráfego anômalo. Essa é uma causa possível, mas não significa que o aviso permita identificar qual usuário ou programa enviou a solicitação, nem que se possa afirmar que a saída entrou em alguma lista negra pública. Deve-se preservar o erro específico e o horário de ocorrência, e verificar separadamente rede, navegador e regras do site de destino conforme IP em lista de bloqueio ou CAPTCHA constante: o que fazer.
Um IP compartilhado não significa por si só insegurança, nem indica que o usuário tenha más intenções. Muitas instituições usam CGNAT para economizar endereços IPv4, uma prática normal de engenharia de rede. A avaliação de segurança deve se basear no tráfego e nas sessões específicas, não em um endereço compartilhado. Se você entrar em contato com o site ou a operadora por causa de problemas com captcha, pode explicar que está em um ambiente de saída compartilhada e fornecer evidências observáveis de horários de acesso e comportamento, em vez de pedir que todo o IP seja "limpo", pois essa limpeza pode mascarar anomalias reais.
Para operadores de sites, depender da reputação de um único IP para tomar decisões pode facilmente causar danos colaterais. Uma abordagem mais razoável é combinar vários sinais, como user agent, impressão digital TLS e padrões de comportamento, e oferecer métodos adicionais de verificação para usuários de saída compartilhada, como códigos por e-mail ou SMS. Usuários comuns que enfrentarem aumento de captchas podem tentar mudar de ambiente de rede ou informar ao site a faixa de IP de saída e os horários de acesso, mas não devem usar ferramentas de evasão para contornar controles de acesso.
O que escrever no chamado para a operadora
Ao enviar um chamado para a operadora, quanto mais completas as informações, mais rápido será o processamento. É necessário fornecer fuso horário e horário precisos, por exemplo, data e intervalo de tempo específicos em UTC+8, para facilitar a correspondência de logs pela operadora. Inclua também o endereço IP exibido na interface WAN do roteador; se o WAN do roteador não for um endereço público, informe-o com veracidade. O IP de saída observado externamente pode ser obtido por meio de sites de consulta; listar ambos em paralelo permite determinar rapidamente se há NAT intermediário.
Se IPv4 e IPv6 forem usados simultaneamente, é necessário descrevê-los separadamente. Muitas redes móveis ou de banda larga doméstica já habilitam IPv6, mas o IPv4 ainda pode passar por CGNAT. Ao descrever o problema, não diga apenas "não consigo acessar"; informe o protocolo de entrada necessário, como porta TCP 443 para HTTPS ou porta UDP 51820 para WireGuard. Descreva também a topologia atual, por exemplo, se o modem óptico está em modo bridge ou roteador, a marca e o modelo do roteador e se há um roteador secundário.
No chamado, não se deve pedir que a operadora "limpe" o IP de listas negras, a menos que haja evidências concretas de que o endereço foi marcado erroneamente. Perguntas mais adequadas são: o plano atual oferece endereço IPv4 público? Permite conexões de entrada? Se o IPv4 não estiver disponível, oferece entrada IPv6? Essas perguntas estão diretamente relacionadas à capacidade da rede, não à reputação. Logs sensíveis, como registros completos de tráfego ou credenciais de acesso, não precisam ser fornecidos proativamente, mas se a operadora precisar de investigação adicional, logs anonimizados podem ser fornecidos conforme o princípio da necessidade mínima.
Se a operadora solicitar evidências, pode-se organizar uma linha do tempo: quando o mapeamento de portas foi configurado, de qual rede externa foi testado, qual ferramenta de teste foi usada e qual resultado foi obtido. Essas evidências devem ser mantidas intactas, sem modificar capturas de tela ou saídas. Ao acompanhar o chamado, registre o horário de cada comunicação, o número do atendente e a conclusão, para formar um registro revisável. Escrever claramente o resultado esperado e o prazo para o próximo passo também aumenta a eficiência do processamento.
Como usuários domésticos e desenvolvedores devem escolher
Usuários domésticos que precisam acessar remotamente dispositivos que gerenciam podem primeiro verificar se o plano oferece entrada IPv4 público ou IPv6 e, em seguida, escolher o esquema adequado. Se não houver capacidade de entrada direta, pode-se avaliar túneis reversos autenticados ou serviços de retransmissão, verificando controle de acesso, manutenção, custo e disponibilidade, e cumprindo as regras de administração da rede em questão. A necessidade desse esquema depende do objetivo do negócio; não é preciso considerar "ter IPv4 público obrigatório" como pré-requisito para todo acesso remoto.
Sobre IP público e alcançabilidade de portas, usuários domésticos frequentemente têm um equívoco: acreditam que, se o endereço WAN do roteador for público, todas as portas poderão ser acessadas pela Internet. Na prática, muitas conexões de banda larga doméstica, mesmo com IPv4 público atribuído, bloqueiam portas de serviços comuns nos equipamentos de borda da operadora. Além disso, IPs públicos dinâmicos podem mudar, e o acesso remoto requer DNS dinâmico. Se for apenas para acesso temporário, usar o gerenciamento remoto fornecido pelo fabricante ou um serviço de retransmissão autorizado é mais seguro.
Desenvolvedores que fazem integração de serviços pela Internet não podem considerar o sucesso do acesso externo a partir da máquina local como validação de entrada pela Internet. O sucesso do acesso de saída pela máquina através de NAT ou firewall só indica que o caminho de saída está livre, não que terceiros possam se conectar ativamente à máquina. Por exemplo, se um serviço Web roda em localhost e acessa uma API externa via curl com sucesso, isso não prova que usuários externos possam acessar esse serviço Web. É necessário testar ativamente a partir de outra máquina em uma rede diferente ou usar ferramentas externas de detecção TCP.
Desenvolvedores também devem verificar a publicação de portas entre contêineres, máquinas virtuais e o host. O serviço funcionando dentro do contêiner não significa que o host tenha aberto essa porta na interface esperada; o endereço de loopback do host estar acessível não significa que a LAN ou a Internet estejam acessíveis. A validação final deve indicar o ponto de observação e o resultado da aplicação: serviços TCP precisam completar a conexão e a interação esperada, serviços UDP precisam enviar uma solicitação conforme o protocolo e verificar a resposta; não se pode concluir "TCP estabelecido" a partir de UDP sem handshake de conexão.
Três perguntas frequentes
O IP público é fixo? Depende da operadora e do plano. Banda larga doméstica geralmente usa endereços dinâmicos; mesmo com IPv4 público atribuído, ele pode mudar após expiração do lease, rediscagem ou reinicialização do equipamento. Linhas dedicadas empresariais ou planos com IP fixo podem fornecer endereços estáticos, mas com custo adicional. Endereços IPv6 geralmente são atribuídos por delegação de prefixo; se o prefixo da operadora não mudar, o endereço do dispositivo pode permanecer estável por um período, mas não há garantia de permanência. Não presuma que o endereço seja fixo; serviços remotos ainda precisam de DNS dinâmico ou atualização periódica da configuração.
Reiniciar o roteador sempre muda o endereço? Não necessariamente. A mudança de endereço depende da duração do lease DHCP, da política de pool de endereços da operadora e do método de autenticação. Às vezes o endereço permanece o mesmo após a reinicialização, às vezes muda; não há regra universal. Em ambiente CGNAT, a reinicialização pode alterar o mapeamento interno da operadora, não o endereço de saída público. Se precisar determinar se a saída atual mudou, registre o IP de saída usando vários serviços de consulta independentes antes e depois da reinicialização, mantendo o fuso horário e o ambiente de rede inalterados.
Vários usuários compartilharem um IP público não significa automaticamente que possam acessar uns aos outros, nem constitui prova de isolamento de segurança. O isolamento real depende da configuração da rede de acesso, controles de acesso e firewalls dos dispositivos; o NAT não deve ser tratado como um perímetro de segurança completo. Saídas compartilhadas podem criar associação de reputação, fazendo com que usuários legítimos enfrentem captchas ou restrições juntos, mas o impacto específico depende das políticas do site de destino. Conectividade, reputação do endereço e segurança do dispositivo devem ser avaliadas separadamente, evitando resumir todos os problemas com um rótulo de "compartilhado".
Criar um registro revisável
Ao solucionar problemas de alcançabilidade de IP público e portas, os registros devem sustentar uma revisão posterior. Ao criar uma linha do tempo, use um formato esquemático: por exemplo, em um determinado dia às 10:00, configure o encaminhamento de porta no roteador; às 10:05, teste a porta 8443 com uma ferramenta TCP de uma rede externa e falhe; às 10:10, modifique o firewall do host; às 10:15, teste novamente e ainda falhe. Esse registro mostra claramente cada ação e resultado. Não omita operações que falharam, pois as falhas também ajudam a excluir variáveis.
Altere apenas uma variável por vez e registre os resultados antes e depois; ajustar firewall e regras do roteador simultaneamente dificulta identificar a causa. Salve páginas de status, textos de erro, horários de teste e resultados de saída; ao fornecer materiais externamente, remova informações irrelevantes como contas e tokens. Para entender tipos de endereço, origens e limites de observação, leia nosso Fontes de dados e metodologia. O foco do registro é permitir que o próximo solucionador reproduza as condições, não acumular capturas de tela inexplicáveis.
IPs compartilhados ou detecção de proxy podem gerar falsos positivos, como uma rede doméstica normal sendo marcada como VPN ou proxy devido à saída compartilhada. Nesse caso, colete o IP de saída, horário da consulta e plataforma de detecção, e registre as diferenças de julgamento entre várias plataformas. Não confie em apenas uma lista negra ou serviço de detecção; algumas plataformas não são amigáveis com faixas CGNAT. Para casos de falsos positivos e direções de solução, veja IP detectado como VPN ou proxy: como verificar falso positivo, que explica como distinguir marcação no nível do endereço do comportamento real de proxy.
Quando o registro de solução de problemas estiver suficientemente completo, mas o problema persistir, defina critérios claros de parada. Por exemplo: já modificou a escuta local e o firewall, confirmou que as regras do roteador estão corretas, testou a partir de duas redes externas diferentes e falhou em ambas, e o provedor respondeu que não há capacidade de entrada. Nesse ponto, o próximo passo deve ser solicitar um endereço público ao provedor ou adotar uma solução de retransmissão autorizada, em vez de continuar adivinhando ou modificando. Após encerrar, arquive todos os registros, marque a conclusão como "não foi possível estabelecer conexão de entrada, causa apontando para política do provedor" e anexe a cadeia de evidências.
