Pesquisar conteúdos

Encontre uma trilha ou aula pelo assunto.

Experimente pesquisar por “governança”, “ITIL” ou “planejamento”.

Conteúdo da trilha

NAT, endereços privados e públicos

Entenda como traduções relacionam endereços e portas e por que NAT não equivale automaticamente a segurança.
Serviços e jornada na Internet15 de 1620 min de leitura
Dois computadores de uma rede privada enviam pacotes distintos a um roteador, que registra as associações, compartilha um caminho público e encaminha cada resposta ao computador correto

NAT relaciona espaços de endereçamento

Um computador da rede doméstica pode usar 10.0.0.25 e acessar um servidor na Internet mesmo que esse endereço não tenha significado global. Na fronteira, um tradutor troca informações do pacote e mantém uma relação que permitirá tratar a resposta.

Network Address Translation, ou NAT, é o mapeamento de endereços IP entre espaços — chamados de address realms. Quando a tradução inclui também portas TCP ou UDP, o nome técnico é Network Address Port Translation, NAPT. No uso cotidiano, “NAT” frequentemente engloba as duas formas; neste conteúdo, a diferença será indicada quando ela mudar o raciocínio.

O endereçamento IPv4 explica prefixos e blocos especiais. Aqui, a pergunta é outra: como um tradutor relaciona as identidades observadas nos dois lados e quais consequências isso traz?

Privado e público descrevem alcance, não confiança

A RFC 1918 reservou três blocos para redes privadas:

BlocoIntervalo completo
10.0.0.0/810.0.0.0 a 10.255.255.255
172.16.0.0/12172.16.0.0 a 172.31.255.255
192.168.0.0/16192.168.0.0 a 192.168.255.255

Esses endereços podem ser reutilizados por organizações diferentes porque não são globalmente únicos. Rotas para eles não devem ser anunciadas entre organizações como se identificassem um destino único na Internet.

Um endereço público ou globalmente único pode ser roteável globalmente quando existe anúncio e política compatíveis. Isso não significa que o host esteja acessível: rota, filtros, estado, serviço e aplicação ainda participam. De modo semelhante, “privado” não significa secreto, autenticado ou seguro. Um invasor presente na rede local, uma VPN, um túnel ou uma rota entre organizações pode alcançar aquele espaço.

Existe ainda 100.64.0.0/10, o Shared Address Space definido pela RFC 6598 para cenários de operadoras. Ele não é público e não pertence à RFC 1918. Confundi-lo com uma quarta faixa privada esconde a presença possível de CGNAT.

Basic NAT e NAPT mudam quantidades diferentes

No Basic NAT, um endereço de um lado é mapeado para outro endereço. Um conjunto interno pode receber endereços de um pool externo enquanto houver recursos. Portas de transporte não são o elemento que permite a multiplexação.

No NAPT, o tradutor relaciona endereço e identificador de transporte. Vários fluxos internos podem compartilhar um único endereço externo porque recebem portas externas distintas.

Considere duas conexões TCP:

DentroFora após NAPTDestino remoto
10.0.0.25:53120203.0.113.10:42001198.51.100.80:443
10.0.0.42:53120203.0.113.10:42002198.51.100.80:443

Os dois computadores escolheram a mesma porta de origem, mas o tradutor atribuiu portas externas diferentes. O protocolo também faz parte do contexto: uma associação UDP não deve ser confundida com uma conexão TCP apenas porque os números coincidem.

Uma saída cria uma relação para a resposta

Quando 10.0.0.25:53120 envia um segmento TCP ao servidor 198.51.100.80:443, o tradutor pode executar esta sequência:

  1. receber o pacote na interface interna;
  2. identificar protocolo, origem e destino;
  3. procurar uma associação existente ou reservar um endereço e uma porta externos;
  4. registrar a relação entre as tuplas;
  5. trocar a origem por 203.0.113.10:42001;
  6. atualizar os checksums afetados e encaminhar o pacote;
  7. receber a resposta destinada a 203.0.113.10:42001;
  8. localizar o estado e trocar o destino de volta para 10.0.0.25:53120.
Notebook 10.0.0.25 porta 53120 envia TCP ao servidor 198.51.100.80 porta 443; o NAPT registra a associação com 203.0.113.10 porta 42001, traduz a origem na saída e traduz o destino da resposta no retorno
O servidor remoto responde ao endpoint externo que observou. A tabela permite ao tradutor reconstruir o destino interno correto.

