Las instancias EC2 no pueden comunicarse entre sí

Las instancias EC2 no pueden comunicarse entre sí

Creé dos instancias EC2 en la misma zona de disponibilidad y en la misma cuenta. Utilizan diferentes grupos de seguridad. Me gustaría que la instancia A acepte conexiones en un puerto determinado únicamente desde la instancia B.

No creo que estas instancias sean VPC, pero no sé cómo confirmarlas. No pude cambiar el grupo de seguridad, lo que me hace pensar que no son VPC.

En el grupo de seguridad, por ejemplo, AI agregó una regla para el puerto y usó la IP pública /32 de la instancia B para la fuente. Luego intenté conectarme desde la instancia B usando la IP pública de la instancia A, pero el intento de conexión falla inmediatamente.

Intenté los mismos pasos con la IP privada de cada instancia. ¿Qué me estoy perdiendo?

Aquí hay un artículo que responde a una pregunta similar, pero VPC está involucrada:No se puede conectar a la instancia EC2 en VPC (Amazon AWS).

Ambas instancias tienen el mismo ID de VPC y ID de subred.

También intenté configurar la fuente en el grupo de seguridad de la instancia B, lo que tampoco funcionó.

Estoy intentando esto con mysql. El cliente MySQL que se ejecuta en la instancia B falló inmediatamente con este error:

ERROR 2003 (HY000): No se puede conectar al servidor MySQL en '54.xx.xx.xx' (113)

Para comprobar que no había ningún problema con la configuración de mysqld, intenté lo mismo con ICMP Echo Reply, que tampoco funcionó.

Editar Gracias a las respuestas iniciales pude confirmar que estas dos instancias se están ejecutando en una VPC (yendo a la consola de la VPC). Entonces, mi pregunta es muy similar al artículo vinculado. Pero, en ese caso, el problema era que las instancias no eran instancias predeterminadas, por lo que no se había creado la ruta ni la subred adecuadas. Así es como está configurada mi VPC: La VPC es predeterminada y tiene una tabla de rutas asociada. La tabla de rutas está asociada implícitamente a la subred asociada a la VPC. La tabla de rutas tiene una única ruta y el objetivo es "local".

Todos estos se crean de forma predeterminada, según tengo entendido, los documentos deberían permitir que dos instancias se conecten entre sí. ¿Qué me (todavía) me falta?

Respuesta1

Resolví esto con la ayuda del soporte técnico de AWS. Aquí está la información para futuros novatos como yo:

El problema era que iptables se estaba ejecutando en la instancia B y no permitía tráfico. Aprendí que existen dos niveles de firewall para instancias EC2: grupos de seguridad (administrados en la consola de AWS) e iptables (administrados en el host). Hay razones para usar iptables, por ejemplo https://wincent.com/wiki/Using_iptables_on_EC2_instances

La mayoría de las veces no necesita preocuparse por el uso de un firewall a nivel de host como iptables cuando ejecuta Amazon EC2, porque Amazon le permite ejecutar instancias dentro de un "grupo de seguridad", que es efectivamente una política de firewall que puede utilizar para especifique qué conexiones del mundo exterior deben poder llegar a la instancia. Sin embargo, este es un enfoque de "lista blanca" y no es sencillo utilizarlo para fines de "lista negra" en una instancia en ejecución.

En mi caso, no necesito un firewall a nivel de host, así que desactivé iptables:

sudo service chkconfig stop
sudo chkconfig iptables off

Aquí hay algunos resultados que obtuve relacionados con los comentarios publicados sobre esta pregunta:

  • conectar con ip privada funcionó
  • la conexión con el nombre DNS privado funcionó
  • conectarse con ip pública funcionó
  • la conexión con el EIP público funcionó
  • conectarse con DNS público funcionó, pero como dijo Chad Smith en su respuesta, DNS devuelve elprivadoIP para este nombre

La razón por la que esto funcionó para mí en una instancia diferente es que la imagen que usé en esa instancia no ejecutaba iptables: cada imagen es diferente. La imagen que utilicé en este caso usó iptables para no permitir todas las conexiones excepto SSH.

Respuesta2

Un poco fuera de tema, pero este es el único resultado de búsqueda para este problema.

Tuvimos un problema similar, pero nuestras instancias existentes se reiniciaron y de repente no pudimos comunicarnos. Resulta que había demasiadas reglas en el grupo de seguridad: simplemente eliminar algunas comunicaciones permitidas para reanudarlas. Todavía funcionaba antes del reinicio porque las reglas se agregan con el tiempo mediante llamadas automáticas a la API.

Espero que esto ayude a alguien en el futuro.

Respuesta3

Si no puede modificar la configuración de seguridad de las instancias en ejecución, NO se inician en una VPC.

Incluso en los casos que no están en VPC, EC2 los lanza a redes privadas que están interconectadas. Entonces deberías especificar eldirección IP privadade la instancia B en el grupo de seguridad de la instancia A.

Respuesta4

AWS tiene grupos de seguridad separados para instancias de VPC y no VPC, por lo que necesita saber de alguna manera si está en VPC o no (simplemente vaya a la consola de VPC y verifique si ve sus instancias allí) y luego asegúrese de que tenga grupos de seguridad. creados están en el mismo contexto. Luego puede simplemente agregar el grupo de seguridad A al grupo de seguridad B como confiable y hacer lo contrario también. De esta manera, simplemente permite todo el tráfico entre dos hosts en puertos individuales (supongo que esta era su intención).

información relacionada