Bloqueado fuera de tu servidor VPN: conserva una segunda vía de entrada
Un túnel roto no debería quitarte también la capacidad de reparar el servidor. Planifica, prueba y revisa una vía administrativa independiente antes de necesitarla.
Abres la consola, cambias una regla de cortafuegos y el túnel por el que estabas conectado desaparece. El cambio era correcto, la recarga no, y ahora la única ruta de vuelta a la máquina es la que acabas de romper. Una segunda vía de entrada es una decisión de diseño, y tiene que existir antes de la caída, no durante.
Repasa lo que todavía tienes
Empieza por la pantalla de consola que tienes delante y enumera las vías que no dependen del túnel. Una consola web del proveedor con una sesión serie o VNC es una. Una interfaz de gestión en una red separada es otra. El acceso físico es la tercera, y es la que la gente descubre que falta en el peor momento.
| Path | Depends on | Usually fails when |
|---|---|---|
| Provider console | Account access and the provider's own API | Credentials live in a wiki only reachable over the tunnel |
| Management subnet | A second interface and its own routing | The bad change was a global route or firewall policy |
| Second tunnel | A different listener, port and credentials | Both listeners were changed in the same edit |
| Physical or local console | Being in the building | Nobody has been in the building for a year |
Lee la tercera columna como una lista de fallos y no como una abstracción. Dos de esas vías suelen fallar por el mismo motivo. La tabla es cómo te das cuenta antes de que una caída te lo explique.
La independencia es una cuestión de dependencias
Una cuenta de recuperación no es independiente si su contraseña se guarda en un servicio al que llegas por el túnel. Una segunda VPN en el mismo host, el mismo puerto y la misma política de cortafuegos tampoco es independiente, porque el cambio que rompió la primera rompe las dos.
Baja por la cadena y nombra qué necesita cada paso. El alcance de red, la resolución de nombres, una fuente de autenticación y el propio servicio de gestión son cuatro dependencias separadas, y una vía que comparta cualquiera de ellas hereda ese fallo.
La vía que nunca se ha probado merece su propia sospecha. Una consola que no se abre desde hace meses puede exigir un restablecimiento de contraseña por correo, y ese buzón puede estar alojado en la máquina a la que no llegas. Prueba la vía mientras todo funciona y lo encontrarás una tarde tranquila.
Usa la segunda vía para un cambio controlado
Desde la consola, toma una instantánea o copia la configuración que estás a punto de editar. Cambia una cosa. Recarga el servicio y lee el resultado antes de tocar nada más, porque dos cambios a la vez convierten una recuperación en un experimento.
Mantén abierta la sesión de recuperación mientras lo haces. Todo el valor de la segunda vía es que sobrevive a lo que estás cambiando, así que cerrarla primero elimina la única propiedad que la hacía útil.
Verifica desde la vía de recuperación, no de memoria
La comprobación que importa es si vuelve la vía normal, y la sesión de recuperación es donde lo confirmas por orden:
systemctl status openvpn-server@server --no-pager ss -lntup | grep -E ':(1194|443)\b' nft list ruleset | sed -n '1,40p' journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30
Lee primero el estado del servicio, luego el oyente, luego las reglas, luego el registro. Un servicio que funciona sin oyente apunta a la configuración del servicio, mientras que un oyente sin reglas accesibles apunta al filtrado. El orden importa porque cada paso estrecha el siguiente, y saltar al registro suele significar leer errores que describen el síntoma y no la causa.
La documentación de systemctl cubre el comportamiento de estado y reinicio que se usa aquí, incluido cómo una recarga fallida deja el proceso anterior en marcha. Restaurar una revisión coherente es mejor que reconectar una y otra vez desde un cliente que no puede reparar el servidor. Si se ha cumplido la condición de reversión que definiste antes del cambio, restaura y detente.
Mantén el inventario al día
Revisa la lista de acceso cuando cambian las personas o la infraestructura. Prueba la vía de recuperación mientras todo funciona. Retira las cuentas que nadie ha usado desde la última reorganización. Dos cuentas obsoletas y un certificado caducado son una pequeña limpieza un martes y una caída un domingo.
Registra quién puede usar cada vía, qué permite y cómo se rotan las credenciales. Una vía de recuperación sin propietario se convierte en una entrada olvidada, que es un tipo de fallo distinto de quedarse fuera.