VPN 로그를 위한 journalctl: 어느 유닛이 연결을 소유하는가?

기억나는 로그 명령이 아니라 VPN 연결을 실제로 소유한 systemd 유닛에서 시작합니다. 직접 실행하는 OpenVPN 서비스, wg-quick 유닛, NetworkManager 프로필은 유용한 메시지를 서로 다른 유닛에 두므로, 잘못된 유닛에 질의하면 침묵처럼 보이는 빈 결과가 나옵니다. 흔한 세 가지 소유자를 비교하고, 범위를 좁힌 다음 단계를 순서대로 읽습니다.

흔한 세 가지 소유자 비교

OpenVPN 클라이언트 서비스는 보통 프로필 이름을 딴 인스턴스 유닛입니다(예: [email protected]). 그 메시지에는 구성 경로, 옵션 파싱, TLS 핸드셰이크, 클라이언트가 수행하는 경로 설정이 포함됩니다.

wg-quick 유닛은 설계상 더 조용합니다. 인터페이스 구성은 시작할 때 이루어지고, 핸드셰이크는 커널이 처리하며, 정기적인 키 재생성은 기본적으로 기록되지 않으므로 wg show가 journal보다 더 많은 정보를 주는 경우가 많습니다. 이 차이는 협상을 기록하는 프로토콜과 그렇지 않은 프로토콜을 비교할 때 중요합니다.

NetworkManager는 자기가 만든 프로필을 소유하며, 기반 플러그인이 VPN 도우미여도 그 메시지는 NetworkManager.service 아래에 있습니다. 프로필이 그런 방식으로 관리되면 관리자와 도우미 유닛 모두에 질의합니다.

질의를 하나의 유닛과 하나의 범위로 좁히기

식별한 유닛에 질의하고, 조사 중인 시도로 시간을 제한합니다. 보통 하루면 충분하며, 머신이 자주 다시 연결되면 더 짧은 범위가 좋습니다.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

질의를 믿기 전에 설치된 이름 확인. 배포판 패키징은 유닛 이름을 바꾸며, 파일로만 존재하는 프로필은 서비스로 활성화된 적이 없을 수 있습니다. 유닛이 없으면 빈 journal은 터널이 아니라 배포에 대해 말해 줍니다.

첫 번째 실패 단계 읽기

사건이 일어나는 순서대로 읽습니다. 엔드포인트 조회, 전송, 신원, 인증, 경로 설정, 그 뒤의 애플리케이션 실패라는 흐름에서 첫 번째 구체적인 실패가 조사할 가치가 있으며, 그 뒤의 모든 것은 결과일 뿐입니다.

성공적으로 시작한 서비스가 필요한 모든 자원에 도달할 수 있음을 증명하지는 않습니다. 재연결 루프는 여러 개의 별도 협상을 만들 수 있으므로 프로필 이름과 시도 시각을 사건과 함께 보관하고, 병합된 스트림이 아니라 한 번의 시도를 읽습니다. 단일 시도는 원인이 있는 순서이고, 병합된 스트림은 반복되는 줄의 벽입니다. 더 읽기 전에 첫 오류를 티켓에 적습니다.

실패한 서비스와 수동 클라이언트를 섞지 않기

서비스가 실패한 뒤 클라이언트를 직접 시작했다면 그 출력은 다른 곳으로 가고 동작도 다를 수 있습니다. 지원되는 수정 뒤에 같은 소유자와 같은 요청에서 새 결과를 확보해, 서로 다른 두 프로그램을 섞는 대신 무엇이 바뀌었는지 비교로 보여 줍니다.

다른 호스트에 맞추려고 원래 타임스탬프를 바꾸지 말고, 시간대와 알려진 시계 차이는 따로 기록합니다. 편집한 타임라인은 더 이상 증거가 아니기 때문입니다.

내보내기가 아니라 발췌 공유

journal 항목에는 사용자 이름, 엔드포인트 주소, 사설 토폴로지, 스크립트 환경 정보가 들어 있을 수 있습니다. 완전한 무제한 내보내기를 공개하는 대신 실제 발췌를 검토하고 민감한 부분을 가립니다. 실패를 입증하는 줄을 인용하고 나머지는 요약합니다. 짧게 검토한 발췌는 아무도 읽지 않는 파일보다 다루기 쉽습니다.

좁은 범위, 유닛 이름, 첫 번째 실패 단계를 보내고 이미 배제한 것을 말합니다. systemd journalctl 설명서는 배포판 버전이 지원하는 형식이 필요할 때 선택자와 출력 옵션을 설명합니다.