Diagnosi dei problemi di connettività delle istanze EC2: Security Groups e Network ACLs

Connettersi a un'istanza Amazon Elastic Compute Cloud (EC2) è un'operazione fondamentale, ma i guasti di connettività sono tra gli scenari di risoluzione dei problemi più comuni per gli utenti AWS. Quando un'istanza sembra essere in esecuzione correttamente ma rimane irraggiungibile—sia tramite SSH, RDP o traffico applicativo—il problema risiede quasi sempre negli strati di sicurezza della rete circostante. Questa guida completa illustra l'approccio sistematico per diagnosticare e risolvere i problemi di connettività concentrandosi sui tre punti di controllo critici della rete: Security Groups (SG), Network Access Control Lists (NACL) e Tabelle di routing VPC.

Comprendere la gerarchia e la funzione di questi controlli è fondamentale. I Security Groups agiscono come firewall stateful a livello di istanza, mentre le NACL agiscono come firewall stateless a livello di sottorete. Errori di configurazione in uno di questi componenti, o percorsi di routing errati, bloccheranno immediatamente il traffico atteso, portando a frustranti timeout di connessione.

I tre pilastri del controllo della connettività EC2

Prima di addentrarci nelle configurazioni specifiche, è cruciale comprendere il ruolo che ciascun componente svolge nel percorso del traffico verso la vostra istanza EC2:

1. Tabelle di routing: Determinano dove viene indirizzato il traffico di rete in base al suo indirizzo IP di destinazione. Se il traffico destinato a Internet o al vostro IP client non riesce a raggiungere il gateway di sottorete corretto, la connettività fallirà.
2. Network ACLs (NACL): Applicano regole a un'intera sottorete. Sono stateless (prive di stato), il che significa che il traffico sia in entrata che in uscita deve essere esplicitamente consentito. Elaborano le regole in ordine, dalla regola con il numero più basso a quella con il numero più alto, fermandosi al primo abbinamento.
3. Security Groups (SG): Applicano regole direttamente all'Elastic Network Interface (ENI) dell'istanza EC2. Sono stateful (con stato), il che significa che se si consente il traffico in entrata, il traffico di ritorno in uscita viene automaticamente permesso.

Fase 1: Verifica delle Tabelle di routing VPC

Il primo controllo diagnostico dovrebbe sempre confermare che esista un percorso affinché il traffico possa persino raggiungere la sottorete in cui risiede l'istanza EC2.

Verifica del routing in entrata

Per un'istanza raggiungibile dall'Internet pubblico (ad esempio, tramite SSH/RDP):

• Obiettivo: Assicurarsi che la sottorete contenente l'istanza abbia una rotta verso l'Internet Gateway (IGW) per il traffico proveniente da 0.0.0.0/0 (o dal vostro specifico intervallo IP client).
• Azione: Accedere alla console VPC, selezionare Tabelle di routing ed esaminare la tabella di routing associata alla sottorete della vostra istanza. Cercare una voce come:
  Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx

Verifica del routing in uscita (per problemi stateful)

Sebbene gli SG siano stateful, la verifica del percorso in uscita è cruciale, specialmente per il traffico di ritorno o per le istanze che avviano connessioni verso servizi esterni.

• Azione: Se la vostra istanza si trova in una sottorete privata, assicuratevi che abbia una rotta verso un NAT Gateway o un'Istanza NAT per raggiungere Internet. Se si trova in una sottorete pubblica, dovrebbe instradare 0.0.0.0/0 verso l'IGW.

Suggerimento: Se non riuscite a effettuare il ping di un'istanza da una sottorete diversa all'interno della stessa VPC, il problema è quasi certamente una tabella di routing configurata male che indirizza il traffico verso il gateway locale o la connessione VPC Peering errati.

Fase 2: Ispezione delle Network ACLs (Livello Sottorete)

Le NACL sono spesso trascurate perché operano a livello di sottorete e sono stateless (prive di stato). Un errore comune è consentire il traffico in entrata ma dimenticare di consentire esplicitamente il traffico di ritorno in uscita.

