Superando el Firewall: Mi Odisea para Acceder al VPS - Episodio13

Superando el Firewall vuelve a ser un eufemismo para decir "Me cago en todo lo que se menea".

Te lo cuento

🎯 La Odisea Comienza: ¿Por Qué No Puedo Acceder al VPS?

Todo empezó con una misión sencilla: acceder al VPS para empezar a configurar el entorno de desarrollo de mi SaaS.

¿Qué tan difícil podía ser?

Spoiler: muy difícil.

Lo que parecía una tarea simple se convirtió en una batalla épica contra firewalls, puertos bloqueados y credenciales malditas. 😅

A ver, de poder acceder, podría acceder mediante Plesk, pero quería hacer el hacker y acceder vía SSH para configurar cosas.

Cosas...

Cositas...

🔥 La Frustración de un SSH Inaccesible

“¿Por qué no conecta?”

Fue la primera pregunta.

Lo intenté todo: PuTTY, PowerShell, cambios de puerto y hasta reinicios del servidor.

Pero cada intento me daba el mismo resultado:

remote side unexpectedly closed network connection

Que viene a ser lo mismo que llamar a la puerta de alguien que sabes que está dentro pero que no quiere abrirte.

Ahí fue cuando supe que esta no sería una simple configuración de VPS.

Y claro, empecé a dudar de todo:  de mis conocimientos,  de mi paciencia, de la madre que me parió!. 😤

🚧 Desafíos y Retos Encontrados

Te cuento en detalle los retos y desafíos encontrados que casi me hacen llorar.

ModSecurity: El Guardián del Caos 🔐

• • Intenté activar y configurar ModSecurity para proteger el servidor, pero me encontré con el error:

    Could not open phrase file "/etc/nginx/modsec/whitelist-ports.txt"

¿Solución temporal?

Deshabilitar ModSecurity

Para poder continuar con la configuración miré de desactivar ModSecurity

Pero esto me dejó unas preguntas:

¿Cómo configurarlo correctamente más adelante?

¿Estaría abriendo puertas traseras a Hackers de verdad?

 

Acceso por SSH: Una Puerta Cerrada con Candado Invisible 🔑

Ninguna configuración funcionaba.

O sea, Dios es testigo que lo intenté con PuTTY y PowerShell.

Comprobé si el puerto 22 estaba abierto.

Test-NetConnection -ComputerName [IP_DEL_SERVIDOR] -Port 22

Resultado:

El puerto 22 estaba bloqueado en el firewall.

Decidí probar con un puerto alternativo ([PUERTO_ALTERNATIVO]) y luego con [PUERTO_PERSONALIZADO].

Pero cada intento fallido era un golpe a mi ego. 🤦‍♂️

Firewall y Puertos: La Muralla Imposible de Traspasar 🔥

Revisé las reglas en Plesk y analicé el script de iptables.

Además, creé reglas personalizadas para permitir el puerto [PUERTO_PERSONALIZADO], pero no funcionaba.

¿El problema?

No había especificado la IP de origen en las reglas. 😵

Cada desafío me hizo dudar del proyecto.

Empecé a pensar que quizás no estaba preparado para esto.

Pero me negué a rendirme.

Si otros lo lograron, ¿por qué no iba a poder yo? 💪

No tenía consola SSH en Plesk

Todo esto venía porque en la propio Plesk no tenía habilitada la consola SSH.

No podía acceder por terminal desde el propio servidor.

Ahora bien, podría haberle dicho a Profesional Hosting que me la pusieran?

Sí, pero quería valerme por mi mismo.

Y miré de hacerlo todo yo.

De hecho, ChatGPT sacama humo, creo que incendié un servidor de OpenAI como mínimo con tanta consulta.

Conclusión, conectar por PowerShell o Putty!

🛠️ Solución Implementada: Desenredando el Caos

Después de muchas pruebas y errores, logré acceder al VPS vía SSH usando el puerto [PUERTO_PERSONALIZADO].

