Solução de Problemas Comuns de Conectividade e Erros de Instância EC2

Quando uma conexão EC2 falha, a primeira pergunta útil é se a instância está inacessível, rejeitando autenticação ou acessível apenas pelo caminho errado. Esteja você usando SSH para instâncias Linux ou Remote Desktop Protocol (RDP) para instâncias Windows, as falhas de conectividade são comuns e muitas vezes frustrantes. Os erros de SSH e RDP tendem a se confundir, mas Permission denied, Connection timed out, Connection refused e uma tela RDP em branco apontam para camadas diferentes. Trate o texto do erro como uma pista e trabalhe de fora para dentro.

Fase 1: Verificações Iniciais e Integridade da Instância

Antes de mergulhar em configurações de rede complexas, certifique-se de que a instância está funcionando corretamente e acessível em um nível fundamental.

1. Verificações de Status da Instância

Use o Console de Gerenciamento da AWS ou a AWS CLI para verificar a integridade geral da instância. Duas verificações cruciais devem passar:

Verificações de Status do Sistema: Falhas aqui geralmente indicam problemas subjacentes de hardware ou infraestrutura que exigem intervenção da AWS ou término/recriação da instância.
Verificações de Status da Instância: Falhas aqui geralmente estão relacionadas a problemas de inicialização do sistema operacional, corrupção do sistema de arquivos ou problemas de driver. Se isso falhar, a instância provavelmente não está saudável o suficiente para aceitar conexões de rede.

Ação: Se alguma das verificações falhar, considere parar e iniciar a instância (o que a move para um novo hardware se a verificação do sistema falhar) ou verificar o Log do Sistema em busca de pistas.

2. Verificando o Endereço IP Público e o Nome DNS

Certifique-se de que você está tentando se conectar ao endereço correto. Se sua instância precisa ser acessada diretamente da internet, ela precisa de um Endereço IPv4 Público ou um Elastic IP e uma rota de sub-rede pública através de um internet gateway. Se estiver em uma sub-rede privada, você deve se conectar através de um Bastion Host ou usar o AWS Systems Manager Session Manager.

Dica: Se a instância foi parada e iniciada, seu endereço IP público pode ter mudado, a menos que você tenha atribuído um Elastic IP.

3. Verificando a Configuração do Cliente (SSH/RDP)

Erros de conectividade às vezes são locais. Verifique se o seu software cliente está funcionando corretamente.

Para SSH (Linux/macOS): Certifique-se de estar usando o arquivo de chave privada correto (.pem ou .ppk) e que as permissões estão configuradas corretamente (chmod 400 /caminho/para/chave.pem).
Para RDP (Windows): Certifique-se de estar usando a senha correta obtida descriptografando a senha do administrador usando o arquivo de chave privada no console EC2.

Fase 2: Diagnóstico das Camadas de Segurança (As Falhas Mais Comuns)

Configurações incorretas de segurança são a principal causa de problemas de conectividade. Tanto os Security Groups quanto as Network ACLs atuam como firewalls, e ambos devem permitir o tráfego necessário.

4. Regras de Entrada do Security Group (SG)

Security Groups são firewalls stateful anexados diretamente à Elastic Network Interface (ENI) da instância.

Requisitos Linux (SSH):

Protocolo: TCP
Faixa de Portas: 22
Origem: Seu endereço IP público (My IP) ou 0.0.0.0/0 (para todos os IPs, embora isso seja desencorajado por segurança).

Requisitos Windows (RDP):

Protocolo: TCP
Faixa de Portas: 3389
Origem: Seu endereço IP público ou 0.0.0.0/0.

Etapa de Solução de Problemas: Altere temporariamente a origem da regra de entrada necessária para 0.0.0.0/0 para a porta relevante (22 ou 3389). Se você conseguir se conectar, o problema era que seu endereço IP de cliente específico estava bloqueado ou não foi identificado corretamente.

Aviso: Nunca deixe security groups abertos para 0.0.0.0/0 para portas de gerenciamento (22/3389) em ambientes de produção. Use IPs de origem específicos ou endpoints VPC quando possível.

5. Network ACLs (NACLs)

Network ACLs são firewalls sem estado no nível da sub-rede. Eles verificam o tráfego de entrada e saída de forma independente. Se o tráfego for permitido na entrada, o tráfego de retorno também deve ser permitido na saída.

Requisitos NACL para Conectividade:

Direção	Protocolo	Faixa de Portas	Ação da Regra
Entrada	TCP	22 (SSH) ou 3389 (RDP)	Permitir
Saída	TCP	Portas Efêmeras (1024-65535)	Permitir

