CGNAT e blocos de portas#

O que é Bulk Port Allocation (BPA)#

No CGNAT tradicional (por conexão), cada conexão recebe uma porta pública avulsa e gera uma linha de log. Num provedor, isso significa milhões de registros por dia, difíceis de guardar e de consultar.

Na alocação por blocos de portas (BPA) o assinante recebe de uma vez um bloco de portas de um IP público, e suas conexões usam as portas desse bloco. O log registra só "assinante X usou o IP Y, portas A a B, de tal data a tal data". Aqui está a vantagem central do Portgrid: o assinante pode receber blocos adicionais sob demanda quando a conectividade dele exige mais portas, e devolvê-los quando deixa de precisar.

BPA x CGNAT determinístico#

	CGNAT determinístico	BPA (Portgrid)
Portas por assinante	Bloco fixo, calculado de antemão a partir do IP privado	Bloco inicial, com blocos extras sob demanda
Cliente que precisa de mais portas	Não tem como escalar: esgotou o bloco, novas conexões falham	Recebe outro bloco automaticamente, até o limite configurado
Dimensionamento	Bloco precisa ser grande para o pior cliente, desperdiçando portas dos demais	Blocos pequenos; só quem precisa ocupa mais
Aproveitamento do IP público	Menor (portas reservadas, usadas ou não)	Maior (portas seguem o uso real)
Log	Nenhum (a regra é matemática)	Um registro por bloco alocado/liberado
Rastreabilidade	Por cálculo	Por consulta ao registro (`lookup`)

Em resumo

O determinístico troca flexibilidade por ausência de log. O BPA mantém o log pequeno e acompanha a necessidade de cada cliente.

Vantagens do BPA#

Vantagem	Explicação
Escala com a necessidade do cliente	Quem usa muitas conexões (jogos, streaming, várias pessoas em casa) recebe blocos extras; o cliente leve fica com um só
Auditoria compacta	Um registro por bloco, não por conexão. A retenção de 1 ano do Marco Civil cabe em poucos GB
Consulta judicial simples	Com IP público, porta e horário, a resposta é um único assinante (`lookup`)
Menos IPs públicos	Blocos pequenos, alocados sob demanda e recuperados quando ociosos: mais assinantes por IP
Desempenho	A porta é escolhida dentro de blocos já reservados, no dataplane e em velocidade de linha, sem consultar o plano de controle a cada conexão
Isolamento de abuso	O consumo de portas de um cliente é limitado ao máximo de blocos dele (`max_blocks_per_subscriber`); um cliente infectado não esgota o IP dos vizinhos
Menos suporte	Com UPnP, PCP, NAT-PMP e UDP EIM/full cone, jogos e chamadas funcionam bem

Como funciona#

Pool e blocos. As portas de cada IP público são divididas em blocos de tamanho fixo. Exemplo ilustrativo: blocos de 2.016 portas permitem cerca de 32 blocos por IP.
Primeiro bloco. Quando um assinante sem bloco inicia tráfego, o cgnatd reserva um bloco livre para ele e grava o registro de auditoria. Daí em diante o dataplane trabalha sozinho.
Tradução. Cada nova conexão recebe uma porta livre dentro dos blocos do assinante, escolhida de forma embaralhada. A resposta volta pelo registro da conexão.
Escala sob demanda. Se os blocos do assinante enchem, o cgnatd aloca um bloco adicional, sempre no mesmo IP público do assinante, e registra o novo bloco. Isso se repete até o limite max_blocks_per_subscriber (1 a 16). No limite, ou se o IP público dele não tem mais blocos livres, só as novas conexões dele são recusadas (show cgnat capacity mostra os IPs cheios).
Recuperação. Blocos sem conexões em uso são devolvidos ao pool, com registro de data e hora.
Rastreabilidade. Dado IP público, porta e horário, o lookup retorna o assinante e o bloco correspondente.

Assinante A (uso leve)    → bloco 1                          (203.0.113.10  portas 1024–3039)
Assinante B (uso médio)   → bloco 2 + bloco 3                (203.0.113.10  portas 3040–5055 + 5056–7071)
Assinante C (uso pesado)  → blocos 4, 5, 6, ... até o limite (alocados conforme a demanda)

Dimensionamento

O tamanho do bloco e o max_blocks_per_subscriber equilibram aproveitamento do IP e folga para o cliente. Prefira blocos menores com bom limite de blocos, acompanhe port_exhausted e a ocupação dos pools, e ajuste. Veja Configurações recomendadas.

Elementos#

Termo	Descrição
Pool	Prefixo(s) público(s). Cada host vira `/32` na loopback do servidor
Política	Liga rede CGNAT (ex.: `100.64.0.0/10`), interfaces de entrada/saída, pool, tamanho do bloco, proteções
Bloco	Faixa de portas de um IP público dedicada a um assinante; o assinante pode ter vários blocos, todos no mesmo IP
max_blocks_per_subscriber	1 a 16; sobrepõe o limite do pool; reduzir não retira blocos já alocados
Alocação sob demanda	O primeiro pacote faz o `cgnatd` reservar o bloco inicial; se a demanda cresce, ele aloca blocos adicionais até o limite
Reserva manual	`POST /subscribers/{ip}/blocks` ou pela CLI/painel

Recuperação de portas#

Blocos vazios são recuperados pelo cgnatd conforme a política.

Portas reservadas para UPnP/PCP#

As últimas CGNAT_PORTMAP_RESERVED portas do primeiro bloco do assinante ficam reservadas para mapeamentos dinâmicos (UPnP IGD, PCP, NAT-PMP). Assim o recurso não consome um bloco extra. A faixa antiga CGNAT_UPNP_PORTS continua aceita por compatibilidade. Veja variáveis de ambiente.

UDP EIM e full cone#

udp_eim: mesmo IP:porta interno → mesmo IP:porta público para todos os destinos; remoto já contatado responde de qualquer porta. Melhor para jogos, chamadas e P2P; custa uma porta por endpoint interno.
udp_full_cone (exige EIM): qualquer remoto alcança o endpoint enquanto o mapeamento existir ("NAT aberto" para consoles). Menos seguro.
TCP sempre por destino.

Timeouts#

Estado	Tempo
TCP parcialmente aberto	240 s
TCP estabelecido	7440 s
TCP em encerramento	120 s
UDP sem resposta	240 s
UDP respondido	1800 s
DNS	30 s

Ajustáveis em show cgnat timeouts / tela de políticas.

NAT estático e port-forward#

static-nat mapeia 1:1 um IP interno a um público; port-forward abre portas específicas. Ambos via API/CLI/painel.