CGNAT: o que é e como funciona no provedor de internet

CGNAT é o NAT que fica dentro do provedor e faz vários clientes saírem para a internet pelo mesmo endereço IPv4 público. Se você trabalha no suporte de um provedor regional, já ouviu a reclamação: o cliente comprou uma câmera, tentou liberar a porta no roteador e nada funciona. Na maioria das vezes a explicação é o CGNAT, e ninguém contou isso ao cliente.

Este guia explica o assunto para técnico de campo, NOC e atendimento. Você vai ver por que o provedor precisa disso, o que é a faixa 100.64.0.0/10, como as portas são divididas, a diferença entre CGNAT determinístico e dinâmico, o que quebra do lado do cliente, por que os logs precisam da porta e onde o IPv6 entra. Os endereços dos exemplos são de documentação.

Resposta rápida: o que é CGNAT

• CGNAT (Carrier-Grade NAT) é um NAT feito pelo provedor, num equipamento central, que traduz o endereço privado do cliente para um IPv4 público compartilhado.
• O cliente recebe um endereço da faixa 100.64.0.0/10, reservada pela RFC 6598 para esse uso. Ele não é roteável na internet.
• Vários assinantes usam o mesmo IP público ao mesmo tempo. O que separa um do outro é a porta de origem da conexão.
• Efeito prático: o cliente não consegue receber conexões de fora. Redirecionar porta no roteador de casa não resolve.
• Saídas: IP público dedicado (normalmente um serviço à parte) ou IPv6, que dá endereço global para cada dispositivo.
• Para identificar um assinante numa ordem judicial, o provedor precisa de IP público, porta e horário com fuso.

Por que o provedor usa CGNAT

O IPv4 tem pouco mais de 4,2 bilhões de endereços, e o estoque dos registros regionais acabou. A LACNIC, que atende a América Latina, não tem mais blocos livres para entregar a quem pede. Um provedor novo consegue, com sorte, um bloco pequeno, e quem cresce precisa comprar endereços no mercado de transferência, a um preço que não fecha a conta para um plano residencial.

Um provedor com 8 mil assinantes e um /22 (1.024 endereços) não tem como dar um IP público para cada casa. Com CGNAT, aqueles 1.024 endereços atendem a base inteira e ainda sobra espaço para crescer. É uma solução de transição: segura o IPv4 enquanto o tráfego migra para o IPv6.

A faixa 100.64.0.0/10 da RFC 6598

Antes de existir uma faixa própria, cada provedor usava o que tinha à mão para o lado interno do CGNAT, muitas vezes 10.0.0.0/8 ou 192.168.0.0/16. Isso dava conflito, porque essas mesmas faixas estão na rede de casa do cliente. Um roteador com LAN em 192.168.0.0/24 e WAN em 192.168.0.10 simplesmente não sabe para onde mandar o tráfego.

A RFC 6598 resolveu isso em 2012 com o Shared Address Space: 100.64.0.0/10, cerca de 4,19 milhões de endereços, de 100.64.0.0 a 100.127.255.255. A faixa serve só para o trecho entre o cliente e o CGNAT do provedor. Ela não pode aparecer em anúncio BGP nem sair para outra rede, e o roteador do cliente não deve usá-la na LAN.

Como o CGNAT funciona: NAT 1:N e portas

Todo NAT guarda uma tabela de sessões. Quando o celular do cliente abre uma conexão para um site, o CGNAT troca o endereço de origem 100.64.x.x por um IP público e troca também a porta de origem por uma porta livre daquele IP. A resposta do site volta para o IP público e para essa porta, e o CGNAT consulta a tabela para saber a qual cliente ela pertence.

Como uma conexão é identificada pelo conjunto de endereços e portas de origem e destino, um único IP público aguenta milhares de sessões ao mesmo tempo, vindas de clientes diferentes. A limitação real são as portas: cada IP tem 65.535, e as abaixo de 1024 costumam ficar fora do pool. Sobram 64.512 portas para dividir.

Na casa do cliente ainda existe o NAT do roteador Wi-Fi (ou da ONU em modo roteador), que traduz a LAN 192.168.x.x para o endereço 100.64 da WAN. São dois NATs em sequência, o que se chama NAT444: endereço privado, endereço compartilhado e endereço público.

Quantas portas cada cliente recebe

A conta que define o projeto é a razão de compartilhamento: quantos assinantes dividem cada IP público. Abaixo, um exemplo com 32 clientes por IP numa base de 4 mil assinantes:

Portas utilizáveis por IP : 1024 a 65535 = 64512
Clientes por IP público   : 32
Portas por cliente        : 64512 / 32 = 2016
Assinantes na base        : 4000
IPs públicos necessários  : 4000 / 32 = 125
Menor bloco que comporta  : /25 (128 IPs)

