Diagnosi dei problemi di connettività delle istanze EC2: Gruppi di sicurezza e ACL di rete

Quando la tua istanza EC2 è in esecuzione ma SSH, RDP o il traffico dell'applicazione vanno in timeout, il problema è solitamente nel percorso di rete intorno all'istanza. Diagnostica la connettività EC2 controllando prima la tabella di routing, poi l'ACL di rete della subnet, quindi il gruppo di sicurezza dell'istanza.

Comprendere la gerarchia e la funzione di questi controlli è fondamentale. I Gruppi di sicurezza agiscono come firewall con stato a livello di istanza, mentre le NACL agiscono come firewall senza stato a livello di subnet. Configurazioni errate in uno di questi componenti, o percorsi di routing errati, bloccheranno immediatamente il traffico previsto, portando a frustranti timeout di connessione.

I tre pilastri del controllo della connettività EC2

Prima di immergerci in configurazioni specifiche, è cruciale comprendere il ruolo che ogni componente gioca nel percorso del traffico verso la tua istanza EC2:

Tabelle di routing: Determinano dove viene diretto il traffico di rete in base all'indirizzo IP di destinazione. Se il traffico destinato a Internet o all'IP del tuo client non può raggiungere il gateway corretto della subnet, la connettività fallirà.
ACL di rete (NACL): Applicano regole a un'intera subnet. Sono senza 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 numero più basso a quella più alta, fermandosi alla prima corrispondenza.
Gruppi di sicurezza (SG): Applicano regole direttamente all'Interfaccia di rete elastica (ENI) dell'istanza EC2. Sono con stato, il che significa che se permetti il traffico in entrata, il traffico di ritorno in uscita è automaticamente permesso.

Passo 1: Verifica delle tabelle di routing del VPC

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

Controllo del routing in entrata

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

Obiettivo: Assicurati che la subnet contenente un'istanza pubblica abbia una route predefinita verso un Internet Gateway (IGW).
Azione: Vai alla console VPC, seleziona Route Tables ed esamina la tabella di routing associata alla subnet della tua istanza. Cerca una voce come:
```
Destinazione: 0.0.0.0/0 | Target: igw-xxxxxxxx
```

Controllo del routing in uscita (Per problemi con stato)

Mentre i SG sono con stato, verificare il percorso in uscita è cruciale, specialmente per il traffico di ritorno o per le istanze che avviano connessioni verso servizi esterni.

Azione: Se la tua istanza è in una subnet privata, assicurati che abbia una route verso un NAT Gateway o una NAT Instance per raggiungere Internet. Se è in una subnet pubblica, dovrebbe instradare 0.0.0.0/0 verso l'IGW.

Suggerimento: Il traffico tra subnet nello stesso VPC normalmente usa la route local implicita. Se quel traffico fallisce, controlla i gruppi di sicurezza, le NACL, i firewall host e se la destinazione permette ICMP prima di incolpare la tabella di routing.

Passo 2: Ispezione delle ACL di rete (Livello subnet)

Le NACL sono spesso trascurate perché operano a livello di subnet e sono senza stato. Un errore comune è permettere il traffico in entrata ma dimenticare di permettere esplicitamente il traffico di ritorno in uscita.

Verifica delle regole in entrata

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

Identifica la NACL associata alla subnet dell'istanza.
Esamina le Regole in entrata.
Assicurati che esista una regola che permetta la porta e il protocollo specifici che stai usando (ad esempio, Regola 100: Tipo: SSH (22), Protocollo: TCP, Sorgente: 0.0.0.0/0).

Verifica delle regole in uscita (La trappola senza stato)

Qui è dove si verificano la maggior parte dei problemi di connessione delle NACL.

Esamina le Regole in uscita.
Se hai permesso SSH in entrata (Porta 22), l'istanza deve inviare traffico di ritorno al tuo client su un intervallo di Porte alte (Porte effimere), tipicamente 1024-65535.
Azione: Assicurati che una regola in uscita permetta esplicitamente il traffico verso l'intervallo di porte di destinazione pertinente (spesso 1024-65535 se il client sta avviando la connessione).

Esempio di regole NACL per accesso SSH in entrata:

Regole in entrata:

Regola #	Tipo	Protocollo	Intervallo porte	Sorgente	Permetti/Nega
100	SSH	TCP	22	IP del tuo client/CIDR	PERMETTI
*	*	*	*	*	NEGA (Predefinito)

Regole in uscita:

Regola #	Tipo	Protocollo	Intervallo porte	Destinazione	Permetti/Nega
100	TCP personalizzato	TCP	1024-65535	IP del tuo client/CIDR	PERMETTI
*	*	*	*	*	NEGA (Predefinito)

Attenzione: Le NACL valutano le regole numericamente. Se la Regola 90 è NEGA TUTTO, la successiva Regola 100 PERMETTI SSH non verrà mai raggiunta. Assicurati che le tue regole PERMETTI esplicite abbiano numeri inferiori rispetto a qualsiasi regola NEGA ampia, o affidati alla regola finale implicita NEGA TUTTO.

Passo 3: Verifica dei Gruppi di sicurezza (Livello istanza)

I Gruppi di sicurezza sono l'ultima linea di difesa, applicati direttamente all'istanza. Sono più facili da gestire perché sono con stato.

Controllo delle regole in entrata

Verifica che il SG collegato all'istanza EC2 permetta il traffico sulle porte richieste dalla sorgente prevista:

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

Controllo delle regole in uscita (Di solito predefinite)

Poiché i SG sono con stato, le regole in uscita sono solitamente configurate per PERMETTERE TUTTO il Traffico (0.0.0.0/0 su tutte le porte). Se hai personalizzato le regole in uscita, assicurati che permettano le risposte di ritorno all'intervallo di porte effimere del client.

Buona pratica: A meno che non ci sia un rigoroso requisito di sicurezza, lascia le Regole in uscita del Gruppo di sicurezza impostate sul predefinito: Permetti tutto il traffico a tutte le destinazioni. Questo semplifica notevolmente la risoluzione dei problemi, poiché puoi isolare i problemi delle ACL di rete o delle tabelle di routing.

Checklist di connettività

Quando una connessione EC2 fallisce, segui questa sequenza diagnostica:

Controllo tabella di routing: Il percorso del traffico (in entrata e in uscita) può raggiungere il gateway corretto della subnet (IGW/VPC Peering/NAT)?
Controllo NACL (senza stato): Il traffico è esplicitamente PERMESSO sulla porta specifica in entrata E il traffico di ritorno (spesso porte effimere alte) è esplicitamente PERMESSO in uscita?
Controllo Gruppo di sicurezza (con stato): Il traffico è esplicitamente PERMESSO sulla porta specifica in entrata? (L'uscita dovrebbe generalmente essere aperta).

Passando sistematicamente dal livello di rete ampio (Routing) verso il basso al livello subnet (NACL) e infine al livello istanza (SG), puoi isolare rapidamente se il meccanismo di blocco è il filtraggio senza stato, il filtraggio con stato o un guasto di routing.