Risoluzione dei problemi comuni di connettività delle istanze EC2 e degli errori

Quando una connessione EC2 fallisce, la prima domanda utile è se l'istanza è irraggiungibile, rifiuta l'autenticazione o è raggiungibile solo attraverso il percorso sbagliato. Che tu stia usando SSH per le istanze Linux o Remote Desktop Protocol (RDP) per le istanze Windows, i problemi di connettività sono comuni e spesso frustranti. Gli errori SSH e RDP tendono a confondersi, ma Permission denied, Connection timed out, Connection refused e una schermata RDP vuota puntano a livelli diversi. Tratta il testo dell'errore come un indizio, poi lavora dall'esterno verso l'interno.

Fase 1: Controlli iniziali e stato dell'istanza

Prima di addentrarti in configurazioni di rete complesse, assicurati che l'istanza sia in esecuzione correttamente e raggiungibile a un livello fondamentale.

1. Controlli dello stato dell'istanza

Usa la console di gestione AWS o la CLI AWS per verificare lo stato generale dell'istanza. Due controlli cruciali devono essere superati:

Controlli dello stato del sistema: I fallimenti qui indicano solitamente problemi hardware o infrastrutturali sottostanti che richiedono l'intervento AWS o la terminazione/ricreazione dell'istanza.
Controlli dello stato dell'istanza: I fallimenti qui spesso riguardano problemi di avvio del sistema operativo, corruzione del file system o problemi di driver. Se questo fallisce, è probabile che l'istanza non sia in salute sufficiente per accettare connessioni di rete.

Azione: Se uno dei due controlli fallisce, considera di fermare e avviare l'istanza (che la sposta su nuovo hardware se il controllo del sistema fallisce) o di controllare il registro di sistema per indizi.

2. Verifica dell'indirizzo IP pubblico e del nome DNS

Assicurati di tentare di connetterti all'indirizzo corretto. Se la tua istanza deve essere raggiunta direttamente da Internet, ha bisogno di un Indirizzo IPv4 pubblico o di un IP elastico e di una route di subnet pubblica attraverso un gateway Internet. Se si trova in una subnet privata, devi connetterti tramite un Bastion Host o utilizzare AWS Systems Manager Session Manager.

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

3. Controllo della configurazione del client (SSH/RDP)

Gli errori di connettività sono talvolta locali. Verifica che il tuo software client funzioni correttamente.

Per SSH (Linux/macOS): Assicurati di utilizzare il file della chiave privata corretta (.pem o .ppk) e che i permessi siano impostati correttamente (chmod 400 /path/to/key.pem).
Per RDP (Windows): Assicurati di utilizzare la password corretta ottenuta decifrando 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 configurazioni di sicurezza errate sono la causa principale dei problemi di connettività. Sia i gruppi di sicurezza che le ACL di rete agiscono come firewall, ed entrambi devono consentire il traffico necessario.

4. Regole di ingresso del gruppo di sicurezza (SG)

I gruppi di sicurezza sono firewall stateful collegati direttamente all'interfaccia di rete elastica (ENI) dell'istanza.

Requisiti Linux (SSH):

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

Requisiti Windows (RDP):

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

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

Avvertenza: Non lasciare mai i gruppi di sicurezza aperti a 0.0.0.0/0 per le porte di gestione (22/3389) in ambienti di produzione. Usa indirizzi IP di origine specifici o endpoint VPC dove possibile.

5. ACL di rete (NACL)

Le ACL di rete sono firewall stateless a livello di subnet. Controllano il traffico in entrata e 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 di porte	Azione regola
In entrata	TCP	22 (SSH) o 3389 (RDP)	Consenti
In uscita	TCP	Porte effimere (1024-65535)	Consenti

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

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

Fase 3: Routing e configurazione VPC

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

6. Tipo di subnet e tabelle di routing

La connettività dipende interamente dal fatto che la tua istanza si trovi in una Subnet pubblica o in una Subnet privata.

