En el mismo Faq/Knowledge Base de Veesp sale:exelente tutorial!
tuve un problema en la instalacion, en la parte de la instalación de hestiacp, la consola me notifica que el sistema operativo de la VPS no es compatible con hestiacp. creo que me salte el paso donde mencionaba que seleccionemos "22.04 TLS" y como hastiacp no es compatible con la ultima version de Ubuntu no me funciona.
alguien sabe como cambiar la version de Ubuntu en la VPS? en el panel de control de Veesp no veo ninguna funcion o opcion que haga referencia a esto asi que supongo que tendre que abrir ticket al soporte para que me cambien la version de Ubuntu para que funcione el tutorial. supongo que esta es una valiosa lexion de como no prestar atencion a un pequeño paso puede traer muchos problemas despues xd
How to reinstall your VPS OS
1.Log in to your client area
2.Click on Dashboard
3.Click on Virtual Private Servers
4.Pick VPS you wish to reinstall
5.In the server management page, open the "Rebuild" tab on the left side
6.Select the OS and press the "Re-Install VPS" button
7.Let the VPS installation complete. It can take ~10-15 minutes.
Haces login con el VPS Control Panel (Credenciales en tu correo) y allí te da para un Rebuild/Reinstall with Ubuntu 22.04 TLS. Verifica y nos comentas como te fue en el proceso, recuerda guardar la contraseña nueva ya que solo sería mostrada Onetime nuevamente.exelente tutorial!
tuve un problema en la instalacion, en la parte de la instalación de hestiacp, la consola me notifica que el sistema operativo de la VPS no es compatible con hestiacp. creo que me salte el paso donde mencionaba que seleccionemos "22.04 TLS" y como hastiacp no es compatible con la ultima version de Ubuntu no me funciona.
alguien sabe como cambiar la version de Ubuntu en la VPS? en el panel de control de Veesp no veo ninguna funcion o opcion que haga referencia a esto asi que supongo que tendre que abrir ticket al soporte para que me cambien la version de Ubuntu para que funcione el tutorial. supongo que esta es una valiosa lexion de como no prestar atencion a un pequeño paso puede traer muchos problemas despues xd
muchas gracias, esto me ayudo mucho. logre ir a la versión anterior y instalar hestiacp de esta forma por lo que te agradezco muchoEn el mismo Faq/Knowledge Base de Veesp sale:
siguiendo estos mismos pasos logre instalar hestiacp, apuntar a la IPv4 de mi servidor original y configurar el dominio en el panel de control. realmente hiciste un genial tutorial y se entendió todo muy bien. aunque lamentablemente me surgieron nuevos problemas que no logro entenderHaces login con el VPS Control Panel (Credenciales en tu correo) y allí te da para un Rebuild/Reinstall with Ubuntu 22.04 TLS. Verifica y nos comentas como te fue en el proceso, recuerda guardar la contraseña nueva ya que solo sería mostrada Onetime nuevamente.
Debes 1) Crear una regla de seguridad excluyendo el user agent de letsencrypt (contains) o desactivar provisionalmente las nubecitas 2) Pasar en SSL/TLS de Flexible por Full (no full strict) de este modo el letsencrypt se va generar sin problema alguno. El 403 es porque tu Cloudflare esta un poco elevado de seguridad, entonces con esto resuelves el asunto inicial de la validation.muchas gracias, esto me ayudo mucho. logre ir a la versión anterior y instalar hestiacp de esta forma por lo que te agradezco mucho
siguiendo estos mismos pasos logre instalar hestiacp, apuntar a la IPv4 de mi servidor original y configurar el dominio en el panel de control. realmente hiciste un genial tutorial y se entendió todo muy bien. aunque lamentablemente me surgieron nuevos problemas que no logro entender
luego de ir a cloudflare y apuntar los DNS a la IP del servidor proxy aparecio un error 521 de cloudflare diciendo que el servidor estaba caido, lo extraño aqui es que en el subdominio www. si esta funcionando el sitio web y dice que esta en mantenimiento ya que yo lo puse asi con un plugin de wordpress, pero no logro entender porque en el subdominio "www" funciona el proxy y en el dominio solo no. se podria decir que funciono y a la vez no del todo, estoy pensando lo que podría ocasionar esto pero al no tener experiencia en el desarrollo de proxys no se me ocurre nada.
lo unico con que puedo conectar esto es que al al tratar de usar el certificado SSL de Let's Encrypt el panel de hestia me respondio con un error de "bad status 403" que por ahora no se del todo que significa. si en algun momento a alguien le sucedio el mismo error o parecido seria interesante escuchar un aporte sobre esto. un saludo a todos y gracias por su ayuda!
impresionante!Debes 1) Crear una regla de seguridad excluyendo el user agent de letsencrypt (contains) o desactivar provisionalmente las nubecitas 2) Pasar en SSL/TLS de Flexible por Full (no full strict) de este modo el letsencrypt se va generar sin problema alguno. El 403 es porque tu Cloudflare esta un poco elevado de seguridad, entonces con esto resuelves el asunto inicial de la validation.
Muy bien, bueno ya cuando alguna otra persona tenga el inconveniente le continuamos asistiendo el caso jeje, esa es la idea, evitar las denuncias y los chantajes, este fue el tutorial mejor y mas esperado del foro de este tiempo, gritos a voces jijiji. Por cierto, bienvenido a forobeta 🚀 👊impresionante!
la solución para mi extrañamente funciono alreves, yo lo había habilitado a Full y lo cambie a Flexible, luego de esto el sitio web comenzó a funcionar perfectamente. no hay retrasos ni va lento, es realmente bellísimo, ahora entiendo como se siente. de verdad muchas gracias por el tutorial, con solo decirte que me registre aqui por tu hilo. ya sabia sobre este foro y eh aprendido mucho aqui pero nunca me habia registrado.
por cierto, no logre solucionar el error SSL de Letsencrypt pero el sitio web no se ve afectado por este error ya que el encriptado y el SSL funciona bien por lo que no tengo problema. realmente te agradezco mucho este tutorial. tengo un sitio web junto a otras personas relacionado con el periodismo de investigación y somos continuamente censurados y chantajeados por lo que esto es una capa de seguridad para nosotros.
gracias por su ayuda y espero tengan todos una linda noche. un saludo!
creo que esto es un tema interesante del que eh visto ser mencionado antes en repetidas ocasiones pero nunca vi a alguien mostrando realmente como podrian explotar una vulnerabilidad del proxy reverso para saber la IP original, espiar los paquetes , hackear el servidor o conseguir algun tipo de acceso. podrias detallar mas sobre esto? como alguien podria hacer esto y como proteger el servidor de esto?.Existe muchísimo riesgo en esta configuración.
Si te esnifean el puerto 80, no solo pueden saber cuál es tu servidor origen, sino que podrían interceptar los paquetes que van sin cifrar entre los dos puertos.
Lo primero, no usaría el puerto 80/443 para el servidor origen, porque no puedes dropear paquetes selectivamente con el firewall y te pueden localizar el servidor origen, por lo que aparte del contenido de los paquetes, simplemente hay un problema de privacidad, (sobre todo si estás usando contenido ilícito).
Hay dos opciones:
La más complicada, bajo mi punto de vista, es encriptar la comunicación con certificados entre el servidor origen y el proxy, pero usando otro puerto en el servidor origen.
Pero quizá lo más pro, hubiera sido mejor crear una VPN entre los servidores en otro puerto, y en el firewall droppear todos los paquetes que no vengan de la IP origen a ese puerto, y tirar el proxy inverso a través de la VPN. Aparte puedes tener más servicios en otros puertos y ya no tienes que estar liando para encriptar cada servicio independientemente.
Si algunas personas me han preguntado lo mismo pero en principios nadie sabría como cambiarle el puerto al servidor principal, como es un tema un poco aparte no hice ni la mención, pero más adelante vere si hago como un self guide para cada control panel.Existe muchísimo riesgo en esta configuración.
Si te esnifean el puerto 80, no solo pueden saber cuál es tu servidor origen, sino que podrían interceptar los paquetes que van sin cifrar entre los dos puertos.
Lo primero, no usaría el puerto 80/443 para el servidor origen, porque no puedes dropear paquetes selectivamente con el firewall y te pueden localizar el servidor origen, por lo que aparte del contenido de los paquetes, simplemente hay un problema de privacidad, (sobre todo si estás usando contenido ilícito).
Hay dos opciones:
La más complicada, bajo mi punto de vista, es encriptar la comunicación con certificados entre el servidor origen y el proxy, pero usando otro puerto en el servidor origen.
Pero quizá lo más pro, hubiera sido mejor crear una VPN entre los servidores en otro puerto, y en el firewall droppear todos los paquetes que no vengan de la IP origen a ese puerto, y tirar el proxy inverso a través de la VPN. Aparte puedes tener más servicios en otros puertos y ya no tienes que estar liando para encriptar cada servicio independientemente.
no se como evitar esto y que se muestre el archivo robots.txt original y no el generado por hestiacp en el proxy reverso. me preguntaba si a alguien mas le paso y en caso de que si, como lo solucionaron? escuche por ahi en un foro ingles que se soluciona borrando el archivo .txt del proxy reverso pero intente hacer esto y todo sigue igual asi que supongo que no se soluciona de esta forma
root %sdocroot%;Me encantaria una actualziación en esto terminos.Pero quizá lo más pro, hubiera sido mejor crear una VPN entre los servidores en otro puerto, y en el firewall droppear todos los paquetes que no vengan de la IP origen a ese puerto, y tirar el proxy inverso a través de la VPN. Aparte puedes tener más servicios en otros puertos y ya no tienes que estar liando para encriptar cada servicio independientemente.
Utilizamos cookies y tecnologías similares para los siguientes fines:
¿Aceptas las cookies y estas tecnologías?
Utilizamos cookies y tecnologías similares para los siguientes fines:
¿Aceptas las cookies y estas tecnologías?