Configuração de NAT determinístico: guia prático para provedores
Configuração de NAT determinístico: é programar o CGNAT para que cada endereço interno use sempre o mesmo IP público e a mesma faixa de portas, calculados por uma fórmula. Com a fórmula guardada, o provedor descobre quem usava um IP e uma porta em qualquer data sem manter uma linha de registro por conexão.
Resumo
- No modo determinístico, a porta pública aponta o endereço interno por conta, sem consultar um log de traduções.
- A proporção de clientes por IP público decide quantas portas cada assinante tem, e é a escolha mais delicada.
- O histórico de sessões do RADIUS continua obrigatório, porque liga o endereço interno ao contrato.
- Mudar a fórmula sem guardar a versão antiga e a data deixa sem resposta qualquer ofício sobre o período anterior.
Como funciona a configuração de NAT determinístico?
Cada bloco de endereços internos é amarrado a um IP público, e cada endereço do bloco recebe uma fatia fixa das portas desse IP. A tradução deixa de ser sorteada a cada conexão e passa a seguir uma tabela previsível.
No CGNAT comum, cada conexão nova ganha uma porta qualquer que esteja livre, e só o registro daquela tradução responde quem era o assinante. Com milhares de clientes abrindo conexões o dia inteiro, esse registro vira o maior volume de dados do provedor.
No determinístico, basta guardar a fórmula e o histórico de quem usava cada endereço interno. É uma das formas de enxugar a guarda de logs de CGNAT para provedores sem perder a capacidade de apontar o cliente.
| Ponto | Dinâmico | Determinístico |
|---|---|---|
| Portas do cliente | Escolhidas a cada conexão | Faixa fixa por cliente |
| Registro necessário | Uma linha por conexão | Fórmula e IP privado do cliente |
| Aproveitamento das portas | Alto | Menor, a faixa fica reservada |
A fórmula que liga a porta ao endereço interno
A fórmula mais simples parte de três números: o início da faixa de portas, o tamanho da fatia de cada cliente e a posição do endereço dentro do bloco interno. Com eles, a conta funciona nos dois sentidos.
Na ida, o endereço interno define a faixa de portas. Na volta, a porta informada num ofício define a posição no bloco, e a posição define o endereço interno que fez a conexão.
O que a RFC 7422 descreve
A RFC 7422 descreve o mapeamento determinístico como forma de reduzir o registro em CGNAT de operadoras. A ideia central é que o equipamento não precise informar cada tradução, porque a tradução já é conhecida.
O documento também lembra que o mapeamento só serve se for reproduzível depois, o que exige guardar a configuração vigente em cada período junto com os registros de sessão.
Quantos clientes por IP público?
Depende de quantas portas cada assinante consome no pico, e a resposta vem de medição, não de tabela pronta. Proporções de 32 ou 64 clientes por IP são pontos de partida comuns em provedores regionais.
A divisão começa pelas portas disponíveis em cada IP público. Usando a faixa de 1024 a 65535, sobram 64.512 portas para repartir entre os endereços internos ligados àquele IP.
| Clientes por IP | Portas por cliente | Leitura |
|---|---|---|
| 32 | 2.016 | Folga para casas com muitos aparelhos |
| 64 | 1.008 | Equilíbrio comum entre IPs e portas |
| 128 | 504 | Pouco para quem usa muitos aplicativos ao mesmo tempo |
Um bloco /26 interno para cada IP público facilita a fórmula na proporção de 64, porque o último octeto do endereço já indica a posição do cliente no bloco.
Quantas portas cada cliente precisa
Depende do uso. Jogos, câmeras e muitas abas abertas consomem portas rápido. Meça o uso real antes de escolher a proporção.
Como medir o consumo de portas antes de decidir
Conte as traduções ativas por endereço interno no horário de pico, durante alguns dias, no CGNAT que já está em produção. O número que importa é o dos clientes mais pesados, e não a média.
Se uma parcela pequena da base passa da fatia escolhida, ela vai sofrer com conexões recusadas. Nesse caso, reduza a proporção ou separe esses clientes num bloco com mais portas.
Determinístico ou alocação por blocos?
O determinístico é a saída para quem não tem equipamento com alocação por blocos ou não quer manter um servidor de registros. O preço é a porta reservada que fica parada quando o cliente está ocioso.
Quando a fatia fixa acaba cedo para alguns assinantes, a configuração de port block allocation entrega portas sob demanda e registra só a entrega de cada bloco.
Configuração de NAT determinístico passo a passo
A configuração de NAT determinístico exige fechar a proporção e a numeração antes de gerar a primeira regra, porque cada mudança posterior cria uma nova versão da fórmula. Em produção, as regras saem de um script, nunca da mão.
- Proporção: defina quantos endereços internos dividem cada IP público, com base na medição de portas.
- Numeração: amarre cada bloco interno, como um /26, a um único IP público.
- Script: gere as regras de TCP, UDP e demais protocolos a partir da fórmula.
- Versão: registre a fórmula, a lista de blocos e a data de entrada em produção.
- Teste: faça uma conexão de teste e refaça a conta de volta até o endereço interno.
O exemplo mostra as regras de um cliente numa divisão de 64 clientes por IP. Em produção, as regras são geradas por script.
/ip firewall nat
add chain=srcnat src-address=100.64.0.0/26 \
action=jump jump-target=cgnat-ip1
add chain=cgnat-ip1 src-address=100.64.0.1 protocol=tcp \
action=src-nat to-addresses=203.0.113.1 to-ports=1024-2031
add chain=cgnat-ip1 src-address=100.64.0.1 protocol=udp \
action=src-nat to-addresses=203.0.113.1 to-ports=1024-2031
add chain=cgnat-ip1 src-address=100.64.0.1 \
action=src-nat to-addresses=203.0.113.1O cliente 100.64.0.2 recebe as portas 2032 a 3039, e assim por diante. A cadeia separada por bloco evita que cada pacote percorra todas as regras.
Consulta de ofício que leva horas?
Na guarda de logs de CGNAT, um Especialista escolhe a forma de registro, documenta a fórmula e entrega uma consulta que vai do IP público ao contrato.
Por que gerar as regras por script
Um IP público na proporção de 64 pede perto de duzentas regras, e um pool com dezenas de IPs passa de milhares. Escrever isso à mão garante pelo menos uma faixa sobreposta ou um cliente esquecido.
O script recebe o bloco interno, o IP público e a proporção, e devolve as regras e uma planilha da fórmula. A mesma planilha serve depois para a consulta reversa.
O detalhe do .0 e da última faixa
No exemplo, a numeração começa no endereço .1 do bloco, que recebe a primeira faixa. Assim, o .0 fica sem uso e a última fatia de portas do IP sobra.
Não há erro nisso, desde que o tratamento seja fixo e esteja escrito na documentação da fórmula. O problema aparece quando um script novo passa a contar a partir do .0 sem mudar a versão registrada.
A regra sem protocolo e outros fabricantes
A última regra do exemplo, sem protocolo, cobre o tráfego que não usa porta, como o ICMP. Sem ela, o ping e alguns protocolos do cliente deixam de funcionar.
Juniper, Cisco, A10 e outros têm o determinístico como função pronta, com a fórmula calculada pelo próprio equipamento. Confira no manual da versão.
Exemplo: do ofício ao endereço interno
A consulta reversa começa no IP público, na porta e no horário que chegam no pedido, passa pela fórmula e termina no histórico de sessões. Sem o horário exato, nenhuma das etapas fecha.
- Pedido: chega um ofício citando o IP 203.0.113.1, a porta 2500 e um horário com fuso definido.
- Versão da fórmula: confere qual configuração estava valendo naquela data.
- Posição: a porta 2500 menos 1024, dividida por 1.008, dá a posição 1, que é o segundo cliente do bloco.
- Endereço interno: a segunda posição do bloco 100.64.0.0/26 é o 100.64.0.2, com as portas 2032 a 3039.
- Sessão: o histórico do RADIUS mostra qual login estava com o 100.64.0.2 naquele horário.
A última etapa depende do registro das sessões PPPoE ou IPoE, com o endereço entregue e o horário de início e de fim. A guarda de registros de conexão cobre essa parte, que vale para qualquer modo de CGNAT.
O que ainda precisa ser guardado
A fórmula não basta sozinha: é preciso guardar qual cliente usava cada IP privado e em que período. O prazo e a forma de guarda seguem o Marco Civil da Internet e a regra aplicável ao provedor [CONFIRMAR na norma].
- Versões da fórmula: cada configuração, com data de início e de fim.
- Sessões de acesso: login, endereço interno, início e fim de cada sessão.
- Relógio: a fonte de horário dos equipamentos, para provar que os registros batem entre si.
Erros comuns no NAT determinístico
Os erros mais comuns deixam o cliente sem portas no pico ou o provedor sem resposta para uma ordem judicial. O segundo tipo só aparece meses depois, quando o ofício chega.
Evite
- Muitos clientes por IP, com portas de menos para o uso real.
- Mudar a fórmula sem guardar a versão antiga e a data.
- Não registrar a troca de IP privado do cliente.
- Regras escritas à mão, sem script.
- Esquecer UDP nas regras, o que quebra jogos, DNS e chamadas.
Jogos são os primeiros a reclamar quando a fatia de portas aperta ou quando o UDP fica de fora. O guia sobre CGNAT travando jogos mostra como separar esse sintoma de outros problemas de NAT.
No longo prazo, cada conexão que sai por IPv6 deixa de ocupar porta no CGNAT. A implantação de NAT64 e o dual stack reduzem a dependência do IPv4 compartilhado.
Checklist de validação do determinístico
Valide refazendo uma consulta real com uma conexão feita de propósito por um login de teste. Se a conta não chegar ao login certo, a fórmula não serve para responder ofícios.
Confira com uma conexão de teste antes de levar a fórmula à base
- Um IP e uma porta públicos levam ao cliente certo pela fórmula.
- Clientes não esgotam as portas no horário de pico.
- O histórico de IPs privados está sendo guardado.
- A versão da fórmula está registrada com data.
- TCP, UDP e ICMP do login de teste saem pelo IP e pela faixa esperados.
- O relógio do CGNAT e o do RADIUS estão sincronizados com a mesma fonte.
A primeira linha é a que importa diante de um ofício. Se ela falhar, revise a numeração e o script antes de qualquer outro ajuste.
A Táquion Tech dimensiona a proporção pelo consumo medido, gera as regras por script e documenta a consulta reversa com um teste feito por um login real.
Perguntas frequentes sobre configuração de NAT determinístico
NAT determinístico dispensa registro?
Dispensa o registro por conexão. Ainda é preciso guardar a fórmula de cada período e quem usava cada IP privado.
E se o cliente esgotar as portas?
Novas conexões dele falham até alguma porta da faixa ficar livre. Reduza a proporção de clientes por IP ou use a alocação por blocos.
O cliente percebe alguma diferença?
Normalmente não, se a faixa de portas for suficiente para o uso dele. Quem tem muitos aparelhos e jogos pode sentir quando a proporção é apertada.
Dá para fazer NAT determinístico em MikroTik?
Dá, com regras de src-nat por endereço interno e faixa de portas, como no exemplo. O ponto de atenção é gerar as regras por script e guardar cada versão.
Mudar a proporção depois da implantação é possível?
É possível, mas cria uma nova versão da fórmula. Guarde a anterior com a data de saída, porque ofícios sobre o período antigo ainda dependem dela.
Serviços ligados a este guia
- Migração de assinantes entre redes para provedores Fusões e aquisições
- Alta disponibilidade de CGNAT para provedores IPv6, CGNAT e BNG
- Migração de concentradores para provedores Modernização e automação
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 7422, Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments: método de mapeamento determinístico.
- RFC 6888, Common Requirements for Carrier-Grade NATs (CGNs): requisitos gerais de CGNAT, inclusive de portas.
