# Um IP, muitas pessoas: o que o Private Relay e o NAT de operadora fazem com a regra por endereço Análise · UNIFOKAL · 1 de outubro de 2026 · 8 min de leitura · Antifraude NAT de operadora e iCloud Private Relay põem muitos usuários atrás do mesmo endereço. O que a IETF e a Apple documentam sobre isso e o que um servidor precisa registrar para não punir a multidão. Uma regra antifraude por endereço de IP (Internet Protocol) parte de uma premissa silenciosa: cada endereço público corresponde a uma casa, a um escritório ou a um aparelho. Bloquear o endereço, contar tentativas por endereço ou ligar contas pelo endereço só faz sentido se essa premissa valer. Ela vale cada vez menos, e não por causa de fraude. Duas tecnologias legítimas, documentadas por quem as opera, colocam muitas pessoas atrás do mesmo endereço público: a tradução de endereços feita pela própria operadora, o NAT (Network Address Translation) de operadora, e serviços de privacidade como o iCloud Private Relay, da Apple. Nos dois casos, o que o servidor vê é um ponto de saída compartilhado. ## NAT de operadora: o que a IETF chama de CGN A RFC 6888 (as RFCs, Request for Comments, são os documentos técnicos publicados pela IETF, a Internet Engineering Task Force), de abril de 2013, publicada como Best Current Practice (BCP 127), define o Carrier-Grade NAT (CGN) como uma função de tradução de endereços usada para compartilhar o mesmo endereço IPv4, a versão 4 do protocolo, entre vários assinantes, e que não é gerenciada pelos assinantes. O termo "carrier-grade", esclarece o documento, não fala de qualidade: é um qualificador de topologia, porque o NAT fica na rede do provedor e traduz o tráfego de potencialmente muitos assinantes. A motivação está na RFC 6598, de abril de 2012, também uma Best Current Practice (BCP 153). Ela parte de uma constatação, "IPv4 address space is nearly exhausted", e registra que muitos provedores implantariam CGN para continuar atendendo ao crescimento do IPv4 até a adoção plena do IPv6, a versão 6. Para isso, a RFC reservou o bloco 100.64.0.0/10, o Shared Address Space, usado para numerar as interfaces entre o CGN e o equipamento instalado na casa do cliente. Um detalhe evita confusão: em regra, esse bloco não chega ao seu servidor como origem. A RFC 6598 determina (MUST NOT) que pacotes com origem ou destino nele não atravessem as fronteiras do provedor, com exceção de relações comerciais como o CGN hospedado, e manda filtrá-los na entrada. O que o servidor registra é o endereço público de saída do CGN, compartilhado pelos assinantes que saem por ele naquele momento. ## O que quebra, segundo a própria IETF A RFC 6598 lista, na seção de dados empíricos, serviços prejudicados pelo CGN. Dois deles tocam diretamente o trabalho antifraude. O primeiro é a geolocalização: os sistemas de geolocalização identificam a localização do servidor de CGN, e não a do equipamento do usuário. O segundo são os logins simultâneos: alguns sites, "particularly banking and social-networking websites", limitam o número de logins simultâneos por endereço público. A RFC 6269, Issues with IP Address Sharing, de junho de 2011, documento informativo da IETF, vai além na seção 13.1. Ela descreve o servidor que põe um endereço numa "penalty box" depois de muitas requisições em pouco tempo, ou passa a exigir um CAPTCHA (teste automatizado para distinguir computadores de pessoas), e aponta duas consequências do endereço compartilhado. Primeiro, ver muitas tentativas de login vindas do mesmo endereço passa a ser o comportamento natural. Segundo, um usuário que erra várias tentativas pode trancar do lado de fora quem nunca tentou nada e agora falha na primeira. A conclusão do texto é seca: na presença de compartilhamento de endereços em larga escala, as soluções de "penalty box" para abuso de serviço "simply will not work". A mesma seção registra o problema do lado da investigação: um relato de abuso na forma "o endereço X fez algo ruim no instante T" não basta para identificar o assinante responsável quando o endereço é compartilhado. E aponta o conserto: registrar também a porta. Quem liga endereço e porta ao assinante, lembra a RFC 6302, é o registro da operadora; o do servidor serve para cruzar com ele. ## Private Relay: compartilhamento por desenho O caso da Apple é diferente na origem e parecido no efeito. Segundo a página Prepare your network or web server for iCloud Private Relay, da própria Apple, o serviço faz parte da assinatura iCloud+ e protege a navegação no Safari, as consultas de DNS (Domain Name System) e o tráfego de aplicativos em HTTP (Hypertext Transfer Protocol) sem criptografia, em iOS 15, iPadOS 15 e macOS Monterey ou posteriores. As requisições passam por dois relays operados por entidades diferentes, e o endereço original do usuário é substituído por um endereço da faixa do serviço. A frase que interessa a quem escreve regra está na mesma página: "The assigned relay IP address may be shared among more than one Private Relay user in the same area." A Apple acrescenta que o endereço representa, por padrão, a localização aproximada no nível de cidade, que preserva a região do usuário e que permanece estável durante uma sessão de navegação enquanto o usuário interage com o site. E a própria Apple escreve o recado para equipes de risco: a detecção de fraude tradicional baseada em endereço IP "might need to be adjusted" para não atingir usuários legítimos. A recomendação é tratar esses endereços como os de um CGN maior ou de uma rede corporativa, "since many Private Relay users may be assigned to a single relay IP address". A empresa publica a lista de endereços do serviço e um feed de geolocalização, para que o servidor reconheça esse tráfego. ## O que registrar para a evidência continuar útil Se o endereço sozinho não identifica, o que identifica melhor? A RFC 6302, Logging Recommendations for Internet-Facing Servers, de junho de 2011, Best Current Practice (BCP 162), responde para os servidores voltados à internet que registram o endereço de origem das conexões recebidas. É RECOMMENDED que, além desse endereço, eles registrem: - a porta de origem; - o instante, recomendado em UTC (tempo universal coordenado), com precisão de segundo, a partir de uma fonte de tempo rastreável; - o protocolo de transporte e a porta de destino, quando a aplicação usa mais de um. A justificativa da RFC é prática: CGNs têm políticas diferentes de reaproveitamento de portas, alguns reutilizam quase imediatamente, e o servidor não tem como saber o ritmo. Por isso o relógio precisa ser preciso. A recomendação vale também para balanceadores de carga que registram conexões em nome dos servidores, ponto que importa em arquitetura com proxy, onde o endereço e a porta que chegam à aplicação são os do último salto. O cuidado com cabeçalho repassado por proxy está no artigo sobre [VPN, proxy e IP de datacenter](https://unifokal.com/blog/ip-de-vpn-proxy-e-datacenter). Note a força normativa: é recomendação de boa prática, não obrigação legal. E o próprio documento declara a política de retenção desses registros fora do seu escopo. ## O que isso muda na regra por endereço Lidos juntos, os documentos sustentam três leituras: - **Contagem por endereço mede a saída, não a pessoa.** Muitas contas vindas do mesmo endereço público são o comportamento esperado atrás de um CGN ou de um relay, como a RFC 6269 descreve para tentativas de login. - **Bloqueio por endereço pune a multidão.** O efeito colateral que a RFC 6269 descreve para a "penalty box" e para listas de bloqueio vale para qualquer bloqueio cujo único critério seja o endereço. - **Geolocalização por endereço é a da saída.** A RFC 6598 diz que, no CGN, ela aponta o servidor de tradução; a Apple diz que, no relay, ela aponta a cidade aproximada. Comparar posição de saída com posição de aparelho fabrica deslocamentos que ninguém fez, armadilha descrita em [viagem impossível no monitoramento de sessão](https://unifokal.com/blog/viagem-impossivel-em-monitoramento-de-sessao). O endereço continua útil como peso e como correlação numa janela curta, desde que a regra saiba que ele pode ser muitas pessoas. É o raciocínio de [rede de fraude e falso positivo](https://unifokal.com/blog/rede-de-fraude-e-falso-positivo): ligar contas por um identificador que não individualiza produz vínculos que não existem. ## Perguntas frequentes ### Se o IP é compartilhado, ainda dá para chegar ao assinante? Não só com o registro do servidor. Endereço e instante não bastam (RFC 6269); a RFC 6302 recomenda registrar também porta de origem e horário preciso, e quem liga esse conjunto ao assinante é o registro da operadora. ### O endereço do Private Relay mostra onde o usuário está? Segundo a Apple, mostra a região e, por padrão, a cidade aproximada, sem divulgar a localização exata. ## Fontes citadas - IETF, RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space, BCP 153, abril de 2012, seções 1, 4, 5.2 e 6: [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc6598.html) - IETF, RFC 6888, Common Requirements for Carrier-Grade NATs (CGNs), BCP 127, abril de 2013, seção 2: [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc6888.html) - IETF, RFC 6269, Issues with IP Address Sharing, informativa, junho de 2011, seção 13: [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc6269.html) - IETF, RFC 6302, Logging Recommendations for Internet-Facing Servers, BCP 162, junho de 2011, seção 2: [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc6302.html) - Apple, Prepare your network or web server for iCloud Private Relay, documentação para desenvolvedores: [developer.apple.com](https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/)