OpenVPN이 시작되었지만 아무것도 출력하지 않음: 먼저 log-append를 확인하세요

구성 파일과 함께 셸에서 OpenVPN을 시작하면 터미널은 아무 출력도 없이 그대로 있습니다. 배너도, 오류도, 프롬프트도 없습니다. 직감은 시작이 실패했다고 말하므로 또 다른 복사본을, 그다음 또 하나를 시작하고, 머신에는 반쯤 구성된 인스턴스가 여러 개 남습니다. 그 전에 프로필에서 로그를 이미 다른 곳으로 보낸 지시문이 있는지 확인하세요. 침묵은 콘솔의 속성이지 프로세스의 속성이 아닙니다.

침묵에는 아주 다른 두 가지 설명이 있습니다

첫째는 프로세스가 정상적으로 실행되며 당신이 보지 않는 파일에 쓰고 있다는 것입니다. 둘째는 같은 파일에 기록된 오류와 함께 즉시 종료되었다는 것입니다.

둘 다 빈 터미널을 남기며, 한 가지 질문이 둘을 가릅니다—지금 프로세스가 있는가, 그리고 쓰라고 지시된 파일에 무엇이 있는가. 구성을 다시 건드리기 전에 그것에 답하세요. 출력을 얻으려고 다시 시작하는 것은 두 인스턴스가 하나의 터널 장치와 같은 포트를 두고 다투게 되는 길이며, 원래 문제와 아무 관련 없는 오류를 낳습니다.

지시문을 찾고, 그다음 프로세스를 찾으세요.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

실행 중인 프로세스가 사용하는 목적지를 찾으세요

프로세스가 실제로 시작된 프로필을, 당신이 편집한 것이 아니라 읽으세요. 서비스가 관리하는 인스턴스는 보통 다른 경로를 불러오고 다른 작업 디렉터리에서 실행되므로 상대 파일 이름은 예상하지 못한 곳에서 해석됩니다.

명시적 cd 지시문은 상대 경로가 디렉터리 변경과 함께 움직이기 때문에 그 차이를 더 날카롭게 만듭니다. 이 구성을 물려받았다면 파일은 지금 아무도 찾지 않을 곳에 있을 수 있습니다.

파일의 수정 시간을 당신이 시작한 순간과 비교하세요. 지난주의 로그는 지난주에 대한 증거입니다. 그다음 변경된 파일의 마지막 줄을 읽고, 거기 있는 내용을 놓쳤던 시작 메시지로 취급하세요.

log 대 log-append: 증거와 지우기

log-append는 파일에 이미 있는 내용에 덧붙입니다. log는 파일을 쓰기 위해 열고 잘라내므로, 둘 사이를 바꾸면 읽으려던 실행이 지워질 수 있습니다.

디버깅 중에 누군가 지시문을 바꿨다면 이전 증거는 이미 사라졌고 파일 크기는 의심스러울 만큼 작아 보일 것입니다. 두 실행을 비교해 무언가 바뀌었다고 결론 내리기 전에 그것을 아는 것이 좋습니다. 로그를 일부러 지우거나 보관하되, 어느 쪽을 했는지 아세요. 의도적으로 제거한 증거가 우연히 잃어버린 증거보다 설명하기 쉽습니다.

두 옵션 모두 없는 상위 디렉터리를 만들지 않고, 파일 시스템 권한이나 서비스 샌드박스를 통해 접근을 허용하지도 않습니다. 구성에서 올바르게 보이는 경로라도 데몬이 실행되는 계정에 쓰기 불가능할 수 있으며, 그러면 데몬은 아무것도 보고하기 전에 실패할 수 있습니다. 파일 이름이 문제라고 가정하기 전에 디렉터리의 존재와 소유자를 확인하세요.

서비스 래퍼가 출력을 가로챌 때

systemd에서는 명시적 파일 지시문이 우선하지 않는 한 표준 출력과 오류가 저널로 가며, 벤더 래퍼가 그것들을 완전히 다른 곳에서 가로챌 수 있습니다.

그래서 같은 프로필이 셸에서와 유닛에서 다르게 동작합니다. 유닛의 환경, 작업 디렉터리, 표준 스트림은 모두 당신의 대화형 셸과 다릅니다. 상대 경로는 한 문맥에서는 해석되고 다른 문맥에서는 어디에도 닿지 않을 수 있습니다. 둘이 어긋날 때는 프로필이 아니라 유닛 정의를 읽으세요.

둘 중 하나가 고장 났다고 결론 내리는 대신 두 시작 방식을 비교하세요. 유닛의 명령줄과 환경을 읽고, 그다음 같은 시간대의 저널을 읽으세요. 래퍼가 출력을 자체 파일로 리디렉션한다면 그 파일이 이제 당신의 로그이며, OpenVPN 지시문은 메시지가 어디로 갔는지와 무관합니다.

읽을 수 있게 된 뒤에만 상세 수준을 올리세요

목적지를 찾기 전에 상세 수준을 올리면 보지 않는 곳에 텍스트만 더 생깁니다.

출력이 어디로 떨어지는지 알면, 중간 수준은 프로필이 파싱되고 연결이 시도되는 것을 보여 줍니다. 시작 문제에는 둘이나 셋이면 충분합니다. 더 높은 수준은 실패가 협상 세부 사항일 때 값을 가지며, 파일도 빠르게 키웁니다.

그다음 실제 오류를 읽으세요. 조용한 터미널은 터널이 올라왔는지에 대해 아무것도 증명하지 못하며, 파일에 기록된 실패가 고칠 가치가 있는 것입니다.