CGNAT: o que muda para quem opera a rede

Autor: Pedro Tebaldi PM do KeepGreen

Publicado set/2026

Quase todo chamado desse tipo chega igual: o acesso remoto ao gravador da filial parou. Ninguém mexeu em nada, o link está no ar e o ping responde. A navegação da loja funciona, assim como o Wi-Fi. Morreu apenas a conexão que vem de fora para dentro, sem aviso e de uma vez só.

Na maioria das vezes a causa não está no seu firewall nem no equipamento da ponta. A operadora colocou aquele link atrás de CGNAT. O endereço público que a filial usava deixou de ser dela, porque agora ele é compartilhado com centenas de outros assinantes.

Este texto trata do que muda na operação quando isso acontece. Você vai encontrar aqui o teste que confirma o diagnóstico em poucos minutos. Depois disso, o que exatamente para de funcionar, por que o IP do seu log deixou de identificar alguém e quais saídas existem.

O que é CGNAT e por que a operadora ligou isso no seu link

CGNAT é o NAT da operadora: um tradutor de endereços instalado dentro da rede do provedor. Ele faz centenas de assinantes saírem para a internet com o mesmo endereço IPv4 público.

O roteador da sua filial continua traduzindo, embora agora exista um segundo tradutor acima dele. Essa pilha de dois é o que a literatura chama de NAT444.

Por trás dessa decisão existe uma aritmética simples. O espaço de endereçamento do IPv4 acabou, de modo que os provedores que cresceram depois não tinham como entregar um endereço público por cliente. Em vez de parar de vender acesso, passaram a compartilhar o que já tinham.

Duas coisas separam esse arranjo do NAT que você já conhece: o lugar e a escala. O NAT do roteador da filial traduz endereços de uma rede que é sua, conforme regras que você escreve. Já o CGNAT traduz o endereço da filial junto com o dos vizinhos, dentro de um equipamento que você não administra. As regras dele você não escreve nem enxerga.

Como confirmar em cinco minutos que o link está atrás de CGNAT

Todo o teste se resume a dois números e uma comparação. Abra a interface do roteador da ponta e anote o endereço da WAN. Depois, de dentro daquela mesma rede, consulte qual endereço público a internet enxerga. Quando os dois são diferentes, existe uma tradução acontecendo fora do seu equipamento.

Existe um atalho que dispensa a comparação. Quando o endereço da WAN cai entre 100.64.0.0 e 100.127.255.255, o diagnóstico fecha ali mesmo.

São cerca de 4,19 milhões de endereços, reservados pela IANA em 2012 para uma finalidade única. Eles ligam o roteador do assinante ao tradutor do provedor, conforme o documento do IETF que criou a reserva.

Essa reserva carrega uma regra que explica o resto do artigo: pacotes com origem ou destino nessa faixa não podem ser encaminhados entre provedores. O endereço parece público, já que não pertence às faixas privadas clássicas, porém ele não roteia na internet aberta.

Duas armadilhas aparecem aqui. A primeira é de classificação. Regra de firewall e parser de log que tratam como interno apenas 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 vão marcar o 100.64.x.x como externo. A segunda é a leitura do traceroute, que costuma exibir um salto nessa faixa antes do primeiro salto público.

O que para de funcionar e o que continua igual

Tudo que a sua rede inicia continua funcionando. O que precisa ser iniciado de fora para dentro para de funcionar. Como a maior parte do uso corporativo sai de dentro, o usuário comum não percebe nada, enquanto a operação perde justamente os caminhos de administração.

Entre esses itens, a VPN merece atenção, porque ela falha de forma assimétrica. Enquanto a filial for a ponta que chama, o túnel sobe; quando o desenho prevê que o concentrador inicie a negociação, ela nunca completa. Revise o desenho antes de culpar o equipamento, já que os modelos de VPN corporativa se comportam de maneira diferente nesse ponto.

Câmeras e gravadores foram a perda mais visível. O acesso por porta publicada morreu na prática. Os fabricantes migraram para relay em nuvem, o que devolve o acesso, embora transfira a dependência para o serviço do fornecedor. Quem opera câmeras IP e CFTV passa a ter um terceiro no caminho crítico.

O IP do seu log deixou de identificar alguém

Sob CGNAT, um endereço IPv4 público não aponta mais para um assinante. Ele aponta para o tradutor do provedor, que naquele segundo atendia dezenas ou centenas de clientes. Sem a porta de origem e sem o horário com precisão de segundo, a identificação não fecha.

Aqui aparece um problema mais profundo: a lei brasileira foi escrita antes desse arranjo. O texto da Lei nº 12.965/2014 define registro de conexão como data, hora de início e término, duração e o endereço IP utilizado pelo terminal.

A lei ainda obriga a guarda desses dados por um ano. A palavra porta não aparece nenhuma vez no texto.

