Tu VPN en la nube sigue dependiendo del proveedor de alojamiento

Instalaste el sistema operativo, endureciste el servicio y tienes las claves, y empieza a parecer que el servidor es tuyo. Es tuyo como es tuyo un piso alquilado: la cerradura está bajo tu control y el edificio no. El hipervisor, la red frente a la instancia y la cuenta que puede reconstruirlo todo pertenecen a otra persona. Esa distinción decide qué debe cubrir un plan de recuperación, y es la parte que el autoalojamiento cambia menos.

La cuenta es el verdadero plano de control

Una cuenta de alojamiento gestiona la máquina virtual, sus discos, sus instantáneas, sus direcciones públicas y sus reglas de red. Todo eso puede cambiarse sin iniciar sesión en el invitado, lo que sitúa la cuenta fuera del modelo de amenazas que describen la mayoría de las guías de VPN. Una configuración de túnel perfecta sobrevive a una acción en la cuenta que sustituya un disco.

Protege esa cuenta como un activo aparte: credenciales independientes, segundos factores con respaldo de hardware y un registro de auditoría que alguien lea de verdad. Compartirla con la misma entrada del gestor de contraseñas que el servicio de VPN es el error que vuelve irrelevante cualquier otro control.

Lee el reparto de deberes del proveedor para el producto concreto, no para la nube en general. El modelo de responsabilidad compartida es un ejemplo útil de cómo se dividen las capas, y otros proveedores describen sus propias fronteras en lugar de heredar esa. Lo que buscas es qué fallos se espera que arregles y cuáles solo puedes comunicar.

Eventos de infraestructura que no puedes administrar

La migración en vivo, el mantenimiento del host, un fallo de hardware en el nodo físico y un evento de capacidad son cosas que el proveedor gestiona según su propio calendario. Puedes ver un reinicio, una breve pérdida de paquetes o un cambio de dirección, y no verás el motivo. Un diseño que trata la instancia como un punto fijo interpretará cada uno de ellos como un fallo de la VPN. La acción correctiva es hacer que el servicio tolere una instancia que desaparece, en lugar de investigar una causa que nunca te mostrarán.

Las copias de seguridad pertenecen a esta capa, no al túnel. Guarda la configuración del servidor, las identidades, el plan de direcciones y las rutas permitidas en un lugar que no dependa de que la instancia sea accesible, y confirma que la copia puede restaurarse sin el disco original.

El comportamiento de la dirección merece su propia comprobación. Que una dirección pública sobreviva a una parada, una sustitución o un borrado depende de cómo se asignó, y las tres operaciones no son intercambiables. Anota de cuál dependes antes de que un incidente haga urgente la pregunta.

Comprueba qué sobrevive a una reconstrucción

Construye el camino de recuperación mientras todo funciona. Identifica la consola o el acceso fuera de banda que ofrece el proveedor, confirma que puedes llegar a ella sin el túnel y guarda las credenciales en un lugar del que no se las lleve un portátil averiado o un teléfono perdido. Si un cambio de cortafuegos local bloquea el túnel, esa consola es la única forma de volver.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

El servicio de metadatos responde preguntas sobre la instancia que el invitado no puede ver de otro modo, y sus rutas exactas varían entre proveedores y entre plataformas, así que verifícalas con la documentación del producto que ejecutas. Después haz una reconstrucción controlada de una instancia de prueba y cronométrala. Un procedimiento de recuperación que nadie ha ejecutado es una hipótesis.

Fíjate en qué hizo la reconstrucción con la dirección, las claves de host, la identidad del disco y todo lo que fijan los clientes. Los clientes que guardaron en caché una clave de host se quejarán tras una reconstrucción, y esa queja es el comportamiento correcto, no un error que haya que silenciar.

Decide qué cambia realmente el autoalojamiento

Ejecutar tu propia VPN traslada la confianza de un operador de VPN a un proveedor de alojamiento y a ti. Ese es un cambio real, y no es lo mismo que eliminar a un tercero. Si el objetivo era impedir que una VPN comercial observara el tráfico, el proveedor todavía puede observar la red de la instancia, su disco y sus registros de facturación.

Tus propios registros describen tu software y no describen todos los registros de infraestructura que guarda el proveedor. Lo contrario también es cierto: la visibilidad de la infraestructura no establece qué retiene un proveedor. Ambas preguntas necesitan la política del proveedor y tu configuración, y ninguna responde a la otra.

Escribe la respuesta como una división del trabajo: qué capa falló, quién puede repararla y cuánto tarda esa reparación. El autoalojamiento cambia en quién confías, y la parte útil del ejercicio es saber exactamente para qué capa confías en ellos.