Connettività della subnet 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 route per 0.0.0.0/0 che punti a un Gateway Internet (IGW).

Connettività della subnet privata

Le istanze nelle subnet private non possono essere raggiunte direttamente da Internet. La connessione richiede un percorso multi-hop:

Connessione tramite Bastion Host (Jump Box): Ti connetti tramite SSH a un'istanza EC2 pubblica, e poi tramite SSH dal Bastion Host all'istanza privata (usando il suo IP privato).
Connessione tramite VPN/Direct Connect: Se utilizzi AWS Site-to-Site VPN o Direct Connect, il routing deve essere configurato per dirigere il traffico verso la tua rete on-premise, che poi instrada verso la subnet privata.

7. Problemi del firewall a livello di sistema operativo

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

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 per il ripristino: Se hai perso tutta la connettività, considera di fermare l'istanza, scollegare il volume root, collegarlo a un'istanza di ripristino funzionante, modificare i file di configurazione del sistema operativo per disabilitare il firewall, e poi ricollegare il volume all'ID dell'istanza originale.

Opzioni di connessione pubbliche, private e gestite

Non dare per scontato che ogni istanza EC2 debba accettare SSH o RDP da Internet. Le istanze pubbliche necessitano di un indirizzo pubblico, una route verso un gateway Internet, controlli di sicurezza permissivi e un listener in esecuzione. Le istanze private di solito necessitano di un metodo di accesso diverso: un bastion host, VPN, Direct Connect, EC2 Instance Connect Endpoint o Systems Manager Session Manager.

Session Manager è particolarmente utile per i team operativi perché può eliminare la necessità di SSH in entrata. L'istanza necessita dell'agente SSM, di un profilo dell'istanza IAM con i permessi corretti di Systems Manager e dell'accesso di rete agli endpoint SSM. Nelle subnet private, ciò di solito significa endpoint dell'interfaccia VPC o Internet in uscita attraverso un percorso NAT. Se manca uno di questi elementi, Session Manager non apparirà come opzione anche se l'istanza stessa è sana.

Per un design con bastion, testa entrambe le tratte. Prima connettiti dalla tua workstation al bastion. Poi connettiti dal bastion all'IP privato dell'istanza di destinazione. Il gruppo di sicurezza dell'istanza di destinazione dovrebbe di solito consentire SSH solo dal gruppo di sicurezza del bastion, non dal tuo IP di casa e non dall'intero CIDR VPC a meno che tu non abbia un motivo.

Per RDP, ricorda che l'avvio di Windows può richiedere più tempo dell'avvio di SSH su Linux, specialmente dopo l'applicazione di patch o il primo avvio. Se i controlli dello stato dell'istanza sono appena stati superati ma RDP fallisce ancora, controlla il registro di sistema e attendi qualche minuto prima di modificare le regole del firewall. Sostituire ripetutamente i gruppi di sicurezza può nascondere il problema reale di avvio o di servizio.

Test rapidi dalla tua workstation

Usa piccoli test di rete prima di modificare le risorse AWS. Da Linux o macOS, nc -vz <ip-pubblico> 22 verifica se la porta TCP 22 si completa. Per RDP, usa nc -vz <ip-pubblico> 3389 o uno strumento di test delle porte da Windows. Un timeout punta verso routing, gruppi di sicurezza, NACL o un firewall a monte. Una connessione rifiutata punta più verso il sistema operativo o il servizio dell'istanza.

Se è coinvolto il DNS, risolvilo esplicitamente:

dig +short ec2-203-0-113-10.compute-1.amazonaws.com

Poi confronta il risultato con l'IP pubblico corrente nella console EC2. Gli IP elastici rimangono stabili, ma gli IP pubblici assegnati automaticamente possono cambiare dopo stop/start. Questa è una causa semplice di runbook interrotti e profili RDP salvati.

Se usi una VPN aziendale, testa da un'altra rete prima di modificare il VPC. Alcune reti aziendali bloccano SSH o RDP in uscita, e alcuni router domestici o ISP interferiscono con porte non comuni. Una connessione riuscita da una rete diversa ti dice che l'istanza potrebbe essere a posto.