Esse mesmo artigo 5º define endereço IP como o código atribuído a um terminal para permitir sua identificação. Essa é exatamente a premissa que o CGNAT quebra, porque o código deixou de pertencer a um terminal. Identificar alguém passou a exigir quatro dados: endereço público, porta de origem, horário com fuso e o registro que liga aquela tradução ao assinante.

Do lado do cliente, a consequência é operacional. Quando chega uma notificação de abuso apontando o endereço de saída da filial, aquele endereço não é só seu. E quando você tenta cruzar um IP do próprio log de firewall com um evento externo, o cruzamento pode simplesmente não existir.

Reputação, geolocalização e portas: o que você herda de desconhecidos

Compartilhar o endereço de saída significa compartilhar a reputação dele. Quando um vizinho de CGNAT dispara spam ou varre portas, o endereço entra em lista de bloqueio. Todo mundo que sai por ali sofre junto, sem ter feito nada.

Os sintomas chegam ao service desk sem cara de problema de rede. CAPTCHA repetido em serviço que sempre abriu, bloqueio em portal de terceiro, geolocalização apontando outra cidade, segundo fator exigido em toda sessão. A causa está no endereço de saída, embora o chamado sempre aponte para a estação do usuário.

Existe ainda um limite menos conhecido: o tradutor do provedor precisa racionar portas entre assinantes.

Segundo os requisitos comuns publicados pelo IETF, o equipamento deve suportar a limitação do número de portas externas por assinante. Quando a filial estoura essa cota, sessões novas falham enquanto as antigas seguem de pé.

Esse é o sintoma que costuma ser reportado como lentidão. A navegação parece normal porque as sessões estabelecidas continuam, porém cada conexão nova demora ou falha. Aplicação que abre muitas sessões curtas sofre primeiro, o que inclui sincronização, telemetria e alguns clientes de banco de dados.

A diferença entre TCP e UDP mostra por onde esse racionamento aperta. Cada fluxo ocupa uma entrada na tabela de tradução do provedor. O UDP ainda depende do tempo de expiração do mapeamento, o que explica o registro SIP caindo sozinho.

Cabe registrar o outro lado dessa história. Do ponto de vista de segurança de rede, o CGNAT não é um controle. Ele esconde a origem por acidente, sem política sua, sem log seu e sem regra que você possa auditar.

As três saídas e o que cada uma custa

Pedir um endereço público dedicado para o link é a saída mais direta. Ela resolve tudo que depende de entrada, cobra mensalidade e depende de o provedor ter endereço sobrando. Em contrato corporativo costuma estar disponível, embora em banda larga de filial pequena nem sempre exista.

Vem em seguida o IPv6, que é a única saída definitiva. Com endereço global por dispositivo, a barreira acidental do NAT some. O firewall passa a ser a única fronteira, o que muda a política de borda antes de qualquer ganho. Vale planejar a migração para IPv6 antes de precisar dela, porque habilitar o protocolo no provedor é a parte fácil.

Sobra a terceira, que é redesenhar para que a conexão sempre nasça de dentro. Túnel iniciado pela filial, agente que reporta ao console, relay do fabricante: em todos os casos quem chama é a ponta atrás do tradutor. Essa saída não depende de negociação com a operadora e costuma entrar em produção mais rápido.

O que vigiar depois de escolher a saída

Cada opção muda o alvo da coleta. Com endereço dedicado, vigie a reputação dele em listas públicas e a continuidade do link. Com IPv6, vigie a paridade, porque o serviço pode responder por um protocolo e falhar no outro. Com túnel, vigie o próprio túnel, já que ele virou o único caminho de administração.

Em comum, as três exigem que o teste deixe de partir de fora. Um check que tenta abrir porta na filial vai falhar para sempre. Pior: ele treina o plantão a ignorar o alarme. O monitoramento do link de cada unidade precisa nascer dentro dela, com o resultado subindo para o console central.

Na Marisa, monitoramos 433 lojas a partir do datacenter. No mesmo painel entram o servidor on-site, o gateway de pagamento e os bancos Oracle de cada operação. Em uma malha desse tamanho a visibilidade se constrói como arquitetura, nunca loja a loja: o case do varejo de moda detalha o desenho.

Por onde começar na segunda-feira

Nada disso é uma falha a corrigir do seu lado. O CGNAT é uma decisão de arquitetura do provedor, cujo resultado a sua operação herda. O que muda é o desenho da rede, já que o equipamento da ponta continua o mesmo.

Três providências resolvem a maior parte do estrago. Levante quais links da sua malha já estão nessa condição, usando a comparação de endereços da seção de diagnóstico. Em seguida, marque todo teste de monitoramento que hoje tenta entrar de fora. Cada um deles é um alarme falso esperando a hora de disparar.

Por fim, decida saída por saída, link a link, já que filial com câmera e filial só com PDV não têm o mesmo requisito. A parte cara desse trabalho nunca é a técnica: é descobrir a condição durante um incidente, com o cliente parado do outro lado.

Quando a sua operação tem unidades remotas atrás de link de operadora, vale mapear o que precisa mudar antes do próximo chamado. Para isso, fale com um especialista da OpServices.