sudo, &, -b 또는 --daemon: OpenVPN 클라이언트를 백그라운드로 돌리는 방법

‘백그라운드에서 실행하라’는 말에는 두 가지 질문이 숨어 있다. 첫째는 이 사용자가 애초에 특권 프로세스를 시작할 수 있느냐이고, 둘째는 누구도 터미널에 입력하지 않아도 세션이 계속될 수 있느냐이다. 셸의 앰퍼샌드는 둘 중 어느 것에도 답하지 않으며, sudo 암호를 변수에 저장하는 스크립트는 첫째에 형편없이 답하고 둘째는 건드리지도 않는다. 둘을 분리하면 선택지를 비교하기 쉬워진다.

세 후보를 편의성이 아니라 소유권으로 비교하라.

터미널을 떠나는 세 가지 방법, 세 명의 다른 소유자

명령에 앰퍼샌드를 붙이면 셸은 그것을 백그라운드 작업으로 실행하며, 작업은 여전히 그 셸에 속한다. sudo는 프로그램이 시작되기도 전에 물을 수 있고, OpenVPN은 그 뒤에 키 암호 문구나 로그인을 물을 수 있다. 입력을 기다리는 명령을 백그라운드로 보내면 아무도 지켜보지 않는 터미널을 기다리는 프로세스가 생긴다. 터미널은 해방되지만 상호작용은 그렇지 않다.

그것은 가장 저렴한 선택지이자, 프롬프트가 운영자가 이미 떠난 자리에 나타나기 때문에 가장 혼란스럽게 실패하는 선택지다.

sudo -b는 자격 증명 처리기가 아니다

sudo -b sudo 자체의 관점에서 명령을 백그라운드로 실행하는데, 이는 빠진 기능처럼 들리지만 그렇지 않다. sudo 설명서에 따르면 대화형 명령은 그 모드에서 대체로 잘못 동작하며, 셸의 작업 제어는 그것이 만든 프로세스를 관리할 수 없다. 질문에 답할 방법을 주지 않은 채 프로세스를 옮길 뿐이다. 그 어디에도 개인 키 암호 문구나 게이트웨이 로그인을 제공하지 않는다.

연결에 상호작용이 필요하다면 해법은 지원되는 비대화형 인증 구성이지, 같은 프롬프트를 띄우는 다른 방법이 아니다.

--daemon은 프로그램을 바꾸지, 로그인을 바꾸지 않는다

--daemon 초기화 후 분리하라고 OpenVPN 자체에 요청한다. 2.6 설명서는 syslog 리디렉션이 옵션을 해석할 때 일어난다고 적고 있는데, 분리는 그보다 늦게 일어나므로 메시지가 예상보다 일찍 터미널에서 사라질 수 있다. 그 지점 이후의 침묵은 터널에 대해 아무것도 증명하지 않는다. 명시적인 --log 또는 --log-append을 추가해 출력이 읽을 수 있는 곳에 남게 하라.

데몬 모드는 콘솔도 영구히 없앤다. 보호된 개인 키는 그 모드에서 askpass 가 필요하며, 콘솔에서 입력한 자격 증명이 캐시 옵션과 결합되면 이후의 재인증이 물어볼 곳을 잃을 수 있다. 백그라운드 시작이 첫 키 갱신을 견딜 것이라고 가정하기 전에 설치된 버전에서 인증 모델을 확인하라.

sudo 검증이 주는 것과 주지 않는 것

sudo -v 캐시된 로컬 자격 증명을 검증하거나 갱신하고, 정책이 요구하면 인증한다. OpenVPN을 시작하지 않고, 게이트웨이에 인증하지 않으며, 스크립트의 이후 명령이 허용된다고 보장하지도 않는다. sudo -n은 반대를 뜻하며, 묻지 말고 실패하라는 것이다. 이것은 로컬 권한 부여 실패를 명시적으로 만들며 유용하지만, OpenVPN이 나중에 무엇을 요구할지는 말해 주지 않는다.

어느 선택지도 모든 사람에게 암호 없는 명령을 주거나 관리자 암호를 스크립트로 흘려보낼 이유가 되지 않는다.

관찰할 수 있는 소유자를 선호하라

머신이 소유한 터널에는 배포판이 지원하는 서비스 인스턴스를 사용하라. 그 소유자는 시작, 중지, 상태, 로그를 제공하며 세션이 끝난 뒤에도 살아남는다. 셸 백그라운드 실행, 데몬화, 재시작 루프를 서로 얽어 놓으면 터널 하나에 소유자가 셋 생기고 어느 것이 돌고 있는지 명확한 답이 없어진다.

무엇을 고르든 터널이 존재하는 이유인 리소스를 검증하라. 성공한 시작 요청은 프로세스 사건일 뿐, 연결이 동작한다는 증거가 아니다.