VPC Reachability Analyzer vale la pena usarlo quando il percorso non è ovvio. Può modellare un percorso tra una sorgente e una destinazione e indicare dove il routing o il filtraggio blocca il traffico. Non risolverà una chiave SSH errata o un servizio fermo all'interno del sistema operativo guest, ma è utile per separare i problemi di progettazione della rete AWS dai problemi del sistema operativo.

Anche i log dei flussi possono aiutare, specialmente quando si sospettano NACL o gruppi di sicurezza. Un flusso rifiutato dal tuo IP client verso la porta 22 o 3389 ti dice che il pacchetto ha raggiunto un'interfaccia di rete o subnet monitorata ed è stato negato. Nessun flusso può significare che il traffico non ha mai raggiunto il VPC, l'indirizzo è sbagliato, o stai guardando l'ENI, la subnet o la finestra temporale sbagliata.

Mantieni un piccolo runbook di accesso per ogni ambiente: intervalli di IP di origine approvati, nome del bastion, requisiti SSM, nomi utente predefiniti per AMI e la procedura dell'istanza di ripristino. Gli incidenti di connettività diventano più lenti quando ogni ingegnere deve riscoprire questi dettagli dalla console.

Registra anche quali subnet sono intenzionalmente private. Quella singola nota previene un sacco di debug sprecato quando qualcuno cerca di connettersi direttamente tramite SSH a un'istanza che non è mai stata progettata per avere un percorso Internet.

Leggere il messaggio di errore

Connection timed out di solito significa che i pacchetti non stanno completando il viaggio. Controlla IP pubblico, tabella di routing, gateway Internet, origine del gruppo di sicurezza, regole NACL, firewall aziendale e se stai tentando di raggiungere direttamente una subnet privata.

Connection refused di solito significa che il percorso di rete ha raggiunto l'istanza, ma nulla è in ascolto su quella porta o il sistema operativo l'ha rifiutata. Su Linux, controlla se sshd è in esecuzione e in ascolto sulla porta 22. Su Windows, controlla se RDP è abilitato e il servizio Desktop remoto è in esecuzione.

Permission denied (publickey) non è un problema VPC. Di solito significa nome utente sbagliato, chiave privata sbagliata, chiave pubblica mancante in authorized_keys, permessi della directory home modificati o una mancata corrispondenza del nome utente AMI come l'uso di ec2-user per un'immagine Ubuntu invece di ubuntu.

Per Windows RDP, i fallimenti di autenticazione spesso derivano dall'uso di una vecchia password dell'amministratore decifrata dopo che l'istanza è stata sostituita, dalla connessione all'IP pubblico sbagliato dopo uno stop/start o da criteri di dominio che sovrascrivono i diritti di accesso locali.

Percorsi di ripristino quando non puoi accedere

Se l'istanza ha l'agente Systems Manager installato, un profilo dell'istanza con permessi SSM e accesso di rete agli endpoint SSM o a Internet, Session Manager è di solito il percorso di ripristino meno invasivo. Puoi ispezionare i log, correggere le regole del firewall o riparare authorized_keys senza aprire SSH al mondo.

Se SSM non è disponibile, usa la console seriale EC2 dove supportata, o scollega il volume root e collegalo a un'istanza di ripristino nella stessa zona di disponibilità. Montalo con attenzione, correggi la configurazione di rete o SSH, smontalo e ricollegalo all'istanza originale. Fai prima uno snapshot in modo che un tentativo di riparazione non peggiori il ripristino.

Quando la connettività fallisce, segui questa checklist prioritaria: stato dell'istanza, indirizzo corretto, nome utente/chiave o password RDP corretti, gruppo di sicurezza, NACL, tabella di routing, firewall del sistema operativo e stato del servizio. Questo ordine ti impedisce di modificare cinque controlli AWS quando il problema reale è una chiave obsoleta o una route mancante.