
Antes de poder conectarme a mi instancia EC2, luego de vaciar IPTABLE, ya no puedo acceder a él, cada vez que intento conectarme, se agota el TIEMPO.
Error que recibo:
FAIL: TIMEOUT
[SSH] FAIL: xx.xx.xx.xx:2020 - No connection was made because the operation was stopped.
Problema que intentamos resolver antes de que suceda este problema.
No pude acceder a mi WHM a través de IP, pero tenía acceso a SSH, leí en alguna parte que necesitas vaciar IPTABLE, luego el problema comenzó a surgir y no pude acceder a SSH.
Pasos que he tomado (fallaron)
- Ya reinicié la instancia.
- Intento ver si la IP funciona en el navegador (probé Safari, Firfox, Chrome), el mismo tiempo de espera de IP en el navegador.
- He marcado el grupo de seguridad y permito el tráfico desde cualquier lugar en entrada y salida.
- Búsqueda en Google durante 2 días, no hay respuesta con la que pueda identificarme, porque necesito acceso a SSH, la mayoría de las respuestas son sobre la línea de comando.
- Cambie la IP de la instancia (sé que esto es realmente inútil).
- Intente comprender "Obtener registro del sistema", pero no pude entenderlo bien porque todo parece estar bien.
- Intente acceder mediante DNS público
- Cree un nuevo grupo de seguridad con conexión Open VPC
Información del servidor:
Centos 6
ejecutando WHM y cPanel
Algunas consideraciones que actualmente estoy pensando que podrían ser son (no hay información en línea sobre estas consideraciones en línea)
- Configuración de VPC del grupo de seguridad
- Error del lado de Amazon (lo dudo)
Respuesta1
te has sonrojadotodode sus reglas de iptables, incluidas las reglas PERMITIR predeterminadas. Deberá realizar una recuperación completa de estos sistemas para poder recuperar el acceso.
Si no ha guardado los cambios de las reglas de iptables en el disco, existe la posibilidad de que reiniciar resuelva el problema. Sin embargo, si ese no es el caso, deberá seguir el proceso que describo enesta respuestapara recuperar la instancia.
Además, si le preocupa perder el contenido de este servidor, está haciendo mal el administrador de sistemas. Deberíasiemprepoder perder un servidor sin una pérdida significativa de datos. Esto es válido tanto para los servidores VPS como para los servidores físicos.