¿Cómo?

Aquí está el desglose:

1. Configuración Inicial de Plesk 🖥️

   • Exploré Plesk Obsidian v18.0.67 para verificar los servicios habilitados.
   • Me di cuenta de que Nginx no estaba instalado y Apache estaba habilitado por defecto.
   • Eso complicó la configuración del proxy inverso.

2. Cambio de Puertos y Reglas de Firewall 🔄

   • Probé con los puertos [PUERTO_ALTERNATIVO] y [PUERTO_PERSONALIZADO], creando reglas personalizadas en iptables.
   • Aprendí que era esencial especificar la IP de origen para acceder de manera segura.

3. Debugging y Pruebas con PowerShell 🔍

   • Usé PowerShell para probar las conexiones en cada cambio:

     Test-NetConnection -ComputerName [IP_DEL_SERVIDOR] -Port [PUERTO_PERSONALIZADO]

   • Esto me permitió identificar errores de configuración y probar cambios en tiempo real.

Después de estos cambios, finalmente accedí al VPS.

Sentí una mezcla de euforia y alivio, como si hubiera ganado una batalla épica. 🎉

⏳ Tiempo Total Dedicado: 9 horas

9 horas de lucha constante contra errores, configuraciones y dudas existenciales.

Pero también fueron nueve horas de aprendizaje, crecimiento y un paso más cerca de completar el SaaS. 🚀

(Optimismo siempre al poder)

⏰ Tiempo Total Dedicado desglosado

Aquí tienes un desglose detallado del tiempo dedicado para superar los desafíos del VPS y el firewall:

1. Configuración Inicial del VPS 🖥️

   • Acceso y exploración de Plesk Obsidian v18.0.67.
   • Verificación de servicios habilitados y revisión de módulos de Apache.
   • Tiempo dedicado: 1.5 horas.

2. Problemas con ModSecurity 🔐

   • Intento de activar y configurar ModSecurity.
   • Error crítico y deshabilitación temporal para continuar.
   • Tiempo dedicado: 1 hora.

3. Acceso por SSH 🔑

   • Intentos de conexión con PuTTY y PowerShell.
   • Configuración de puertos alternativos y debugging.
   • Tiempo dedicado: 3 horas.

4. Configuración del Firewall 🔥

   • Revisión de reglas predeterminadas y creación de reglas personalizadas.
   • Debugging con PowerShell y ajustes en iptables.
   • Tiempo dedicado: 2.5 horas.

5. Acceso Exitoso y Lecciones Aprendidas 🚀

   • Acceso exitoso al VPS vía SSH y verificación de recursos.
   • Revisión de reglas de firewall y conexión persistente.
   • Tiempo dedicado: 1 hora.

💡 Lecciones Aprendidas

• ModSecurity es poderoso, pero traicionero: Hay que revisar dependencias y rutas antes de activar reglas personalizadas.
• El firewall no perdona: Es fundamental especificar la IP de origen en las reglas para accesos SSH seguros.
• Pruebas y Debugging son clave: Usar PuTTY junto con PowerShell agiliza el proceso de prueba y debugging.
• Documentar cambios: Documentar reglas y cambios en iptables es crucial para evitar conflictos y errores futuros.

🚀 Próximo Paso: Instalación de Flask y Gunicorn

Con el acceso SSH finalmente funcionando, el siguiente paso es instalar Flask y Gunicorn para empezar a configurar el backend del SaaS.

Además, tengo que decidir si utilizaré Nginx o seguiré con Apache como proxy inverso.

Y estoy seguro de que no será fácil. 😅

Como todo vaya!

➡️ ¿También has luchado contra firewalls y accesos SSH?

¡Cuéntame tus batallitas!

Si quieres conocer otros artículos parecidos a Superando el Firewall: Mi Odisea para Acceder al VPS - Episodio13 puedes visitar la categoría Proyecto-IA.