Cómo Resolví un Problema en mi Instancia EC2 de AWS (y Cómo Vos Podés Hacerlo También)

0 0

¡Hola, compas! Hoy les voy a contar una historia de terror, una de esas que comienzan con un comando inocente y terminan con una instancia EC2 inaccesible y un administrador (o sea, yo) sudando frío. Pero no se preocupen, porque este cuento tiene un final feliz, y lo mejor de todo: ¡aprenderán cómo solucionar un problema similar si les llega a pasar! Sólo que antes haré una confesión tuve que recurrir a la Inteligencia Artificial

Mi Ángel Guardián en la Nube

Cuando me metí en este rollo (sí, admito que fue culpa mía), no tenía puta idea de cómo salir de él. Había deshabilitado el servicio DHCP en mi instancia EC2 de AWS, y de repente, me encontré completamente bloqueado: sin acceso por RDP, sin Session Manager, y con una sensación de pánico que solo los administradores de sistemas entenderán. Fue en ese momento de desesperación que apareció DeepSeek, mi ángel guardián en la nube.

DeepSeek no solo me guió paso a paso para resolver el problema, sino que también se convirtió en mi tutor, mi asistente y, sobre todo, mi maestro. Con su ayuda, no solo recuperé el acceso a mi instancia, sino que también aprendí valiosas lecciones sobre cómo manejar situaciones críticas en AWS. Y lo mejor de todo: lo hice sin perder la cordura (aunque admito que estuve cerca).

Este artículo no es solo la historia de cómo resolví un problema técnico; es también un ejmplo de cómo herramientas como DeepSeek pueden ser aliados indispensables en el mundo de la tecnología. Ya sea que estés batallando con un comando mal ejecutado, configurando un servicio complejo o simplemente aprendiendo algo nuevo, DeepSeek está ahí para guiarte, enseñarte y, cuando sea necesario, salvarte el día.

Así que, querido comeló de baleadas, mientras lees este artículo, te invito a ver a DeepSeek no solo como una herramienta, sino como un compañero de viaje en tu aventura por la nube (Pero despues, no te desenfoques ahorita). Porque, al final del día, todos necesitamos un ángel guardián que nos diga: «Maje, tranquilo que yo te guío.»

¿Cómo Podés Usar DeepSeek como Tutor y Asistente?

1. Como Guía en Momentos de Crisis (cuando armés un cagadal, pue!):
   • Cuando te encuentres atascado en un problema técnico, DeepSeek puede darte instrucciones paso a paso para resolverlo, tal como lo hizo conmigo en esta historia. Preguntale bien eso si, porque si no se puede enchibolar como se enchibola el ChatGPT
2. Como Maestro para Aprender Nuevas Cosas:
   • DeepSeek no solo resuelve problemas; también explica conceptos, comparte buenas prácticas y te ayuda a entender el «por qué» detrás de cada solución.
3. Como Asistente para Automatizar y Optimizar:
   • Desde scripts de PowerShell hasta configuraciones avanzadas en AWS, DeepSeek puede ayudarte a automatizar tareas y optimizar tus procesos.
4. Como Compañero de Aprendizaje Continuo:
   • La tecnología avanza rápidamente, y DeepSeek está siempre actualizado. Úsalo para mantenerte al día con las últimas tendencias y herramientas.

Ahora sí, ¡vamos al artículo! Espero que disfrutes esta historia tanto como yo disfruté (bueno, casi) vivirla.

El Comando que lo Cambió Todo

Todo comenzó un día normal. Estaba trabajando en mi instancia EC2 de Windows Server 2022, configurando algunos servicios, cuando, por error, ejecuté este comando en PowerShell:

Set-Service -Name Dhcp -StartupType Disabled

¿Qué hace este comando? Básicamente, deshabilita el servicio DHCP en mi servidor. «No pasa nada», pensé. Hasta que intenté conectarme de nuevo a la instancia usando Remote Desktop (RDP) y… ¡nada! No podía acceder. Ni siquiera el AWS Session Manager funcionaba, porque el SSM Agent tampoco estaba en línea. ¡Desastre total!

¿Qué Pasó Aquí?

