O que muda entre casa, empresa e nuvem (e o que permanece igual)
Os três cenários (doméstico, corporativo e nuvem) diferem principalmente em: (1) onde ocorre a borda de rede (o “perímetro”), (2) como o tráfego é segmentado e filtrado, e (3) quantas camadas de controle existem entre o cliente e o servidor. O que permanece igual é a lógica do caminho do pacote: um cliente tenta alcançar um IP:porta, o tráfego atravessa dispositivos de camada 3/4 (roteadores, NAT, firewalls) e precisa ser permitido em cada ponto. Quando algo falha, quase sempre está em um destes grupos: resolução de nome, caminho/rota, tradução (NAT), filtragem (firewall/regras) ou serviço local (aplicação não escutando/porta errada).
A seguir, três estudos de caso progressivos. Em cada um: topologia, caminho do pacote, pontos prováveis de falha e um roteiro prático de diagnóstico e correção.
Estudo de caso 1: servidor em casa atrás de roteador com NAT
Topologia típica
- Internet ⇄ (IP público) Roteador doméstico (NAT + firewall básico) ⇄ Rede LAN (ex.: 192.168.1.0/24) ⇄ Servidor (ex.: 192.168.1.10)
- Objetivo: publicar um serviço (ex.: HTTPS 443) para acesso externo.
Caminho do pacote (acesso externo ao serviço)
- Cliente na Internet resolve o nome do serviço e obtém o IP público do roteador.
- Cliente envia pacote TCP para
IP_publico:443. - Roteador recebe na interface WAN e aplica regras: (a) se houver redirecionamento de porta (port forwarding), ele cria uma tradução NAT e encaminha para
192.168.1.10:443; (b) se não houver, descarta. - Servidor recebe o pacote na LAN e responde.
- Roteador traduz o retorno (NAT de saída) e entrega ao cliente.
Pontos de falha prováveis
- DNS: nome aponta para IP público errado (mudança de IP), ou aponta para um IP antigo.
- NAT/Port forwarding: regra inexistente, porta errada, IP interno do servidor mudou, redirecionamento para host errado.
- Firewall do roteador: bloqueio na WAN mesmo com port forwarding (alguns roteadores exigem “permitir” explicitamente).
- Firewall do servidor: porta não liberada localmente.
- Serviço: aplicação não está escutando na porta/interface correta (escuta só em localhost, por exemplo).
- CGNAT: a “WAN” do roteador não é realmente um IP público roteável; port forwarding não funciona para entrada.
- Hairpin NAT: acesso ao IP público a partir da própria LAN falha (teste interno enganoso).
Diagnóstico e correção (passo a passo)
1) Confirme se o problema é “de fora para dentro”
Teste a partir de uma rede externa (4G/5G, outra conexão) para evitar confusão com hairpin NAT. Se você só consegue testar de dentro, use o IP privado diretamente para validar o serviço local.
2) Valide o serviço no servidor (local)
- No servidor, verifique se a aplicação está escutando na porta esperada e em todas as interfaces (ou na interface LAN):
ss -lntup | grep ':443' - Teste localmente no servidor:
curl -vk https://127.0.0.1/ - Teste a partir de outro host na LAN:
curl -vk https://192.168.1.10/
Se falhar aqui, o problema é serviço ou firewall local. Corrija antes de mexer no roteador.
3) Verifique IP do servidor e estabilidade do endereço
- Confirme o IP do servidor:
ip addr show - Evite que o IP mude: configure reserva no DHCP do roteador ou IP estático no servidor (com gateway correto).
4) Verifique o IP “público” do roteador e detecte CGNAT
- No roteador, veja o IP da interface WAN.
- Se o IP WAN estiver em faixas privadas (ex.: 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, 192.168.0.0/16), você provavelmente está atrás de CGNAT e não receberá conexões de entrada diretamente.
Correção típica para CGNAT: solicitar IP público ao provedor, usar um túnel/VPN reversa, ou hospedar o serviço em outro local com IP público.
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
5) Configure e valide o port forwarding
- Crie regra: WAN TCP 443 →
192.168.1.10TCP 443. - Se o serviço for HTTP, faça para 80; se for SSH, 22 (idealmente com porta externa diferente e controles adicionais).
- Garanta que não há conflito com serviços do próprio roteador (admin remoto na mesma porta).
6) Teste a abertura da porta a partir de fora
- De uma rede externa:
nc -vz IP_publico 443 - Ou:
curl -vk https://IP_publico/
Se nc não conecta, o bloqueio está no caminho (NAT/firewall/CGNAT). Se conecta mas curl falha, pode ser aplicação/TLS/host header.
7) Use captura de pacotes para localizar onde para
- No servidor, capture na interface LAN enquanto testa de fora:
sudo tcpdump -ni any port 443
Interpretação rápida: se não chega nada no servidor, o problema está antes (roteador/CGNAT). Se chega SYN e não há SYN-ACK, é firewall local ou serviço não escutando.
Estudo de caso 2: servidor em empresa com VLANs e firewall
Topologia típica
- Internet ⇄ Firewall/UTM (perímetro) ⇄ Core/L3 (roteamento entre VLANs) ⇄ Switches ⇄ Servidores
- VLANs comuns: Usuários, Servidores, Gerência, DMZ, Visitantes.
- Objetivo: (a) acesso interno controlado a um servidor; (b) publicação externa via DMZ/regras no firewall.
Caminho do pacote (usuário interno acessando servidor em VLAN de servidores)
- PC do usuário (VLAN Usuários) envia tráfego para o IP do servidor (VLAN Servidores).
- O gateway do PC (SVI/roteador L3) roteia entre VLANs conforme ACLs/políticas internas.
- O tráfego chega ao servidor; a resposta volta pelo gateway do servidor.
Caminho do pacote (cliente externo acessando serviço publicado)
- Cliente na Internet resolve o nome e obtém o IP público do firewall.
- Firewall aplica regra de entrada (DNAT/port forward para DMZ ou VIP) e política de segurança.
- Tráfego segue para a VLAN/segmento correto (DMZ ou Servidores) conforme desenho.
- Servidor responde; o firewall aplica SNAT/estado e devolve ao cliente.
Pontos de falha prováveis
- DNS: nome interno resolve para IP errado (split DNS), ou nome externo aponta para endereço incorreto.
- Rota assimétrica: ida passa pelo firewall, volta sai por outro gateway (quebra de estado).
- Inter-VLAN: ACL no core bloqueando tráfego entre VLANs (ex.: Usuários → Servidores).
- Firewall perímetro: regra de entrada/saída faltando, ordem de regras, política “deny” implícita.
- DMZ: servidor está na VLAN errada ou sem rota de retorno para o firewall.
- NAT no firewall: DNAT aponta para IP/porta errados; falta de SNAT quando necessário.
- Firewall local do servidor: porta fechada ou restrita a sub-rede diferente.
Diagnóstico e correção (passo a passo)
1) Separe o problema em “interno” e “externo”
Teste primeiro o acesso interno (PC na rede corporativa → servidor). Depois teste a publicação externa. Isso reduz variáveis (NAT e políticas de borda).
2) Valide conectividade L3 entre VLANs
- De um host na VLAN Usuários, teste até o gateway e até o servidor (ICMP pode ser bloqueado; use TCP quando possível):
traceroute -n IP_DO_SERVIDOR - Teste a porta do serviço:
nc -vz IP_DO_SERVIDOR 443
Se o traceroute para no gateway ou no core, suspeite de ACL inter-VLAN ou rota ausente.
3) Confirme gateways e rotas padrão do servidor
- No servidor:
ip route
Erros comuns: gateway apontando para a VLAN errada, múltiplos gateways, rota default inexistente. Correção: ajustar rota padrão e rotas específicas conforme o desenho (um único default, rotas adicionais quando necessário).
4) Verifique políticas inter-VLAN (ACLs no core/L3)
Se usuários não conseguem acessar servidores, confirme se há regra permitindo VLAN_Usuarios → VLAN_Servidores na porta/protocolo necessários. Em ambientes corporativos, o padrão é “bloqueia tudo e libera o mínimo”. Ajuste liberando apenas as portas do serviço e, se aplicável, apenas as sub-redes de origem.
5) Para publicação externa: valide DNAT e política no firewall
- Confirme o mapeamento: IP público/porta → IP privado/porta corretos.
- Confirme a regra de entrada permitindo a origem desejada para o destino traduzido.
- Confirme se há regra de saída/retorno (dependendo do modelo do firewall) e se o tráfego está “stateful”.
Correção típica: ajustar ordem de regras (uma regra mais genérica pode estar bloqueando antes), corrigir objeto de rede/serviço, ou habilitar logging na regra para ver o motivo do bloqueio.
6) Detecte rota assimétrica (quebra de estado)
Sintoma: o SYN chega ao servidor, o servidor responde, mas o cliente não recebe. Em firewalls stateful, se a volta não passa pelo mesmo firewall, a sessão quebra.
- No servidor, capture:
sudo tcpdump -ni any host IP_DO_CLIENTE and port 443 - Se você vê SYN chegando e SYN-ACK saindo, mas o cliente não completa, investigue o caminho de retorno (gateway do servidor, rotas no core, múltiplos links de Internet).
Correção: garantir que o default gateway do servidor aponte para o caminho correto, ou ajustar rotas para que ida e volta passem pelo mesmo dispositivo de estado/NAT.
7) Use logs do firewall e do servidor
- No firewall: habilite log na regra de deny relacionada e filtre por IP/porta do teste.
- No servidor: verifique logs do serviço e do firewall local para drops.
Estudo de caso 3: servidor em nuvem com sub-rede pública/privada e regras de segurança
Topologia conceitual típica
- Rede virtual (VPC/VNet conceitual) com sub-redes:
- Sub-rede pública: tem rota para a Internet via um gateway de Internet; recursos podem ter IP público.
- Sub-rede privada: sem rota direta de entrada da Internet; saída pode existir via NAT de egress.
- Controles comuns:
- Security group (equivalente): firewall virtual por instância/interface (stateful).
- NACL/ACL de sub-rede (equivalente): filtro por sub-rede (frequentemente stateless).
- Rotas: tabelas de rotas associadas a sub-redes.
- Objetivo: publicar um serviço em instância privada via componente público (ex.: balanceador/reverso) ou expor diretamente uma instância pública; e permitir que instância privada acesse atualizações na Internet (egress).
Caminho do pacote (instância em sub-rede pública exposta diretamente)
- Cliente na Internet resolve o nome e obtém o IP público associado ao recurso.
- Tráfego entra pelo gateway de Internet e é roteado para a sub-rede pública.
- Security group permite a porta (ex.: 443) a partir das origens autorizadas.
- Instância recebe e responde; como o security group é stateful, o retorno é permitido para a sessão estabelecida.
Caminho do pacote (instância em sub-rede privada publicada via componente na sub-rede pública)
- Cliente na Internet chega ao componente público (ex.: proxy/balanceador) na sub-rede pública.
- Security group do componente público permite entrada 443.
- O componente público encaminha para a instância privada (ex.: 10.x.y.z:443) pela rede interna.
- Security group da instância privada permite entrada apenas a partir do componente público (origem restrita).
- Resposta retorna ao componente público e depois ao cliente.
Caminho do pacote (egress: instância privada acessando Internet)
- Instância privada envia tráfego para fora (ex.: repositórios/atualizações).
- Rota da sub-rede privada aponta para um NAT de egress.
- NAT traduz para um IP público e envia via gateway de Internet.
- Retorno volta ao NAT e é entregue à instância privada.
Pontos de falha prováveis
- DNS: nome aponta para IP público errado; ou o nome interno resolve para endereço não alcançável a partir do cliente.
- Rotas da sub-rede: sub-rede pública sem rota para Internet; sub-rede privada sem rota para NAT de egress; rota para o componente interno ausente.
- Security group (equivalente): porta não liberada; origem muito restrita; regra aplicada ao recurso errado.
- NACL/ACL de sub-rede (equivalente): bloqueio de entrada ou, por ser stateless, bloqueio do retorno (porta efêmera/retorno não permitido).
- IP público: recurso não tem IP público associado (quando deveria), ou está em sub-rede privada tentando receber tráfego direto da Internet.
- Firewall local: porta fechada na instância.
- Componente público → privado: regra permite entrada do cliente no componente público, mas não permite o tráfego do componente público para a instância privada.
Diagnóstico e correção (passo a passo)
1) Identifique o padrão de publicação escolhido
Perguntas objetivas: o servidor deve ser acessível diretamente da Internet (sub-rede pública + IP público) ou somente via um componente público (servidor em sub-rede privada)? Muitos problemas vêm de tentar “forçar” acesso direto a um recurso que está corretamente privado.
2) Verifique rotas da sub-rede
- Para recurso público: a tabela de rotas da sub-rede deve ter rota para Internet via gateway de Internet.
- Para recurso privado com saída: a tabela de rotas deve ter rota padrão para o NAT de egress.
Correção: associar a tabela de rotas correta à sub-rede correta e garantir que o next-hop (gateway/NAT) exista e esteja ativo.
3) Valide regras do security group (equivalente) por fluxo
Trate cada salto como um fluxo separado:
- Internet → componente público: liberar TCP 443 (ou a porta do serviço) nas regras de entrada do componente público.
- Componente público → instância privada: liberar TCP 443 na entrada da instância privada, com origem restrita ao security group (ou IP) do componente público.
- Instância privada → Internet (egress): liberar saída (egress) para destinos necessários (idealmente mínimo necessário).
Correção: ajustar origem/destino, porta e anexar a regra ao recurso certo. Erro comum: editar o security group “parecido” e não o efetivamente associado à interface.
4) Se houver NACL/ACL stateless, confira retorno
Em filtros stateless, você precisa permitir ida e volta explicitamente. Sintoma comum: conexão inicia (SYN chega) mas não completa, ou tráfego de retorno é bloqueado.
- Permita a porta de destino do serviço na entrada.
- Permita portas efêmeras de retorno na direção oposta (conforme política do ambiente).
5) Teste de fora e de dentro com ferramentas simples
- De fora (cliente):
nc -vz IP_PUBLICO 443 - De dentro (instância pública para privada):
nc -vz IP_PRIVADO_DA_PRIVADA 443 - Na instância privada, teste egress:
curl -I https://example.com
Interpretação: se o componente público alcança a instância privada, mas o cliente externo não alcança o componente público, o problema está na borda (rota/SG/NACL). Se o cliente alcança o componente público, mas o componente não alcança a instância privada, o problema está no fluxo interno (SG/NACL/rota interna/porta no servidor).
6) Use captura de pacotes na instância para confirmar chegada
- Na instância alvo:
sudo tcpdump -ni any port 443
Se não chega tráfego, foque em rotas e regras (security group/NACL). Se chega e não responde, foque em firewall local e serviço.
7) Checklist rápido de correção por sintoma
| Sintoma | Suspeita principal | Ação típica |
|---|---|---|
| Nome resolve, mas não conecta | Regras (SG/firewall) ou rota | Conferir porta liberada e tabela de rotas da sub-rede |
| Conecta de dentro, não de fora | Publicação/perímetro | Verificar IP público, rota para Internet e regra de entrada |
| SYN chega, não completa | Retorno bloqueado (ACL stateless) ou rota assimétrica | Permitir retorno/efêmeras; garantir simetria de caminho |
| HTTP responde local, não remoto | NAT/port mapping ou regra aplicada ao recurso errado | Revisar mapeamentos e associações de regras |
| Privada não sai para Internet | Sem NAT de egress ou rota padrão | Adicionar rota para NAT e liberar egress |
