CGNAT: O Que É, Como Funciona e Por Que Seu Provedor Usa

O Problema: Os Endereços IPv4 Acabaram

A internet foi projetada nos anos 80 com um sistema de endereçamento chamado IPv4, que permite cerca de 4,3 bilhões de endereços únicos. Parecia muito na época — mas em 2011, a IANA (organização que distribui IPs) anunciou o esgotamento do pool global de IPv4.

Na América Latina, o LACNIC (nosso registro regional) esgotou seu estoque de IPv4 em 2014. Desde então, provedores brasileiros recebem blocos minúsculos (um /24 = 256 IPs, se tanto) e pagam cada vez mais caro por IPs usados no mercado secundário.

Para um provedor com 3.000 assinantes, seria necessário ter 3.000 IPs públicos — um custo e escassez inviáveis. A solução? Compartilhar IPs públicos entre vários assinantes. É aí que entra o CGNAT.

O Que É NAT (Network Address Translation)

Antes de entender CGNAT, vamos revisar o NAT básico que todo mundo usa em casa.

Seu roteador WiFi tem um IP público (ex.: 200.150.100.50) e distribui IPs privados internos (192.168.0.x) para seus dispositivos. Quando seu celular acessa um site, o roteador faz a tradução:

Celular (192.168.0.10:45000) → Roteador NAT → Internet (200.150.100.50:45000)
                                    ↕
                    Tabela NAT: 192.168.0.10:45000 ↔ 200.150.100.50:45000

O roteador mantém uma tabela de tradução que mapeia cada conexão interna para uma porta no IP público. Quando a resposta chega, ele sabe para qual dispositivo interno encaminhar.

Isso funciona porque dentro de uma casa, raramente se usam mais que algumas centenas de conexões simultâneas. Um IP público com 65.535 portas disponíveis é mais que suficiente.

O Que É CGNAT (Carrier-Grade NAT)

CGNAT, também chamado de NAT444 ou Large-Scale NAT (LSN), é o mesmo conceito de NAT, mas aplicado no nível do provedor — não na casa do cliente.

Em vez de cada assinante ter um IP público próprio, dezenas ou centenas de assinantes compartilham o mesmo IP público, cada um usando uma faixa de portas diferente.

Fluxo do CGNAT

Cliente A (100.64.0.10)  ─┐
Cliente B (100.64.0.11)  ─┼─→  Roteador CGNAT  ─→  IP Público 203.0.113.1
Cliente C (100.64.0.12)  ─┘    do Provedor          (compartilhado)

Distribuição de portas:
  Cliente A → portas 1024-17407
  Cliente B → portas 17408-33791
  Cliente C → portas 33792-50175

O assinante recebe um IP privado na faixa 100.64.0.0/10 (range reservado especificamente para CGNAT pela RFC 6598). Na casa dele, o roteador WiFi faz o primeiro NAT (NAT44 local). No roteador de borda do provedor, acontece o segundo NAT (CGNAT). Por isso o nome NAT444 — são duas camadas de tradução.

CGNAT Determinístico vs. Dinâmico

Existem duas formas de implementar CGNAT:

Determinístico (Stateful com Mapeamento Fixo)

Cada assinante recebe uma faixa fixa de portas pré-calculada com base no IP interno. O mapeamento é previsível — dado o IP interno, você sabe exatamente quais portas aquele assinante usa.

Vantagens:

• Menos logs necessários (o mapeamento é calculável)
• Performance mais previsível

Desvantagens:

• Menos portas por assinante (distribuição fixa)
• Clientes "pesados" não podem usar mais portas que a cota

Dinâmico (Stateful com Alocação sob Demanda)

Portas são alocadas sob demanda conforme o assinante abre conexões. Mais eficiente no uso de portas, mas gera muito mais logs porque cada alocação individual precisa ser registrada.

Vantagens:

• Melhor uso do pool de portas
• Clientes leves usam poucas portas, sobrando mais para os pesados

Desvantagens:

• Volume de logs explosivo (cada sessão NAT gera um log)
• Mais processamento no roteador CGNAT

Na Prática: MikroTik

No MikroTik (RouterOS), o CGNAT é implementado com src-nat e netmap ou same. Exemplo clássico de CGNAT no MikroTik CCR:

/ip firewall nat
add chain=srcnat src-address=100.64.0.0/22 out-interface=ether1-wan \
    action=src-nat to-addresses=203.0.113.0/28 to-ports=1024-65535

# Para CGNAT determinístico, usa-se netmap por faixas:
add chain=srcnat src-address=100.64.0.0/30 action=src-nat \
    to-addresses=203.0.113.1 to-ports=1024-17407
add chain=srcnat src-address=100.64.0.4/30 action=src-nat \
    to-addresses=203.0.113.1 to-ports=17408-33791

No Huawei NE8000 (BRAS usado por provedores maiores), o CGNAT é configurado via NAT instance com user-table:

