Impossible de se connecter à l'instance RDS à partir de l'instance EC2
Depuis l'instance EC2 i-78a8df00, j'essaie de me connecter à l'instance RDS mysql. ************. Us-east-1.rds.amazonaws.com. Ils sont tous deux dans la région Est des États-Unis. J'ai ajouté le groupe de sécurité de l'instance EC2 (sg - ********) au groupe de sécurité RDS, mais cela n'a pas aidé. Il semble s'agir d'un problème de pare-feu/DNS car il arrive à expiration lors de l'exécution de cette commande:
ubuntu@ip-10-195-189-237:~$ mysql -h mysql.************.us-east-1.rds.amazonaws.com
ERREUR 2003 (HY000): impossible de se connecter au serveur MySQL sur 'mysql. ************. Us-east-1.rds.amazonaws.com' (110)
Je peux me connecter correctement à l'instance RDS à partir de ma machine locale en utilisant la même ligne que ci-dessus. J'ai essayé diverses solutions de forum, mais celles-ci n'aident pas.
On dirait qu'entre la dernière publication et cette publication, Amazon a résolu le problème de routage DNS, car tout fonctionne bien maintenant pour les rds multi-AZ ...
J'ai rencontré un problème similaire lorsque j'ai créé une nouvelle instance EC2, mais je n'ai pas modifié le paramètre du groupe de sécurité RDS de l'adresse IP entrante autorisée à se connecter au port 3306 de mon instance RDS.
Le bit déroutant était une option du tableau de bord RDS, appelé groupes de sécurité. Vous n'en avez pas besoin pour résoudre le problème.
Ce dont vous avez vraiment besoin est d'aller dans la liste des instances RDS, cliquez sur l'instance que vous essayez de vous connecter, puis cliquez sur l'onglet du milieu, recherchez Sécurité et réseau et cliquez sur le nom du groupe de sécurité.
Cela devrait ouvrir un nouvel onglet ou une nouvelle fenêtre de navigateur avec les détails du groupe de sécurité. Localisez plusieurs onglets dans la partie inférieure, sélectionnez l'onglet Entrant et cliquez sur le bouton Modifier .
Remplacez la valeur par l'adresse IP de votre instance EC2 ou des blocs CIDR IPv4, par ex.
174.33.0.0/16
Pour obtenir cette valeur, vous pouvez soit ssh dans votre instance et exécuter ifconfig ou exécuter EC2 Manager dans le navigateur et localiser la valeur de IP privées dans les détails de votre instance.
Informations supplémentaires pour les personnes susceptibles de rencontrer des problèmes similaires en essayant de se connecter à RDS ou RedShift:
1) Vérifiez les groupes de sécurité
Vérifiez que le groupe de sécurité pour l'instance RDS autorise l'accès à partir du groupe de sécurité auquel votre serveur source appartient (ou son adresse IP ajoutée directement si elle est externe à AWS). Le groupe de sécurité que vous devez examiner est celui spécifié dans les attributs d'instance RDS de l'interface utilisateur de la console RDS (nommé "groupe de sécurité").
[~ # ~] note [~ # ~] : les groupes de sécurité de la base de données peuvent être différents des groupes de sécurité AWS EC2. Si votre instance RDS est dans EC2 classique/public, vous devez vérifier dans la section "groupe de sécurité de base de données" de l'interface utilisateur RDS. Pour les utilisateurs VPC, le groupe de sécurité sera un groupe de sécurité VPC normal (le nom sg-xxx sera répertorié dans les attributs de l'instance RDS).
2) Confirmez que le DNS n'est pas un problème.
Amazon utilise un DNS fractionné, donc une recherche DNS externe à AWS renverra l'IP publique tandis qu'une recherche interne à AWS renverra une IP privée. Si vous pensez qu'il s'agit d'un problème DNS, avez-vous confirmé que différentes IP sont renvoyées depuis différentes zones de disponibilité? Si différents AZ obtiennent des adresses IP différentes, vous devrez contacter le support AWS.
3) Confirmez la connectivité réseau en établissant une connexion socket.
Des outils comme tracepath et traceroute n'aideront probablement pas, car RDS supprime actuellement le trafic ICMP.
Testez la connectivité du port en essayant d'établir une connexion socket à l'instance RDS sur le port 3306 (mysql ou 5432 pour postgres). Commencez par trouver l'IP de l'instance RDS et utilisez telnet ou nc:
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a) Si votre tentative de connexion échoue et échoue immédiatement, le port est probablement bloqué ou l'hôte distant n'exécute pas de service sur ce port . vous devrez peut-être engager le support AWS pour dépanner davantage. Si vous vous connectez depuis l'extérieur d'AWS, essayez d'abord de vous connecter à partir d'une autre instance à l'intérieur d'AWS (car votre pare-feu peut bloquer ces connexions).
b) Si votre connexion échoue et que vous obtenez un délai d'attente, les paquets sont probablement abandonnés/ignorés par un pare-feu ou les paquets reviennent sur un autre chemin réseau. Vous pouvez le confirmer en exécutant netstat -an | grep SYN (à partir d'une fenêtre/session CLI différente pendant l'exécution et l'attente de l'expiration de la commande telnet/nc). Les connexions à l'état SYN signifient que vous avez envoyé une demande de connexion, mais n'avez rien reçu en retour (SYN_ACK ou rejet/blocage). Cela signifie généralement qu'un pare-feu ou un groupe de sécurité ignore ou supprime des paquets.
Assurez-vous que vous n'utilisez pas iptables ou une passerelle NAT entre votre hôte et l'instance RDS. Si vous êtes dans un VPC, assurez-vous également d'autoriser le trafic sortant/sortant du hôte source.
c) Si votre test de connexion de socket a réussi, mais que vous ne pouvez pas vous connecter avec un client mysql (CLI, plan de travail, application, etc.), prenez un coup d'oeil à la sortie de netstat pour voir dans quel état est la connexion (remplacez xxxx par l'adresse IP réelle de l'instance RDS):
netstat -an | grep x.x.x.x
Si vous obteniez une connexion établie lors de l'utilisation de telnet ou NC, mais que vous voyez l'état "SYN" lorsque vous utilisez un client mysql, vous rencontrez peut-être un problème MTU.
RDS, au moment où cela est écrit, peut ne pas prendre en charge les paquets ICMP utilisés pour PMTUD ( https://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ). Cela peut être un problème si vous essayez d'accéder à RDS ou RedShift qui se trouve dans un VPC à partir d'une instance ec2 classique via ClassicLink. Essayez d'abaisser le MTU avec ce qui suit, puis testez à nouveau:
Sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
Sudo ip link set dev eth0 mtu 1400
Si le MTU inférieur a fonctionné, assurez-vous de contacter le support client AWS pour obtenir de l'aide et mentionnez que vous rencontrez un problème MTU lorsque vous essayez de vous connecter à votre instance RDS. Cela peut se produire si TCP sont encapsulés avec l'encapsulation pour la tunnellisation, ce qui entraîne une MTU utilisable inférieure pour les données de paquets/charge utile. L'abaissement de la MTU sur le serveur source permet aux paquets encapsulés de rester sous le limite.
Si cela ne fonctionne pas, réinitialisez votre MTU à sa valeur par défaut et engagez le support AWS pour un dépannage supplémentaire.
Alors que le problème de Mark semblait avoir quelque chose à voir avec le routage multi-AZ et EC2 classique, je suis tombé sur ce même problème aujourd'hui.
Pour y remédier, j'ai modifié le groupe de sécurité qui a été créé automatiquement avec mon instance RDS en ajoutant les deux adresses IP privées de mon instance EC2.
C'était un problème assez évident, mais je suis nouveau dans AWS en général, donc j'espère que cela sera utile pour d'autres comme moi.
Apparemment, le multi-AZ bousille tout. Étant donné que la configuration multi-AZ par défaut a placé ma base de données dans la région us-east-1d et que mon instance EC2 était dans la région us-east-1a, le DNS ne routait pas correctement. J'ai recréé l'instance RDS en tant que non multi-AZ, et l'ai fait vivre dans us-east-1a, et tout est heureux.
S'il y a des super génies en ce qui concerne le routage DNS sur AWS avec des capacités RDS, ELB et multi-AZ, il serait assez génial de savoir comment faire, car cela n'est documenté nulle part dans la documentation d'Amazon Web Service .
J'ai eu le même problème aujourd'hui lorsque mon instance EC2 a soudainement perdu l'accès à l'instance RDS et Wordpress a cessé de fonctionner. Les groupes de sécurité étaient corrects et je pouvais même me connecter à MySQL depuis la console sur l'instance EC2 mais pas depuis PHP Pour une raison quelconque, le redémarrage du serveur EC2 m'a aidé.