Un solo cagadal! resulta que, al deshabilitar el servicio DHCP, mi instancia perdió la capacidad de obtener una dirección IP automáticamente. Sin IP, no hay conexión de red. Sin conexión de red, no hay RDP, no hay Session Manager, y mucho menos acceso a la instancia. En resumen: yo mismo me metí en este lío.

Deshabilitar el servicio DHCP es como cortar la cuerda de tu paracaídas: no sabes que lo necesitas hasta que es demasiado tarde

Las Pruebas que Realicé

Antes de entrar en pánico (bueno, para qué finjo, si me cagué todo!), intenté varias cosas para recuperar el acceso:

1. AWS Session Manager:
   • Intenté conectarme usando Session Manager, pero me encontré con este error
     • CopySSM Agent is not online The SSM Agent was unable to connect to a Systems Manager endpoint to register itself with the service.
   • El SSM Agent no estaba funcionando, así que esta opción no era viable.
2. EC2 Serial Console:
   • Probé usar la EC2 Serial Console, pero no funcionó como esperaba. Parece que no estaba configurada correctamente.
3. Verificación de Conectividad:
   • Usé PowerShell para verificar si la instancia podía conectarse a los endpoints de AWS:
     • Test-NetConnection -ComputerName ssm.us-east-1.amazonaws.com -Port 443
   • El resultado fue un rotundo «No puedo conectarme».

La Solución: Una Instancia Rescatadora

Después de varias pruebas (ya como a las 3:00 de la madrugada), llegué a la conclusión de que necesitaba modificar el registro de Windows para habilitar el servicio DHCP nuevamente. Pero, ¿cómo putas hacerlo si no podía acceder a la instancia? Aquí es donde entra en juego la instancia rescatadora (sugerencia de DeepSeek, esta onda si es la mera versh!).

Paso 1: Detener la Instancia Afectada

• En la consola de AWS, detuve la instancia afectada para poder desvincular su volumen.

Paso 2: Adjuntar el Volumen a una Instancia Rescatadora

• Como el tema es que estoy actualizando los servidores de ZelvaPOS, ya tenía una instancia EC2 con Windows Server 2012 (sí, una versión diferente, pero funcionó) y adjunté el volumen de la instancia afectada como un disco secundario. Este paso es casi como que le sacaras el disco duro a una computadora y se lo ponés como disco secundario a otra computadora.

Consideraciones Previas

1. Verifica el Tamaño del Volumen Adjunto

• El volumen que vas a adjuntar (el de la instancia afectada) tiene un tamaño específico (por ejemplo, 30 GB, 100 GB, etc.).
• Asegúrate de que la instancia rescatadora no tenga un límite de volúmenes adjuntos que impida agregar otro disco.
  • Por defecto, AWS permite adjuntar hasta 27 volúmenes a una instancia, dependiendo del tipo de instancia. Esto no debería ser un problema en la mayoría de los casos.

2. Verifica el Tipo de Instancia Rescatadora

• Algunos tipos de instancias tienen límites en el número de discos que pueden manejar o en el ancho de banda de EBS.
• Para este caso, cualquier instancia Windows Server 2022 con un tamaño moderado (por ejemplo, t3.medium, t3.large, etc.) debería ser suficiente, ya que solo estás adjuntando un volumen adicional para modificar el registro.

3. Verifica el Espacio en el Disco Raíz de la Instancia Rescatadora

• Aunque no estás usando el espacio del disco raíz de la instancia rescatadora, es recomendable que tenga suficiente espacio libre para evitar problemas de rendimiento.
• Asegúrate de que el disco raíz de la instancia rescatadora tenga al menos 20-30 GB libres para operar sin problemas.

4. Verifica los Límites de AWS

• AWS tiene límites en la cantidad de volúmenes que puedes adjuntar a una instancia. Por ejemplo:
  • Las instancias de la familia t3 permiten adjuntar hasta 27 volúmenes.
  • Las instancias de la familia t2 permiten adjuntar hasta 40 volúmenes.
• Si ya tienes muchos volúmenes adjuntos a la instancia rescatadora, es posible que no puedas adjuntar otro. En ese caso, usa una instancia diferente.

