NAT e publicação de serviços: acesso externo a servidores com segurança

O que é NAT e por que ele existe

NAT (Network Address Translation) é a tradução de endereços IP (e, na prática, muitas vezes também de portas) feita por um roteador/firewall entre duas redes. O caso mais comum é uma rede privada (LAN) acessando a Internet usando um único IP público. O NAT altera campos do cabeçalho IP e, quando necessário, do cabeçalho TCP/UDP, para que o tráfego “faça sentido” nos dois lados.

Em administração de servidores, NAT aparece em três lugares típicos:

• Roteadores domésticos: sua LAN usa IPs privados e sai para a Internet por um IP público do provedor.
• Firewalls corporativos: políticas de saída (SNAT) e publicação controlada de serviços (DNAT/port forwarding), geralmente com logs e regras por origem.
• Nuvem: instâncias em sub-redes privadas saem via NAT Gateway; publicação de serviços costuma envolver IP público, Load Balancer ou regras de DNAT em appliances virtuais.

Tipos principais: SNAT e DNAT (port forwarding)

SNAT (Source NAT): saída da LAN para a Internet

No SNAT, o dispositivo de borda troca o endereço de origem (e frequentemente a porta de origem) do tráfego que sai da rede interna. Isso permite que vários hosts internos compartilhem um único IP público.

Exemplo conceitual (saída para web):

• Antes do NAT: 192.168.1.10:51544 -> 93.184.216.34:443
• Depois do NAT: 203.0.113.50:40001 -> 93.184.216.34:443

O roteador mantém uma tabela de estados/associações para saber que respostas para 203.0.113.50:40001 devem voltar para 192.168.1.10:51544.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

DNAT (Destination NAT): entrada da Internet para um servidor interno

No DNAT, o dispositivo de borda troca o endereço de destino (e/ou a porta de destino) para encaminhar conexões que chegam ao IP público para um host interno. O nome mais comum em roteadores domésticos é port forwarding (encaminhamento de porta).

Exemplo conceitual (publicar web interna):

• Chega da Internet: 198.51.100.77:53210 -> 203.0.113.50:80
• Após DNAT: 198.51.100.77:53210 -> 192.168.1.20:80

Para a sessão funcionar, o firewall/roteador também precisa garantir o caminho de volta (normalmente via estado de conexão e/ou SNAT de retorno, dependendo do desenho).

Onde o NAT “mora” em ambientes reais

Roteador doméstico

• SNAT quase sempre habilitado (às vezes chamado de “NAT” apenas).
• DNAT/Port Forward configurável por porta (ex.: TCP 80 para um IP interno).
• Frequentemente há UPnP (mapeamento automático por apps). Em servidores, prefira mapeamentos manuais e regras explícitas.

Firewall corporativo

• Regras de NAT costumam ser separadas de regras de segurança (policy), mas ambas precisam permitir o tráfego.
• Logs detalhados: NAT aplicado, IP/porta original, IP/porta traduzidos, interface de entrada/saída.
• Possibilidade de publicar serviços com restrição por origem, geo, rate limit, inspeção e WAF (para HTTP).

Nuvem

• Saída: instâncias privadas usam NAT Gateway/Instance (SNAT) para acessar Internet sem receber conexões de entrada.
• Entrada: pode ser IP público direto na VM, Load Balancer, ou DNAT em firewall virtual. Em muitos provedores, “Security Groups”/ACLs fazem o papel de permitir/negá-lo além do NAT.

Publicando um servidor web (HTTP/HTTPS) com port forwarding

Checklist antes de mexer no NAT

• O serviço está escutando na porta correta no servidor (ex.: 80/443) e no IP esperado (0.0.0.0 ou IP da LAN)?
• O servidor tem IP fixo na LAN (estático ou reserva no DHCP) para o forward não “quebrar”.
• O firewall do servidor permite a porta (ex.: regra de entrada para 80/443).

