Diagnóstico de Problemas de Conectividade da Instância EC2: Grupos de Segurança e ACLs de Rede

Conectar-se a uma instância do Amazon Elastic Compute Cloud (EC2) é uma operação fundamental, mas falhas de conectividade estão entre os cenários de solução de problemas mais comuns para usuários da AWS. Quando uma instância parece estar sendo executada corretamente, mas permanece inacessível – seja via SSH, RDP ou tráfego de aplicação –, o problema quase sempre reside nas camadas de segurança de rede circundantes. Este guia abrangente descreve a abordagem sistemática para diagnosticar e resolver problemas de conectividade, focando nos três pontos críticos de controle de rede: Security Groups (SGs), Network Access Control Lists (NACLs) e Tabelas de Rotas da VPC.

Compreender a hierarquia e a função desses controles é fundamental. Security Groups atuam como firewalls stateful (com estado) no nível da instância, enquanto NACLs atuam como firewalls stateless (sem estado) no nível da sub-rede. Configurações incorretas em qualquer um desses componentes, ou caminhos de roteamento incorretos, bloquearão imediatamente o tráfego esperado, levando a timeouts de conexão frustrantes.

Os Três Pilares do Controle de Conectividade EC2

Antes de mergulhar em configurações específicas, é crucial entender o papel que cada componente desempenha no caminho do tráfego para a sua instância EC2:

1. Tabelas de Rotas: Determinam para onde o tráfego de rede é direcionado com base no seu endereço IP de destino. Se o tráfego destinado à internet ou ao IP do seu cliente não conseguir alcançar o gateway correto da sub-rede, a conectividade falhará.
2. Network ACLs (NACLs): Aplicam regras a uma sub-rede inteira. Elas são stateless (sem estado), o que significa que o tráfego de entrada e de saída deve ser explicitamente permitido. Elas processam as regras em ordem, do número mais baixo ao mais alto, parando na primeira correspondência.
3. Security Groups (SGs): Aplicam regras diretamente à Elastic Network Interface (ENI) da instância EC2. Elas são stateful (com estado), o que significa que, se você permitir o tráfego de entrada, o tráfego de saída de retorno é automaticamente permitido.

Etapa 1: Verificando as Tabelas de Rotas da VPC

A primeira verificação de diagnóstico deve sempre confirmar se existe um caminho para o tráfego sequer alcançar a sub-rede onde a instância EC2 reside.

Verificando o Roteamento de Entrada (Inbound Routing)

Para uma instância acessível pela internet pública (por exemplo, via SSH/RDP):

• Objetivo: Garantir que a sub-rede que contém a instância tenha uma rota para o Internet Gateway (IGW) para o tráfego originado de 0.0.0.0/0 (ou do seu intervalo de IP de cliente específico).
• Ação: Navegue até o console da VPC, selecione Route Tables (Tabelas de Rotas) e examine a tabela de rotas associada à sub-rede da sua instância. Procure por uma entrada como:
  Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx

Verificando o Roteamento de Saída (Outbound Routing) (Para Problemas Stateful)

Embora os SGs sejam stateful, verificar o caminho de saída é crucial, especialmente para o tráfego de retorno ou instâncias que iniciam conexões com serviços externos.

• Ação: Se sua instância estiver em uma sub-rede privada, certifique-se de que ela tenha uma rota para um NAT Gateway ou NAT Instance para acessar a internet. Se estiver em uma sub-rede pública, ela deve rotear 0.0.0.0/0 para o IGW.

Dica: Se você não conseguir enviar ping para uma instância a partir de uma sub-rede diferente dentro da mesma VPC, o problema é quase certamente uma tabela de rotas mal configurada, direcionando o tráfego para o gateway local incorreto ou para a conexão de VPC Peering.

Etapa 2: Inspecionando Network ACLs (Nível da Sub-rede)

As NACLs são frequentemente negligenciadas porque operam no nível da sub-rede e são stateless (sem estado). Um erro comum é permitir o tráfego de entrada, mas esquecer de permitir explicitamente o tráfego de saída de retorno.