O desenho usa blocos reservados para documentação, evitando representar endereços reais. Ele também simplifica a chave da tabela. Implementações podem considerar endereço e porta remotos ao decidir reutilização, filtragem e estado; por isso, não deduza todo o comportamento observando somente a porta externa.

A tradução não “sabe” qual programa merece a resposta. Ela relaciona campos do pacote. Depois que o pacote volta ao host, o sistema operacional usa a tupla e o socket para entregar os dados ao processo, como explicado em TCP, UDP, portas e sockets.

Checksums precisam acompanhar a tradução

O cabeçalho IPv4 possui checksum. TCP e UDP incluem um pseudo-header que usa endereços IP, além de campos próprios. Se o tradutor altera endereço ou porta e deixa o checksum antigo, o pacote pode ser descartado como corrompido.

Por isso, NAT ajusta os checksums afetados. Mensagens ICMP de erro também podem carregar parte do pacote original; um tradutor precisa tratar essas informações de maneira coerente para que o erro seja associado ao fluxo correto.

Protocolos que gravam endereços ou portas dentro do payload criam uma dificuldade adicional. Alterar apenas o cabeçalho não corrige uma referência embutida e protegida por criptografia ou assinatura. Application Level Gateways tentaram interpretar alguns protocolos, mas acrescentam acoplamento, complexidade e riscos de incompatibilidade.

Estado tem ciclo de vida

Uma tabela de NAPT não cresce para sempre. Associações são criadas, atualizadas e removidas segundo protocolo, eventos e temporizadores.

No TCP, o tradutor pode observar sinais como SYN, FIN e RST para acompanhar aproximadamente o estado, mas não é uma das pontas da conexão. Uma sessão silenciosa pode continuar válida nas pontas enquanto o mapeamento expira no meio. No UDP não existe abertura ou fechamento de conexão no protocolo; a atividade e temporizadores são ainda mais importantes.

Isso explica falhas como:

  • uma aplicação ociosa deixa de receber depois de alguns minutos;
  • o primeiro pacote após a pausa desaparece;
  • mensagens de manutenção preservam o mapeamento;
  • reiniciar o roteador derruba sessões mesmo que os hosts não tenham mudado;
  • dois tradutores em série expiram estado em momentos diferentes.

Keepalives consomem energia e rede, e intervalos agressivos não devem ser escolhidos às cegas. A aplicação precisa equilibrar detecção, mobilidade, custo e o comportamento do caminho.

Entrada exige uma associação aplicável

Um pacote que chega de fora para 203.0.113.10:50000 só pode ser traduzido se existir uma relação que indique o destino interno e se a política permitir o tráfego. Essa relação pode surgir de:

  • uma comunicação iniciada internamente;
  • um mapeamento estático entre endereços;
  • uma regra estática de endereço e porta, conhecida como port forwarding;
  • um protocolo de criação controlada de mapeamentos;
  • uma função intermediária específica da aplicação.

No encaminhamento de porta, por exemplo, TCP 203.0.113.10:8443 pode ser associado a 10.0.0.50:443. A regra deve indicar o protocolo. “Porta 8443” sem TCP ou UDP está incompleta.

Três painéis com Basic NAT relacionando um endereço a outro, NAPT compartilhando um endereço externo por portas e port forwarding levando uma porta externa a um servidor interno; uma seta hairpin mostra um cliente interno usando o endpoint externo para chegar ao servidor interno
Basic NAT troca endereços; NAPT multiplexa fluxos; port forwarding estabelece uma entrada conhecida. Hairpinning devolve pelo tradutor um tráfego que começou no lado interno.

Hairpinning ocorre quando um cliente interno usa o endereço e a porta externos de outro endpoint que está atrás do mesmo tradutor. O pacote vai até a fronteira e é redirecionado para dentro. Sem suporte ou configuração coerente, o serviço pode funcionar de fora e falhar para clientes internos que usam o mesmo nome público.

Uma alternativa operacional é publicar respostas DNS diferentes dentro e fora da organização, mas isso transfere a responsabilidade para dados, cache e consistência DNS. Não existe uma solução universal independente da arquitetura.

Portas externas também são um recurso finito

