CGNAT para Provedor de Internet

Quando o estoque de endereços IPv4 públicos do seu provedor começa a apertar, o CGNAT para provedor de internet deixa de ser um assunto técnico distante e vira uma decisão comercial urgente. Sem ele, você simplesmente para de atender novos assinantes — ou passa a pagar caro por blocos IPv4 que cada vez valem menos. O problema é que um CGNAT mal implementado quebra serviços dos clientes, gera chamados em massa e pode deixar o provedor sem condições de responder a ofícios.

Este guia mostra como a Baronix implementa CGNAT para provedores em todo o Brasil: o que considerar antes de ligar o NAT444, como dimensionar o bloco de portas, como estruturar o logging para compliance e por que CGNAT não substitui a migração para IPv6.

O que é CGNAT e quando um provedor precisa implementar

CGNAT (Carrier-Grade NAT), também chamado de NAT444, é uma técnica de tradução de endereços que permite que muitos clientes compartilhem um mesmo endereço IPv4 público. Em vez de entregar um IP dedicado para cada assinante, o provedor usa um bloco de portas TCP/UDP de cada IP público para atender vários clientes simultaneamente.

O provedor precisa implementar CGNAT quando:

• Esgotamento de IPv4: os blocos públicos não comportam mais novos assinantes;
• Custo de novos blocos: adquirir IPv4 no mercado secundário ficou proibitivo;
• Crescimento acelerado: a base de clientes cresce mais rápido que a disponibilidade de IPs;
• Preparação para IPv6: CGNAT dá fôlego para planejar a migração dual-stack sem pressa.

CGNAT não é opcional para a maioria dos ISPs em crescimento — é a única forma de continuar atendendo novos clientes enquanto o IPv6 não cobre toda a base.

Como funciona o NAT444 na prática

O NAT444 encadeia duas traduções: o NAT do cliente (NAT44, dentro do CPE) e o CGNAT na borda do provedor. O resultado é que o tráfego sai do cliente com IP privado, é traduzido pelo CPE e novamente traduzido pelo CGNAT antes de chegar à internet.

O ponto crítico é o bloco de portas. Cada IP público tem 65.535 portas utilizáveis. Se você reservar, por exemplo, 1.000 portas por cliente, um único IP público atende cerca de 60 assinantes. Ajustar essa razão define quantos clientes um bloco IPv4 sustenta — e quanto cada cliente "enxerga" de internet simultânea.

CGNAT não é só ligar NAT na borda. É decidir quantas portas cada cliente recebe, como alocar os blocos e como registrar cada tradução para responder a um ofício sem depender de adivinhação.

Dimensionamento de CGNAT: portas, blocos e escala

O dimensionamento errado é a causa mais comum de problemas em CGNAT. Poucas portas por cliente quebram aplicações que abrem muitas conexões (streaming, jogos, videochamadas). Portas demais reduzem a taxa de compartilhamento e esgotam o bloco IPv4 mais rápido.

Pontos que definem o dimensionamento:

• Portas por cliente: definir um bloco fixo (ex.: 1.000 a 2.000 portas) ou alocar dinamicamente conforme demanda;
• Tamanho do bloco IPv4 público: um /24 (256 IPs) com 1.000 portas por cliente atende cerca de 15.000 assinantes em pico;
• Capacidade do equipamento: CPU, memória e taxa de tradução do roteador/appliance de CGNAT;
• Concorrência de conexões: estimar quantas conexões simultâneas cada perfil de cliente gera;
• Margin de segurança: reservar IPs públicos para serviços que não podem passar por CGNAT (corporativo, servidores).

A Baronix projeta a borda do provedor considerando o dimensionamento de CGNAT junto com BGP e redundância, para que o crescimento não quebre a rede no primeiro pico de demanda.

CGNAT em MikroTik vs roteador de borda dedicado

Muitos provedores pequenos e médios rodam CGNAT em MikroTik (RouterOS). Funciona, mas tem limites. A escala suportada depende do modelo do equipamento — roteadores CCR aguentam mais tradução que RBs de entrada. Em provedores com milhares de assinantes, o CGNAT em MikroTik pode virar gargalo de CPU e memória, especialmente com logging habilitado.

Quando avaliar uma plataforma dedicada de CGNAT:

