L2TP 디버그 로그가 비어 있나요? 오류는 아마 journal에 있습니다

디버깅을 켜고 L2TP 도우미를 시작해 터미널을 지켜봐도, 화면에는 쓸모 있는 것이 없이 멈춥니다. 이것은 고장 난 디버그 플래그가 아닙니다. NetworkManager L2TP 연결은 함께 동작하는 네 개의 프로세스이며, 그중 일부만 당신이 보는 터미널에 씁니다. 나머지 증거는 journal에 있으며, 필터 하나만큼 떨어져 있습니다.

네 개의 프로세스, 두 개의 로그 목적지

연결은 IPsec으로 시작하며, 설치에 따라 libreswan 또는 strongSwan입니다. 그다음 L2TP 데몬이 전통적으로는 xl2tpd, 일부 빌드에서는 kl2tpd가 터널을 운영합니다. 마지막으로 pppd가 그 안에서 인증과 주소 지정을 처리합니다.

도우미 서비스는 이 조각들을 조정하고 자체 진행 상황을 인쇄합니다. IPsec 데몬과 pppd는 보통 시스템 journal을 통해 보고하므로, 터미널에는 실패하는 연결이 보이고 이유는 당신이 열지 않은 파일에 있습니다.

이 분리는 PSK 오류와 비밀번호 오류가 데스크톱에서 똑같아 보이는 이유도 설명합니다. 둘 다 일반적인 연결 끊김을 만들고, 실패한 단계는 각 프로세스의 출력에서만 보입니다. 여기서 journal이 중요한 이유는 바로 이것입니다. 데스크톱에는 일반 메시지 하나, 그 뒤에는 네 명의 가능한 작성자가 있습니다.

한 번의 시도를 모은 다음 순서를 읽으세요

알려진 프로필과 알려진 시각으로 한 번 재현한 다음, 부팅 전체가 아니라 좁은 창을 읽으세요. 설정을 바꾸면서 시도를 반복하면 로그가 해석할 수 없는 혼합물이 됩니다.

이 명령은 현재 부팅에서 참여하는 프로세스를 선택하며, 플러그인 경로는 배포판에서 확인할 가치가 있습니다:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

한 번의 호출에서 반복된 필드는 그 프로세스들의 합집합을 선택하며, 이것이 순서를 시간 순으로 유지합니다. Debian 기반 시스템에서 동등한 쿼리는 dpkg -L 입니다; 요점은 손으로 실행하기 전에 도우미가 실제로 어디에 있는지 찾는 것입니다.

다음 행동을 결정하는 세 가지 조건

처음 실패한 단계를 읽고 그에 따라 선택하세요. IPsec이 제안이나 피어 인증 실패를 보고하면 터널은 전혀 형성되지 않았고, PPP 비밀번호를 바꿔도 도움이 되지 않습니다.

터널이 형성되었고 pppd가 로그인을 거부했다면 공유 비밀은 이미 정상이었고 자격 증명 문제는 한 계층 위에 있습니다. pppd가 주소를 협상했고 실패가 나중에 나타난다면 둘 다 작동하며 남은 문제는 라우팅, DNS 또는 서버 자체의 정책입니다.

이 세 갈래는 거의 모든 일반적인 연결 끊김을 포괄하며, 어떤 프로세스가 마지막 오류를 기록했는지로 결정되지, 어떤 오류 메시지가 가장 놀라워 보이는지로 결정되지 않습니다.

디버그 설정을 건드리기 전에 어떤 IPsec 백엔드가 설치되어 있는지 확인할 가치도 있습니다. strongSwan용으로 작성된 로깅 옵션은 libreswan이 실행 중일 때 아무것도 하지 않으며, 아무도 읽지 않는 파일을 편집하는 동안 연결은 같은 지점에서 계속 실패합니다.

디버그 모드는 파일을 남깁니다

원래 디버그 워크플로는 디버그 플래그로 서비스를 수동 실행하며, 그 모드는 연결이 끝날 때 생성된 런타임 구성 파일을 그대로 남길 수 있습니다.

이 파일에는 인증 자료가 들어 있습니다. 미리 공유한 키, 자격 증명 또는 둘 다입니다. 생성된 구성을 채팅 창에 복사하는 것은 로그 발췌가 아니라 자격 증명 노출입니다. 무엇이든 공유하기 전에 비밀 줄을 제거하고, 조사가 끝나면 디렉터리를 삭제하세요. 비밀로 취급하고, 보고서에 필요한 특정 줄만 추출한 뒤, 디렉터리를 티켓에 붙여 넣는 대신 나중에 삭제하세요.

수동 인스턴스도 일반 인스턴스와 조정해야 합니다. 서비스가 이미 플러그인을 소유한 상태에서 디버그 사본을 시작하면 소유자가 둘이 되고 둘을 섞은 로그가 생기며, 이는 디버그 출력이 전혀 없는 것보다 나쁩니다.

그다음 일반 도우미를 복원하세요

조사가 끝나면 수동 인스턴스를 중지하고, 보관된 런타임 파일을 제거하고, 일반 경로로 다시 연결해 다음 사람이 현실과 맞는 구성을 보도록 하세요.

그런 다음 결과를 실패한 계층에서 확인하세요. 데스크톱 아이콘이 아니라:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

인증하고 주소를 받고 의도한 목적지로 라우팅되는 세션이 당신이 디버깅하던 결과입니다. 실패한 시도 동안 조용한 터미널은 한 가지만 알려 줍니다: 출력이 기록되지 않은 곳.