As portas efêmeras são críticas. Quando seu cliente se conecta (por exemplo, da porta 54321), o servidor responde em uma porta efêmera de número alto. Se o NACL bloquear o tráfego de saída nessas portas altas, o servidor não poderá enviar a resposta de volta para você, resultando em um tempo limite de conexão.

Etapa de Solução de Problemas: Verifique se tanto a porta de entrada (22/3389) quanto as portas efêmeras de saída (1024-65535) têm uma regra Permitir no NACL associado.

Fase 3: Roteamento e Configuração da VPC

Se as camadas de segurança forem confirmadas como abertas, o problema está em como o tráfego é roteado para a sub-rede da instância e a partir dela.

6. Tipo de Sub-rede e Tabelas de Rotas

A conectividade depende inteiramente se sua instância está em uma Sub-rede Pública ou uma Sub-rede Privada.

Conectividade de Sub-rede Pública

Para acesso direto à internet (SSH/RDP do mundo exterior):

A instância deve ter um endereço IPv4 público ou Elastic IP atribuído.
A Tabela de Rotas associada deve ter uma rota para 0.0.0.0/0 apontando para um Internet Gateway (IGW).

Conectividade de Sub-rede Privada

Instâncias em sub-redes privadas não podem ser acessadas diretamente da internet. A conexão requer um caminho de múltiplos saltos:

Conexão via Bastion Host (Jump Box): Você faz SSH em uma instância EC2 pública e, em seguida, faz SSH do Bastion Host para a instância privada (usando seu IP Privado).
Conexão via VPN/Direct Connect: Se estiver usando AWS Site-to-Site VPN ou Direct Connect, o roteamento deve ser configurado para direcionar o tráfego para sua rede local, que então roteia para a sub-rede privada.

7. Problemas de Firewall no Nível do SO

Se as verificações de segurança da AWS passarem, o sistema operacional em execução na instância EC2 pode estar bloqueando a conexão. Isso é comum se você instalou ou configurou manualmente firewalls locais (como iptables no Linux ou Windows Defender Firewall).

Diagnóstico (Se possível via Console ou Session Manager):

Linux: Verifique iptables -L ou use firewall-cmd --list-all. Certifique-se de que a porta 22 está explicitamente permitida.
Windows: Verifique as configurações do Windows Defender Firewall para regras de entrada na porta 3389.

Dica de Recuperação: Se você perdeu toda a conectividade, considere parar a instância, desanexar o volume raiz, anexá-lo a uma instância de recuperação funcional, modificar os arquivos de configuração do SO para desabilitar o firewall e, em seguida, reanexar o volume ao ID da instância original.

Opções de conexão pública, privada e gerenciada

Não presuma que toda instância EC2 deve aceitar SSH ou RDP da internet. Instâncias públicas precisam de um endereço público, uma rota para um internet gateway, controles de segurança permissivos e um listener em execução. Instâncias privadas geralmente precisam de um método de acesso diferente: um bastion host, VPN, Direct Connect, EC2 Instance Connect Endpoint ou Systems Manager Session Manager.

O Session Manager é especialmente útil para equipes de operações porque pode eliminar a necessidade de SSH de entrada. A instância precisa do agente SSM, um perfil de instância IAM com as permissões corretas do Systems Manager e acesso de rede aos endpoints SSM. Em sub-redes privadas, isso geralmente significa endpoints de interface VPC ou internet de saída através de um caminho NAT. Se alguma dessas peças estiver faltando, o Session Manager não aparecerá como uma opção, mesmo que a instância em si esteja saudável.

Para um design de bastion, teste ambas as pernas. Primeiro, conecte-se da sua estação de trabalho ao bastion. Em seguida, conecte-se do bastion ao IP privado da instância de destino. O security group da instância de destino geralmente deve permitir SSH apenas do security group do bastion, não do seu IP residencial e não de todo o CIDR da VPC, a menos que você tenha um motivo.

Para RDP, lembre-se de que a inicialização do Windows pode demorar mais do que a inicialização do SSH no Linux, especialmente após aplicação de patches ou primeiro lançamento. Se as verificações de status da instância acabaram de passar, mas o RDP ainda falhar, verifique o log do sistema e aguarde alguns minutos antes de alterar as regras do firewall. Substituir repetidamente os security groups pode ocultar o problema real de inicialização ou serviço.

Testes rápidos da sua estação de trabalho

