Editor VPN remoto por SSH: ¿qué máquina está editando?

El reenvío X11 pone la ventana del editor en su portátil mientras el proceso sigue ejecutándose en el host remoto. Esa brecha es toda la trampa: usted mira una ventana local y edita un perfil remoto, y una suposición equivocada sobre qué máquina posee el cambio puede cortar el enlace SSH por el que trabaja. La lista de comprobación de abajo fija el host y el perfil antes de guardar nada. Cada paso tiene una condición de parada, así que un fallo temprano sale barato.

Paso 1: nombre la máquina que posee el perfil

Ejecute los comandos de identidad en el shell que va a configurar y lea la respuesta en lugar de suponerla por el indicador. Un nombre de host en el indicador es una cadena que imprimió su shell; el nombre de host del kernel es lo que confía el resto de esta lista. Si los dos no coinciden, está en la máquina equivocada o el indicador está decorado por su shell local. Deténgase y vuelva a conectarse al host previsto antes de continuar.

hostnamectl
hostname -f
ip -brief address

La siguiente pregunta es si esta máquina debe alojar la VPN siquiera. Configurar el cliente del portátil y configurar el cliente del host remoto producen rutas distintas, DNS distinto y modos de fallo distintos. Decida cuál de los dos quiere decir antes de tocar un perfil, y escriba la decisión donde la encuentre la siguiente persona.

Paso 2: lea el perfil por UUID, no por etiqueta

NetworkManager identifica una conexión por UUID, mientras que el nombre es una etiqueta que cualquiera puede editar o duplicar. Enumere ambos y haga coincidir la entrada que realmente quiere, sobre todo en un host donde se han importado varios perfiles VPN con los años.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
nmcli general permissions

Las entradas guardadas y las conexiones activas responden preguntas distintas: la primera enumera lo que existe, la segunda enumera lo que lleva tráfico ahora mismo. La línea de permisos describe la política local de su sesión y no dice nada sobre si la puerta de enlace VPN aceptará la cuenta. Si el perfil que necesita no está en la lista guardada, deténgase aquí, porque editar la entrada equivocada es peor que no editar ninguna.

Cuando tenga el UUID, póngalo en una variable y use esa variable en cada comando posterior. Eso elimina una clase de errores de copiar y pegar y hace que la transcripción sea reproducible.

UUID=$(nmcli -g UUID connection show 'Corp VPN')
nmcli connection edit uuid "$UUID"

Paso 3: decida si un editor gráfico es la herramienta adecuada

Un editor que necesita un aviso de polkit o un agente de secretos no lo tendrá solo porque su ventana aparezca en su portátil. Esos componentes se ejecutan en el contexto de la sesión remota, y reenviar una pantalla no los reenvía. Si el editor no puede guardar con un error de autorización o de secreto, la pantalla no es el problema.

echo "$DISPLAY"
ssh -X you@vpn-host
xauth list

OpenSSH habilita el reenvío X11 con -X y documenta la precaución que lo acompaña: el host remoto puede alcanzar su pantalla local, lo que es una frontera de confianza real. El reenvío de confianza con -Y elimina algunas de esas comprobaciones y nunca debería ser la solución refleja para una aplicación que falla con la configuración predeterminada. Si su organización publica un método de administración remota, use ese en lugar de inventar una variante. En la mayoría de los casos, el editor de línea de comandos es la superficie más pequeña y la mejor respuesta.

Deténgase aquí si el único camino que funciona requiere -Y y no puede explicar por qué. Esa es una decisión de quien posee la política de seguridad, no una solución alternativa para guardar en un script personal.

Paso 4: mantenga una vía de recuperación antes de activar nada

Un cambio de VPN puede eliminar la ruta de la que depende su sesión SSH, así que prepare una forma de volver antes de activar el perfil. El acceso por consola, una dirección de gestión fuera de banda o una reversión programada cuentan; la esperanza de que el cambio funcione no cuenta.

sudo systemctl status NetworkManager
ip route show default
ss -tn state established '( sport = :22 )'

Active solo el perfil previsto y luego verifique desde el host remoto: la ruta predeterminada, la ruta de retorno SSH y un recurso que debería ser accesible por el túnel. Una comprobación correcta desde su portátil prueba la ruta del portátil y no dice nada del host remoto. Si la sesión se cae, use la vía de recuperación en lugar de reconectarse a ciegas. Guardar un perfil no es activarlo, y activarlo no es verificarlo.

Anote el UUID, los valores de propiedad que cambió y los comandos que usó para verificarlos. La siguiente persona que toque este host necesitará los tres, y una transcripción vale más que un resumen que diga que la VPN quedó arreglada. Una lista de comprobación que termina sin una nota de reversión es media lista.