Nastavení nástroje VPN: prostředí při spuštění, nebo export v hooku?
Hook spouští své vlastní potomky, ne shell, který jste už otevřeli. Prostředí při spuštění drží soukromý koncový bod jen v tom jediném příkazu, který ho potřebuje.
Hook VPN, který exportuje koncový bod API, mění prostředí procesů, které spouští, ne terminálu, jenž byl otevřený už při navázání tunelu. Právě tento rozdíl vysvětluje většinu hlášení „nástroj pořád volá veřejný koncový bod“. Existují dvě použitelná místa, kam nastavení umístit, a volba závisí na tom, kdo ho spotřebovává a jak často se mění. Porovnejte je, než přidáte další spouštěcí skript.
Dvě místa, kde nastavení může žít
První možnost je prefix na samotném příkazu: hodnota existuje pro to jedno volání a s ním zmizí. Druhá možnost je export uvnitř připojovacího hooku, který zasáhne každý proces, jenž hook od té chvíle spustí. Liší se dosahem a životností, ne syntaxí, a tento rozdíl rozhoduje většinu selhání.
| Property | Prefix on the command | Export from the hook |
|---|---|---|
| Who receives it | That invocation only | Children the hook starts |
| Lifetime | Until the process exits | Until the hook's own session ends |
| Leakage | Scoped to one command | Applies to later commands in that session |
| Repeat cost | Every invocation | Once per connection |
| Works for an open editor | No, unless the editor is started with it | No |
Tabulka dělá hook levným a skrývá skutečný účet: vybírá soukromý koncový bod i pro příkazy, které s úkolem nemají nic společného. Čtěte každý řádek jako omezení, ne jako preferenci. Pokud se koncový bod mění podle úkolu, prefix vítězí v přesnosti, i když stojí jedno stisknutí klávesy.
Proč hook nedosáhne na už otevřený shell
Proměnné prostředí se procesu předávají při vytvoření obrazu procesu. Shell, který začal před připojením, si drží kopii, kterou dostal, a export provedený uvnitř hooku není vysílání do každého procesu na stroji. Dědí ho jen vlastní potomci hooku. Vlastní potomci shellu přebírají to, co shell drží v okamžiku jejich spuštění, a proto stejný příkaz může v jednom terminálu fungovat a v jiném selhat.
Totéž platí pro grafický editor. Jeho hostitel rozšíření, vestavěný terminál a jazykový server na pozadí se při spuštění rozdvojili a drží si vlastní kopie. Opětovné otevření složky tyto potomky nutně nerestartuje, takže nastavení, které jste přidali, stále nikdy nedorazí.
Nejlevnější test je vypsat proměnnou z místa, které selhává, ne ze shellu, který funguje. Pokud selhávající proces začal před tunelem, export neměl žádnou šanci.
Forma pro jednotlivý příkaz, rozepsaná
Prefix drží volbu viditelnou v příkazu, který ji používá, což pomáhá, když se koncový bod mezi úkoly mění:
env INTERNAL_API='https://internal-api.example.net:8443' my-work-toolPříkaz je ilustrativní: my-work-tool je zástupný název a INTERNAL_API není standard VPN, takže doplňte zdokumentované nastavení programu, který skutečně spouštíte, a svůj schválený hostitel. Nedávejte token ani heslo na stejný řádek, protože skončí v historii shellu.
Když k jednomu úkolu patří několik příkazů, krátký zkontrolovaný obalový skript nastaví proměnné a pak je spustí. Tím zůstává jediná definice, aniž by se hodnota stala globální pro každý budoucí příkaz v terminálu.
Znovu načtěte, restartujte, nebo to nechte být
U nástroje, který už běží, dejte přednost jeho vlastnímu znovunačtení nebo profilu pracovního prostoru, pokud ho má. Jinak uložte práci a restartujte komponentu, která nastavení čte, což je často jazykový server, ne okno editoru. Restartování okna s domněnkou, že potomci ho následovali, je důvod, proč znovunačtení vypadá, že nefunguje.
Odpojení je samostatné rozhodnutí. Pozastavení, zavření nebo opětovné připojení patří aplikaci a proměnná koncového bodu to neřídí. Berte proměnnou jako konfiguraci, která volí adresu, ne jako pravidlo o tom, jaký síťový provoz se smí potom použít, a obě věci zůstanou oddělitelné.