NAPT economiza endereços ao compartilhar um IPv4 externo, mas passa a administrar portas, estado, memória e processamento. Nem todas as 65.536 portas de um protocolo estão necessariamente disponíveis para qualquer finalidade: há reservas, conexões existentes, políticas, múltiplos endereços e requisitos de implementação.

Sob muita concorrência, o tradutor pode não encontrar uma combinação externa disponível. O sintoma pode ser abertura intermitente de conexões, falha concentrada em um assinante ou limitação por destino. A quantidade de dispositivos não basta para estimar a pressão: um único cliente pode criar milhares de fluxos, enquanto muitos clientes ociosos quase não consomem mapeamentos.

Reutilizar portas rápido demais também cria ambiguidade com pacotes atrasados. Mantê-las por tempo demais reduz capacidade. Bons diagnósticos correlacionam protocolo, tuplas, timestamps e ciclo de vida em vez de concluir apenas que “o IP público responde”.

CGNAT acrescenta outra fronteira

No Carrier-Grade NAT, a operadora compartilha endereços IPv4 públicos entre assinantes. Se a residência já possui NAPT, o caminho pode ter duas traduções — cenário frequentemente chamado de NAT444:

  1. 10.0.0.25:53120 torna-se 100.64.12.34:41000 no roteador doméstico;
  2. a CGN da operadora torna-se 203.0.113.10:52000 diante da Internet;
  3. o servidor responde ao endpoint público;
  4. as duas tabelas precisam continuar válidas para a resposta alcançar o computador.
Computador com endereço 10.0.0.25 atravessa o NAT doméstico e usa 100.64.12.34, depois atravessa o CGN da operadora e compartilha 203.0.113.10 com outro assinante por blocos de portas distintos antes de alcançar a Internet
Em CGNAT, endereço público e horário isolados não identificam necessariamente um assinante. Portas, protocolo e registros correlacionados tornam-se essenciais.

Esse desenho reforça três pontos:

  • 100.64.0.0/10 serve ao espaço compartilhado da operadora e não é uma faixa RFC 1918;
  • encaminhar uma porta apenas no roteador doméstico não cria automaticamente um mapeamento no CGN;
  • atribuir uma atividade ao endereço público exige também porta, protocolo, instante e registros confiáveis das traduções.

CGNAT pode afetar jogos, comunicação ponto a ponto, hospedagem doméstica e protocolos que esperam entrada direta. Também aumenta o valor operacional dos logs de mapeamento, ao mesmo tempo que cria custos de armazenamento e questões de privacidade. A RFC 6888 recomenda evitar registrar destinos sem necessidade administrativa e discute o equilíbrio entre uso de portas, volume de logs e imprevisibilidade.

NAT altera o princípio fim a fim

Na arquitetura IP ideal, as pontas escolhem endereços e o caminho apenas encaminha. NAT introduz um intermediário que modifica identificadores e mantém estado. Aplicações podem enfrentar:

  • dificuldade para receber conexões não solicitadas;
  • necessidade de descobrir o endpoint externo;
  • mudança do endpoint ao trocar de rede ou reiniciar o tradutor;
  • protocolos que carregam endereço ou porta no payload;
  • múltiplas camadas com comportamentos diferentes;
  • incompatibilidade entre integridade criptográfica e campos alterados;
  • perda de estado em falhas ou caminhos assimétricos.

Técnicas de travessia, relays e protocolos modernos conseguem operar em muitos desses cenários, mas não tornam a tradução invisível. Cada mecanismo possui hipóteses sobre filtragem, mapeamento, tempo e conectividade.

Roteamento assimétrico merece atenção: se a saída cria estado em um equipamento e a resposta passa por outro sem estado sincronizado, o retorno pode falhar. O conteúdo sobre roteadores, gateway e tabelas de roteamento continua canônico para escolher o próximo salto; NAT é uma função adicional na fronteira.

NAT não é firewall

NAT responde como identificadores são traduzidos. Firewall responde qual comunicação é permitida. Um mesmo equipamento doméstico costuma executar NAPT e filtro stateful, o que torna os efeitos difíceis de separar na interface.

A falta de mapeamento pode impedir uma entrada inesperada, mas isso é consequência do modelo de tradução, não uma política de segurança completa. Existem mapeamentos estáticos, hairpinning, protocolos de abertura, falhas de configuração e tráfego iniciado internamente. NAT não autentica usuário, não inspeciona toda ameaça e não corrige serviços vulneráveis.

