OpenVPN의 up 스크립트가 너무 일찍 실행된 것일까요, 아니면 애초에 준비된 적이 없었던 것일까요?

up 스크립트는 실행되고 종료 코드 영을 반환하지만, 그 안의 작업은 터미널에서라면 두 초 뒤에 완벽하게 동작하는 사설 서비스에 도달하지 못합니다. 본능은 타이밍을 의심하고, 흔한 수리는 슬립이며, 그것은 경쟁을 이해하지 못한 채 숨길 뿐입니다. 더 유용한 해석은 “up”이 준비 보장이 아니라 훅의 이름이라는 것입니다. up은 터널 장치가 구성될 때 발생하며, 그 시점은 라우트와 DNS 보다 이르고 터널 뒤의 어떤 애플리케이션보다도 확실히 이릅니다.

셸 테스트가 성공한 것은 모든 것이 정리된 뒤에 실행되었기 때문입니다. 훅은 한 특정 순간에 실행되었습니다.

시작 순서에서 up의 위치

OpenVPN은 터널 장치를 구성한 다음 up 훅을 실행합니다. 라우트 설치는 그 이후 단계이며 자체 훅을 가지고 있으므로, up에 배치된 라우트 의존 작업은 유용한 경로가 없는 장치를 보게 됩니다. 라우트 작업을 route-up에 두면 타이밍 문제는 대개 사라집니다.

매뉴얼은 이 순서와 각 훅이 받는 환경을 기록합니다. 그 순서가 “내 셸에서는 된다”는 전형적인 보고에 대한 온전한 설명이며, 같은 스크립트가 한 머신에서는 통과하고 라우트 단계가 느린 다른 머신에서는 실패하는 이유이기도 합니다. 어느 결과도 스크립트의 품질에 대해 말해 주지 않습니다.

DNS와 애플리케이션 준비는 훨씬 더 나중에 옵니다. 설치된 라우트조차 원격 엔드포인트가 수신 중인지, 이름이 해석되는지, 또는 사용자 범위 작업을 위한 데스크톱 세션이 존재하는지의 증거가 아닙니다.

훅이 실제로 물려받는 것

훅은 OpenVPN 프로세스의 계정과 환경 아래에서 실행됩니다, 이는 여러분의 대화형 셸과 같지 않습니다. 사용자의 세션 버스, 데스크톱 환경, 또는 로그인할 때만 잠금 해제되는 자격 증명이 없을 수 있습니다. 작업에 실제로 그중 무엇이 필요한지 적어 두십시오.

이것은 네트워킹처럼 보이지만 사용자 컨텍스트에 의존하는 작업, 예컨대 사용자 자격 증명으로 공유를 마운트하거나 사용자별 프록시를 설정하거나 프린터를 구성하는 작업에 중요합니다. 권한 있는 터널 훅은 그런 작업에 맞는 자리가 아니며, 아무리 기다려도 없는 세션은 고쳐지지 않습니다.

훅에서 작업이 실패하면 계정, 환경, 그리고 처음 실패한 작업을 기록하십시오. 그러면 조기 타이밍 문제와 권한 또는 컨텍스트 문제가 구분되며, 둘의 수리는 전혀 다릅니다. 둘 사이를 추측하는 것이 오 분짜리 수리를 하루 종일로 만드는 방법입니다.

슬립을 추가하는 것이 준비 확인이 아닌 이유

슬립은 스크립트를 지연시키고 경쟁 창을 옮깁니다. 빠른 날에는 작업이 성공하고, 느린 날에는 다시 실패하며, 지연이 효과가 있는 것처럼 보이기 때문에 실패를 재현하기가 더 어려워집니다. 가벼운 부하에서만 통하는 지연은 우연이지 수리가 아닙니다.

의존 대상이 라우트라면 라우트 설치에 해당하는 훅을 사용하십시오. 의존 대상이 터널 뒤의 서비스라면 그 특정 조건을 기다리고, 결코 도착하지 않을 때 분명히 실패하는 한도 있는 확인을 사용하십시오.

실패를 명시적으로 두십시오. 실제 작업이 실패했는데 종료 코드 영으로 끝나는 훅은, 서비스 관리자가 성공으로 기록하고 아무도 다시 보지 않기 때문에, 실패하는 훅보다 나쁩니다. 스크립트 자체가 남기는 로그 한 줄이 그것을 정직하게 유지하는 가장 값싼 방법입니다.

정리와 재연결에도 같은 주의가 필요합니다

공유 상태를 바꾸는 스크립트에는 대응하는 되돌림 경로가 필요합니다. 훅이 추가한 라우트, 리졸버 항목, 방화벽 표시는 멱등이고 되돌릴 수 있어야 하며, 그렇지 않으면 재연결이 두 번째 사본을 첫 번째 위에 쌓습니다.

재연결은 서비스 전체 시작보다 훅을 더 자주 실행할 수 있습니다. 세션을 다시 수립하는 지속 인터페이스는 up과 route-up 주기를 다시 유발할 수 있으므로, 부팅당 한 번 실행된다고 가정하는 스크립트는 결국 오작동합니다. 하루 동안의 요동 로그에서 실행 횟수를 세어 실제로 얼마나 자주 실행되는지 확인하십시오. 그런 다음 스크립트가 그 횟수만큼 실행되어도 안전하게 만드십시오.

실패한 생명 주기를 테스트하십시오, 이후 명령이 아니라. 부팅이나 재연결을 재현하고, 훅이 실행되는 것을 관찰하며, 작업이 실제로 실행되는 그 순간에 성공했는지 확인하십시오. 나중에 대화형 셸에서의 성공은 의존 대상에 관한 증거이지, 시작 경로가 동작한다는 증거가 아닙니다.

각 작업이 의존하는 이벤트의 이름을 붙이고, 그 이벤트에 연결하십시오. 나머지는 모두 확인인 척하는 지연입니다.