Resumo

  • A REQ-7 da RFC 5382 determina que um NAT não use port overloading para TCP, isto é, não entregue simultaneamente o mesmo mapeamento de endereço e porta a endpoints internos diferentes.
  • A otimização depende do destino remoto como chave escondida; quando os assinantes convergem para o mesmo endpoint externo, os quatro campos públicos ficam iguais e a identidade deixa de ser reversível.

O KPI que não mostra quem pagou

Uma operação de CGN acompanha ocupação do pool, portas disponíveis, sessões por endereço e taxa de criação. Esses indicadores têm valor direto: mostram quando comprar endereços, ampliar nós ou acelerar a migração para IPv6. Mas um KPI de densidade pode melhorar por duas razões muito diferentes. A plataforma pode administrar melhor recursos preservando as garantias, ou pode retirar uma distinção que só fará falta em um caso menos frequente.

Port overloading pertence à segunda categoria. Dois pares internos recebem o mesmo endereço e porta públicos. Enquanto um fala com o destino X e outro com Y, o equipamento usa o peer remoto para distinguir as entradas. A tabela parece compacta. Quando os dois acessam o mesmo serviço, porém, origem pública e destino ficam idênticos. O mundo externo já não tem como representar as duas conexões ao mesmo tempo.

A RFC 5382 descreve esse defeito na seção 7.1. Dois endpoints internos que compartilham o mapeamento não conseguem estabelecer conexões simultâneas com um endpoint externo comum. Por isso a REQ-7 usa MUST NOT. Não é uma recomendação de desempenho; é uma condição para que o identificador de transporte continue significando uma conexão distinta.

O assinante paga quando a métrica não incorpora essa condição. Ele vê falhas intermitentes em serviços populares, enquanto o operador vê alta admissão e boa utilização. O suporte recebe um problema que depende de concorrência e é difícil de reproduzir. A economia ficou no painel do tradutor; o custo apareceu fora dele.

Compartilhar endereço não é compartilhar identidade completa

A escassez de IPv4 exige compartilhamento. Um único endereço pode servir muitos assinantes porque as portas distinguem mapeamentos. O argumento do CGN não está em disputa. A fronteira é o quanto pode ser compartilhado no mesmo instante.

A RFC também exige endpoint-independent mapping. Um par interno pode conservar seu mapeamento externo ao conversar com destinos diferentes. Isso dá continuidade a um único titular. Port overloading entrega o mesmo mapeamento a titulares internos diferentes. A primeira reutilização preserva identidade; a segunda cria coautoria sobre o mesmo nome público.

Para esconder essa coautoria, o destino remoto vira parte obrigatória da chave interna. O resultado contradiz a intuição da independência: o mapeamento parece estável, mas a identidade de quem o usa depende justamente do destino. Se os peers convergem, a chave deixa de separar.

Filtragem continua sendo outra superfície. Uma regra define de quais fontes externas o retorno será aceito. Ela não cria um único destinatário interno quando o mapeamento tem dois titulares. Uma análise BTW anterior já separa mapeamento e filtro no NAT64. Aqui, a pergunta vem antes da política de acesso: existe um receptor único para o pacote que a política decidiu permitir?

Não confundir com simultaneous open

Outra parte conhecida da RFC 5382 trata de TCP simultaneous open. Dois peers enviam SYN ao mesmo tempo, os pacotes se cruzam e o estado TCP correto permite que uma conexão surja. NATs simplificados podiam rejeitar esse caminho válido. Esse mecanismo e sua janela de incerteza já têm cobertura BTW própria.

No port overloading, dois clientes internos apontam para um terceiro endpoint comum. A falha não é a troca de papéis entre chamador e ouvinte. É a decisão anterior do tradutor de projetar duas origens internas sobre uma origem pública. Aumentar a tolerância para SYN não inventa a segunda porta pública necessária.

O diagnóstico precisa refletir a diferença. Para simultaneous open, guardam-se transições TCP e ordem de pacotes. Para sobrecarga, guardam-se decisões de alocação: origem interna, mapeamento externo, destino remoto, protocolo, horário, versão da política e nó que possui o estado. Sem isso, o operador enxerga apenas uma conexão que falhou “às vezes”.

Recusar é melhor do que admitir sem identidade

