Réglages de l’outil VPN : environnement au lancement ou export dans le hook ?

Un hook VPN qui exporte un point de terminaison d’API modifie l’environnement des processus qu’il lance, pas celui du terminal déjà ouvert quand le tunnel est monté. Cette seule distinction explique la plupart des rapports « l’outil appelle toujours le point de terminaison public ». Il existe deux emplacements viables pour le réglage, et le choix dépend de qui le consomme et de la fréquence de changement. Comparez-les avant d’ajouter un autre script de démarrage.

Deux endroits où le réglage peut vivre

La première option est un préfixe sur la commande elle-même : la valeur n’existe que pour cet appel et disparaît avec lui. La seconde est un export à l’intérieur du hook de connexion, qui atteint chaque processus que le hook lance ensuite. Elles diffèrent par la portée et la durée, pas par la syntaxe, et cette différence décide de la plupart des échecs.

Le tableau fait paraître le hook peu coûteux et cache la vraie facture : il sélectionne aussi un point de terminaison privé pour des commandes sans rapport avec la tâche. Lisez chaque ligne comme une contrainte, non comme une préférence. Si le point de terminaison change selon la tâche, le préfixe gagne en précision même s’il coûte une frappe.

Pourquoi le hook ne peut pas atteindre un shell déjà ouvert

Les variables d’environnement sont remises à un processus lors de la création de l’image du processus. Un shell démarré avant la connexion conserve la copie qu’il a reçue, et un export exécuté dans le hook n’est pas une diffusion à chaque processus de la machine. Seuls les propres enfants du hook en héritent. Les propres enfants d’un shell prennent ce que le shell détient au moment de leur démarrage, et c’est pourquoi la même commande peut fonctionner dans un terminal et échouer dans un autre.

Il en va de même pour un éditeur graphique. Son hôte d’extensions, son terminal intégré et son serveur de langage en arrière-plan ont été détachés au lancement et détiennent leurs propres copies. Rouvrir un dossier ne redémarre pas nécessairement ces enfants, donc le réglage ajouté n’arrive toujours jamais.

Le test le moins coûteux consiste à afficher la variable depuis l’endroit qui échoue, non depuis le shell qui fonctionne. Si le processus qui échoue a démarré avant le tunnel, l’export n’a jamais eu la moindre chance.

La forme par commande, écrite

Un préfixe garde le choix visible dans la commande qui l’utilise, ce qui aide quand le point de terminaison change d’une tâche à l’autre :

env INTERNAL_API='https://internal-api.example.net:8443' my-work-tool

La commande est illustrative : my-work-tool est un espace réservé et INTERNAL_API n’est pas un standard de VPN, remplacez donc par le réglage documenté du programme que vous exécutez réellement et par votre propre hôte approuvé. Ne mettez pas de jeton ni de mot de passe sur la même ligne, car ils finissent dans l’historique du shell.

Quand plusieurs commandes relèvent d’une même tâche, un court script d’enveloppe relu définit les variables puis les lance. Cela conserve une définition unique sans rendre la valeur globale pour chaque commande future du terminal.

Recharger, redémarrer ou laisser tranquille

Pour un outil déjà en cours d’exécution, préférez son propre rechargement ou son profil d’espace de travail lorsqu’il en a un. Sinon, enregistrez le travail et redémarrez le composant qui lit le réglage, souvent un serveur de langage plutôt que la fenêtre de l’éditeur. Redémarrer la fenêtre en supposant que les processus enfants ont suivi est précisément ce qui donne l’impression qu’un rechargement ne fonctionne pas.

La déconnexion est une décision distincte. La mise en pause, la fermeture ou la reconnexion relèvent de l’application, et la variable du point de terminaison ne la contrôle pas. Traitez la variable comme une configuration qui choisit une adresse, non comme une règle sur le trafic réseau utilisable ensuite, et les deux sujets restent séparables.