Com 2.016 portas, um cliente comum navega, assiste vídeo e joga sem perceber. Uma casa com muitos dispositivos, aplicativos que abrem centenas de conexões ou um torrent ativo pode chegar ao limite. Quando as portas acabam, novas conexões falham, e o cliente descreve isso como site que não abre ou aplicativo que fica carregando. Razões entre 1:16 e 1:64 são comuns; quanto maior a razão, menos portas por cliente.

CGNAT determinístico x dinâmico

Existem duas formas de distribuir as portas, e a escolha mexe com o tamanho do log que o provedor vai precisar guardar.

No modelo determinístico, a faixa de portas sai de uma conta fixa. O primeiro endereço interno fica com a primeira fatia do primeiro IP público, o segundo com a fatia seguinte, e assim por diante. Exemplo com o pool 100.64.0.0/22 saindo por 203.0.113.32/27 na razão 1:32:

Cliente (interno)   IP público       Portas
100.64.0.0          203.0.113.32     1024-3039
100.64.0.1          203.0.113.32     3040-5055
100.64.0.2          203.0.113.32     5056-7071
100.64.0.31         203.0.113.32     63520-65535
100.64.0.32         203.0.113.33     1024-3039
100.64.0.33         203.0.113.33     3040-5055
100.64.3.255        203.0.113.63     63520-65535

Repare que 1.024 endereços internos cabem exatamente em 32 IPs públicos vezes 32 clientes. Se chega um pedido sobre 203.0.113.33, porta 3500, a conta mostra que a porta está na segunda fatia desse IP, ou seja, no cliente 100.64.0.33. Daí basta saber quem estava com esse endereço interno naquele horário, o que vem do log do PPPoE ou do DHCP.

No modelo dinâmico, o equipamento entrega blocos de portas (por exemplo, de 512 em 512) conforme a demanda e devolve o bloco quando as sessões fecham. O aproveitamento é melhor, mas cada alocação precisa ser registrada com data, hora, endereço interno, IP público e faixa de portas.

O que muda para o cliente com CGNAT

Para navegar, ver vídeo e usar redes sociais, o cliente não nota diferença. Tudo que começa dentro da casa e vai para fora funciona. O problema aparece em quem precisa receber conexões iniciadas pela internet, porque não existe uma porta reservada esperando por ele no IP público.

Muitas câmeras atuais funcionam bem nesse cenário porque usam o serviço em nuvem do próprio fabricante: a câmera abre a conexão para fora e o aplicativo do celular se encontra com ela lá. O problema é o equipamento antigo configurado por DDNS e porta redirecionada.

Como o atendimento pode explicar

Uma explicação que costuma funcionar ao telefone: o seu plano usa um endereço de internet compartilhado com outros clientes, como um prédio com uma só portaria. Você consegue sair e voltar normalmente, mas quem está de fora não consegue chamar o seu apartamento direto. Para isso existe o IP público fixo ou o IPv6.

Antes de vender IP público, confirme que o problema é esse. Peça o IP da WAN do roteador: se ele estiver entre 100.64.0.0 e 100.127.255.255, o cliente está no CGNAT. Se for outro endereço privado, o mais provável é haver dois roteadores na casa. Nesse caso, o primeiro passo é deixar a ONU em bridge ou o roteador extra em modo AP. O passo a passo do lado da OLT está no guia sobre como provisionar ONU na OLT Huawei.

Guarda de logs no CGNAT

O Marco Civil da Internet (Lei 12.965/2014, art. 13) obriga o provedor de conexão a guardar os registros de conexão por um ano, em sigilo. Sem CGNAT, isso é simples: o IP público identifica o assinante. Com CGNAT, o mesmo IP está com dezenas de clientes no mesmo segundo, e só a porta de origem separa um do outro.

Por isso o log precisa ter, no mínimo, os campos abaixo. É um exemplo genérico de conteúdo; o formato muda de equipamento para equipamento:

data/hora (com fuso)       : 2026-10-07 07:31:12 -03:00
evento                     : criação de sessão (TCP)
origem interna             : 100.64.0.37:51522
tradução (IP público:porta): 203.0.113.33:11187
destino                    : 198.51.100.80:443

• Horário com fuso e relógio certo. Todos os equipamentos sincronizados por NTP. Um minuto de diferença já pode apontar outro cliente.
• Porta de origem traduzida. Sem ela, o IP público não ajuda em nada na hora de identificar alguém.
• Endereço interno e quem estava com ele. O log do CGNAT diz qual 100.64 usou a porta; o log do PPPoE ou do DHCP diz qual assinante tinha esse 100.64 naquele horário.
• Retenção e integridade. Pelo menos um ano, em servidor separado, com backup e acesso controlado.

No modelo determinístico, a parte pesada desaparece: a regra de mapeamento já diz qual endereço interno tinha cada faixa, e o que precisa ser guardado é o histórico de sessões PPPoE ou DHCP. No dinâmico, o servidor de log recebe um volume grande e precisa de disco à altura.

