Impossible de se connecter à l'instance RDS depuis l'extérieur du VPC (ERREUR 2003 (HY000) Impossible de se connecter au serveur MySQL)

J'ai créé un VPC, et à l'intérieur, une instance RDS. L'instance RDS est accessible au public et ses paramètres sont les suivants:

Paramètres RDS

Le groupe de sécurité attaché à l'instance RDS accepte tout le trafic:

Tous les ACL de mon réseau acceptent tout le trafic. Cependant, je ne peux pas accéder à mon instance à partir d'une machine en dehors de mon VPC. J'obtiens l'erreur suivante:

    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)

Si j'exécute la même commande à partir d'un EC2 à l'intérieur de mon VPC, je peux me connecter. J'ai essayé de me connecter à partir de plusieurs machines, toutes sans pare-feu (c'est-à-dire le port 3306 ouvert).

Il me manque évidemment quelque chose mais tout semble être configuré correctement. Quel pourrait être le problème?

Pour qu'une instance RDS dans un VPC soit accessible "publiquement" (Internet), tous les sous-réseaux auxquels elle est attachée doivent être des sous-réseaux "publics" - par opposition à "privés" du VPC.

Un sous-réseau public est essentiellement défini comme un sous-réseau qui a l'objet passerelle Internet (igw-xxxxxxxx) comme route vers «Internet», ou au moins vers toutes les destinations Internet auxquelles vous devez accéder. Il s'agit généralement d'une adresse de destination de 0.0.0.0/0. Les sous-réseaux publics doivent être utilisés pour les instances (y compris RDS) qui auront une adresse IP publique associée, et ne doivent pas être utilisées pour les instances qui n'ont pas d'adresse IP publique, car les adresses privées ne fonctionnent pas sur Internet sans traduction.

Un sous-réseau privé, en revanche, a sa table de routage configurée pour atteindre les destinations Internet via une autre instance EC2, généralement une instance NAT. Cela apparaît dans la table de routage VPC associée à ce sous-réseau en tant que i-xxxxxxxx, plutôt que «igw». Cette machine (qui, elle-même, sera en fait sur un sous-réseau différent de ceux pour lesquels elle agit comme une destination de route) sert de traducteur, permettant aux instances privées IP uniquement de faire de manière transparente des demandes Internet sortantes en utilisant le public de la machine NAT. IP pour leurs besoins Internet. Les instances avec une adresse IP publique ne peuvent pas interagir correctement avec Internet si elles sont attachées à un sous-réseau privé.

Dans le cas spécifique, ici, les sous-réseaux associés à l'instance RDS n'étaient pas vraiment configurés comme quelque chose qui pouvait être simplement classé comme un sous-réseau privé ou public, car le sous-réseau n'avait aucun itinéraire par défaut. L'ajout d'une route par défaut via l'objet «igw» ou, comme OP, l'ajout d'une route statique à l'adresse IP Internet où la connectivité était nécessaire, dans la table de routage VPC pour les sous-réseaux résout le problème de connectivité.

Cependant ... Si vous rencontrez un problème similaire, vous ne pouvez pas simplement modifier la table de routage ou créer de nouvelles tables de routage et leur associer les sous-réseaux, à moins que rien d'autre ne fonctionne déjà correctement sur les sous-réseaux, car la modification pourrait raisonnablement être devrait rompre la connectivité existante. Le cours correct, dans ce cas, serait de provisionner les instances sur différents sous-réseaux avec les entrées de table de routage correctes en place.

Lors de la configuration d'un VPC, il est idéal de définir clairement les rôles de sous-réseau et de fournir ensuite les itinéraires nécessaires lors de la première mise en service du VPC. Il est également important de se rappeler que le "LAN" VPC entier est un réseau défini par logiciel. Contrairement à un réseau physique, où le routeur peut devenir un goulot d'étranglement et il est souvent judicieux de placer des machines à fort trafic parmi elles sur le même sous-réseau ... le trafic traversant les sous-réseaux n'a aucun inconvénient en termes de performances sur VPC. Les machines doivent être placées sur des sous-réseaux appropriés aux besoins d'adressage IP de la machine - adresse publique, sous-réseau public; pas d'adresse publique, sous-réseau privé.

Plus de discussion sur la logistique des sous-réseaux privés / publics dans VPC peut être trouvée dans Pourquoi avons-nous besoin d'un sous-réseau privé dans VPC (à Stack Overflow).

Cela a déjà une excellente réponse, mais AWS crée un sous-réseau public pour vous lorsque vous choisissez l'option "accessible au public". Au contraire, pour moi, le problème était le groupe de sécurité VPC par défaut. Je regardais les règles du réseau ACL - pas le groupe de sécurité . (Le choix de l'option "accessible au public" dans RDS ajoute le groupe de sécurité mais n'ajoute pas automatiquement les règles entrantes.)

Cliquez sur RDS et identifiez et cliquez sur le groupe de sécurité. Ensuite, sous "règles entrantes", ajoutez le port 3306 et ajoutez votre adresse IPV4 de connexion, xxxx / 32 (ou 0.0.0.0/32 - si vous voulez que tout Internet se connecte - mais faites attention à cela).

Vérifiez également que le réseau auquel vous êtes connecté ne bloque pas les connexions à un autre serveur sur le port 3306. Ce fut le cas pour moi lorsque je suis connecté à mon réseau d'entreprise.