화면이 어두워질 때 VPN이 끊긴다: 잠금, 화면 꺼짐, 아니면 절전?

화면이 어두워졌을 때 VPN이 죽었다고 누군가 말할 때, 첫 번째로 유용한 질문은 세 가지 사건 중 무엇이 실제로 일어났는가입니다. 세션이 잠겼는지, 패널이 꺼졌는지, 아니면 기기 전체가 잠들었는지는 서로 다른 타이머에서 도는 별개의 메커니즘이며, 프로세스의 스케줄링을 완전히 막을 수 있는 것은 그중 하나뿐입니다. 아래 점검을 순서대로 진행하고, 질문에 답하는 첫 점검에서 멈추세요. 그 뒤의 점검은 다른 것에 답하고 있습니다.

점검 하나: 잠금과 화면 꺼짐과 절전을 분리하라

잠금은 세션을 쓸 수 있는 사람을 바꿀 뿐이고, 컴포지터는 계속 그리며, 네트워크 스택은 계속 돌아가고, VPN 클라이언트는 아무것도 알아차리지 못합니다. 화면 꺼짐은 유휴 시간이 지나면 패널을 끄고 기기는 완전히 깨어 있는 상태로 둡니다. 절전은 CPU를 멈추므로 사용자 공간의 어떤 프로세스도 스케줄되지 않으며, 따라서 간격을 아무리 짧게 잡아도 연결 유지 신호는 실행될 수 없습니다.

이 표가 바로 «화면이 어두워졌다»가 진단이 아닌 이유입니다. 다섯 분에 화면 끄기, 서른 분에 절전으로 설정된 데스크톱은 여섯 분 시점에 완전히 건강한 터널을 두고도 어두운 화면을 보여 줍니다. 서른 분 시점의 고장은 다른 사건이고 다른 해법이 필요하며, 방 건너편에서 보면 둘 다 똑같아 보입니다.

점검 둘: 전원과 네트워크 사건을 하나의 시간선에 올려라

부팅 전체가 아니라 제한된 구간의 저널을 읽고, 로그인 관리자와 연결 소유자를 모두 포함하세요:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

첫 번째 명령은 절전 요청, 깨어남, 그 뒤에 이어진 네트워크 전환을 보여 줍니다. 두 번째는 지금 무엇이 억제 잠금을 쥐고 있는지 보여 주며, 이는 무언가가 의도적으로 절전을 막고 있는지, 그 프로그램이 무엇인지 알려 줍니다. 연결 소유자가 NetworkManager가 아니면 유닛 이름을 조정하고, 다른 사용자의 유닛이나 시스템 저널을 읽는 것은 로컬 정책에 달려 있음을 기억하세요.

줄이 없다고 해서 부정적 결과는 아닙니다. 선택한 유닛의 저널이 당신의 계정에 보이지 않는다면, 절전 기록이 없다는 것은 아무것도 증명하지 못하며, 빈 필터에서 «한 번도 잠든 적이 없다»고 결론짓는 것이 사람들이 일주일 동안 연결 유지 기능을 조정하며 보내는 길입니다.

점검 셋: 절전에 들어갔다면 그것이 의도된 것인지 판단하라

절전 전환이 시간선에 오르면, 질문은 «VPN이 왜 깨졌나»에서 «기기가 애초에 잠들어야 했나»로 바뀝니다. 노트북에서는 답이 흔히 그렇다이고, 터널 중단은 클라이언트가 깨어날 때 복구해야 하는 예상된 동작입니다. 계속 접근 가능해야 하는 워크스테이션에서는 절전 정책이 바꿔야 할 대상입니다. 이 두 기기 중 어느 쪽을 보고 있는지 판단하려면 질문 하나가 필요하며, 그것은 저널이 대신 답해 줄 수 있는 질문이 아닙니다.

로그인한 세션에 속한 제어 수단으로 바꾸거나, 요구 사항이 기기 전체에 적용된다면 관리자가 지원하는 메커니즘으로 바꾸세요. 다른 계정으로 로그인한 채 디스플레이 관리자 설정을 편집하는 것은 같은 조작이 아니며 다음 세션이 시작될 때까지는 효과가 있는 것처럼 보입니다. 전원 관리를 완전히 끄는 것은 배터리 수명을 희생하고 실제 정책 질문을 가리는 광범위한 첫 반응입니다.

점검 넷: 깨어 있었다면 네트워크와 클라이언트를 보라

터널을 잃은 깨어 있는 기기에는 접속 네트워크가 끊겼거나, VPN 클라이언트가 멈추거나 다시 시작했거나, 서버 쪽이 연결을 만료시켰는데 클라이언트는 여전히 연결되어 있다고 믿고 있었던, 세 가지 이야기 중 하나가 있습니다. 하위 링크 사건의 타임스탬프를 터널 사건과 비교하고, 어느 쪽이 먼저였는지 정확히 하세요.

그다음 원래 세션과 별도로 복구 경로를 시험하세요. 복구된 터널을 통한 새 요청은 성공할 수 있지만, 끊기기 전에 열린 장기 애플리케이션 세션은 애플리케이션이 낡은 소켓이나 캐시된 주소를 쥐고 있기 때문에 깨진 채로 남습니다. 그것은 애플리케이션 문제이지, 터널이 돌아오지 못했다는 증거가 아닙니다.

유용한 보고서에 담기는 것

타임스탬프와 담당자를 붙여, 세션이 언제 잠겼는지, 화면이 언제 어두워졌는지, 절전 요청이 기록되었는지, 링크가 언제 끊겼다 돌아왔는지, 터널이 언제 상태를 바꿨는지, 애플리케이션이 실제로 무엇을 했는지를 순서로 쓰세요. 각 항목에는 담당자가 있으므로, 리눅스에 대한 막연한 불평이 되는 대신 맞는 사람에게 넘길 수 있습니다.

이 줄 중 하나라도 빠져 있다면, 그것이 다음에 측정할 것이지 다음에 바꿀 것이 아닙니다. 빈틈이 있는 시간선은 짐작으로 한 설정 변경보다 많은 것을 말해 줍니다.