No se puede conectar a la instancia de RDS desde fuera de VPC (ERROR 2003 (HY000) No se puede conectar al servidor MySQL)


12

He creado una VPC y dentro de ella una instancia de RDS. La instancia de RDS es de acceso público y su configuración es la siguiente:

Configuraciones RDS

El grupo de seguridad adjunto a la instancia de RDS acepta todo el tráfico:

Configuraciones de grupo de seguridad

Todas las ACL de mi red aceptan todo el tráfico. Sin embargo, no puedo acceder a mi instancia desde una máquina fuera de mi VPC. Obtuve el siguiente error:

    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 ejecuto el mismo comando desde un EC2 dentro de mi VPC, puedo conectarme. Intenté conectarme desde varias máquinas, todas ellas sin firewall (es decir, puerto 3306 abierto).

Obviamente me falta algo, pero todo parece estar configurado correctamente. ¿Cual podría ser el problema?


1
El (110)mensaje de error en el mensaje significa "conexión agotada", por lo que definitivamente se trata de un problema de conectividad IP. Su instancia de RDS muestra que está asociada con dos subredes. En la consola VPC, ¿cuál es la ruta predeterminada de esas dos subredes? ¿Es un "igw-xxxxxxxx" o es un "i-xxxxxxxx"?
Michael - sqlbot

Ambas subredes están implícitamente asociadas con la tabla de ruta principal de la VPC.
dazedviper

1
Asociar explícitamente ambas subredes a una tabla de ruta personalizada que enruta todo el tráfico saliente a la puerta de enlace de Internet de la VPC no hace ninguna diferencia.
dazedviper

1
Bueno, eso es un fastidio. La ruta predeterminada al "igw" parecía la pieza que faltaba más probable ... y en cualquier caso debería ser necesaria para que esto funcione. Suponiendo que le dio a la VPC suficiente tiempo para reconfigurarse en segundo plano después de cambiar las configuraciones de subred en consecuencia, no tengo ideas.
Michael - sqlbot

2
Ah, el bloque que necesitas para todas las direcciones IP es 0.0.0.0/0. Publicaré la respuesta.
Michael - sqlbot

Respuestas:


20

Para que una instancia de RDS en VPC sea accesible "públicamente" (Internet), todas las subredes a las que está conectada deben ser subredes "públicas", en lugar de "privadas".

Una subred pública se define esencialmente como una subred que tiene el objeto Puerta de enlace de Internet (igw-xxxxxxxx) como su ruta a "Internet", o al menos a cualquier destino de Internet al que necesite acceder. Por lo general, esta es una dirección de destino de 0.0.0.0/0. Las subredes públicas deben usarse para instancias (incluyendo RDS) que tendrán una dirección IP pública asociada, y no deben usarse para instancias que no tendrán direcciones IP públicas, ya que las direcciones privadas no funcionan en Internet sin traducción.

Una subred privada, por el contrario, tiene su tabla de enrutamiento configurada para llegar a destinos de Internet a través de otra instancia EC2, generalmente una instancia NAT. Esto se muestra en la tabla de rutas VPC asociada con esa subred como i-xxxxxxxx, en lugar de "igw". Esa máquina (que, en sí misma, estará en una subred diferente de la que actúa como destino de ruta) sirve como traductor, permitiendo que las instancias privadas de IP solo realicen de manera transparente las solicitudes salientes de Internet utilizando el público de la máquina NAT. IP para sus necesidades de Internet. Las instancias con una dirección IP pública no pueden interactuar adecuadamente con Internet si están conectadas a una subred privada.

En el caso específico, aquí, las subredes asociadas con la instancia de RDS no se configuraron realmente como algo que podría clasificarse simplemente como una subred privada o pública, porque la subred no tenía ninguna ruta predeterminada. Agregar una ruta predeterminada a través del objeto "igw" o, como lo hizo OP, agregar una ruta estática a la dirección IP de Internet donde se necesitaba conectividad, en la tabla de rutas VPC para las subredes soluciona el problema de conectividad.

Sin embargo ... Si experimenta un problema similar, no puede simplemente cambiar la tabla de ruta o construir nuevas tablas de ruta y asociar las subredes con ellas, a menos que ya no tenga nada más funcionando correctamente en las subredes, porque el cambio podría razonablemente ser Se espera que rompa la conectividad existente. El curso correcto, en ese caso, sería aprovisionar las instancias en diferentes subredes con las entradas correctas de la tabla de rutas en su lugar.

Al configurar una VPC, es ideal definir claramente los roles de subred y aprovisionar completamente las rutas necesarias cuando se comisiona la VPC por primera vez. También es importante recordar que toda la "LAN" de VPC es una red definida por software. A diferencia de una red física, donde el enrutador puede convertirse en un cuello de botella y, a menudo, es razonable colocar máquinas con mucho tráfico entre ellas en la misma subred ... el tráfico que cruza las subredes no tiene ninguna desventaja de rendimiento en VPC. Las máquinas deben colocarse en subredes que sean apropiadas para las necesidades de direccionamiento IP de la máquina: dirección pública, subred pública; sin dirección pública, subred privada.

Puede encontrar más información sobre la logística de las subredes privadas / públicas en VPC en Por qué necesitamos una subred privada en VPC (en Stack Overflow).


2

Esto ya tiene una gran respuesta, pero AWS crea una subred pública para usted cuando elige la opción "públicamente accesible". Más bien, para mí, el problema era el grupo de seguridad VPC predeterminado. Estaba mirando las reglas de ACL de red , no el Grupo de seguridad . (Al elegir la opción de "acceso público" en RDS, se agrega el grupo de seguridad, pero no se agregan automáticamente las reglas de entrada).

Haga clic en RDS e identifique y haga clic en el grupo de seguridad. Luego, en "reglas de entrada", agregue el puerto 3306 y agregue su dirección IPV4 de conexión, xxxx / 32 (o 0.0.0.0/32, si desea que se conecte todo Internet, pero tenga cuidado con eso).


0

También verifique para asegurarse de que la red a la que está conectado no esté bloqueando las conexiones a otro servidor en el puerto 3306. Este fue mi caso cuando me conecté a mi red corporativa.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.