화면이 꺼지면 VPN이 끊긴다: 어떤 수명 주기?

화면이 어두워지는 순간 전송이 멈추고, 배지는 몇 초 뒤에 따른다. 이 그림을 만드는 원인은 세 가지다: 클라이언트 프로세스가 제한되거나, 경로가 유휴 상태가 되어 매핑을 잃거나, 터널이 알아차리지 못한 세션을 앱이 잃는 것이다. 각각 증거가 다르고, 각 해결책은 다른 계층에 속한다. 아래 순서는 설정을 전부 훑는 대신 통제된 시험 하나로 이들을 구분한다.

똑같아 보이는 세 가지 고장

제한된 백그라운드 프로세스는 keepalive 전송을 멈추고, 상대편은 결국 터널이 죽었다고 선언한다. 경로의 유휴 매핑은 기기가 잠자는 동안 만료될 수 있어, 아직 완전히 살아 있는 클라이언트에 반환 트래픽이 닿지 않는다. 앱은 터널이 올라간 채로 자기 연결을 잃을 수 있고, 그러면 뒤에 건강한 VPN 배지가 있는 오류 대화상자가 뜬다. 사용자 입장에서는 셋 다 화면 꺼짐에서 VPN이 끊긴 것으로 읽힌다.

이 구분이 중요한 이유는 실제로 해결책이 서로 모순되기 때문이다. 클라이언트를 전력 제한에서 제외하면 첫 번째 경우는 고쳐지지만 만료된 매핑에는 아무 효과가 없다. keepalive를 늘리면 두 번째는 고쳐지지만 세 번째에서는, 애초에 네트워크 문제가 없었는데도, 배터리를 낭비한다.

통제된 조건에서 활성과 유휴를 비교한다

모든 것을 일정하게 유지한다: 같은 기기, 같은 네트워크, 같은 엔드포인트, 같은 앱. 화면을 짧은 고정 간격 동안 잠그고 세 가지 관찰을 기록한다: 클라이언트가 연결 끊김을 보고하는지, 잠금 해제 시 새 요청이 되는지, 기존 전송이 재개되었는지. 그다음 keepalive나 주기적 요청을 돌린 상태로 반복하고 두 실행을 비교한다. 두 실행 사이에 바꾼 변수 하나가 일주일치 일화 보고보다 낫다.

타이밍은 기록에 남긴다. 구십 초 뒤의 끊김은 매핑이나 keepalive 간격을 시사하고, 잠금 순간의 끊김은 프로세스 중단을 가리킨다. 트리거와 간격을 모두 적어 둔다는 것은 다음 시도에 비교할 대상이 필요하기 때문이다.

플랫폼의 백그라운드 정책을 읽는다

Android에서 VPN 서비스 수명 주기는 플랫폼의 일부이며, always-on과 block-without-VPN은 효과가 다른 별개의 스위치다. always-on이 아닌 클라이언트는 시스템이 자원을 회수할 때 중지될 수 있고, 앱 내 설정으로는 바뀌지 않는다. iOS는 터널 제공자에게 자체 백그라운드 제한을 적용하며, 문서화된 동작은 계속 실행되는 데스크톱 데몬과 다르다. 일반적인 배터리 최적화 안내서가 아니라 해당 구성 요소의 플랫폼 문서를 읽는다.

관리되는 기기는 한 겹을 더한다. 정책이 개인 설정을 덮어쓸 수 있어, 작동하는 것처럼 보인 변경이 다음 정책 새로 고침에서 되돌아간다. 요구가 실제라면 조직의 지원되는 예외 절차를 사용하고, 예외가 왜 존재하는지 적어 둔다.

깨어난 뒤 기기가 하는 일

자동 재연결은 공백 동안 트래픽을 차단하는 것과 같지 않다. 둘 다 확인한다: 터널이 돌아오는지, 그리고 공백 동안 보내려 한 앱이 보호 없이 나갔는지. 곧바로 재연결하지만 첫 초에 DNS 질의를 유출하는 클라이언트는 업무 기기에 잘못된 장애 정책을 가진 것이다. 무해한 요청과 직접 통제하는 목적지로 시험한다.

앱 복구가 세 번째 질문이다. 돌아온 터널은 시간 초과된 SSH 세션을 고치지 않으며, 사용자는 그 세션 손실을 VPN 고장으로 보고하곤 한다. 트리거, 클라이언트 빌드, 정확한 시각을 보고서에 함께 남기는 것은 그 조합이 예측 가능한 화면 꺼짐 수명 주기와 기기와 무관하게 실패하는 서버를 구분하기 때문이다.