5. Recomendaciones para la Instancia Rescatadora

• Tipo de instancia: Usa una instancia con suficiente capacidad de CPU y memoria para manejar la carga adicional (por ejemplo, t3.medium o superior).
• Sistema operativo: Usa la misma versión de Windows Server (2022) para evitar problemas de compatibilidad.
• Disco raíz: Asegúrate de que el disco raíz tenga suficiente espacio libre (al menos 20-30 GB).

Paso 3: Modificar el Registro

• En la instancia rescatadora, abrí el Editor del Registro (regedit) y cargué el hive (esta onda del Hive era una cosa totalmente desconocida para mi, se los explicaré en otro artículo) del archivo SYSTEM del volumen adjuntado.
• Modifiqué la clave del servicio DHCP para habilitarlo:
  • HKEY_LOCAL_MACHINE\TempHive\ControlSet001\Services\Dhcp
    • Cambié el valor Start de 4 (Deshabilitado) a 2 (Automático).

Pasos para Hacerlo de Manera Segura

1. Crea un Snapshot del Volumen Afectado

1. En la consola de AWS:
   • Ve a EC2 > Volumes.
   • Selecciona el volumen de la instancia afectada.
   • Haz clic en Actions > Create Snapshot.
   • Espera a que el snapshot se complete antes de continuar.

2. Adjunta el Volumen a la Instancia Rescatadora (Windows Server 2012)

1. Detén la instancia afectada:
   • Ve a EC2 > Instances.
   • Selecciona la instancia afectada y haz clic en Instance State > Stop.
2. Desvincula el volumen:
   • Ve a EC2 > Volumes.
   • Selecciona el volumen de la instancia afectada y haz clic en Actions > Detach Volume.
3. Adjunta el volumen a la instancia rescatadora:
   • Selecciona el volumen y haz clic en Actions > Attach Volume.
   • Selecciona la instancia rescatadora (Windows Server 2012) y asígnale una letra de dispositivo (por ejemplo, /dev/sdf).

3. Modifica el Registro en la Instancia Rescatadora

1. Conéctate a la instancia rescatadora usando RDP.
2. Abre Disk Management:
   • Presiona Win + X y selecciona Disk Management.
   • Inicializa el volumen adjuntado y asígnale una letra de unidad (por ejemplo, F:).
3. Edita el registro:
   • Abre regedit (Editor del Registro).
   • Ve a File > Load Hive.
   • Navega a F:\Windows\System32\config\SYSTEM y asígnale un nombre (por ejemplo, TempHive).
4. Habilita el servicio DHCP:
   • Navega a HKEY_LOCAL_MACHINE\TempHive\ControlSet001\Services\Dhcp.
   • Cambia el valor Start de 4 (Deshabilitado) a 2 (Automático).
5. Descarga el hive:
   • Selecciona TempHive y haz clic en File > Unload Hive.

4. Revierte los Cambios

1. Desvincula el volumen de la instancia rescatadora:
   • En Disk Management, desvincula el volumen.
   • En la consola de AWS, desvincula el volumen de la instancia rescatadora.
2. Vuelve a adjuntar el volumen a la instancia original:
   • Adjunta el volumen a la instancia original como dispositivo raíz (/dev/sda1).
3. Inicia la instancia original:
   • En la consola de AWS, inicia la instancia original.
   • Intenta conectarte usando RDP o Session Manager.

Paso 4: Descargar el Hive y Revertir los Cambios

• Descargué el hive para guardar los cambios y desvinculé el volumen de la instancia rescatadora.
• Volví a adjuntar el volumen a la instancia original y la encendí.

¡Y voilà! La instancia arrancó correctamente, y pude conectarme usando RDP. El servicio DHCP estaba habilitado, y todo volvió a la normalidad.

¿Qué Hace «Descargar el hive»?

Cuando cargas un hive en el Editor del Registro (regedit), estás abriendo un archivo de registro (en este caso, el archivo SYSTEM del volumen adjuntado) para modificarlo. Este hive se carga en una sección temporal del registro de la instancia rescatadora.

