Consola, shell y SSH: tres puertas distintas a la misma máquina

No consigues alcanzar una máquina. Antes de entrar en pánico, hazte una pregunta: ¿qué puerta estabas usando?

Hay tres puertas distintas a la misma máquina, y cada una depende de que funcionen cosas diferentes. Saber cuál se cerró te dice directamente dónde está el problema.

Tres puertas

Consola. Mirar la pantalla y el teclado de la máquina. El equivalente a acercarse a un servidor físico y conectar un monitor. No usa la red del invitado, pasa por el anfitrión.

Shell. Escribir un comando y recibir su salida. No imita una pantalla, abre directamente un canal de comandos.

SSH. Un servicio que corre dentro del invitado. Necesita la red, necesita el servicio en marcha, necesita credenciales.

La regla: cuanto más cómoda la puerta, más partes del invitado deben funcionar

SSH es la más cómoda. Te conectas desde tu propio terminal, copiar y pegar funciona, mueves archivos. A cambio exige lo máximo: la configuración de red tiene que estar bien, la interfaz tiene que estar levantada, el servicio tiene que correr, el cortafuegos tiene que permitirlo, la clave o la contraseña tienen que ser válidas. Si se rompe un eslabón de esa cadena, la puerta se cierra.

La consola es la menos cómoda. Miras una pantalla dentro de un navegador, y copiar y pegar suele ser incómodo. A cambio no exige casi nada: la red del invitado puede estar rota, el cortafuegos puede bloquearlo todo, SSH puede no estar instalado, y la pantalla aparece igual. Porque esa pantalla viene del anfitrión, no de la red del invitado.

Por eso la consola es un camino de recuperación. No porque sea cómoda, sino porque depende de muy poco.

El incidente clásico

Cambias un ajuste de red. Lo aplicas. La conexión se cae y no vuelve.

Puede que lo que hiciste ni siquiera estuviera mal: a veces el ajuste es correcto y la sesión simplemente muere mientras la interfaz cambia. Pero ahora ya no alcanzas la máquina por red, y para arreglarlo tendrías que alcanzarla.

Abres la consola, aparece la pantalla, corriges el ajuste. Como nunca pasó por la red, la red rota no la tocó.

El hábito práctico que sale de ahí: confirma que la consola abre antes de tocar un ajuste de red. Haz el trabajo arriesgado cuando ya tienes en la mano un camino de recuperación que funciona, en vez de buscarlo después.

Del lado del shell, un contenedor y una máquina virtual no son lo mismo

Esta distinción sorprende a mucha gente, porque en el panel los dos están uno al lado del otro y ofrecen el mismo botón.

En un contenedor el anfitrión puede entrar directamente. El contenedor comparte el núcleo del anfitrión, así que los procesos de dentro ya son visibles para él. El anfitrión puede ejecutar un comando ahí dentro sin pedirle nada al interior.

En una máquina virtual no funciona así. Una máquina virtual es una caja sellada: el anfitrión ve su disco y su memoria como bloques y no sabe qué contienen. El anfitrión no puede meter un comando dentro de la caja.

La única vía de entrada es que algo dentro de la caja esté escuchando. Eso es exactamente el agente invitado: un pequeño servicio instalado dentro de la máquina virtual que escucha las peticiones del anfitrión y las responde. Si no está instalado, la puerta del shell no existe para esa máquina virtual, y eso no es una avería, es una consecuencia de la arquitectura.

Por la misma razón el shell no funciona mientras una máquina virtual está apagada. No hay nada escuchando. La consola, en cambio, también muestra la pantalla de una máquina apagada, y cuando la enciendes ves lo que ocurre desde el primer segundo.

La consola también tiene límites

Siendo honestos, la consola no es mágica.

Si el anfitrión está apagado, las tres puertas están cerradas. La consola pasa por el anfitrión, así que se va con él.

Y hay algo más: la consola te da una pantalla, no archivos. Si necesitas sacar un archivo, la consola es una mala herramienta. Buena para recuperar, no para el trabajo diario.

Por último, el acceso a consola es un permiso aparte. Que un usuario pueda leer el panel no significa que pueda mirar las pantallas de las máquinas, y esa separación es deliberada: una pantalla muestra el contenido del trabajo en curso.

Qué hace Atlas

Atlas abre la consola desde su propia pantalla, sin pedir un segundo inicio de sesión. Suena a poco, pero detrás hay una historia que merece contarse con honestidad.

La consola vive en realidad en la dirección propia del panel de Proxmox. Atlas está en otra. Para un navegador son dos sitios distintos, y la sesión de uno no pasa sola al otro. Sin hacer nada, el usuario que pulsa el botón de consola recibe un error de "sin sesión" y se le pide entrar al panel por segunda vez.

La primera solución fue esta: entregar la sesión al panel desde dentro de un marco invisible. Funcionaba. Luego los navegadores endurecieron sus reglas sobre cookies de terceros y dejó de funcionar. No había ningún fallo en el código; se movió el suelo bajo él.

La segunda solución se quedó porque es más sólida: la consola se sirve desde la dirección propia de Atlas. El navegador ve un único sitio, no queda ninguna sesión que entregar, y el problema desaparece en su origen.

Dos detalles pequeños pero honestos: las cabeceras que ponen cookies en las respuestas que llegan del panel se eliminan, así que Atlas no acumula cookies del panel en su propia dirección. Y la conexión hacia el panel se queda dentro de la máquina, nunca sale a la red.

La lección general, al margen de cualquier producto: una solución que funcionaba y deja de funcionar no siempre significa un fallo. A veces cambió una suposición en la que te apoyabas. La solución que perdura es la que se apoya en menos suposiciones.