OpenVPN 이 오류 없이 시작되지 않나요? 저널을 확인하세요

명령이 돌아오고 서비스는 실패로 표시되며 설명처럼 보이는 것은 터미널에 도달하지 않습니다. 그 침묵이 사람들이 «OpenVPN이 시작되지 않는다»고 표현하는 증상이며, 프로그램이 아무 말 없이 죽었다는 뜻인 경우는 거의 없습니다. 메시지가 읽지 않던 채널로 갔거나, 시작한 것이 설정한 것이 아니었다는 뜻입니다. 프로필을 용의자로 취급하기를 멈추면 두 경우 모두 일 분 이내에 진단할 수 있습니다.

출력을 흡수하는 곳은 네 군데입니다: 유닛의 저널, 연결을 소유한 플러그인, 터널의 반대편, 그리고 실행 중이라고 생각하는 것과 다른 바이너리입니다. 각각 고유한 확인 방법이 있습니다.

침묵은 올바른 채널을 보고 있지 않았다는 뜻입니다

전경에서 실행한 호출은 터미널에 출력합니다. 유닛은 저널에 출력하며, 실패한 유닛은 실패가 어떻게 시작되었는지에 있고 무엇을 지시받았는지에 있지 않다면 아무것도 쓰기 전에 종료될 수 있습니다. 이 구분은 중요합니다: 저널에 기록이 없으면 프로세스가 실제로 실행된 적이 없다는 뜻이고, 기록 하나와 그 뒤의 종료는 실행되어 무언가를 거부했다는 뜻입니다.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

깨끗한 종료를 신호와 구분하려면 다음을 추가하십시오: systemctl show -p Result -p ExecMainStatus openvpn-client@office. 상태 1 과 Result=exit-code 는 프로그램의 결정이고, Result=signal 나 타임아웃은 대신 환경을 가리키며, 프로필을 아무리 편집해도 그것은 바뀌지 않습니다. 무언가를 다시 시작하기 전에 두 값을 기록하십시오, 재시작은 그것들을 만들어 낸 일시적 상태를 지우기 때문입니다.

인스턴스 이름은 경로의 일부입니다

패키지된 템플릿 유닛은 파일 경로를 받지 않습니다. 인스턴스 이름을 받고, 그 이름이 디렉터리에 붙어 프로필을 찾습니다: office 는 Debian 및 Ubuntu 패키징에서 /etc/openvpn/client/office.conf 로 해석됩니다. office-v2.conf 라는 파일을 @office 로 시작해도 절대 읽히지 않고, 유닛은 자기 관점에서 할 일이 없었기 때문에 조용히 종료됩니다. 조회 디렉터리는 클라이언트 모드와 서버 모드에서 다르므로 템플릿을 바꾸면 같은 실수가 완전히 다른 곳을 가리킵니다.

그 불일치가 조용한 실패의 가장 흔한 원인이며, 프로필 자체는 멀쩡하기 때문에 프로필에서는 보이지 않습니다. 실제로 존재하는 것을 나열하고 패키징이 기대하는 확장자를 포함해 두 이름을 글자 단위로 비교하십시오.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

유닛이 활성화되어 있는데 인스턴스가 하나도 나열되지 않는다면, 활성화 자체가 나중에 이름이 바뀐 이름을 가리킬 수 있습니다. 올바른 인스턴스를 다시 활성화하는 것으로 보통 충분하며, 남겨진 옛 유닛 파일은 다음 사람을 헷갈리게 하지 않도록 삭제할 가치가 있습니다. 남겨진 유닛 파일은 나중에 누군가의 한 시간을 앗아가는 작은 일입니다.

플러그인이 터널을 소유하면 터미널은 아무것도 보지 못합니다

데스크톱 애플릿에서 시작한 연결은 NetworkManager가 소유하며, 그 OpenVPN 출력은 열어 둔 셸이 아니라 해당 서비스의 저널로 갑니다. 클라이언트를 직접 실행해서 아무것도 보이지 않는 것은 그 구성에서 예상된 일인데, 직접 실행한 프로세스가 연결을 나르는 프로세스가 아니기 때문입니다.

저널에서 그것을 소유한 서비스를 찾고, 읽을 수 있는 수준의 상세도로 파싱을 재현하십시오. 아래 두 명령은 같은 실패의 서로 다른 소유자를 봅니다.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

독립 실행은 메시지를 읽기 위한 것이지 관리되는 연결을 대체하기 위한 것이 아니며, 둘은 이후에 다릅니다: DNS 통합, 경로, 수명은 플러그인에 속합니다. 독립 실행에서 파싱 오류를 고쳐도 애플릿이 넘겨받은 뒤 이름 확인이 자동으로 고쳐지지는 않으므로 두 관찰을 분리해 두십시오.

바이너리 둘, PATH 하나

직접 빌드해 /usr/local 아래에 설치한 것이 셸 호출에서 이기는데, /usr/local/sbin 가 Ubuntu 기본 PATH에서 /usr/sbin 보다 앞서기 때문입니다. 유닛은 당신의 PATH를 쓰지 않고, ExecStart 에 적힌 절대 경로를 실행합니다. 그래서 터미널에서 동작하는 버전과 서비스로 실패하는 버전이 정말로 다른 프로그램일 수 있습니다.

무언가를 다시 빌드하기 전에 둘을 비교하십시오. 세 번째 명령이 논쟁을 결정합니다.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

또 하나의 환경 차이가 같은 곳에 숨어 있습니다. 패키지된 유닛은 /run 아래에서 systemd가 만들어 주는 런타임 디렉터리에 의존하는데, 그 설정을 빼먹은 직접 작성한 대체 유닛은 파일 하나를 열기도 전에 실패할 수 있고, 그 실패는 OpenVPN 메시지가 없는 일반적인 거부처럼 보입니다.

클라이언트가 보고할 수 없는 실패

일부 결과는 먼 쪽에서 결정됩니다. HTTP 상태로 응답하고 연결을 닫는 게이트웨이는 자기 상태를 이미 알려 준 것이며, 다음에 유용한 단계는 당신의 로컬 파일이 아니라 그 로그나 자격 증명 뒤의 계정입니다. 그 시나리오에서 로컬에서 망가진 것은 없고, 보상하려고 프로필을 편집하면 다음 진단이 더 어려워집니다. 클라이언트 구성을 건드리기 전에 그 로그를 읽으십시오.

또 다른 조용한 경우는 올바르게 동작하는 클라이언트입니다. 클라이언트 모드 터널은 결코 포트에서 수신하지 않으므로 열린 리스너를 기대하는 검사는 아무것도 보고하지 않고 실패처럼 보입니다. 빈 포트 목록에서 결론을 내리기 전에 어느 모드로 시작했는지 확인하십시오.

계층을 순서대로 다루십시오: 유닛이 있는지와 인스턴스 이름이 맞는지, 저널이나 --log, 어떤 바이너리와 프로필이 실제로 실행되었는지, 실패가 로컬인지 원격인지. 각 답이 한 계층을 제거합니다. 프로필에서 시작하는 것은 한 번도 열리지 않았을 수 있는 파일을 다시 쓰는 것입니다.