Dous alias SSH, un servidor: VPN directa ou host de salto

Manteña unha ruta VPN aprobada e unha ruta de bastión aprobada como alias e marcadores separados, para que ningún atallo teña que adiviñar que ruta está autorizada.

O mesmo servidor privado responde por unha VPN aprobada e a través dun bastión aprobado, e vostede quere un marcador de Emacs para cada un en lugar dun atallo que adiviñe. A decisión non é que ruta é mellor; é que ruta está autorizada para o traballo que ten diante. Manteña ambas explícitas, nomee cada unha por separado e deixe que o nome do ficheiro diga cal escolleu.

Condición unha: que rutas están aprobadas?

Un host de salto non é unha alternativa automática a un requisito de VPN, e unha VPN non é unha licenza para saltar un bastión aprobado. Pregunte que rutas están autorizadas para a súa conta e para estes datos. Se ambas o están, ten elección; se só unha, o conxunto de marcadores ten unha entrada. Esa resposta vén do propietario dos datos, non da ruta que hoxe funciona por casualidade.

Escriba a resposta, porque a distinción desaparece axiña durante un incidente.

Ambas as rutas tamén necesitan a súa propia configuración de conta e identidade. Un alias compartido que funciona por unha ruta pode fallar pola outra por razóns que non teñen nada que ver coa rede.

Condición dúas: pode nomear cada ruta de forma distinta?

Unha configuración de SSH pode conter dous alias de host para un enderezo, cada un cun comportamento de proxy distinto. Poña os bloques específicos antes de calquera comodín amplo, porque o primeiro valor obtido gaña para a maioría das opcións.

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

O enderezo de arriba é un exemplo; substitúao polo que documente o seu equipo. O alias de salto tamén necesita a conta aprobada do bastión, o que normalmente significa un segundo bloque Host para o propio bastión. Desactivar aquí a compartición de conexións mantén honesta a comparación de rutas, xa que unha conexión multiplexada reutilizada pode sobrevivir ao cambio de ruta que intenta observar.

Entón os nomes de ficheiro remotos seguen sendo distintos e lexibles.

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

Condición tres: o editor coñece a diferenza?

TRAMP trata eses dous nomes de ficheiro como destinos distintos, que é xusto o que quere. Marque cada un cun nome que diga que ruta usa, e volva abrir o marcador en lugar de editar o significado dun único destino. Dous marcadores tamén fan visible a comparación: pode abrir ambos e ver cal falla sen cambiar ningunha configuración.

Un axuste merece atención cando hai ProxyJump: a compartición de conexións de TRAMP debe estar desactivada para as conexións pertinentes, así que pon tramp-use-connection-share en nil antes de abrirlas. É un axuste de compatibilidade, non unha solución para unha ruta ausente, e non fai que unha ruta non autorizada estea autorizada. As preguntas frecuentes de TRAMP documentan os marcadores como a forma admitida de acurtar estes nomes.

Un marcador que cambia de ruta en silencio é peor que ningún.

Por que a icona de rede non demostra nada

O valor global de estado 70 de NetworkManager significa que a máquina ten conectividade global. Non nomea ningún perfil de VPN, e o Wi-Fi normal satisfaino. Un túnel só para a rede privada que leva exactamente a ruta que necesita pode deixar ese valor agregado intacto. Por iso un atallo ligado á icona pode informar de dispoñibilidade para unha ruta que nunca probou.

Lea o estado da conexión concreta en lugar do global.

Se automatiza algo, consulte a conexión nomeada e despois comprobe a ruta de destino, a resposta do resolutor e o alcance de SSH nesa orde. Cada un deles pode fallar mentres o anterior ten éxito, e colapsalos nun único booleano é como a automatización acaba informando de éxito para unha ruta que nunca utilizou.

Que facer cando unha ruta deixa de funcionar

Garde os seus búferes antes de investigar, porque unha sesión TRAMP existente pode sobrevivir a un cambio de ruta e despois fallar na seguinte escritura. Péchea mediante a limpeza admitida, volva abrir o marcador e compare as dúas rutas en lugar de supoñer que o servidor está caído.

Manteña activa a verificación de clave de host tanto para o bastión como para o destino.

Unha ruta distinta non o autoriza a aceptar unha clave de servidor que non esperaba, nin fai aceptable unha ruta non aprobada. Ambas son decisións separadas da que estaba tomando.

Artigos relacionados