La sesión SSH muere con la VPN: ¿tmux o un ejecutor de tareas?

El indicador de la VPN se pone verde, la ruta vuelve, y la ventana SSH que dejó abierta nunca vuelve a devolver el símbolo del sistema. Restaurar una ruta no restaura la conversación TCP que la usaba, así que todo lo que se escribió en esa ventana se ha perdido. Si la preocupación real es un búfer del editor o una migración larga, la solución es dejar de atar ese trabajo a una sola conexión. tmux y un ejecutor de tareas resuelven mitades distintas de ese problema.

Una VPN reconectada no reanuda el socket

TCP no tiene noción de reanudar tras un cambio de dirección. La conexión SSH se identifica por ambos extremos, y cuando el túnel se reconstruye, la dirección local puede cambiar y el viejo socket está muerto. El servidor lo nota al final, pero su terminal lo nota de inmediato.

Un keepalive de cliente detecta un par muerto antes. No devuelve la sesión, y no puede recuperar un comando que ya se estaba ejecutando. El keepalive es un detector, no una herramienta de recuperación. No dice nada sobre si el comando remoto sobrevivió.

Ponga el trabajo en el host remoto

Cree la sesión en el host remoto, no en el portátil. Conéctese como siempre, inicie tmux allí y ejecute el editor o la migración dentro. Desenganche con el prefijo predeterminado y la sesión sigue ejecutándose mientras la conexión SSH desaparece. Iniciar tmux en local protege su shell de una ventana cerrada, no un comando remoto de un túnel muerto.

ssh [email protected]
tmux new-session -s office-work

Cuando vuelva la VPN, abra una conexión SSH nueva al mismo host y vuelva a engancharse por el nombre. El objeto duradero es la sesión, no la conexión. Póngale un nombre que aún reconozca una semana después.

tmux frente a un ejecutor de tareas

tmux mantiene vivo un proceso interactivo mientras el host esté encendido. Un ejecutor de tareas o gestor de servicios mantiene viva una tarea no interactiva, registra su estado de salida y sobrevive a que la sesión SSH termine del todo. El primero es para trabajo que usted observa; el segundo, para trabajo que programa e inspecciona después.

Ninguno de los dos sobrevive a un reinicio a menos que el host esté configurado para restaurarlo. Una sesión de tmux muere con la máquina, y una tarea transitoria muere con el arranque a menos que se haya registrado como unidad. Elija según lo que el trabajo deba sobrevivir.

Ambos enfoques también necesitan un registro que pueda leer tras reconectarse. Sin uno, sabe que el proceso existe, pero no qué ha hecho. Anote la ruta del registro junto al nombre de la sesión.

Decida por lo que debe sobrevivir

Decida por lo peor que puede pasar si el trabajo se detiene a medias. Una sesión de editor pierde búferes sin guardar, lo cual es molesto pero recuperable. Una migración que confirma la mitad de sus cambios no lo es, y eso aboga por un ejecutor con un resultado registrado. Si la tarea es interactiva y larga, tmux más un registro escrito suele bastar.

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

Elija lo que elija, revise el resultado registrado antes de volver a ejecutar nada. Una última línea que falta le dice lo que vio el portátil, no lo que confirmó el servidor. Esa distinción es la razón para mantener el trabajo fuera de la conexión desde el principio, y el modelo de desenganchar y volver a enganchar es la versión más pequeña de ella.