Orden recomendado para preparar el servidor de un proxy IP propio: comprobar primero el acceso SSH, cambiar el puerto y pasar a autenticación por clave, aplicar el refuerzo básico, instalar el servicio proxy y abrir el puerto, y por último conectar y validar desde el cliente.
Al comprar un servidor en la nube para usarlo como proxy, el problema rara vez está en la conectividad básica. Lo que suele complicar las cosas es el orden de preparación del lado del servidor. Si se sigue el orden correcto, el cliente normalmente conecta a la primera; si se mezcla, toca volver una y otra vez al terminal para cambiar la configuración.
Aquí solo se trata el lado del servidor: desde el primer inicio de sesión y el endurecimiento del acceso hasta poner en marcha el servicio proxy, abrir los puertos, conectar el cliente y localizar por capas la causa de un fallo de conexión.
Primer inicio de sesión: comprueba primero el acceso
Después de crear la instancia, inicia sesión primero con el terminal web incluido en la consola del proveedor y no dependas desde el principio de una herramienta local. En este paso solo se busca confirmar que la máquina está activa y que la red funciona.
Una vez dentro, cambia a root ejecutando sudo -i y pulsando Enter. Cuando el indicador cambie de $ a #, la elevación de privilegios se habrá completado. Realiza los pasos siguientes con esa identidad.
Anota cuatro datos: IP pública, nombre de usuario de acceso (root por defecto en Linux), contraseña y puerto SSH (22 por defecto). El cliente necesita exactamente esos cuatro valores; si falta uno, no podrá conectarse.
Cambia el puerto predeterminado y después usa autenticación por clave
El puerto 22 se escanea innumerables veces cada día y los intentos automatizados con credenciales son habituales. Cambiar el puerto no hace que el servidor sea intrínsecamente más seguro, pero elimina gran parte del ruido automatizado.
El cambio se realiza en /etc/ssh/sshd_config. Abre el archivo con vi, pulsa i para entrar en modo de edición, cambia las líneas PermitRootLogin y PasswordAuthentication a yes y, después de pulsar Esc, escribe :wq para guardar y salir. Si el proveedor admite acceso por clave, una opción más sólida es añadir tu clave pública local a authorized_keys en el servidor y cambiar PasswordAuthentication a no para aceptar solo claves.
No cierres la sesión actual justo después de cambiar la configuración. Abre primero otra ventana de terminal, inicia sesión una vez con el nuevo puerto y el nuevo método, confirma que funciona y solo entonces cierra la ventana anterior. Si hay un error de configuración, podrías bloquearte fuera del servidor y tendrías que recuperarlo desde la consola del proveedor.
El puerto SSH se cambia en la línea Port. Después, reinicia el servicio SSH para aplicar la configuración. En sistemas Debian y Ubuntu puedes ejecutar /etc/init.d/ssh restart.
Aplica el refuerzo básico el primer día
Además de cambiar el puerto y usar claves, conviene completar dos tareas sencillas desde el primer día. La primera es establecer para root una contraseña aleatoria y suficientemente larga con passwd root, en lugar de una combinación fácil de adivinar. La segunda es desactivar servicios y puertos innecesarios. Cuanto menos software expuesto haya, menor será la superficie de ataque; el firewall del sistema debe permitir únicamente los puertos que realmente se necesiten.
Si el servidor va a utilizarse de forma permanente desde unos pocos orígenes fijos, limita en el grupo de seguridad las direcciones de origen a esos puntos. Es mucho más seguro que abrir el acceso a todo Internet.
Instala el servicio proxy y configura la autenticación
Una vez terminada la inicialización del servidor, configura el proxy propiamente dicho.
Una opción es usar directamente un túnel SSH. No hace falta instalar nada adicional en el servidor: el cliente usa el servicio SSH incorporado en el sistema para el reenvío y emplea las mismas credenciales del servidor. Es sencillo, pero el rendimiento es normal y con mucha concurrencia se queda corto, por lo que conviene para uso temporal o para pocos perfiles.
La otra opción es instalar un servicio proxy dedicado. Normalmente se instala con un solo comando y después se configuran manualmente el método de autenticación y el puerto de escucha. Activa el inicio automático; si no, un reinicio del servidor dejará el proxy fuera de servicio.
Hay tres niveles habituales de autenticación, con seguridad creciente: usuario y contraseña son lo más sencillo, pero una filtración equivale a entregar el proxy; contraseña más lista blanca de IP de origen suele bastar para el uso diario; autenticación por clave o certificado es la opción más sólida, aunque requiere más configuración y merece la pena para cuentas que funcionarán a largo plazo.
Abre el puerto en dos lugares distintos
Este es uno de los puntos que más problemas causa. El puerto de escucha del servicio proxy debe permitirse tanto en el firewall del sistema como en el grupo de seguridad del proveedor. Son controles independientes y abrir solo uno no basta.
También se suele pasar por alto la dirección de escucha del servicio. Algunos servicios se enlazan por defecto solo a 127.0.0.1. Si una prueba local en el servidor funciona pero desde fuera no, esta suele ser la causa. Cambia la dirección de escucha a la dirección privada del servidor o a 0.0.0.0.
Conecta desde el cliente local
Crea un entorno nuevo en la herramienta de gestión de entornos y selecciona el tipo de proxy que corresponda. Si utilizas un túnel SSH, la dirección es la IP pública del servidor, el puerto es el puerto SSH y el usuario y la contraseña son los del servidor. Después, ejecuta la prueba de conexión.
Que la prueba pase solo demuestra que la ruta funciona. Abre el entorno y confirma tres cosas más: que la IP de salida sea la IP pública del servidor; que DNS también pase por el proxy, porque si la resolución sigue siendo local puede revelar una región distinta de la IP de salida; y que la zona horaria y el idioma coincidan con la región de salida. Solo cuando se cumplan las tres condiciones puede considerarse listo el entorno.
Cuando aumente el número de cuentas, mantén fija la relación entre cada entorno y su salida para evitar que varias cuentas compartan un mismo entorno. Herramientas como PurpleMark pueden asignar una salida independiente a cada cuenta, algo más estable que mantener una tabla manual.
Si no conecta, revisa de fuera hacia dentro
Empieza por la capa más externa: ¿está permitido el acceso en el grupo de seguridad? ¿Y en el firewall del sistema? Confirma ambas cosas antes de seguir.
Después revisa el propio servicio: ¿sigue activo el proceso, sobre todo tras reiniciar el servidor? ¿La dirección de escucha está enlazada solo al equipo local?
A continuación revisa la autenticación: ¿están mal el usuario o la contraseña? ¿Los permisos del archivo de clave son demasiado amplios? SSHD rechazará directamente una clave con permisos incorrectos. Solo al final revisa el cliente: ¿has escrito la IP pública o por error la IP privada? Esa confusión es especialmente frecuente.
Siguiendo este orden, normalmente bastan dos o tres pasadas para localizar la capa donde está el problema, en lugar de reinstalar el servicio una y otra vez.
Cierre
Preparar el lado del servidor lleva menos de media hora, pero determina cuánto mantenimiento dará la máquina durante los meses siguientes. Asegura el acceso, abre correctamente los puertos y deja clara la autenticación; después, el resto será mantenimiento rutinario.
