Diagnosticando Problemas de Conectividade em Instâncias EC2: Grupos de Segurança e ACLs de Rede

Quando sua instância EC2 está em execução, mas o tráfego SSH, RDP ou de aplicativos expira, o problema geralmente está no caminho de rede ao redor da instância. Diagnostique a conectividade EC2 verificando primeiro a tabela de roteamento, depois a ACL de rede da sub-rede e, em seguida, o grupo de segurança da instância.

Entender a hierarquia e a função desses controles é fundamental. Os Grupos de Segurança atuam como firewalls stateful no nível da instância, enquanto as NACLs atuam como firewalls stateless 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 sua instância EC2:

1. Tabelas de Roteamento: Determinam para onde o tráfego de rede é direcionado com base no 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. ACLs de Rede (NACLs): Aplicam regras a uma sub-rede inteira. Elas são stateless, o que significa que o tráfego de entrada e saída deve ser explicitamente permitido. Elas processam as regras em ordem, da regra de número mais baixo para a mais alta, parando na primeira correspondência.
3. Grupos de Segurança (SGs): Aplicam regras diretamente à Interface de Rede Elástica (ENI) da instância EC2. Eles são stateful, o que significa que, se você permitir o tráfego de entrada, o tráfego de retorno é automaticamente permitido.

---

Passo 1: Verificando as Tabelas de Roteamento da VPC

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

Verificando o Roteamento de Entrada

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

• Objetivo: Garantir que a sub-rede que contém uma instância pública tenha uma rota padrão para um Internet Gateway (IGW).
• Ação: Navegue até o console da VPC, selecione Tabelas de Roteamento e examine a tabela de roteamento associada à sub-rede da sua instância. Procure por uma entrada como:

  Destino: 0.0.0.0/0 | Alvo: igw-xxxxxxxx
  

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

Embora os SGs sejam stateful, verificar o caminho de saída é crucial, especialmente para 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 alcançar a internet. Se estiver em uma sub-rede pública, ela deve rotear 0.0.0.0/0 para o IGW.

Dica: O tráfego entre sub-redes na mesma VPC normalmente usa a rota local implícita. Se esse tráfego falhar, verifique grupos de segurança, NACLs, firewalls do host e se o destino permite ICMP antes de culpar a tabela de roteamento.

Passo 2: Inspecionando as ACLs de Rede (Nível da Sub-rede)

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

Verificação de Regras de Entrada

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 Regras de Entrada.
3. Certifique-se de que existe uma regra que permite 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 (A Armadilha Stateless)

É aqui que ocorre a maioria dos problemas de conexão com NACLs.

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

Exemplo de Regras NACL para Acesso SSH de Entrada:

Regras de entrada:

Regra #	Tipo	Protocolo	Faixa de Porta	Origem	Permitir/Negar
100	SSH	TCP	22	IP do seu cliente/CIDR	PERMITIR
*	*	*	*	*	NEGAR (Padrão)

Regras de saída:

Regra #	Tipo	Protocolo	Faixa de Porta	Destino	Permitir/Negar
100	TCP Personalizado	TCP	1024-65535	IP do seu cliente/CIDR	PERMITIR
*	*	*	*	*	NEGAR (Padrão)

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

Passo 3: Auditando os Grupos de Segurança (Nível da Instância)

Os Grupos de Segurança são a última linha de defesa, aplicados diretamente à instância. Eles são mais fáceis de gerenciar porque são stateful.

Verificação de Regras de Entrada

Verifique se o SG anexado à instância EC2 permite o tráfego nas portas necessárias 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 Regras de Saída (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, certifique-se de que elas permitam respostas de volta para a faixa de porta efêmera do cliente.

Melhor Prática: A menos que haja um requisito de segurança rigoroso, deixe as Regras de Saída do Grupo de Segurança 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 Roteamento.

Lista de Verificação de Conectividade

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

1. Verificação da Tabela de Roteamento: O caminho do tráfego (entrada e saída) consegue alcançar o gateway correto da sub-rede (IGW/VPC Peering/NAT)?
2. Verificação da NACL (Stateless): O tráfego é explicitamente PERMITIDO na porta de entrada específica E o tráfego de retorno (geralmente portas efêmeras altas) é explicitamente PERMITIDO na saída?
3. Verificação do Grupo de Segurança (Stateful): O tráfego é 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.