Quando o pool ou as portas acabam, a plataforma precisa decidir. Ela pode rejeitar uma nova tentativa, preservar as sessões existentes e registrar a causa. Pode também sobrecarregar um mapeamento e elevar o contador de admissões. A segunda opção parece mais amigável no instante inicial, mas promete algo que não consegue sustentar quando o tráfego converge.

Uma recusa explícita é um recibo de capacidade. Ela permite relacionar demanda, pool, horário e cliente afetado. O planejamento pode responder com mais endereços, distribuição de portas, ajuste de retenção ou mudança de arquitetura. A admissão ambígua apaga esse sinal e transforma falta de recurso em erro de identidade.

Também é preciso evitar outra falsa solução: reduzir temporizadores indiscriminadamente. Conexões TCP estabelecidas podem ficar ociosas e ainda estar vivas. A RFC define mínimos quando o NAT não consegue verificar atividade. Um artigo BTW separado trata da ambiguidade do silêncio e do keepalive. Para REQ-7, basta reconhecer que um mapeamento ainda válido não é porta livre para empréstimo simultâneo.

Eficiência responsável mede quantas identidades válidas o sistema sustenta, não quantas linhas consegue comprimir na memória.

Hairpinning expõe o contrato com a aplicação

A REQ-8 exige hairpinning para TCP e determina que o pacote devolvido internamente apresente endereço e porta externos como origem. Duas aplicações atrás do mesmo NAT, conhecendo-se apenas pelos mapeamentos públicos, devem conseguir conversar e reconhecer o peer esperado.

Essa regra mostra que o par externo não serve apenas ao roteamento. Ele participa da associação feita pela aplicação. Mesmo numa volta interna, trocar a origem por um endereço privado inesperado pode confundir quem recebeu. A identidade externa precisa sobreviver ao caminho.

Port overloading enfraquece o mesmo contrato. Um par que só designa um titular quando acrescido de um destino secreto é menos estável do que aparenta. Pode funcionar numa tabela local e falhar depois de uma troca de nó se o estado completo não acompanhar. O operador não precisa prometer eternidade ao mapeamento, mas precisa preservar seu significado enquanto o publica.

Erro e transformação têm autoridade limitada

As exigências de ICMP reforçam a separação de poderes. O NAT deve traduzir mensagens Destination Unreachable relevantes, mas nenhuma mensagem ICMP pode, por si só, encerrar o mapeamento ou a conexão TCP. O erro informa sobre um evento; não recebe autoridade automática para apagar estado.

Os ALGs também têm limite. A RFC recomenda mantê-los desabilitados por padrão, exceto FTP. Se um tradutor alterar números de sequência, deve tratar SACK corretamente. Cada mutação escondida cria uma obrigação de contabilidade ao longo da conversa.

Com port overloading, a ambiguidade surge antes: a qual assinante e a qual espaço de sequência pertence este pacote? Acrescentar transformações sobre uma identidade compartilhada aumenta a dependência de estado privado e torna o recibo mais frágil.

O princípio é o mesmo em todos os casos. Um sinal de ICMP, um timer, um ALG ou um algoritmo de portas pode agir dentro de seu contrato. Nenhum deles deve herdar a autoridade de redefinir o titular da sessão sem evidência compatível.

A prova operacional

O teste mínimo usa duas origens internas diferentes e um listener externo comum. A primeira conexão permanece ativa. A segunda aponta para o mesmo endereço e porta. Os mapeamentos públicos precisam ser distintos; na falta de recurso, a segunda tentativa deve produzir falha explícita. O equipamento não pode admitir as duas sob a mesma identidade.

Repita sob pressão de pool, depois de atualização de software e durante failover. Registre tuple interno, tuple externo, peer remoto, protocolo, criação, refresh, remoção, versão do alocador, nó e época de estado. Correlacione com SYN, SYN-ACK e ACK. Em seguida, execute uma transação de aplicação, porque handshake não prova entrega útil.

Para atribuição, endereço e porta públicos precisam de janela temporal e relógios confiáveis. Se o destino remoto for necessário para encontrar o assinante, essa limitação deve acompanhar a resposta a abuso. A proibição da REQ-7 reduz a chance de duas reivindicações TCP simultâneas exigirem essa qualificação escondida.

Preserve também os resultados negativos. Um teste que recusa corretamente a segunda alocação revela o limite real. Esconder a recusa para proteger a taxa de sucesso remove o dado que justificaria investimento.

Fontes