Al descargar el hive, estás guardando los cambios que hiciste y cerrando el archivo de registro. Esto asegura que los cambios se escriban correctamente en el archivo SYSTEM del volumen adjuntado.

¿Dónde Queda Guardado?

El hive que modificaste (en este caso, el archivo SYSTEM del volumen adjuntado) se guarda en su ubicación original, es decir, en la ruta:

F:\Windows\System32\config\SYSTEM

(Donde F: es la letra de unidad asignada al volumen adjuntado).

Los cambios que hiciste (por ejemplo, habilitar el servicio DHCP) se aplican directamente a este archivo.

¿Cómo se Aplica en la Instancia Original?

Una vez que descargas el hive, los cambios quedan guardados en el archivo SYSTEM del volumen adjuntado. Cuando vuelvas a adjuntar este volumen a la instancia original y la inicies, Windows cargará el archivo SYSTEM modificado, y los cambios que hiciste (en este caso, habilitar el servicio DHCP) se aplicarán automáticamente.

Pasos Detallados para Descargar el Hive

1. Abre el Editor del Registro (regedit):
   • Presiona Win + R, escribe regedit y presiona Enter.
2. Selecciona el hive que cargaste:
   • En el panel izquierdo, navega a HKEY_LOCAL_MACHINE\TempHive (o el nombre que le diste al hive).
3. Descarga el hive:
   • Haz clic derecho sobre TempHive (o el nombre que le diste).
   • Selecciona Unload Hive.
   • Confirma la acción si se te solicita.
4. Verifica que el hive se haya descargado:
   • Una vez descargado, el hive ya no aparecerá en HKEY_LOCAL_MACHINE.

¿Qué Pasa Después?

• Desvincula el volumen de la instancia rescatadora:
  • En Disk Management, desvincula el volumen.
  • En la consola de AWS, desvincula el volumen de la instancia rescatadora.
• Vuelve a adjuntar el volumen a la instancia original:
  • Adjunta el volumen a la instancia original como dispositivo raíz (/dev/sda1).
• Inicia la instancia original:
  • En la consola de AWS, inicia la instancia original.
  • Windows cargará el archivo SYSTEM modificado, y el servicio DHCP estará habilitado.

Recomendaciones para Evitar Problemas Futuros

1. Haz Snapshots Regularmente:
   • Antes de hacer cambios críticos, crea un snapshot de tu volumen. Te salvará la vida en situaciones como esta.
2. Usa AWS Systems Manager (SSM):
   • Configura el SSM Agent en todas tus instancias. Te permitirá acceder a ellas incluso si pierdes conectividad de red.
3. Prueba Comandos en Entornos No Productivos:
   • Antes de ejecutar comandos críticos en producción, pruébalos en un entorno de prueba. Aprende de mi error. 😅
4. Ten una Instancia Rescatadora a Mano:
   • Mantén una instancia EC2 con Windows Server lista para usarse en caso de emergencias. Te ahorrará tiempo y estrés.

Conclusión

Aunque este problema fue estresante, también fue una gran oportunidad para aprender. Ahora sé que, con las herramientas y los conocimientos adecuados, puedo resolver casi cualquier problema en la nube. Y tú también puedes hacerlo.

Así que, si alguna vez te encuentras en una situación similar, recuerda: no entres en pánico, sigue los pasos correctos, y siempre, siempre, haz un snapshot antes de hacer cambios críticos.

¡Espero que esta historia les haya sido útil y entretenida! Si tienen alguna pregunta o quieren compartir sus propias experiencias, déjenla en los comentarios. ¡Nos vemos en la nube! ☁️

About Post Author

Carlos Zelaya Irías

Carlos Alberto Zelaya Irías es un profesional hondureño especializado en tecnología, desarrollo de software y consultoría empresarial. Como CEO de ZelvaIT, educador universitario y divulgador en plataformas digitales, promueve la innovación tecnológica y la educación inclusiva. Apasionado por la ciberseguridad, metodologías ágiles y transformación digital, comparte conocimientos prácticos para empoderar a su comunidad

cazeli.work@gmail.com

https://zelvait.com

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %