CGNAT em provedores: logs de porta, NAT determinístico e o Marco Civil

O CGNAT resolveu a falta de IPv4 nos provedores, mas criou um problema jurídico: quando chega um ofício pedindo a identificação de quem usou um IP em determinado horário, aquele IP estava sendo usado por dezenas de clientes ao mesmo tempo. Sem a porta de origem e registros confiáveis, o provedor não consegue responder.

Neste tutorial você vai entender o que precisa ser registrado, as três formas de fazer isso, o impacto de cada uma no volume de logs e o que garante que os registros valham quando forem necessários. Não é orientação jurídica: para o enquadramento legal do seu caso, consulte um advogado.

Por que o IP não basta

Sem CGNAT, cada cliente recebe um IP público, e o registro "IP X, das 10h às 18h, cliente Y" basta para identificar quem estava conectado. Com CGNAT, o cliente recebe um IP da faixa 100.64.0.0/10, e o concentrador traduz as conexões dele para um IP público compartilhado, diferenciando os clientes pela porta.

Um site ou serviço de terceiros registra algo como:

2026-10-17 14:32:07 -0300  origem 203.0.113.45:51234  →  destino 198.51.100.10:443

Para chegar ao cliente, o provedor precisa responder: naquele segundo, quem estava usando a porta 51234 do IP 203.0.113.45? Isso só é possível com o IP público, a porta e o horário exato, e só se o provedor tiver guardado como cada porta estava mapeada.

O que o Marco Civil exige

O Marco Civil da Internet (Lei 12.965/2014) obriga o provedor de conexão a guardar os registros de conexão por 1 ano, sob sigilo, em ambiente controlado e de segurança. Esses registros são a data e a hora de início e término da conexão, a duração e o endereço IP usado.

A lei não fala em porta, porque foi escrita pensando em IPs exclusivos. Mas, com CGNAT, o IP sozinho não identifica ninguém, e decisões judiciais têm exigido a porta lógica de origem justamente por isso. Na prática, o provedor que usa CGNAT precisa ser capaz de chegar do trio IP, porta e horário ao cliente, pelo mesmo prazo.

Três formas de registrar o NAT

O log por sessão é o mais simples de ativar e o mais caro de manter: armazenamento, indexação e, principalmente, a busca, que precisa achar uma linha entre bilhões quando chega o ofício. A maioria dos provedores que começam assim acaba migrando para uma das outras duas formas.

NAT determinístico na prática

No NAT determinístico (descrito no RFC 7422), a relação entre IP privado e porta pública é uma conta fixa. Com 2.000 portas por cliente, por exemplo:

IP público 203.0.113.45
  cliente 100.64.0.0  → portas  1024 a  3023
  cliente 100.64.0.1  → portas  3024 a  5023
  cliente 100.64.0.2  → portas  5024 a  7023
  ...
  cliente 100.64.0.31 → portas 63024 a 65023

Para responder "quem usava 203.0.113.45:51234", basta fazer a conta inversa e chegar ao IP privado 100.64.0.25. Depois, os registros de autenticação dizem qual cliente estava com esse IP privado naquele horário.

As vantagens são claras: nenhum log por sessão, consulta instantânea e nada que se perca se o servidor de logs cair. Os pontos de atenção:

• A configuração vira registro. Qualquer mudança no mapeamento (mais IPs públicos, outro tamanho de bloco) precisa ser guardada com data e hora de início e fim de validade, pelo mesmo prazo.
• Portas fixas por cliente. Um cliente que esgota as portas dele não pega emprestadas de outro, então o tamanho do bloco precisa ser bem escolhido.
• Cada fabricante implementa de um jeito. Alguns concentradores fazem nativamente; em outros o mapeamento é montado com regras, e um erro na regra quebra a conta.

Quantos clientes por IP público

Cada IP público tem 64.512 portas utilizáveis (de 1024 a 65535). A divisão depende de quantas portas cada cliente precisa:

