Dos alias SSH, un servidor: VPN directa o host de salto

El mismo servidor privado responde por una VPN aprobada y a través de un bastión aprobado, y usted quiere un marcador de Emacs para cada uno en lugar de un atajo que adivine. La decisión no es qué ruta es mejor; es qué ruta está autorizada para el trabajo que tiene delante. Mantenga ambas explícitas, nómbrelas por separado y deje que el nombre del archivo diga cuál eligió.

Condición uno: ¿qué rutas están aprobadas?

Un host de salto no es un respaldo automático frente a un requisito de VPN, y una VPN no es una licencia para saltarse un bastión aprobado. Pregunte qué rutas están autorizadas para su cuenta y para estos datos. Si ambas lo están, tiene elección; si solo una, el conjunto de marcadores tiene una entrada. Esa respuesta viene del propietario de los datos, no de la ruta que hoy funciona por casualidad.

Escriba la respuesta, porque la distinción desaparece deprisa durante un incidente.

Ambas rutas también necesitan su propia configuración de cuenta e identidad. Un alias compartido que funciona por una ruta puede fallar por la otra por razones que no tienen nada que ver con la red.

Condición dos: ¿puede nombrar cada ruta de forma distinta?

Una configuración de SSH puede contener dos alias de host para una dirección, cada uno con un comportamiento de proxy distinto. Ponga los bloques específicos antes de cualquier comodín amplio, porque el primer valor obtenido gana para la mayoría de las opciones.

Host proj-direct proj-bastion
    HostName 10.60.0.21
    User analyst
    ControlPath none

Host proj-direct
    ProxyJump none

Host proj-bastion
    ProxyJump gw.example.com

La dirección de arriba es un ejemplo; sustitúyala por la que documente su equipo. El alias de salto también necesita la cuenta aprobada del bastión, lo que normalmente significa un segundo bloque Host para el propio bastión. Desactivar aquí la compartición de conexiones mantiene honesta la comparación de rutas, ya que una conexión multiplexada reutilizada puede sobrevivir al cambio de ruta que intenta observar.

Entonces los nombres de archivo remotos siguen siendo distintos y legibles.

/ssh:proj-direct:/srv/project/README.md
/ssh:proj-bastion:/srv/project/README.md

Condición tres: ¿el editor conoce la diferencia?

TRAMP trata esos dos nombres de archivo como destinos distintos, que es justo lo que quiere. Marque cada uno con un nombre que diga qué ruta usa, y vuelva a abrir el marcador en lugar de editar el significado de un único destino. Dos marcadores también hacen visible la comparación: puede abrir ambos y ver cuál falla sin cambiar ninguna configuración.

Un ajuste merece atención cuando hay ProxyJump: la compartición de conexiones de TRAMP debe estar desactivada para las conexiones pertinentes, así que ponga tramp-use-connection-share en nil antes de abrirlas. Es un ajuste de compatibilidad, no una solución para una ruta ausente, y no hace que una ruta no autorizada esté autorizada. Las preguntas frecuentes de TRAMP documentan los marcadores como la forma admitida de acortar estos nombres.

Un marcador que cambia de ruta en silencio es peor que ninguno.

Por qué el icono de red no demuestra nada

El valor global de estado 70 de NetworkManager significa que la máquina tiene conectividad global. No nombra ningún perfil de VPN, y el Wi-Fi normal lo satisface. Un túnel solo para la red privada que lleva exactamente la ruta que necesita puede dejar ese valor agregado intacto. Por eso un atajo vinculado al icono puede informar de disponibilidad para una ruta que nunca ha probado.

Lea el estado de la conexión concreta en lugar del global.

Si automatiza algo, consulte la conexión nombrada y luego compruebe la ruta de destino, la respuesta del resolutor y el alcance de SSH en ese orden. Cada uno de ellos puede fallar mientras el anterior tiene éxito, y colapsarlos en un único booleano es como la automatización acaba informando de éxito para una ruta que nunca utilizó.

Qué hacer cuando una ruta deja de funcionar

Guarde sus búferes antes de investigar, porque una sesión TRAMP existente puede sobrevivir a un cambio de ruta y luego fallar en la siguiente escritura. Ciérrela mediante la limpieza admitida, vuelva a abrir el marcador y compare las dos rutas en lugar de suponer que el servidor está caído.

Mantenga activa la verificación de clave de host tanto para el bastión como para el destino.

Una ruta distinta no le autoriza a aceptar una clave de servidor que no esperaba, ni hace aceptable una ruta no aprobada. Ambas son decisiones separadas de la que estaba tomando.