Como Correlacionar IP CGNAT com Assinante PPPoE

O Problema: Um IP, Muitos Assinantes

No mundo pré-CGNAT, cada assinante de internet recebia um IP público único. Quando uma autoridade judicial pedia "quem estava usando o IP 200.200.200.5 em 15/01/2026 às 14:30?", bastava consultar o RADIUS e a resposta era imediata: um único assinante.

Com a exaustão dos endereços IPv4 e a adoção massiva de CGNAT (Carrier-Grade NAT) pelos provedores brasileiros, esse cenário mudou drasticamente. Agora, um único IP público pode ser compartilhado por 16, 32 ou até 64 assinantes simultaneamente.

Isso significa que a pergunta "quem usava o IP 200.200.200.5?" não tem mais uma resposta simples. A resposta correta é: depende da porta.

Como o CGNAT Funciona (Visão Técnica)

O CGNAT opera traduzindo endereços IP privados (tipicamente da faixa 100.64.0.0/10, conhecida como Shared Address Space — RFC 6598) para um pool menor de IPs públicos. A diferenciação entre assinantes é feita pela faixa de portas.

Exemplo simplificado de uma tabela de tradução CGNAT:

Quando João acessa um site, a conexão sai com o IP 200.200.200.5 e uma porta na faixa 1024-2047. Quando Maria acessa o mesmo site, sai com o mesmo IP mas uma porta na faixa 2048-3071.

Por isso, para identificar um assinante atrás de CGNAT, você precisa de três informações:

1. IP público de destino/origem
2. Porta de origem (source port)
3. Timestamp exato (data e hora com precisão de segundos)

O Papel do RADIUS Accounting

O RADIUS é o protocolo que autentica e contabiliza as sessões PPPoE dos assinantes. Quando um cliente conecta, o NAS (seu roteador/BRAS) envia um Accounting-Start para o servidor RADIUS. Quando desconecta, envia um Accounting-Stop.

Esses registros ficam na tabela radacct (FreeRADIUS) e contêm campos essenciais:

SELECT username, framedipaddress, acctstarttime, acctstoptime, nasipaddress
FROM radacct
WHERE framedipaddress = '100.64.1.10'
  AND acctstarttime <= '2026-01-15 14:30:00'
  AND (acctstoptime >= '2026-01-15 14:30:00' OR acctstoptime IS NULL);

Campos relevantes:

• username — login PPPoE do assinante (geralmente CPF, código ou login)
• framedipaddress — IP privado atribuído ao assinante (100.64.x.x)
• acctstarttime — quando a sessão PPPoE iniciou
• acctstoptime — quando a sessão PPPoE encerrou (NULL se ainda ativa)
• nasipaddress — IP do concentrador que autenticou

O Processo de Correlação Manual

Quando chega uma intimação judicial dizendo: "Identificar o usuário que utilizava o IP 200.200.200.5, porta 2500, em 15/01/2026 às 14:32:15", o processo manual é:

Passo 1: Buscar no Log NAT

Procurar nos logs do equipamento que faz CGNAT (MikroTik, Huawei, Juniper) qual IP privado foi traduzido para aquele IP público + porta naquele momento:

# Exemplo de busca em log syslog
grep "200.200.200.5" /var/log/cgnat/2026-01-15.log | grep ":2500" | grep "14:32"

O resultado pode ser algo como:

Jan 15 14:32:15 CCR1036 CGNAT: src=100.64.1.11:43210 -> dst=200.200.200.5:2500 proto=TCP

Isso nos diz que o IP privado 100.64.1.11 estava por trás daquela porta.

Passo 2: Buscar no RADIUS

Agora, com o IP privado, consultar o RADIUS para saber qual assinante estava com aquele IP naquele momento:

SELECT username, framedipaddress, acctstarttime, acctstoptime
FROM radacct
WHERE framedipaddress = '100.64.1.11'
  AND acctstarttime <= '2026-01-15 14:32:15'
  AND (acctstoptime >= '2026-01-15 14:32:15' OR acctstoptime IS NULL);

Resultado:

username: maria.silva | framedipaddress: 100.64.1.11 | start: 2026-01-15 08:10:00 | stop: 2026-01-15 23:45:00

Pronto: o assinante era maria.silva.

Passo 3: Identificar o Assinante

Com o username PPPoE, consultar o sistema de gestão (ERP/CRM) para obter nome completo, CPF, endereço de instalação.

Por Que a Correlação Manual é Problemática

O processo descrito acima parece simples, mas na prática há diversos problemas:

1. Volume de dados absurdo

Um provedor com 2.000 assinantes gera 100-500 milhões de linhas de log NAT por dia. Buscar com grep em arquivos desse tamanho é lento e consome recursos do servidor. Uma busca pode levar minutos ou horas.

2. Formato inconsistente

Cada fabricante de equipamento gera logs NAT em formato diferente:

