로컬 시스템 로그가 VPN 연결에 대해 알려 주는 것
운영체제는 앱이 결코 기록하지 않는 서비스 시작, 어댑터 변경, 경로 실패를 남긴다. 좁은 시간 창 하나를 읽고 대조하라.
모든 데스크톱은 VPN이 무엇을 했는지에 대한 자체 기록을 남기며, 앱의 내보내기는 보통 그중 가장 불완전하다. 서비스 관리자는 유닛이 언제 시작되었는지 적고, 커널은 인터페이스가 언제 나타났는지 적으며, 네트워크 스택은 경로가 언제 적용되지 못했는지 적는다. 이 설비 중 어느 것도 클라이언트가 무엇을 의도했는지 알지 못하고, 클라이언트는 커널이 자기 요청을 어떻게 처리했는지 알지 못한다.
그런 기록 하나만 따로 읽으면 잘못된 결론으로 이끌린다. 같은 분의 기록 두 개를 읽으면 순서가 보이기 시작한다.
세 가지 설비, 세 가지 어휘
Linux에서는 systemd 저널이 wg-quick@wg0 또는 NetworkManager의 VPN 플러그인에서 오는 유닛 수명 주기 메시지를 붙잡고, 커널의 링 버퍼는 인터페이스와 라우팅 메시지를 나른다. Windows에서는 이벤트 로그가 이야기를 시스템, WLAN, 원격 액세스 공급자로 나누며 각자 고유한 식별자를 가진다. macOS에서는 통합 로그가 하위 시스템으로 제한된 메시지를 나르고, 그래픽 Console은 그 일부만 보여 준다.
어휘는 번역되지 않는다. 한 플랫폼의 이벤트 식별자는 다른 플랫폼에서 아무 의미도 없고, Windows 대화 상자의 스크린샷은 Linux 유닛에 대해 아무것도 증명하지 못한다.
세 가지가 공유하는 것은 타임스탬프, 출처, 심각도이며, 바로 이 삼인조가 클라이언트 로그와 운영체제 기록 사이의 대조를 가능하게 한다. 가용성도 다르다: 저널이 없는 컨테이너, 잘라낸 Windows 이미지, 빌드 시 낮춘 로그 수준은 계층 하나를 통째로 감출 수 있다.
| Facility | What it records | What it cannot show |
|---|---|---|
| systemd journal | Unit start and stop, helper output, exit status | Whether packets actually reached the peer |
| Kernel and netlink | Interface creation, address assignment, route changes | Why the client asked for that configuration |
| Windows event log | Provider-specific connection and adapter events | Anything the provider chose not to log |
연결된 한 줄이 증명하는 것과 증명하지 않는 것
서비스 시작 이벤트는 로컬 유닛에 시작이 요청되었고 곧바로 종료되지 않았다는 사실을 적는다. 완료된 핸드셰이크도, 유효한 피어 키도, 동작하는 경로도 적지 않는다. 그 줄을 터널의 증거로 보는 것이 이 로그에서 가장 흔한 오독이다. 그 줄이 증명하는 것은 의도와 프로세스 상태뿐이며, 도달 가능성에 대해서는 아무것도 아니다.
전달 상태는 별개의 관찰이며, 어떤 로그가 아니라 라우팅 테이블에서 온다.
어댑터 이벤트가 조용한 실패를 설명할 수 있다: 인터페이스가 올라오고 주소가 할당되었지만 정책 규칙이 거부해서 경로가 한 번도 설치되지 않은 경우다. 그 순서에서는 아무것도 라우팅되지 않는데 보이는 모든 줄이 건강해 보이며, 그것을 보는 유일한 방법은 같은 순간의 라우팅 테이블과 로그 타임스탬프를 비교하는 것이다. 무엇을 요청했는지 아는 유일한 출처가 클라이언트이므로 클라이언트 자신의 이벤트 순서를 둘 옆에 두어야 한다. 함께 필요한 두 사실은 거의 같은 줄에 나타나지 않는다.
나중의 재연결은 이 그림에서 흥미로운 부분을 덮어쓰므로, 세 번의 재시도 뒤가 아니라 첫 실패에서 창을 잡아 두어야 한다.
좁은 시간 창을 대조하라
시도 시각을 시간대와 함께 적고, 그 주변의 몇 분을 뽑아낸다. 창 안의 첫 오류는 지원 티켓이 인용하는 연결 끊김 줄보다 거의 항상 앞선다.
journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20" ip route show table all | grep wg0 log show --last 20m --predicate 'subsystem == "com.apple.network"'
각 명령은 질문의 다른 부분에 답한다: 첫 번째는 수명 주기를, 두 번째는 전달 상태를, 세 번째는 macOS 네트워크 하위 시스템을 준다. Windows에서는 채널 전체를 스크롤하는 대신 공급자 이름으로 시스템 로그를 필터링하고, 일치하는 이벤트만 내보내라.
발췌는 읽는 사람이 따라갈 수 있을 만큼 작게 유지하라. 관련 이벤트 네 개가 있는 이십 분짜리 창은 결론을 뒷받침하지만, 수천 줄짜리 하루치 내보내기는 아무것도 뒷받침하지 못한다.
이 기록이 멈추는 지점
로컬 기록은 장치를 설명할 뿐 경로를 설명하지 않는다. 공급자가 무엇을 저장했는지, 세션이 계정과 연결되었는지, 목적지가 무엇을 보았는지는 보여 줄 수 없다. 로그를 보관하지 않는다는 공급자의 말은 노트북의 운영체제에 대해 아무것도 말해 주지 않으며, 로컬 이벤트는 공급자의 과거 기록에 대해 아무것도 증명하지 못한다.
예상보다 많은 개인 데이터도 담는다: 사용자 이름, 호스트 이름, 마운트 경로, 장치 식별자가 브라우징 내용이 전혀 없어도 평범한 시스템 메시지에 나타난다. 티켓에 무엇을 첨부하기 전에 그것들을 제거하고, 원본은 정상적인 접근 통제 아래에 두어라.
관리되는 장치에서는 조직의 로깅을 지우려 하지 말고 IT에 관련 발췌를 요청하라. 진단 목표는 두 출처가 답하는 좁은 질문 하나이지, 기계의 완전한 이력이 아니다.