O outro lado também conta. Uma ordem judicial que chega só com IP e horário, sem porta, não permite identificar o usuário quando o IP é compartilhado. O provedor responde explicando que precisa da porta de origem, e os serviços que recebem a conexão precisam registrar esse dado.

IPv6 como saída do CGNAT

O CGNAT segura o IPv4, mas não resolve a falta de endereços. A saída de longo prazo é o IPv6, em que cada cliente recebe um prefixo inteiro (normalmente um /56 ou /64 por delegação) e cada dispositivo tem endereço global. Não existe tradução de porta, e o cliente pode receber conexões, respeitando o firewall do roteador.

Na prática, o provedor roda as duas pilhas ao mesmo tempo (dual stack): IPv6 nativo e IPv4 via CGNAT. Boa parte do tráfego pesado, como vídeo e redes sociais, já sai por IPv6 quando o cliente tem o protocolo ligado. Isso alivia a tabela de sessões e o uso de portas do equipamento. Se quiser revisar a base, veja o guia sobre o que é IPv6 e como ele funciona.

Do lado do roteamento, os blocos públicos usados no CGNAT são anunciados por BGP como qualquer outro prefixo seu (se o BGP ainda é novidade, veja o que é BGP e como ele funciona), e a faixa 100.64.0.0/10 nunca deve sair. Quem já filtra a exportação com prefix-list, como no post sobre BGP communities e filtros de saída no Huawei, só precisa garantir que o pool interno não entra nessa lista.

Erros comuns ao montar o CGNAT

1. Razão de compartilhamento alta demais. Economiza IP, mas o cliente esgota as portas no horário de pico e reclama de lentidão que não aparece no gráfico de banda.
2. Logar só o IP público. O log fica inútil para identificar alguém. Confira se a porta traduzida e o horário com fuso estão gravados.
3. Relógio sem NTP. Equipamentos com horários diferentes tornam a consulta impossível. NTP em todos, com o mesmo fuso documentado.
4. Usar 10.0.0.0/8 ou 192.168.0.0/16 no lado interno. Conflita com a LAN do cliente. Use a faixa 100.64.0.0/10, feita para isso.
5. Deixar o pool 100.64 vazar. Rota para 100.64.0.0/10 anunciada ao trânsito ou a um peer é erro de filtro. Bloqueie na exportação.
6. NAT triplo na casa do cliente. ONU roteando, roteador do cliente roteando e CGNAT por cima. Padronize um único roteador por instalação.
7. Não ter caminho para quem precisa de IP público. Separe um pequeno bloco para vender como IP fixo; é o que resolve câmera antiga, servidor e alguns jogos.

Perguntas frequentes

O que é CGNAT?

É o NAT feito pelo provedor, num equipamento central, que faz vários clientes compartilharem o mesmo IPv4 público. Cada cliente recebe um endereço da faixa 100.64.0.0/10 e, na saída, ganha portas daquele IP público.

Como saber se minha internet está atrás de CGNAT?

Veja o IP da WAN no roteador e compare com o IP que um site de consulta mostra. Se forem diferentes e o da WAN estiver entre 100.64.0.0 e 100.127.255.255, a conexão está atrás de CGNAT.

CGNAT deixa a internet mais lenta?

Não diretamente. A banda é a mesma e o atraso que o NAT acrescenta é pequeno. Lentidão aparece quando o cliente esgota a faixa de portas ou quando o equipamento de CGNAT está no limite de sessões.

Dá para abrir portas no roteador com CGNAT?

Você pode criar o redirecionamento no roteador, mas ele não recebe nada, porque a conexão de fora para no IP público compartilhado do provedor. Para receber conexões, é preciso IP público dedicado ou IPv6.

Qual a diferença entre CGNAT e NAT do roteador?

O NAT do roteador traduz a rede da casa para o endereço que o provedor entrega. O CGNAT fica no provedor e traduz esse endereço 100.64 para um IP público compartilhado. Com os dois juntos, o tráfego passa por duas traduções, o chamado NAT444.

O provedor precisa guardar log de porta no CGNAT?

Sim. O Marco Civil exige guardar os registros de conexão por um ano, e com CGNAT o IP público sozinho não identifica ninguém. O log precisa de IP público, porta de origem e horário com fuso, cruzado com o log de autenticação.

Resumo para levar ao suporte

CGNAT é o jeito que o provedor encontrou para continuar crescendo sem IPv4 sobrando. Para o técnico, o que importa cabe em três frases: o cliente recebe um 100.64, sai por um IP público dividido por portas e não recebe conexões de fora. O resto é dimensionar a razão com folga, guardar log com porta e horário certo e oferecer IP fixo para quem precisa.

E, enquanto isso, ligar o IPv6 para todo mundo. Cada cliente que passa a usar IPv6 tira carga do CGNAT e deixa as portas para quem ainda depende do IPv4.