OpenVPN이 active (exited)라고 표시되나요? 시작한 인스턴스를 찾으세요

터널을 확인하고 systemctl status openvpn을 실행하면 Main PID가 없고 프로세스 목록이 빈 active (exited)가 나옵니다. 자연스러운 해석은 서비스가 시작했다가 죽었다는 것이므로, unit을 열어 /bin/true를 발견하고 패키지가 망가졌다고 결론짓습니다. Debian 패키징에서 그 상태는 설계대로 동작하는 wrapper이며, 터널은 그것이 시작하는 인스턴스 unit 중 하나에 살아 있습니다. 집계 unit은 어느 인스턴스가 그것을 만들었는지 결코 알려주지 않습니다.

이 unit에서 active (exited)가 실제로 의미하는 것

패키징된 unit은 일회성 작업입니다. ExecStart는 /bin/true이고, 끝난 unit을 active (exited)로 계속 보고되게 하는 것은 RemainAfterExit=yes입니다. 그 지시문을 빼면 같은 성공적인 /bin/true 작업이 inactive (dead)로 끝나는데, 이는 사람들이 기대하고 반대 방향으로 잘못 읽는 바로 그 상태입니다. 명령은 단지 자리 표시자이고 unit은 다른 unit이 하는 작업을 보고하며, 이 배치에서 망가진 것은 없고 /bin/true를 바꾸는 것은 터널이 아니라 패키징 계약을 바꿉니다.

wrapper는 위임합니다. 패키지 구성이나 그 systemd 생성기가 제공하는 인스턴스 unit을 시작하므로, 빈 프로세스 목록은 터널에 대해 아무것도 증명하지 못합니다. 인스턴스가 선택되지 않아도 wrapper는 여전히 성공하고 여전히 아무것도 시작하지 않습니다. 상태는 wrapper가 실행되었는지를 답하지, 터널이 존재하는지를 답하지 않습니다.

괄호 안의 단어가 아니라 status 출력의 세 줄을 읽으세요. Loaded는 systemd가 읽은 unit 파일을 지명하고, Active는 마지막 성공 실행의 타임스탬프를 담고, Main PID의 부재는 끝난 일회성 작업에 맞습니다. 그 세 줄은 시작 직후에 무너진 서비스와 이 wrapper를 구분하는 방법이기도 합니다.

status를 다시 읽기 전에 unit을 나열하세요

무엇이 실행 중인지 묻기 전에 무엇이 존재하는지 systemd에 물으세요. 인스턴스가 만들어지지 않은 채 템플릿이 설치될 수 있고, 터널을 지니는 것은 만들어진 unit뿐입니다. 로드된 집합부터 시작하세요:

systemctl list-units 'openvpn*'

그 목록은 systemd가 이 순간 로드한 것이며, 터널 목록에 가장 가까운 것입니다. 설치된 unit 파일은 다른 질문에 답하고, 아무것도 만들어지지 않았을 때도 그 목록은 템플릿을 보여줍니다:

systemctl list-unit-files 'openvpn*'

두 목록을 함께 읽으세요. 두 번째의 템플릿과 첫 번째의 인스턴스는 다른 답이기 때문입니다. 존재하는 템플릿과 실행 중인 인스턴스는 같은 사실이 아니며, 두 번째만이 터널을 뜻합니다. 패키지 배치는 배포판과 OpenVPN 버전에 따라서도 다르며, 더 오래된 openvpn@ 템플릿, 분리된 client와 server 쌍, 배포판 wrapper는 모두 각자의 패키징에서 정당할 수 있습니다.

찾은 자습서가 아니라 자신의 기계에 맞추세요. 다른 사람의 출력에서 인스턴스 이름이 office일 수 있지만 당신 것은 home이나 work일 수 있습니다. 전달되는 것은 방법이지 문자열이 아닙니다.

인스턴스 이름을 따라가 그것이 읽는 파일로 가세요

upstream client 템플릿에서 unit의 작업 디렉터리는 /etc/openvpn/client이고 그 명령은 거기서 %i.conf를 가져오므로 openvpn-client@office는 /etc/openvpn/client/office.conf를 읽으니, 예를 믿는 대신 설치된 unit에서 그 대응을 확인하세요. 당신의 템플릿은 더 오래되었거나 배포판의 재작성일 수 있습니다:

systemctl cat [email protected]

그 출력 맨 아래에 나타나는 drop-in은 .d/ 아래의 파일이 ExecStart, 작업 디렉터리, 구성 경로를 바꿀 수 있어 읽을 가치가 있습니다. office.ovpn으로 내려받은 프로필은 인스턴스가 여는 파일이 아닙니다. 이 간극이 편집한 적 없는 경로를 오류가 지명하는 흔한 이유입니다.

프로필 안의 상대 경로가 다음 함정입니다. ca, cert, key 참조를 상대 경로로 둔 채 기본 파일을 옮기면 없는 파일 오류를 다른 없는 파일 오류로 바꿀 뿐입니다. 두 번째는 존재한다고 확신했던 파일을 가리키므로, 프로필 디렉터리가 파일 이름보다 더 중요합니다.

그것을 시작한 뒤 그 인스턴스의 저널을 읽으세요

방금 점검한 인스턴스를 시작하세요. 집계 unit의 로그에는 터널의 오류가 들어 있지 않으므로, 이 부팅의 저널을 읽고 그 순서대로 구성 오류, 파일 접근 오류, 연결 오류를 찾으세요.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

시작과 활성화는 별개의 결정입니다: start는 unit을 지금 실행하고, enable은 다음 부팅을 마련하며, enable --now는 둘 다 한 단계로 합니다. daemon-reload는 unit 정의를 다시 읽고 실행 중인 프로세스를 재시작하지 않으며 편집한 프로필을 적용하지 않습니다. 프로필을 바꾼 뒤에는 파일을 다시 읽는 인스턴스 재시작이 필요합니다.

같은 터널에 두 번째 관리자를 두지 마세요

NetworkManager와 OpenVPN 3 세션 관리자는 자체 연결 상태를 가지며, 그중 하나 옆에 systemd 인스턴스를 두면 같은 터널에 두 소유자가 생깁니다. 증상은 터널이 올라왔다가 몇 초 뒤 교체되거나, 멈춘 상태로 남기를 거부하는 것입니다. 배포판이 데스크톱용으로 문서화한 관리자를 선택하고, 서버에서는 의도적으로 systemd를 사용하세요.

인스턴스를 시작하기 전에 기존 소유자가 있는지 확인하세요. 데스크톱 애플릿이 연결을 보여 줄 때, 당신이 시작한 인스턴스는 그것을 완성하는 대신 경쟁합니다. 둘 다 실행하고 순서가 유지되기를 바라는 대신 사용하지 않는 관리자를 비활성화하세요. 그 충돌은 터널이 설정된 뒤 당신이 시작한 적 없는 프로세스에 의해 무너지는 저널도 설명합니다.

원래 질문에 인스턴스 이름, 그것이 읽은 파일, 실패한 저널 줄로 답하세요. OpenVPN의 systemd 통합 관련 노트 는 템플릿 배치와 인스턴스 이름이 해석되는 파일 대응을 설명합니다.