Portas de menos geram reclamações difíceis de diagnosticar: páginas que carregam pela metade, jogos que desconectam, câmeras que caem. Portas de mais desperdiçam IPv4, que custa caro. O número certo vem da medição do uso real dos seus clientes, não de uma tabela.

Do ofício ao cliente: a cadeia de registros

Responder um ofício com CGNAT exige cruzar três registros diferentes, cada um com o próprio prazo de guarda:

1. NAT: IP público, porta e horário levam ao IP privado (pelo log, pelo bloco atribuído ou pela conta do determinístico).
2. Autenticação: o accounting do RADIUS diz qual login estava com aquele IP privado naquele momento.
3. Cadastro: o login leva ao contrato e aos dados do cliente.

Se qualquer elo falhar, a resposta é "não foi possível identificar". E se um elo estiver errado, o problema é pior: o provedor identifica a pessoa errada.

Cuidados que invalidam os registros

• Relógio. Concentradores, servidores RADIUS e servidores de log sincronizados por NTP. Alguns segundos de diferença bastam para apontar outro cliente, já que IPs privados e portas são reaproveitados o tempo todo.
• Fuso horário. O ofício pode vir em UTC, em horário de Brasília ou no horário do servidor de destino. Registros sem fuso explícito geram dúvida sobre qual hora é qual.
• Lacunas. Um servidor de log que encheu o disco ou ficou fora do ar por um dia é um dia sem como responder.
• Integridade. Registros que podem ser alterados sem deixar rastro têm valor questionável. Cópias imutáveis e controle de acesso fazem parte do "ambiente controlado e de segurança" da lei.
• Teste. O único jeito de saber se a cadeia funciona é testar: escolher uma conexão real, anotar IP, porta e horário e verificar se o processo chega ao cliente certo.

Do tutorial à produção

Entender o que guardar é o primeiro passo. Montar um CGNAT que responda ofícios corretamente por um ano inteiro, em todos os concentradores, é o que este tutorial não cobre:

• Escolha e implantação do modelo. Determinístico, por blocos ou por sessão conforme os seus concentradores, com o tamanho de bloco medido no uso real.
• Guarda dos registros. NAT, RADIUS e histórico de configuração guardados por um ano, com integridade, cópia e controle de acesso.
• Consulta em minutos. Uma ferramenta interna que recebe IP, porta e horário e devolve o cliente, sem depender de alguém procurar em arquivos.
• Relógio e fuso confiáveis. NTP em todos os elementos, monitorado, e registros com fuso explícito.
• IPv6 em paralelo. Quanto mais tráfego em IPv6, menos sessões no CGNAT e menos pressão sobre os registros.

Perguntas frequentes

Por quanto tempo o provedor deve guardar os logs de CGNAT?

O Marco Civil da Internet (Lei 12.965/2014) determina que o provedor de conexão guarde os registros de conexão por 1 ano, sob sigilo e em ambiente controlado e seguro. Com CGNAT, o registro só identifica o cliente se incluir a porta, então os logs de NAT precisam seguir o mesmo prazo.

NAT determinístico dispensa guardar logs?

Dispensa o log de cada sessão, mas não todos os registros. Ainda é preciso guardar a configuração do mapeamento com o período de validade de cada versão e os registros de autenticação (RADIUS), que dizem qual cliente estava com cada IP privado em cada momento.

Qual faixa de IP usar no CGNAT?

A faixa 100.64.0.0/10, reservada para esse uso pelo RFC 6598. Ela não conflita com as redes privadas (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16) que os clientes usam dentro de casa.

O IPv6 resolve o problema dos logs?

Para o tráfego IPv6, sim: cada cliente tem o próprio prefixo e o registro de conexão volta a ser só o endereço e o horário. Mas enquanto houver tráfego IPv4 passando pelo CGNAT, os registros de porta continuam necessários.