Passo a passo (genérico) para publicar HTTP

1. Defina o alvo interno: por exemplo, servidor web em 192.168.1.20.

2. Crie a regra de DNAT/Port Forward no roteador/firewall:

   • WAN TCP 80 -> LAN 192.168.1.20:80
   • (Opcional) WAN TCP 443 -> LAN 192.168.1.20:443

3. Garanta a regra de permissão (policy): permitir entrada na WAN para TCP 80/443 com destino ao servidor interno.

4. Teste de fora (ver seção de testes): valide que a porta está aberta e que o conteúdo responde.

Implicações de logs e “origem real” do cliente

Quando você publica um serviço via DNAT, o servidor normalmente ainda vê o IP real do cliente como origem (ex.: 198.51.100.77), porque o NAT alterou o destino, não a origem. Porém, há cenários em que a origem pode se perder:

• Proxy reverso/Load Balancer: o servidor pode ver o IP do proxy como origem. Para preservar a origem real, usa-se cabeçalhos como X-Forwarded-For (HTTP) e configurações específicas no servidor web.
• SNAT aplicado na entrada (alguns firewalls fazem “NAT reflection”/políticas específicas): o servidor pode ver como origem o IP do firewall. Isso afeta logs e controles por IP.

Boas práticas:

• Habilite logs no firewall/roteador para a regra de publicação (tentativas, bloqueios, portas).
• No servidor web, registre IP de origem e User-Agent; em HTTPS, considere logs de SNI/host (quando aplicável) e métricas de taxa.
• Se houver proxy, configure o web server para confiar apenas no proxy e extrair o IP real de cabeçalhos confiáveis.

Publicando SSH com segurança (evitando exposição desnecessária)

Publicar SSH diretamente na Internet aumenta superfície de ataque (varreduras e tentativas de brute force). Se for inevitável, reduza o risco:

• Restrinja por IP de origem (allowlist) no firewall de borda.
• Use autenticação por chave, desabilite senha, e aplique rate limit/fail2ban no servidor.
• Considere mudar a porta externa (ex.: 2222 -> 22). Isso não é segurança por si só, mas reduz ruído de scans automáticos.

Passo a passo (genérico) para publicar SSH

1. Defina o alvo interno: servidor em 192.168.1.30 com SSH na porta 22.

2. Crie o DNAT/Port Forward:

   • WAN TCP 2222 -> LAN 192.168.1.30:22

3. Crie a regra de permissão na WAN:

   • Permitir TCP 2222 apenas de IPs confiáveis (ex.: seu escritório/VPN).

4. Valide no servidor:

   • Firewall local permitindo 22 apenas da LAN (ou do IP do gateway, dependendo do desenho).
   • Logs do SSH (tentativas, falhas) e proteção contra brute force.

Limites e armadilhas: CGNAT e IP público

Como saber se você consegue publicar portas

Para receber conexões da Internet, você precisa de um IP público roteável na sua WAN. Se o provedor usa CGNAT (Carrier-Grade NAT), seu roteador recebe um IP “privado do provedor” e você não consegue fazer port forwarding funcional para a Internet, porque o NAT está “acima” de você.

Indícios comuns de CGNAT:

• O IP na interface WAN do roteador é de faixas privadas (ex.: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) ou da faixa 100.64.0.0/10 (muito usada em CGNAT).
• O “meu IP” visto em sites difere do IP WAN do roteador.

Alternativas quando há CGNAT:

• Solicitar IP público ao provedor (fixo ou dinâmico, mas público).
• Usar IPv6 (quando disponível) com firewall bem configurado, evitando NAT para entrada.
• Usar um servidor intermediário com IP público (túnel/VPN/reverse proxy) para expor o serviço.

Cenários de troubleshooting (serviço funciona na LAN, mas não fora)

1) Funciona na LAN, mas não acessa de fora: porta não chega