Use pequenos testes de rede antes de alterar os recursos da AWS. No Linux ou macOS, nc -vz <ip-publico> 22 testa se a porta TCP 22 é concluída. Para RDP, use nc -vz <ip-publico> 3389 ou uma ferramenta de teste de porta no Windows. Um tempo limite aponta para roteamento, security groups, NACLs ou um firewall upstream. Uma conexão recusada aponta mais para o SO da instância ou serviço.

Se o DNS estiver envolvido, resolva-o explicitamente:

dig +short ec2-203-0-113-10.compute-1.amazonaws.com

Em seguida, compare o resultado com o IP público atual no console EC2. Elastic IPs permanecem estáveis, mas IPs públicos atribuídos automaticamente podem mudar após parar/iniciar. Esta é uma causa simples de runbooks quebrados e perfis RDP salvos.

Se você usa uma VPN corporativa, teste de outra rede antes de editar a VPC. Algumas redes de empresas bloqueiam SSH ou RDP de saída, e alguns roteadores residenciais ou ISPs interferem em portas incomuns. Uma conexão bem-sucedida de uma rede diferente indica que a instância pode estar bem.

Vale a pena usar o VPC Reachability Analyzer quando a rota não é óbvia. Ele pode modelar um caminho entre uma origem e um destino e apontar onde o roteamento ou a filtragem bloqueia o tráfego. Ele não corrigirá uma chave SSH ruim ou um serviço parado dentro do SO convidado, mas é útil para separar problemas de design de rede AWS de problemas de sistema operacional.

Os Flow logs também podem ajudar, especialmente quando NACLs ou security groups são suspeitos. Um fluxo rejeitado do IP do seu cliente para a porta 22 ou 3389 indica que o pacote atingiu uma interface de rede ou sub-rede monitorada e foi negado. Nenhum fluxo pode significar que o tráfego nunca chegou à VPC, o endereço está errado ou você está olhando para a ENI, sub-rede ou janela de tempo errada.

Mantenha um pequeno runbook de acesso para cada ambiente: faixas de IP de origem aprovadas, nome do bastion, requisitos SSM, nomes de usuário padrão por AMI e o procedimento de instância de recuperação. Incidentes de conectividade ficam mais lentos quando cada engenheiro precisa redescobrir esses detalhes no console.

Registre também quais sub-redes são intencionalmente privadas. Essa única anotação evita muita depuração desperdiçada quando alguém tenta fazer SSH diretamente para uma instância que nunca foi projetada para ter um caminho de internet.

Lendo a mensagem de erro

Connection timed out geralmente significa que os pacotes não estão completando a viagem. Verifique o IP público, tabela de rotas, internet gateway, origem do security group, regras NACL, firewall corporativo e se você está tentando alcançar uma sub-rede privada diretamente.

Connection refused geralmente significa que o caminho de rede alcançou a instância, mas nada está ouvindo nessa porta ou o SO a rejeitou. No Linux, verifique se sshd está em execução e ouvindo na porta 22. No Windows, verifique se o RDP está habilitado e o serviço Remote Desktop está em execução.

Permission denied (publickey) não é um problema de VPC. Geralmente significa nome de usuário errado, chave privada errada, chave pública ausente em authorized_keys, permissões de diretório home alteradas ou incompatibilidade de nome de usuário AMI, como usar ec2-user para uma imagem Ubuntu em vez de ubuntu.

Para RDP do Windows, falhas de autenticação geralmente vêm do uso de uma senha de administrador descriptografada antiga após a instância ser substituída, conectar-se ao IP público errado após uma parada/inicialização ou política de domínio substituindo os direitos de login local.

Caminhos de recuperação quando você não consegue fazer login

Se a instância tiver o agente Systems Manager instalado, um perfil de instância com permissões SSM e acesso de rede aos endpoints SSM ou à internet, o Session Manager geralmente é o caminho de recuperação menos disruptivo. Você pode inspecionar logs, corrigir regras de firewall ou reparar authorized_keys sem abrir SSH para o mundo.

Se o SSM não estiver disponível, use o console serial EC2 onde for suportado, ou desanexe o volume raiz e anexe-o a uma instância de recuperação na mesma Zona de Disponibilidade. Monte-o com cuidado, corrija a configuração de rede ou SSH, desmonte-o e reanexe-o à instância original. Faça um snapshot primeiro para que uma tentativa de reparo não piore a recuperação.

Quando a conectividade falhar, siga esta lista de verificação priorizada: integridade da instância, endereço correto, nome de usuário/chave ou senha RDP corretos, security group, NACL, tabela de rotas, firewall do SO e integridade do serviço. Essa ordem impede que você altere cinco controles da AWS quando o problema real é uma chave desatualizada ou uma rota ausente.