Información adicional para las personas que puedan tener problemas similares al intentar conectarse a RDS o RedShift:
1) Comprobar grupos de seguridad
Verifique que el grupo de seguridad para la instancia de RDS permita el acceso desde el grupo de seguridad al que pertenece su servidor de origen (o su IP agregada directamente si es externo a AWS). El grupo de seguridad que debe observar es el especificado en los atributos de la instancia de RDS de la interfaz de usuario de la consola de RDS (denominado "grupo de seguridad").
NOTA :los grupos de seguridad de la base de datos pueden ser diferentes de los grupos de seguridad de AWS EC2. Si su instancia de RDS está en EC2 clásico/público, debe consultar la sección "grupo de seguridad de la base de datos" de la interfaz de usuario de RDS. Para los usuarios de VPC, el grupo de seguridad será un grupo de seguridad de VPC normal (el nombre sg-xxx aparecerá en los atributos de la instancia de RDS).
2) Confirme que el DNS no es un problema.
Amazon utiliza DNS dividido, por lo que una búsqueda de DNS externa a AWS devolverá la IP pública, mientras que una búsqueda interna a AWS devolverá una IP privada. Si sospecha que se trata de un problema de DNS, ¿ha confirmado que se devuelven diferentes direcciones IP desde diferentes zonas de disponibilidad? Si diferentes AZ obtienen diferentes IP, deberá ponerse en contacto con el soporte de AWS.
3) Confirme la conectividad de la red estableciendo una conexión de socket.
Es probable que herramientas como tracepath y traceroute no ayuden, ya que RDS actualmente descarta el tráfico ICMP.
Pruebe la conectividad del puerto intentando establecer una conexión de socket a la instancia de RDS en el puerto 3306 (mysql o 5432 para postgres). Comience por encontrar la IP de la instancia de RDS y use telnet o nc (asegúrese de usar la IP interna/privada si se conecta desde AWS):
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a) Si su intento de conexión no tiene éxito y falla de inmediato, es probable que el puerto esté bloqueado o que el host remoto no esté ejecutando un servicio en ese puerto. es posible que deba contratar el soporte de AWS para solucionar más problemas. Si se conecta desde fuera de AWS, primero intente conectarse desde otra instancia dentro de AWS (ya que su firewall podría estar bloqueando esas conexiones).
b) Si su conexión no es exitosa y obtiene un tiempo de espera, es probable que un cortafuegos esté descartando/ignorando los paquetes o que los paquetes regresen a una ruta de red diferente. Puede confirmar esto ejecutando netstat -an | grep SYN (desde una sesión ssh diferente mientras se espera que se agote el tiempo de espera del comando telnet/nc).
Las conexiones en el estado SYN significan que ha enviado una solicitud de conexión, pero no ha recibido nada (SYN_ACK o rechazo/bloqueo). Por lo general, esto significa que un firewall o un grupo de seguridad está ignorando o descartando paquetes.
También puede ser un problema con el enrutamiento NAT o múltiples rutas desde múltiples interfaces. Verifique que no esté usando iptables o una puerta de enlace NAT entre su host y la instancia de RDS. Si está en una VPC, también asegúrese de permitir el tráfico de salida/saliente desde el host de origen.
netstat -an | grep x.x.x.x
Si estaba estableciendo una conexión cuando usaba telnet o NC, pero ve el estado 'SYN' cuando usa un cliente mysql, es posible que tenga un problema de MTU.
Es posible que RDS, en el momento de escribir esto, no admita los paquetes ICMP utilizados para PMTUD (https:/ /en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ). Esto puede ser un problema si intenta acceder a RDS o RedShift que está en una VPC desde una instancia ec2 clásica a través de ClassicLink. Intente reducir la MTU con lo siguiente y vuelva a probar:
sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400
Si la MTU más baja funcionó, asegúrese de hacer un seguimiento con el servicio de atención al cliente de AWS para obtener ayuda y mencionar que está viendo un problema de MTU al intentar conectarse a su instancia de RDS. Esto puede suceder si los paquetes TCP se encapsulan para la tunelización, lo que da como resultado una MTU utilizable más baja para los datos/la carga del paquete. Reducir la MTU en el servidor de origen permite que los paquetes envueltos aún queden por debajo del límite de MTU mientras pasan a través de la puerta de enlace de tunelización.
Si no funcionó, restablezca su MTU a su valor predeterminado y contacte con el soporte de AWS para solucionar más problemas.
