Deux alias SSH, un serveur : VPN direct ou hôte de rebond

Le même serveur privé répond par un VPN approuvé et via un bastion approuvé, et vous voulez un signet Emacs pour chacun plutôt qu’un raccourci qui devine. La décision n’est pas quel chemin est meilleur ; c’est quel chemin est autorisé pour le travail qui vous attend. Gardez les deux explicites, nommez-les séparément, et laissez le nom du fichier dire lequel vous avez choisi.

Première condition : quels chemins sont approuvés ?

Un hôte de rebond n’est pas un repli automatique autour d’une exigence de VPN, et un VPN n’est pas une licence pour contourner un bastion approuvé. Demandez quelles routes sont autorisées pour votre compte et pour ces données. Si les deux le sont, vous avez le choix ; si un seul l’est, l’ensemble de signets comporte une entrée. Cette réponse vient du propriétaire des données, pas de la route qui fonctionne aujourd’hui par hasard.

Écrivez la réponse, car la distinction disparaît vite pendant un incident.

Les deux chemins ont aussi besoin de leur propre configuration de compte et d’identité. Un alias partagé qui fonctionne par une route peut échouer par l’autre pour des raisons qui n’ont rien à voir avec le réseau.

Deuxième condition : pouvez-vous nommer chaque chemin distinctement ?

Une configuration SSH peut contenir deux alias d’hôte pour une adresse, chacun avec un comportement de proxy différent. Placez les blocs spécifiques avant tout joker large, car la première valeur obtenue l’emporte pour la plupart des options.

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

L’adresse ci-dessus est un exemple ; remplacez-la par celle que votre équipe documente. L’alias de rebond a aussi besoin du compte approuvé du bastion, ce qui signifie généralement un second bloc Host pour le bastion lui-même. Désactiver ici le partage de connexions garde une comparaison de chemins honnête, car une connexion multiplexée réutilisée peut survivre au changement de route que vous essayez d’observer.

Alors les noms de fichiers distants restent distincts et lisibles.

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

Troisième condition : l’éditeur connaît-il la différence ?

TRAMP traite ces deux noms de fichiers comme des destinations différentes, ce qui est exactement ce que vous voulez. Marquez chacun d’un signet sous un nom qui indique quel chemin il utilise, et rouvrez le signet au lieu de modifier la signification d’une seule destination. Deux signets rendent aussi la comparaison visible : vous pouvez ouvrir les deux et voir lequel échoue sans changer aucune configuration.

Un réglage mérite attention lorsque ProxyJump est impliqué : le partage de connexions de TRAMP doit être désactivé pour les connexions concernées, alors mettez tramp-use-connection-share à nil avant de les ouvrir. C’est un réglage de compatibilité, pas un correctif pour une route manquante, et il ne rend pas autorisé un chemin non autorisé. La FAQ de TRAMP documente les signets comme le moyen pris en charge de raccourcir ces noms.

Un signet qui change de route en silence est pire que pas de signet du tout.

Pourquoi l’icône réseau ne prouve rien

La valeur globale d’état 70 de NetworkManager signifie que la machine a une connectivité globale. Elle ne nomme aucun profil VPN, et un Wi-Fi ordinaire la satisfait. Un tunnel limité au réseau privé qui porte exactement la route qu’il vous faut peut laisser cette valeur agrégée intacte. C’est pourquoi un raccourci lié à l’icône peut signaler une disponibilité pour un chemin qu’il n’a jamais testé.

Lisez l’état de la connexion précise plutôt que l’état global.

Si vous automatisez quoi que ce soit, interrogez la connexion nommée, puis vérifiez la route cible, la réponse du résolveur et l’accessibilité SSH dans cet ordre. Chacun de ces éléments peut échouer alors que le précédent réussit, et les réduire à un seul booléen est la façon dont l’automatisation finit par signaler un succès pour un chemin qu’elle n’a jamais utilisé.

Que faire quand un chemin cesse de fonctionner

Enregistrez vos tampons avant d’enquêter, car une session TRAMP existante peut survivre à un changement de route puis échouer à l’écriture suivante. Fermez-la via le nettoyage pris en charge, rouvrez le signet et comparez les deux chemins au lieu de supposer que le serveur est hors service.

Gardez la vérification de clé d’hôte active pour le bastion comme pour la destination.

Un chemin différent ne vous autorise pas à accepter une clé de serveur que vous n’attendiez pas, et il ne rend pas acceptable un chemin non approuvé non plus. Les deux sont des décisions distinctes de celle que vous preniez.