• A base passa de alguns milhares de assinantes sob CGNAT;
• O logging para compliance consome recursos do roteador principal;
• Aparecem reclamações de serviços que pararam de funcionar após o CGNAT;
• O provedor quer separar a função de CGNAT do roteamento de borda (BGP).

A Baronix avalia caso a caso se o MikroTik atual comporta o CGNAT ou se vale migrar para um appliance dedicado, sempre considerando o custo-benefício para o porte do provedor.

Logging e compliance: respondendo a ofícios sem caos

O maior risco jurídico do CGNAT mal implementado é não conseguir identificar qual cliente usava um IP público em um determinado momento. Quando chega um ofício (judicial, policial, Anatel), o provedor precisa informar qual assinante estava atrás daquele IP:porta na data e hora indicadas.

Sem logging estruturado, o provedor fica exposto. Com logging correto, a resposta sai em minutos. O que registrar:

• IP:porta pública alocada a cada cliente em cada intervalo de tempo;
• IP interno do assinante (do CPE) e identificador do cliente;
• Timestamp de início e fim de cada tradução;
• Retenção pelo prazo exigido pela legislação aplicável.

O logging determinístico (bloco de portas fixo por cliente) simplifica muito a resposta a ofícios, porque basta olhar o IP:porta para saber o cliente — sem precisar consultar log de cada conexão. A Baronix implementa essa abordagem sempre que possível.

CGNAT vs migração para IPv6: por que não é um substituto

Um erro comum é tratar CGNAT como solução definitiva. Ele é um paliativo. O IPv4 público vai continuar escassez e ficando mais caro, e o CGNAT impõe limitações técnicas (conexões de entrada, NAT traversal, experiência do cliente em alguns serviços).

A estratégia correta é dupla:

• Curto prazo: implementar CGNAT para liberar crescimento imediato;
• Médio/longo prazo: iniciar a migração para IPv6 com dual-stack, delegação de prefixos (DHCPv6-PD) e ajuste de firewall e monitoramento.

Assim o provedor para de depender do CGNAT gradualmente, à medida que mais clientes e serviços passam a funcionar nativamente em IPv6. A Baronix conduz as duas frentes em paralelo, integrando CGNAT e IPv6 na mesma arquitetura de borda.

Erros comuns que quebram o provedor

• Portas insuficientes por cliente: streaming e videochamadas começam a falhar;
• Sem logging: impossível responder a ofícios, risco jurídico;
• CGNAT no roteador errado: CPU no limite derruba o BGP junto;
• Não isolar clientes corporativos: IP dedicado entregue por engano no CGNAT;
• Ignorar IPv6: CGNAT vira solução permanente e o provedor fica para trás;
• Sem monitoramento de CGNAT: esgotamento de portas só é percebido quando o cliente liga reclamando.

A Baronix implementa monitoramento específico para CGNAT — alertas de esgotamento de portas, utilização de blocos e taxa de tradução, para que a operação detecte o problema antes do cliente.

Como a Baronix implementa CGNAT para provedores

A Baronix atua na implementação completa de CGNAT para ISPs em todo o Brasil, remoto e presencial:

• Diagnóstico da borda: avaliação do roteamento atual, blocos IPv4 disponíveis e perfil da base de clientes;
• Dimensionamento: cálculo de portas por cliente, blocos públicos e capacidade do equipamento;
• Implementação: configuração de NAT444 em MikroTik ou roteador de borda, com bloco de portas determinístico;
• Logging e compliance: estrutura de logs para resposta a ofícios com retenção adequada;
• Integração com IPv6: plano de migração dual-stack para reduzir a dependência de CGNAT;
• Monitoramento: alertas de esgotamento de portas e integridade do CGNAT;
• Suporte N2/N3: sustentação recorrente para incidentes e evolução da borda.

Perguntas frequentes

Conclusão

CGNAT para provedor de internet é uma decisão técnica e comercial ao mesmo tempo. Feito certo, libera crescimento e dá tempo para migrar para IPv6 com calma. Feito errado, gera chamados, quebra serviços e deixa o provedor exposto juridicamente. Se o seu estoque de IPv4 está apertando, o momento de estruturar o CGNAT é agora — antes que vire emergência.