Cambiar la cerradura sin quedarte afuera

Nos tocó mover la red de acceso remoto de una empresa a una cuenta propia de ella. En el papel es media hora de trabajo: sacar el equipo de una red privada y meterlo en otra. El problema no estaba en los pasos. Estaba en que la única vía por la que podíamos entrar a hacerlo era, exactamente, la que íbamos a reemplazar.

El servidor se administraba por Tailscale. El escritorio remoto y la consola SSH viajaban por ahí, los dos. Y el primer comando de la migración es cerrar sesión de la red vieja. En el segundo en que se ejecuta, se corta la conexión desde la que uno está trabajando — a mitad de la operación, entre salir de una red y entrar a la otra.

Es una situación más común de lo que parece: la herramienta con la que te sostienes es la misma que estás a punto de mover. Y tiene una sola regla que la vuelve segura.

La salida de emergencia se prueba, no se supone#

Antes de tocar la red, hay que tener una segunda vía de entrada que no dependa de ella. Una puerta trasera que siga abierta aunque la migración falle a la mitad. En este caso era AnyDesk, que sale por internet con su propio relay y no depende de Tailscale — la red que íbamos a mover.

Pero tenerla instalada no es tenerla lista. Aquí está el matiz que separa una operación seria de una con los dedos cruzados: un servicio que aparece "en ejecución" no prueba nada. Prueba que arranca cuando alguien lo arranca, no que sirve cuando nadie está. La pregunta real es si esa puerta abre estando el operador fuera, y eso solo lo contesta una prueba de verdad: cerrar todo —el escritorio remoto, la consola, la red privada desde el propio equipo— y volver a entrar únicamente por la salida de emergencia.

Si esa prueba pasa, se puede tocar la red. Si no pasa, no se toca. No hay término medio, porque el término medio es quedarse afuera de un servidor que está a kilómetros.

Un servicio corriendo no prueba que te obedezca#

La red privada llevaba meses funcionando. Arrancaba sola tras un reinicio, aparecía conectada, movía tráfico. Por todos los indicadores visibles, estaba sana. Y cuando el administrador intentó migrarla, la rechazó:

ya está en uso por otra cuenta del sistema.

El perfil de la red pertenecía a un usuario distinto del que estaba operando. En este tipo de sistemas, la configuración de red se guarda por usuario, y ni la cuenta de máxima autoridad del sistema operativo puede cerrar la sesión de otro. El servicio corría perfecto; simplemente no le respondía a quien se lo pedía.

Es la misma lección que nada es servicio, girada un cuarto de vuelta: no basta con que un proceso esté vivo y sea inmortal. Hay que saber quién es su dueño, porque la autoridad para administrarlo no viene con ser administrador de la máquina — viene con ser el dueño del perfil. Lo descubrimos a la tercera, después de dos intentos que fallaron sin dañar nada. La salida fue entrar con la cuenta correcta y correr la migración desde ahí.

El peor resultado no es el error: es el falso éxito#

El primer rodeo que armamos era una tarea automatizada que corría desacoplada de la sesión, para sobrevivir al corte. Y tenía un defecto que vale la pena contar, porque es el más traicionero de todos.

La tarea verificaba el éxito comparando la dirección nueva contra la anterior: si cambió, migró. Pero por el rechazo del perfil, el dato de la dirección anterior le llegó vacío. Y "cualquier dirección es distinta de vacío" siempre da verdadero. La tarea declaró LISTO sobre una migración que jamás ocurrió, y reportó como nueva la dirección de siempre.

Un proceso que se detiene y grita se arregla en cinco minutos. Un proceso que sigue caminando y te dice "todo bien" con el dato equivocado se descubre cuando ya decidiste sobre él — aquí, cuando intentas reconectar a una dirección que crees nueva y no lo es. Por eso la corrección no fue solo arreglar el perfil: fue que la verificación abortara ruidosamente cuando le falta con qué comparar, en lugar de aprobar por omisión. Una comprobación que da luz verde cuando no tiene datos no es una comprobación; es un adorno.

Lo que no se enteró#

La migración, bien hecha, tomó segundos. Y mientras la red de acceso cambiaba de dueño, la planta siguió trabajando sin notar nada: el sistema administrativo y su base de datos viajaban por un canal separado, que no dependía de la red que estábamos moviendo. Esa separación no fue suerte. Fue el testigo que instalamos justo para esto — una vía que confirma, en todo momento, que la máquina sigue viva aunque el acceso remoto esté en el aire.

Ese es el resumen de una migración que se hace bien: el negocio no se entera de que ocurrió, y el operador nunca se queda sin forma de volver.

Lo que quedó como regla#

La vía de rescate se prueba antes de tocar nada, y la prueba es usarla de verdad. No alcanza con verla instalada; hay que entrar por ella con todo lo demás cerrado.

Antes de administrar un servicio, hay que saber de quién es. Estar vivo no es obedecerte, y la autoridad sobre un proceso no siempre viene de ser administrador de la máquina.

Y una automatización que no puede verificar su resultado debe detenerse, no aprobarlo. El falso éxito cuesta más que el error honesto, porque al error se le cree lo justo y al falso éxito se le cree todo.

Qué hicimos#

Probar la salida antes de tocar la entrada: cerrar sesión a propósito en el servidor y verificar que AnyDesk seguía respondiendo. Solo entonces la migración — un comando, con la ventana de rescate abierta al lado.

El epílogo, un año después#

Vale la pena contarlo porque no fue una hipótesis: pasó.

Google deshabilitó, sin aviso y sin explicación, la cuenta que era dueña de ese tailnet. Nadie pudo entrar a administrarlo. Al intentar cerrar sesión, la llave del nodo caducó y el servidor salió de la red privada.

La única forma de entrar a repararlo fueron las dos salidas alternas: AnyDesk y el escritorio remoto publicado. Desde ahí se creó una red nueva, con una cuenta dedicada de otro proveedor, y se remontó el servidor.

Si esa salida no hubiera estado instalada como servicio y probada de antemano, ese día se habría perdido el acceso a un servidor en producción. No fue suerte: fue el único paso que nos habíamos negado a saltarnos.

Caso real de una migración de infraestructura para una empresa manufacturera en México. Se removió todo dato que permitiera identificar a la empresa, y no se publican direcciones ni credenciales. La operación se completó sin interrupción del negocio.