Risoluzione dei problemi comuni di connettività ed errori delle istanze EC2

La connessione a un'istanza Amazon Elastic Compute Cloud (EC2) è fondamentale per la gestione delle risorse cloud. Sia che si utilizzi SSH per le istanze Linux o Remote Desktop Protocol (RDP) per le istanze Windows, i fallimenti di connettività sono comuni e spesso frustranti. Questa guida fornisce un approccio sistematico, passo dopo passo, per diagnosticare e risolvere le ragioni più frequenti per cui potresti non riuscire a raggiungere la tua istanza EC2.

La comprensione dei fallimenti di connettività richiede di guardare oltre l'istanza stessa. I problemi derivano tipicamente da errate configurazioni nei livelli di sicurezza (Gruppi di Sicurezza, NACL), impostazioni di rete errate (instradamento VPC) o problemi di autenticazione. Controllando metodicamente questi componenti in ordine, è possibile isolare rapidamente la causa principale e ripristinare l'accesso.

Fase 1: Controlli Iniziali e Stato dell'Istanza

Prima di addentrarsi in complesse configurazioni di rete, assicurarsi che l'istanza funzioni correttamente e sia raggiungibile a livello fondamentale.

1. Controlli di Stato dell'Istanza

Utilizzare la AWS Management Console o AWS CLI per verificare lo stato generale dell'istanza. Due controlli cruciali devono superare:

Controlli di Stato del Sistema: I fallimenti qui solitamente indicano problemi hardware o infrastrutturali sottostanti che richiedono l'intervento di AWS o la terminazione/ricreazione dell'istanza.
Controlli di Stato dell'Istanza: I fallimenti qui sono spesso correlati a problemi di avvio del sistema operativo, corruzione del file system o problemi di driver. Se questo fallisce, è probabile che l'istanza non sia abbastanza integra da rifiutare le connessioni di rete.

Azione: Se uno dei controlli fallisce, considerare l'arresto e l'avvio dell'istanza (che la sposta su nuovo hardware se il controllo di sistema fallisce) o la verifica del Log di Sistema per indizi.

2. Verifica dell'Indirizzo IP Pubblico e del Nome DNS

Assicurarsi di tentare di connettersi all'indirizzo corretto. Se la tua istanza si trova in una sottorete pubblica, richiede un Indirizzo IPv4 Pubblico o un IP Elastico. Se si trova in una sottorete privata, devi connetterti tramite un Bastion Host o utilizzare AWS Systems Manager Session Manager.

Suggerimento: Se l'istanza è stata arrestata e riavviata, il suo indirizzo IP pubblico potrebbe essere cambiato a meno che tu non abbia assegnato un IP Elastico.

3. Verifica della Configurazione del Client (SSH/RDP)

Gli errori di connettività sono a volte locali. Verificare che il software client funzioni correttamente.

Per SSH (Linux/macOS): Assicurarsi di utilizzare il file della chiave privata corretto (.pem o .ppk) e che i permessi siano impostati correttamente (chmod 400 /percorso/alla/chiave.pem).
Per RDP (Windows): Assicurarsi di utilizzare la password corretta ottenuta decrittografando la password dell'amministratore utilizzando il file della chiave privata nella console EC2.

Fase 2: Diagnostica dei Livelli di Sicurezza (I Fallimenti Più Comuni)

Le errate configurazioni di sicurezza sono la causa principale dei problemi di connettività. Sia i Gruppi di Sicurezza che le Network ACL agiscono come firewall, ed entrambi devono consentire il traffico necessario.

4. Regole di Ingress del Gruppo di Sicurezza (SG)

I Gruppi di Sicurezza sono firewall stateful collegati direttamente all'Interfaccia di Rete Elastica (ENI) dell'istanza.

Requisiti per Linux (SSH):

Protocollo: TCP
Intervallo Porte: 22
Origine: Il tuo indirizzo IP pubblico (Mio IP) o 0.0.0.0/0 (per tutti gli IP, anche se sconsigliato per motivi di sicurezza).

Requisiti per Windows (RDP):

Protocollo: TCP
Intervallo Porte: 3389
Origine: Il tuo indirizzo IP pubblico o 0.0.0.0/0.

Passaggio di Risoluzione Problemi: Modifica temporaneamente l'origine della regola di ingress richiesta a 0.0.0.0/0 per la porta pertinente (22 o 3389). Se riesci a connetterti, il problema era che il tuo specifico indirizzo IP client era bloccato o non identificato correttamente.