[NE8000] nat instance cgnat-1 id 1
[NE8000-nat-instance-cgnat-1] nat user-table user-table-1
[NE8000-nat-instance-cgnat-1] nat address-group 1
[NE8000-nat-instance-cgnat-1] section 0 203.0.113.0 203.0.113.15

Por Que Provedores Brasileiros Usam CGNAT

Motivo simples: não há IPv4 suficiente. Um provedor com 3.000 assinantes precisaria de ~12 blocos /24 (3.072 IPs) para dar um IP público para cada cliente. No mercado secundário, um /24 custa entre US$ 15-25 por IP. São US$ 45.000-75.000 — e o preço só sobe.

Com CGNAT, o mesmo provedor opera com 1-2 blocos /24 (256-512 IPs públicos), compartilhando cada IP entre 8-64 assinantes. Economia de 90%+ no custo de endereçamento.

E o IPv6? Sim, IPv6 é a solução definitiva e todo provedor deveria estar implementando. Mas a realidade é que em 2026, muitos serviços e dispositivos ainda não funcionam 100% com IPv6, então o CGNAT continua necessário como ponte.

Desvantagens do CGNAT para o Assinante

O CGNAT não é transparente — ele afeta o uso da internet:

• Port forwarding impossível — O assinante não controla o IP público, então não pode abrir portas para câmeras IP, servidores de jogo, acesso remoto
• Gaming — Alguns jogos (especialmente consoles) têm problemas com NAT duplo. O famoso "NAT Type: Strict" que impede party chat e matchmaking
• P2P — BitTorrent e similares funcionam pior com CGNAT (menos peers alcançáveis)
• Bancos e serviços — Múltiplos assinantes com o mesmo IP podem causar bloqueios em sites que limitam por IP
• Identificação — Sem logs adequados, é impossível saber qual assinante fez qual acesso

O Desafio dos Logs CGNAT

E aqui está o problema central que afeta provedores: a obrigação legal de guardar logs.

O Marco Civil da Internet (Lei 12.965/2014, art. 13) obriga provedores de conexão a guardar registros de conexão por no mínimo 1 ano, "sob sigilo, em ambiente controlado e de segurança".

Sem CGNAT, um registro de conexão é simples: "Assinante João usou o IP 200.150.100.50 das 08:00 às 22:00 do dia 15/01".

Com CGNAT, você precisa registrar cada tradução NAT individual:

2026-01-15 14:32:15 | IP Privado: 100.64.5.23:45000 → IP Público: 203.0.113.45:34567 | Protocolo: TCP
2026-01-15 14:32:15 | IP Privado: 100.64.5.23:45001 → IP Público: 203.0.113.45:34568 | Protocolo: TCP
... (milhares de linhas por assinante por dia)

Quando a polícia ou justiça pergunta "quem usou o IP 203.0.113.45 porta 34567 às 14:32 do dia 15/01?", você precisa:

1. Pesquisar nos logs CGNAT para encontrar qual IP privado (100.64.x.x) estava mapeado naquela porta naquele momento
2. Cruzar com os logs de sessão PPPoE/DHCP para descobrir qual assinante tinha aquele IP privado
3. Responder com os dados do assinante

Um provedor de 1.000 assinantes com CGNAT dinâmico gera facilmente 10-50 milhões de registros NAT por dia. Em 1 ano, são bilhões de registros. Gerenciar isso exige ferramentas especializadas.

A Faixa 100.64.0.0/10 — O "IP de CGNAT"

A RFC 6598 definiu a faixa 100.64.0.0/10 (100.64.0.0 a 100.127.255.255) como "Shared Address Space", reservada especificamente para uso entre o provedor e o CPE do assinante em cenários de CGNAT.

Essa faixa:

• Não é roteável na internet pública
• Não deve ser confundida com 10.0.0.0/8 ou 192.168.0.0/16 (que são para redes privadas internas)
• Deve ser usada exclusivamente na camada entre o BRAS/CGNAT e o CPE

Quando um assinante reclama que "meu IP é 100.64.alguma.coisa", isso confirma que ele está atrás de CGNAT.

CGNAT no Dia a Dia do Provedor

Algumas situações práticas que todo NOC de provedor enfrenta com CGNAT:

• "Não consigo abrir porta" — Solução: oferecer IP público fixo (plano premium) ou IPv6 com port forwarding
• "Site X me bloqueou" — Causa: muitos assinantes no mesmo IP. Solução: aumentar pool de IPs públicos para aquele bloco CGNAT
• "Meu jogo diz NAT Strict" — Causa: NAT duplo (CPE + CGNAT). Solução: bridge mode no CPE + Full Cone NAT no CGNAT (se o equipamento suportar)
• "Preciso de IP fixo para câmeras" — Solução: plano com IP público (R$ 20-50/mês adicional) ou Dynamic DNS + IPv6