A política deve ser explícita e testável. A aula de segurança de redes, firewall, VPN e segmentação aprofunda controles de caminho. Remover a tradução não exige remover o firewall; adicionar tradução não prova que o filtro está correto.

IPv6 não precisa de NAT44 para conservar endereços

O espaço IPv6 foi projetado para permitir endereçamento global em escala sem o compartilhamento típico do NAPT IPv4. Isso recupera transparência, mas não significa liberar todo tráfego de entrada. Um firewall stateful pode bloquear comunicações não autorizadas sem reescrever endereços.

Existem mecanismos de tradução para necessidades específicas, como NAT64 entre famílias de protocolo e NPTv6 para tradução de prefixos. Eles não justificam a frase “IPv6 também precisa do mesmo NAT doméstico para ser seguro”. Endereço, tradução e controle de acesso continuam decisões diferentes.

Diagnostique comparando os dois lados

Quando uma comunicação atravessa NAT, registre evidências em ordem:

  1. identifique IP, porta e protocolo do cliente interno;
  2. confirme destino, rota e gateway usados;
  3. verifique se o pacote chega à interface interna do tradutor;
  4. localize o mapeamento e o endpoint externo alocado;
  5. capture ou consulte o lado externo para confirmar a tradução;
  6. veja se a resposta retorna ao mesmo tradutor;
  7. confirme a tradução inversa e a entrega ao host;
  8. compare regras de firewall separadamente;
  9. avalie timeout, reinício, pressão de portas e colisões;
  10. procure outra tradução no roteador superior ou na operadora;
  11. para entrada, valide regra, protocolo, endereço de escuta e mapeamento em cada fronteira;
  12. considere endereço embutido, ALG, fragmentação, ICMP e assimetria quando o básico estiver correto.

Uma captura feita somente no cliente não revela a tupla pública. Um teste externo feito somente pelo endereço público não mostra a qual host interno o estado aponta. Relógios alinhados e capturas nos dois lados transformam “o NAT está bloqueando” em uma hipótese verificável.

Erros comuns sobre NAT

  • “todo NAT traduz portas”: Basic NAT traduz endereços; NAPT inclui identificadores de transporte;
  • “PAT e porta são uma camada nova”: a porta continua pertencendo a TCP ou UDP;
  • “IP privado é seguro”: escopo de endereçamento não é controle de acesso;
  • “100.64/10 é RFC 1918”: é Shared Address Space da RFC 6598;
  • “um IP público identifica um dispositivo”: NAPT e CGNAT permitem compartilhamento;
  • “port forwarding abre TCP e UDP”: protocolo precisa ser definido;
  • “encaminhar porta ignora firewall”: tradução e permissão são avaliações distintas;
  • “NAT é firewall”: um traduz; o outro aplica política;
  • “NAT torna anônimo”: serviços ainda observam endpoint, aplicação, conta e outros sinais;
  • “a tabela guarda somente IPs”: NAPT considera portas, protocolo, estado e possivelmente endpoints remotos;
  • “UDP não precisa de estado”: o tradutor precisa manter associação temporária para o retorno;
  • “reiniciar o roteador preserva conexões”: a perda da tabela pode invalidar fluxos ativos;
  • “abrir no roteador resolve CGNAT”: outra fronteira continua sem mapeamento;
  • “IPv6 sem NAT fica desprotegido”: filtragem pode proteger sem tradução.

O que você deve guardar

NAT mapeia endereços entre espaços distintos. NAPT também relaciona portas ou outros identificadores de transporte, permitindo que muitos fluxos compartilhem um endereço externo. O retorno funciona porque o tradutor mantém uma associação e reescreve o destino de volta.

Endereços privados RFC 1918 não são globalmente únicos. 100.64.0.0/10 é espaço compartilhado para operadoras e aparece em cenários de CGNAT. Nenhuma dessas classificações define confiança ou segurança.

Entrada requer um estado ou mapeamento aplicável, como port forwarding, além da política de firewall. Timeouts, escassez de portas, dupla tradução, assimetria e endereços embutidos podem quebrar aplicações. No IPv6, filtros continuam importantes, mas o compartilhamento de IPv4 por NAPT não é requisito de proteção.

Referências