Sintoma: de dentro da rede, http://192.168.1.20 funciona, mas de fora http://IP_PUBLICO não abre.

Verificações em ordem prática:

1. Confirme IP público e ausência de CGNAT:

   • Compare IP WAN do roteador com o IP visto externamente.

2. Confirme o port forward:

   • Regra aponta para o IP interno correto?
   • Protocolo correto (TCP vs UDP)?
   • Porta externa e interna corretas?

3. Confirme a policy/ACL:

   • Alguns equipamentos exigem regra de firewall separada além do NAT.

4. Confirme firewall local do servidor:

   • Bloqueio local pode fazer parecer que o NAT não funciona.

5. Confirme se não há “duplo NAT”:

   • Ex.: modem do provedor em modo roteador + seu roteador atrás. Nesse caso, você precisa encaminhar portas no primeiro equipamento ou colocar em modo bridge.

2) Portas “abrem” mas o serviço não responde como esperado

Causas comuns:

• Serviço escutando apenas em localhost (ex.: 127.0.0.1), então o NAT entrega ao host, mas o serviço não aceita conexões externas.
• Virtual host/host header no web server: você acessa por IP e o servidor responde com site padrão/errado.
• HTTPS: certificado e SNI/host incorretos podem dar erro no navegador, parecendo indisponibilidade.

3) Hairpin NAT (NAT loopback): acesso ao IP público a partir da própria LAN

Sintoma: de fora funciona, mas de dentro da LAN, ao acessar o IP público (ou um DNS que aponta para ele), não funciona.

Isso acontece quando o roteador não suporta ou não está configurado para hairpin NAT (o tráfego sai da LAN para o IP público e precisa “voltar” para a LAN via DNAT, mantendo coerência de rotas e estados).

Soluções típicas:

• Habilitar “NAT loopback/hairpin” no roteador (se existir).
• Usar split DNS: dentro da LAN, o nome resolve para o IP interno; fora, resolve para o IP público.
• Adicionar regra específica de NAT/roteamento no firewall corporativo para refletir o acesso interno.

4) Teste de dentro engana: você está testando “por dentro” algo que só falha “por fora”

Testar apenas na LAN valida o serviço, mas não valida:

• IP público/CGNAT
• Regras de entrada na WAN
• Bloqueio do provedor (alguns bloqueiam portas comuns)
• Duplo NAT

Como testar corretamente (lado de dentro e lado de fora)

Testes do lado de dentro (LAN)

• Verificar se o serviço está escutando no servidor:

  ss -lntp | grep -E ':80|:443|:22'

• Testar conectividade local a partir de outra máquina na LAN:

  curl -I http://192.168.1.20

  nc -vz 192.168.1.30 22

• Testar acesso via IP público a partir da LAN (para detectar hairpin NAT):

  curl -I http://SEU_IP_PUBLICO

  Se falhar aqui mas funcionar de fora, suspeite de hairpin NAT/split DNS.

Testes do lado de fora (Internet)

O ideal é testar de uma rede realmente externa (4G/5G do celular, outra conexão, ou uma VM externa).

• Checar se a porta está alcançável:

  nc -vz SEU_IP_PUBLICO 80

  nc -vz SEU_IP_PUBLICO 2222

• Testar HTTP:

  curl -I http://SEU_IP_PUBLICO

• Testar SSH (se publicado em 2222):

  ssh -p 2222 usuario@SEU_IP_PUBLICO

Interpretando resultados rapidamente

Boas práticas ao publicar serviços

• Publique o mínimo: exponha apenas portas necessárias.
• Restrinja origem sempre que possível (especialmente SSH e painéis administrativos).
• Monitore logs do firewall e do servidor para tentativas e padrões anormais.
• Separe portas externas e internas quando fizer sentido (ex.: 2222->22), documentando claramente.
• Planeje DNS para evitar problemas de hairpin (split DNS em ambientes corporativos).