Impossibile connettersi all'istanza RDS dall'esterno VPC (ERRORE 2003 (HY000) Impossibile connettersi al server MySQL)

Ho creato un VPC e al suo interno un'istanza RDS. L'istanza RDS è accessibile pubblicamente e le sue impostazioni sono le seguenti:

Impostazioni RDS

Il gruppo di sicurezza collegato all'istanza RDS accetta tutto il traffico:

Tutti i miei ACL di rete accettano tutto il traffico. Tuttavia, non riesco ad accedere alla mia istanza da una macchina esterna al mio VPC. Ottengo il seguente errore:

    root@vps151014:~# mysql -h mysql1.xxxxxxxxxxxx.eu-west-1.rds.amazonaws.com -P 3306 -u skullberry -p
Enter password: 
ERROR 2003 (HY000): Can't connect to MySQL server on 'mysql1.xxxxxxxxxxxx.eu-west-1.rds.amazonaws.com' (110)

Se eseguo lo stesso comando da un EC2 all'interno del mio VPC, sono in grado di connettermi. Ho provato a collegarmi da più macchine, tutte senza firewall (cioè porta 3306 aperta).

Mi manca ovviamente qualcosa, ma tutto sembra essere configurato correttamente. Quale potrebbe essere il problema?

Per un'istanza RDS in VPC accessibile "pubblicamente" (Internet), tutte le sottoreti alle quali è collegata devono essere "pubbliche" - anziché "private" - le sottoreti del VPC.

Una sottorete pubblica è essenzialmente definita come una sottorete che ha l'oggetto Internet Gateway (igw-xxxxxxxx) come rotta verso "Internet" o almeno verso qualsiasi destinazione Internet a cui è necessario accedere. In genere, questo è un indirizzo di destinazione di 0.0.0.0/0. Le sottoreti pubbliche devono essere utilizzate per istanze (incluso RDS) a cui sarà associato un indirizzo IP pubblico e non dovrebbero essere utilizzate per istanze che non dispongono di indirizzi IP pubblici, poiché gli indirizzi privati ​​non funzionano su Internet senza traduzione.

Una sottorete privata, al contrario, ha la sua tabella di routing configurata per raggiungere destinazioni Internet tramite un'altra istanza EC2, in genere un'istanza NAT. Ciò mostra nella tabella di route VPC associata a quella sottorete come i-xxxxxxxx, anziché "igw". Quella macchina (che, di per sé, si troverà effettivamente su una sottorete diversa da quelle per cui funge da destinazione del percorso) funge da traduttore, consentendo alle istanze solo IP private di effettuare in modo trasparente richieste Internet in uscita utilizzando il pubblico della macchina NAT IP per le loro esigenze in Internet. Le istanze con un indirizzo IP pubblico non possono interagire correttamente con Internet se collegate a una sottorete privata.

Nel caso specifico, qui, le sottoreti associate all'istanza RDS non erano realmente configurate come qualcosa che poteva essere semplicemente classificata come sottorete privata o pubblica, poiché la sottorete non aveva alcuna route predefinita. L'aggiunta di una route predefinita tramite l'oggetto "igw" o, come ha fatto OP, l'aggiunta di una route statica all'indirizzo IP Internet in cui era necessaria la connettività, nella tabella delle route VPC per le sottoreti risolve il problema di connettività.

Tuttavia ... Se si verifica un problema simile, non è possibile semplicemente modificare la tabella delle rotte o creare nuove tabelle delle rotte e associare le sottoreti a esse, a meno che non ci sia nient'altro che funzioni correttamente sulle sottoreti, perché la modifica potrebbe ragionevolmente dovrebbe interrompere la connettività esistente. La rotta corretta, in tal caso, sarebbe quella di eseguire il provisioning delle istanze su sottoreti diverse con le voci della tabella di instradamento corrette in atto.

Quando si configura un VPC, è ideale definire chiaramente i ruoli della sottorete e eseguire il provisioning completo con le route necessarie al primo avvio del VPC. È anche importante ricordare che l'intera "LAN" VPC è una rete definita dal software. A differenza di una rete fisica, in cui il router può diventare un collo di bottiglia ed è spesso sensato posizionare macchine con traffico intenso tra loro sulla stessa sottorete ... le sottoreti di attraversamento del traffico non presentano svantaggi in termini di prestazioni su VPC. Le macchine dovrebbero essere posizionate su sottoreti adeguate alle esigenze di indirizzamento IP della macchina: indirizzo pubblico, sottorete pubblica; nessun indirizzo pubblico, sottorete privata.

Ulteriori discussioni sulla logistica delle sottoreti private / pubbliche in VPC sono disponibili in Perché abbiamo bisogno della sottorete privata in VPC (in Stack Overflow).

Questa ha già un'ottima risposta, ma AWS crea una sottorete pubblica per te quando scegli l'opzione "accessibile pubblicamente". Piuttosto, per me il problema era il gruppo di sicurezza VPC predefinito. Stavo guardando le regole della rete ACL , non del gruppo di sicurezza . (La scelta dell'opzione "accessibile pubblicamente" in RDS aggiunge il gruppo di sicurezza ma non aggiunge automaticamente le regole in entrata.)

Fare clic su RDS, identificare e fare clic sul gruppo di sicurezza. Quindi sotto "regole in entrata" aggiungi la porta 3306 e aggiungi il tuo indirizzo IPV4 di connessione, xxxx / 32 (o 0.0.0.0/32 - se vuoi che l'intera Internet si connetta - ma fai attenzione).

Verifica inoltre che la rete a cui sei connesso non blocchi le connessioni a un altro server sulla porta 3306. Questo è stato il caso per me quando sono connesso alla mia rete aziendale.