Éditeur VPN distant via SSH : quelle machine modifiez-vous ?

Le transfert X11 place la fenêtre de l'éditeur sur votre ordinateur portable pendant que le processus continue de tourner sur l'hôte distant. Cet écart est tout le piège : vous regardez une fenêtre locale et modifiez un profil distant, et une mauvaise supposition sur la machine qui possède la modification peut couper la liaison SSH par laquelle vous travaillez. La liste de vérification ci-dessous fixe l'hôte et le profil avant que quoi que ce soit ne soit enregistré. Chaque étape a une condition d'arrêt, donc un échec précoce coûte peu.

Étape 1 : nommez la machine qui possède le profil

Exécutez les commandes d'identité dans le shell que vous allez configurer, et lisez la réponse au lieu de la déduire de l'invite. Le nom d'hôte affiché dans l'invite est une chaîne imprimée par votre shell ; le nom d'hôte du noyau est ce à quoi le reste de cette liste se fie. Si les deux ne concordent pas, vous êtes sur la mauvaise machine ou l'invite est décorée par votre shell local. Arrêtez-vous et reconnectez-vous à l'hôte prévu avant de continuer.

hostnamectl
hostname -f
ip -brief address

La question suivante est de savoir si cette machine doit héberger le VPN. Configurer le client du portable et configurer le client de l'hôte distant produisent des routes, un DNS et des modes de défaillance différents. Décidez lequel vous voulez dire avant de toucher à un profil, et consignez la décision là où la personne suivante la trouvera.

Étape 2 : lisez le profil par UUID, pas par libellé

NetworkManager identifie une connexion par UUID, tandis que le nom est un libellé que n'importe qui peut modifier ou dupliquer. Listez les deux et faites correspondre l'entrée que vous visez réellement, surtout sur un hôte où plusieurs profils VPN ont été importés au fil des ans.

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

Les entrées enregistrées et les connexions actives répondent à des questions différentes : la première liste ce qui existe, la seconde liste ce qui transporte du trafic en ce moment. La ligne des autorisations décrit la politique locale de votre session et ne dit rien sur l'acceptation du compte par la passerelle VPN. Si le profil dont vous avez besoin n'est pas dans la liste enregistrée, arrêtez-vous ici, car modifier la mauvaise entrée est pire que ne rien modifier.

Une fois l'UUID obtenu, placez-le dans une variable et utilisez cette variable dans chaque commande ultérieure. Cela élimine une classe d'erreurs de copier-coller et rend la transcription reproductible.

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

Étape 3 : décidez si un éditeur graphique est le bon outil

Un éditeur qui a besoin d'une invite polkit ou d'un agent de secrets n'en obtiendra pas simplement parce que sa fenêtre apparaît sur votre portable. Ces composants s'exécutent dans le contexte de la session distante, et transférer un affichage ne les transfère pas. Si l'éditeur échoue à enregistrer avec une erreur d'autorisation ou de secret, l'affichage n'est pas le problème.

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

OpenSSH active le transfert X11 avec -X et documente la prudence qui l'accompagne : l'hôte distant peut atteindre votre affichage local, ce qui est une véritable frontière de confiance. Le transfert de confiance avec -Y supprime certains de ces contrôles et ne devrait jamais être la solution réflexe pour une application qui échoue avec les réglages par défaut. Si votre organisation publie une méthode d'administration à distance, utilisez-la plutôt que d'inventer une variante. Dans la plupart des cas, l'éditeur en ligne de commande est la surface la plus petite et la meilleure réponse.

Arrêtez-vous ici si le seul chemin qui fonctionne exige -Y et que vous ne pouvez pas expliquer pourquoi. C'est une décision pour celui qui possède la politique de sécurité, pas un contournement à garder dans un script personnel.

Étape 4 : gardez un chemin de récupération avant d'activer quoi que ce soit

Une modification VPN peut supprimer la route dont dépend votre session SSH, alors prévoyez un chemin de retour avant d'activer le profil. L'accès console, une adresse de gestion hors bande ou un retour arrière planifié comptent ; l'espoir que la modification fonctionne ne compte pas.

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

Activez uniquement le profil prévu, puis vérifiez depuis l'hôte distant : la route par défaut, le chemin de retour SSH et une ressource qui devrait être joignable par le tunnel. Une vérification réussie depuis votre portable teste le chemin du portable et ne dit rien de l'hôte distant. Si la session tombe, utilisez le chemin de récupération plutôt que de vous reconnecter à l'aveugle. Enregistrer un profil n'est pas l'activer, et activer n'est pas vérifier.

Notez l'UUID, les valeurs de propriétés que vous avez modifiées et les commandes utilisées pour les vérifier. La personne suivante qui touchera cet hôte aura besoin des trois, et une transcription vaut plus qu'un résumé disant que le VPN a été réparé. Une liste de vérification qui se termine sans note de retour arrière est une demi-liste.