Attenzione: Non lasciare mai i gruppi di sicurezza aperti a 0.0.0.0/0 per le porte di gestione (22/3389) negli ambienti di produzione. Utilizzare indirizzi IP sorgente specifici o endpoint VPC ove possibile.

5. Network ACL (NACL)

Le Network ACL sono firewall stateless a livello di sottorete. Controllano il traffico sia in entrata che in uscita in modo indipendente. Se il traffico è consentito in entrata, anche il traffico di ritorno deve essere consentito in uscita.

Requisiti NACL per la Connettività:

Direzione	Protocollo	Intervallo Porte	Azione Regola
In entrata	TCP	22 (SSH) o 3389 (RDP)	Consenti
In uscita	TCP	Porte Effimere (1024-65535)	Consenti

Le porte effimere sono critiche. Quando il tuo client si connette (ad esempio, dalla porta 54321), il server risponde su una porta effimera numerata in alto. Se la NACL blocca il traffico in uscita su queste porte alte, il server non può inviare la risposta, causando un timeout della connessione.

Passaggio di Risoluzione Problemi: Verifica che sia la porta in entrata (22/3389) sia le porte effimere in uscita (1024-65535) abbiano una regola Consenti nella NACL associata.

Fase 3: Instradamento e Configurazione VPC

Se i livelli di sicurezza sono confermati come aperti, il problema risiede nel modo in cui il traffico viene instradato da e verso la sottorete dell'istanza.

6. Tipo di Sottorete e Tabelle di Routing

La connettività dipende interamente dal fatto che la tua istanza si trovi in una Sottorete Pubblica o in una Sottorete Privata.

Connettività Sottorete Pubblica

Per l'accesso diretto a Internet (SSH/RDP dal mondo esterno):

All'istanza deve essere assegnato un indirizzo IPv4 pubblico o un IP elastico.
La Tabella di Routing associata deve avere una rotta per 0.0.0.0/0 che punti a un Internet Gateway (IGW).

Connettività Sottorete Privata

Le istanze in sottoreti private non sono raggiungibili direttamente da Internet. La connessione richiede un percorso multi-hop:

Connessione tramite Bastion Host (Jump Box): Ti connetti via SSH a un'istanza EC2 pubblica, e poi ti connetti via SSH dal Bastion Host all'istanza privata (utilizzando il suo IP privato).
Connessione tramite VPN/Direct Connect: Se si utilizza AWS Site-to-Site VPN o Direct Connect, l'instradamento deve essere configurato per dirigere il traffico alla tua rete on-premises, che a sua volta instrada alla sottorete privata.

7. Problemi Firewall a Livello di Sistema Operativo

Se i controlli di sicurezza AWS passano, il sistema operativo in esecuzione sull'istanza EC2 stessa potrebbe bloccare la connessione. Questo è comune se hai installato o configurato manualmente firewall locali (come iptables su Linux o Windows Defender Firewall).

Diagnosi (Se possibile tramite Console o Session Manager):

Linux: Controlla iptables -L o usa firewall-cmd --list-all. Assicurati che la porta 22 sia esplicitamente consentita.
Windows: Controlla le impostazioni di Windows Defender Firewall per le regole in entrata sulla porta 3389.

Suggerimento di Ripristino: Se hai perso tutta la connettività, considera di arrestare l'istanza, scollegare il volume root, collegarlo a un'istanza di recupero funzionante, modificare i file di configurazione del sistema operativo per disabilitare il firewall, e poi ricollegare il volume all'ID dell'istanza originale.

Riepilogo del Flusso di Risoluzione Problemi

Quando la connettività fallisce, segui questa checklist prioritaria:

Stato Istanza: I controlli di stato del sistema/istanza sono superati?
Autenticazione Client: Il file della chiave è corretto e con i permessi giusti (SSH)?
Gruppo di Sicurezza: Il SG consente il traffico in entrata sulla Porta 22/3389 dal tuo IP?
NACL: La NACL consente il traffico in entrata (22/3389) E in uscita (1024-65535)?
Instradamento: La Tabella di Routing punta a un IGW per le sottoreti pubbliche?
Firewall OS: Il firewall locale sull'istanza EC2 consente la connessione?

Esaminando sistematicamente queste sei aree, puoi risolvere con sicurezza la stragrande maggioranza dei fallimenti di connettività EC2.