Verifica della regola in entrata

Per i tentativi di connessione in entrata (ad esempio, SSH sulla porta 22):

1. Identificare la NACL associata alla sottorete dell'istanza.
2. Esaminare le Regole in entrata.
3. Assicurarsi che esista una regola che consenta la porta e il protocollo specifici che state utilizzando (ad esempio, Regola 100: Tipo: SSH (22), Protocollo: TCP, Origine: 0.0.0.0/0).

Verifica della regola in uscita (La trappola stateless)

È qui che si verifica la maggior parte dei problemi di connessione NACL.

1. Esaminare le Regole in uscita.
2. Se avete consentito SSH in entrata (Porta 22), l'istanza deve inviare traffico di ritorno al vostro client su un intervallo di Porte Alte (Porte Effimere), in genere 1024-65535.
3. Azione: Assicurarsi che una regola in uscita consenta esplicitamente il traffico verso l'intervallo di porte di destinazione pertinente (spesso 1024-65535 se il client sta avviando la connessione).

Esempio di set di regole NACL per l'accesso SSH in entrata:

Attenzione: Le NACL valutano le regole in ordine numerico. Se la Regola 90 è NEGA TUTTO, la successiva Regola 100 CONSENTI SSH non verrà mai raggiunta. Assicuratevi che le vostre regole CONSENTI esplicite abbiano numeri inferiori rispetto a qualsiasi regola NEGA ampia, oppure affidatevi alla regola implicita finale NEGA TUTTO.

Fase 3: Verifica dei Security Groups (Livello Istanza)

I Security Groups sono l'ultima linea di difesa, applicata direttamente all'istanza. Sono più facili da gestire perché sono stateful (con stato).

Controllo della regola in entrata

Verificare che l'SG collegato all'istanza EC2 consenta il traffico sulle porte richieste dalla sorgente prevista:

• Per SSH (Linux): Regola in entrata che consenta la Porta TCP 22 dal vostro IP pubblico o 0.0.0.0/0 (se necessario).
• Per RDP (Windows): Regola in entrata che consenta la Porta TCP 3389 dal vostro IP pubblico o 0.0.0.0/0.
• Per il Traffico Web: Regola in entrata che consenta la Porta TCP 80 e/o 443 da 0.0.0.0/0.

Controllo della regola in uscita (solitamente predefinita)

Poiché gli SG sono stateful, le Regole in uscita sono solitamente configurate per CONSENTIRE TUTTO il Traffico (0.0.0.0/0 su tutte le porte). Se avete personalizzato le regole in uscita, assicuratevi che consentano le risposte all'intervallo di porte effimere del client.

Best Practice: A meno che non vi sia un rigoroso requisito di sicurezza, lasciare le Regole in uscita del Security Group impostate sull'impostazione predefinita: Consenti tutto il traffico a tutte le destinazioni. Ciò semplifica notevolmente la risoluzione dei problemi, poiché è possibile isolare problemi di NACL o di Tabelle di routing.

Riepilogo: La lista di controllo del flusso di connettività

Quando una connessione EC2 fallisce, seguite questa sequenza diagnostica:

1. Controllo della Tabella di routing: Il percorso del traffico (in entrata e in uscita) può raggiungere il gateway di sottorete corretto (IGW/VPC Peering/NAT)?
2. Controllo NACL (Stateless): Il traffico è esplicitamente CONSENTITO sulla porta specifica in entrata E il traffico di ritorno (spesso porte effimere alte) è esplicitamente CONSENTITO in uscita?
3. Controllo Security Group (Stateful): Il traffico è esplicitamente CONSENTITO sulla porta specifica in entrata? (L'uscita dovrebbe essere generalmente aperta).

Muovendosi sistematicamente dallo strato di rete più ampio (Routing) al livello di sottorete (NACL) e infine al livello di istanza (SG), è possibile isolare rapidamente se il meccanismo di blocco è un filtraggio stateless, un filtraggio stateful o un errore di routing.