• MikroTik: CGNAT: forward: in:ether3 out:ether1, src-mac 00:11:22:33:44:55, proto TCP, 100.64.1.11:43210->203.0.113.50:443, NAT 100.64.1.11:43210->200.200.200.5:2500
• Huawei NE: NAT444 1 100.64.1.11 43210 200.200.200.5 2500 6 2026-01-15 14:32:15
• Juniper: RT_FLOW_SESSION_CREATE ... source-address="100.64.1.11" source-port="43210" nat-source-address="200.200.200.5" nat-source-port="2500"

Parsear esses formatos manualmente é propenso a erros.

3. Erros de timezone e NTP

Se o equipamento CGNAT e o servidor RADIUS estiverem com relógios dessincronizados (mesmo que em poucos segundos), a correlação pode falhar. O assinante A desconectou às 14:32:14 e o assinante B conectou com o mesmo IP às 14:32:16 — se o log NAT diz 14:32:15, qual dos dois era?

4. Pressão de tempo judicial

Intimações judiciais frequentemente chegam com prazo de 72 horas ou menos. Se o técnico está de folga, se o log está em um arquivo corrompido, se o RADIUS trocou de servidor... qualquer imprevisto pode causar descumprimento.

5. Falta de rastreabilidade

O processo manual não deixa um audit trail. Quem fez a consulta? Quando? Quais parâmetros usou? Isso pode ser questionado judicialmente.

Correlação Automática: Como Funciona no NATVault

O NATVault automatiza todo esse processo em uma única consulta:

1. Recebe o log NAT em tempo real (syslog, NetFlow ou IPFIX) e indexa no VictoriaLogs
2. Conecta-se ao RADIUS (FreeRADIUS, IXCSoft, MK-Auth, SGP, ou qualquer base com tabela radacct)
3. Na hora da consulta, o operador informa: IP público, porta, timestamp
4. O sistema automaticamente:
   • Busca no índice NAT qual IP privado corresponde (em milissegundos, mesmo com bilhões de registros)
   • Consulta o RADIUS para identificar a sessão PPPoE ativa naquele momento
   • Retorna: username, nome do assinante, CPF, IP privado, sessão RADIUS
5. Gera um relatório formatado para anexar à resposta judicial, com hash de integridade

Tempo total: menos de 5 segundos, independente do volume de dados.

Diagrama do fluxo:

Intimação Judicial
    ↓
[IP: 200.200.200.5 | Porta: 2500 | Data: 15/01/2026 14:32:15]
    ↓
┌─────────────────────────────────┐
│         NATVault Engine          │
│                                  │
│  1. Busca log NAT (VictoriaLogs) │
│     → 100.64.1.11               │
│                                  │
│  2. Busca RADIUS (radacct)       │
│     → maria.silva               │
│                                  │
│  3. Busca ERP (opcional)         │
│     → Maria Silva, CPF xxx      │
└─────────────────────────────────┘
    ↓
Relatório Judicial (PDF, hash SHA-256)

Integração com Diferentes Sistemas RADIUS

O NATVault se conecta às bases RADIUS mais comuns no mercado ISP brasileiro:

A configuração é feita uma única vez: você informa o IP, porta, credenciais (somente leitura) e o NATVault passa a correlacionar automaticamente.

Casos Especiais e Armadilhas

Assinantes com IP fixo

Alguns assinantes (geralmente empresariais) possuem IP público fixo e não passam pelo CGNAT. Nesses casos, a correlação é direta pelo RADIUS, sem necessidade do log NAT. O NATVault identifica automaticamente quando o IP consultado é público fixo e pula a etapa de busca NAT.

Double NAT

Se o assinante tem um roteador próprio fazendo NAT local (o que é quase sempre o caso), há um segundo nível de tradução. Porém, para fins judiciais, a responsabilidade do provedor vai até o CGNAT — identificar o assinante. O que acontece dentro da rede local do cliente é outra questão.

Sessões PPPoE que reconectam

É comum que sessões PPPoE caiam e reconectem várias vezes ao dia. A cada reconexão, o assinante pode receber um IP privado diferente. Por isso, a precisão do timestamp é crucial — um erro de poucos minutos pode apontar para o assinante errado.

Logs de NAT incompletos

Se o equipamento CGNAT não logou determinado período (falha de syslog, reboot, buffer cheio), a correlação é impossível para aquele período. O NATVault detecta gaps nos logs e alerta proativamente, para que você resolva antes que seja tarde.

Montando o Relatório Judicial

O relatório de resposta à intimação deve conter, no mínimo:

• Dados da consulta: IP, porta, protocolo, data/hora solicitados
• Resultado da correlação: IP privado encontrado no log NAT
• Sessão RADIUS: username, horário de início e fim da sessão
• Dados do assinante: nome, CPF, endereço
• Hash de integridade dos logs consultados
• Identificação do responsável técnico que gerou o relatório

O NATVault gera esse relatório automaticamente em formato PDF, com hash SHA-256 dos registros utilizados, pronto para protocolar.