VPN 도구 설정: 시작 시점의 환경인가, 훅 안의 내보내기인가

API 엔드포인트를 내보내는 VPN 훅이 바꾸는 것은 자기가 띄우는 프로세스의 환경이지, 터널이 올라올 때 이미 열려 있던 터미널의 환경이 아닙니다. 이 한 가지 차이가 «도구가 여전히 공용 엔드포인트를 호출한다»는 보고의 대부분을 설명합니다. 설정을 둘 수 있는 실용적인 자리는 두 곳이고, 선택은 누가 그것을 쓰는지와 얼마나 자주 바뀌는지에 달려 있습니다. 또 다른 시작 스크립트를 넣기 전에 둘을 비교해 보십시오.

설정이 머물 수 있는 두 자리

첫 번째 선택지는 명령 자체에 붙는 접두사이며, 값은 그 한 번의 호출에만 존재하고 호출과 함께 사라집니다. 두 번째는 연결 훅 안의 내보내기로, 그 시점 이후 훅이 띄우는 모든 프로세스에 닿습니다. 둘은 문법이 아니라 도달 범위와 수명이 다르고, 그 차이가 대부분의 실패를 가릅니다.

표는 훅을 값싸 보이게 하는 한편, 작업과 아무 상관이 없는 명령에도 사설 엔드포인트를 골라 버려 실제 청구서를 감춥니다. 각 행은 선호가 아니라 제약으로 읽으십시오. 엔드포인트가 작업마다 바뀐다면 키 한 번 누르는 비용을 치르더라도 접두사가 정확성에서 이깁니다.

훅이 이미 열린 셸에 닿지 못하는 이유

환경 변수는 프로세스 이미지가 만들어질 때 그 프로세스에 전달됩니다. 연결 전에 시작한 셸은 받은 사본을 그대로 들고 있고, 훅 안에서 실행한 내보내기는 기계의 모든 프로세스로 가는 방송이 아닙니다. 상속하는 것은 훅 자신의 자식뿐입니다. 셸 자신의 자식은 시작하는 순간 셸이 들고 있는 것을 물려받으므로, 같은 명령이 한 터미널에서는 되고 다른 터미널에서는 실패합니다.

그래픽 편집기도 마찬가지입니다. 확장 호스트, 내장 터미널, 백그라운드 언어 서버는 시작할 때 갈라져 나와 각자의 사본을 들고 있습니다. 폴더를 다시 열어도 그 자식들이 반드시 다시 시작되지는 않으므로, 추가한 설정은 끝내 도착하지 않습니다.

가장 값싼 검증은 잘 동작하는 셸이 아니라 실패하는 지점에서 변수를 찍어 보는 것입니다. 실패하는 프로세스가 터널보다 먼저 시작했다면 내보내기는 기회조차 없었습니다.

명령별 형태를 적어 두면

접두사는 그 선택을 쓰는 명령 안에 그대로 보이게 두므로, 엔드포인트가 작업마다 바뀔 때 도움이 됩니다:

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

이 명령은 예시일 뿐이며, my-work-tool는 자리 표시자이고 INTERNAL_API는 VPN 표준이 아니므로 실제로 실행하는 프로그램의 문서화된 설정과 직접 승인한 호스트로 바꾸십시오. 같은 줄에 토큰이나 비밀번호를 두면 셸 기록에 남으므로 두지 마십시오.

여러 명령이 한 작업에 속한다면, 짧고 검토된 래퍼 스크립트가 변수를 설정한 뒤 그것들을 실행합니다. 이렇게 하면 정의는 하나로 유지되고, 값이 터미널의 앞으로의 모든 명령에 전역이 되지는 않습니다.

다시 불러오든지, 다시 시작하든지, 그대로 두든지

이미 실행 중인 도구라면 있다면 자체 다시 불러오기나 작업 공간 프로필을 우선하십시오. 없다면 작업을 저장하고 설정을 읽는 구성 요소(대개 편집기 창이 아니라 언어 서버)를 다시 시작하십시오. 창만 다시 시작하고 자식 프로세스도 따라왔다고 가정하는 것이 다시 불러오기가 안 되는 것처럼 보이는 이유입니다.

연결 해제는 별개의 결정입니다. 일시 정지, 닫기, 다시 연결은 애플리케이션의 몫이고 엔드포인트 변수가 그것을 제어하지 않습니다. 변수는 주소를 고르는 설정으로 다루고, 이후 어떤 네트워크 트래픽을 써도 되는지에 대한 규칙으로 다루지 않으면 두 관심사는 분리된 채로 남습니다.