Verificação de Regras de Entrada (Inbound Rule Verification)

Para tentativas de conexão de entrada (por exemplo, SSH na porta 22):

1. Identifique a NACL associada à sub-rede da instância.
2. Examine as Inbound Rules (Regras de Entrada).
3. Garanta que exista uma regra que permita a porta e o protocolo específicos que você está usando (por exemplo, Regra 100: Tipo: SSH (22), Protocolo: TCP, Origem: 0.0.0.0/0).

Verificação de Regras de Saída (Outbound Rule Verification) (A Armadilha Stateless)

É aqui que ocorre a maioria dos problemas de conexão da NACL.

1. Examine as Outbound Rules (Regras de Saída).
2. Se você permitiu SSH de entrada (Porta 22), a instância precisa enviar o tráfego de volta para o seu cliente em um intervalo de Porta Alta (Porta Efêmera), tipicamente 1024-65535.
3. Ação: Garanta que uma regra de Saída permita explicitamente o tráfego para o intervalo de porta de destino relevante (geralmente 1024-65535 se o cliente estiver iniciando a conexão).

Exemplo de Conjunto de Regras NACL para Acesso SSH de Entrada:

Aviso: As NACLs avaliam as regras numericamente. Se a Regra 90 for DENY ALL (NEGAR TUDO), sua Regra 100 subsequente ALLOW SSH (PERMITIR SSH) nunca será alcançada. Certifique-se de que suas regras ALLOW explícitas tenham números mais baixos do que quaisquer regras DENY amplas, ou confie na regra implícita final DENY ALL.

Etapa 3: Auditoria de Security Groups (Nível da Instância)

Security Groups são a linha final de defesa, aplicados diretamente à instância. Eles são mais fáceis de gerenciar porque são stateful (com estado).

Verificação de Regra de Entrada (Inbound Rule Check)

Verifique se o SG anexado à instância EC2 permite tráfego nas portas necessárias a partir da origem esperada:

• Para SSH (Linux): Regra de entrada permitindo Porta TCP 22 do seu IP público ou 0.0.0.0/0 (se necessário).
• Para RDP (Windows): Regra de entrada permitindo Porta TCP 3389 do seu IP público ou 0.0.0.0/0.
• Para Tráfego Web: Regra de entrada permitindo Porta TCP 80 e/ou 443 de 0.0.0.0/0.

Verificação de Regra de Saída (Outbound Rule Check) (Geralmente Padrão)

Como os SGs são stateful, as Regras de Saída geralmente são configuradas para PERMITIR TODO o Tráfego (0.0.0.0/0 em todas as portas). Se você personalizou as regras de saída, garanta que elas permitam respostas de volta para o intervalo de portas efêmeras do cliente.

Prática Recomendada: A menos que haja um requisito de segurança rigoroso, mantenha as Outbound Rules (Regras de Saída) do Security Group definidas como padrão: Permitir Todo o Tráfego para Todos os Destinos. Isso simplifica significativamente a solução de problemas, pois você pode isolar problemas de NACL ou Tabela de Rotas.

Resumo: O Checklist do Fluxo de Conectividade

Quando uma conexão EC2 falha, siga esta sequência de diagnóstico:

1. Verificação da Tabela de Rotas: O caminho do tráfego (entrada e saída) pode alcançar o gateway de sub-rede correto (IGW/VPC Peering/NAT)?
2. Verificação da NACL (Stateless): O tráfego está explicitamente PERMITIDO na porta de entrada específica E o tráfego de retorno (muitas vezes portas efêmeras altas) está explicitamente PERMITIDO na saída?
3. Verificação do Security Group (Stateful): O tráfego está explicitamente PERMITIDO na porta de entrada específica? (A saída geralmente deve estar aberta).

Ao mover-se sistematicamente da camada de rede ampla (Roteamento) para o nível da sub-rede (NACLs) e, finalmente, para o nível da instância (SGs), você pode isolar rapidamente se o mecanismo de bloqueio é filtragem stateless, filtragem stateful ou falha de roteamento.