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é de l'instance RDS autorise l'accès depuis le groupe de sécurité auquel appartient votre serveur source (ou son adresse IP ajoutée directement si elle est externe à AWS). Le groupe de sécurité que vous devriez examiner est celui spécifié dans les attributs d'instance RDS de l'interface utilisateur de la console RDS (nommé "groupe de sécurité").
REMARQUE :Les groupes de sécurité de 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 la base de données" de l'interface utilisateur RDS. Pour les utilisateurs de 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é, de sorte qu'une recherche DNS externe à AWS renverra l'adresse IP publique tandis qu'une recherche interne à AWS renverra une adresse IP privée. Si vous pensez qu'il s'agit d'un problème DNS, avez-vous confirmé que différentes adresses IP sont renvoyées à partir de différentes zones de disponibilité ? Si différentes zones de disponibilité 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 tels que tracepath et traceroute ne vous 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'adresse IP de l'instance RDS et utilisez telnet ou nc (assurez-vous d'utiliser l'adresse IP interne/privée si vous vous connectez depuis AWS) :
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 contacter l'assistance AWS pour résoudre les problèmes plus avant. Si vous vous connectez depuis l'extérieur d'AWS, essayez d'abord de vous connecter depuis 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 chemin réseau différent. Vous pouvez le confirmer en exécutant netstat -an | grep SYN (à partir d'une session ssh différente en attendant que la commande telnet/nc expire).
Les connexions à l'état SYN signifient que vous avez envoyé une demande de connexion, mais que vous 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 abandonne des paquets.
Il peut également s'agir d'un problème de routage NAT ou de plusieurs chemins à partir de plusieurs interfaces. Vérifiez 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 depuis l'hôte source.
c) Si votre test de connexion socket a réussi, mais que vous ne pouvez pas vous connecter avec un client mysql (CLI, workbench, app, etc.), jetez un œil à la sortie de netstat pour voir dans quel état se trouve la connexion (remplacez x.x.x.x par le 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" lors de l'utilisation d'un client mysql, vous rencontrez peut-être un problème de MTU.
RDS, au moment où ceci 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 poser 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 de réduire 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 de MTU lorsque vous essayez de vous connecter à votre instance RDS. Cela peut se produire si les paquets TCP sont enveloppés avec une encapsulation pour le tunneling, ce qui entraîne une MTU utilisable inférieure pour les données de paquets/charge utile. La réduction de la MTU sur le serveur source permet aux paquets enveloppés de rester sous la limite de MTU tout en passant par la passerelle de tunneling.
Si cela ne fonctionne pas, rétablissez votre MTU à sa valeur par défaut et engagez l'assistance AWS pour un dépannage plus approfondi.
