앱별 킬 스위치 대 기기 전체 잠금: 무엇이 달라지는가
라벨이 아니라 보호되는 집합으로 결정하세요: 제외된 앱, 백그라운드 도우미, 새 연결에서 무엇이 멈추는지, 그리고 각 경우를 어떻게 시험할지.
앱별 킬 스위치는 신중한 선택처럼 들린다—터널이 끊기면 업무 클라이언트만 네트워크를 잃고 나머지는 계속 작동한다. 그런데 누군가 알아차린다—개인 브라우저는 그래도 페이지를 불러왔고, 같은 제품군에 포함된 동기화 도우미는 계속 재시도했으며, 캐시된 이름은 터널을 한 번도 거치지 않은 주소로 여전히 해석되었다. 기능에 붙은 라벨과 그것이 실제로 보호하는 연결의 집합은 서로 다른 것이다. 먼저 보호되는 집합을 정하라—그 집합이 앱별 적용인지 기기 전체 잠금인지가 정직한 설명인지를 결정하기 때문이다.
라벨이 아니라 집합에서 시작하라
앱별 정책은 선택된 애플리케이션을 보호한다. 기기 잠금은 더 넓은 네트워크 경계를 겨냥하며, 보통 로컬 인쇄, 관리 트래픽, 캡티브 포털에 대한 문서화된 예외를 둔다. 두 라벨 모두 세 가지 질문에 답할 수 있을 때까지 완전하지 않다— 제외된 앱은 어떻게 되는가, 그 앱이 시작하는 도우미는 어떻게 되는가, 보호가 불가능한 동안 열린 연결은 어떻게 되는가.
클라이언트 설정을 건드리기 전에 그 답을 적어 두라. 요구가 "이 급여 클라이언트는 터널 밖에서 인터넷과 절대 통신해서는 안 되고, 내 브라우저는 통신해도 된다"라면 집합이 작고 앱별 적용이 맞는다. 요구가 "이 기기에서는 업데이트 서비스를 제외하고 아무것도 보호 없이 인터넷에 도달해서는 안 된다"라면 어떤 앱별 정책도 그것을 만들어 내지 못한다—이름을 대지 않은 앱이 바로 문제이기 때문이다.
앱별 적용은 식별자와 일치하고, 프로그램 이름과는 일치하지 않는다
Android는 패키지를 통해 앱별 VPN을 제공하며, VpnService 문서는 그것이 상시 켜짐 동작 및 차단과 어떻게 상호작용하는지 설명한다. iOS는 관리 프로필을 통해 앱별 VPN을 구성하고 앱 또는 도메인으로 일치시킨다. Windows와 Linux에는 프로세스별 경로가 아예 없으므로, 같은 아이디어를 프로그램으로 한정한 방화벽 규칙이나 소유 사용자와 일치하는 규칙으로 근사한다.
경계는 식별자이며, 식별자는 우회하기 쉽다. URL을 시스템 브라우저에 넘기거나 뷰어에서 문서를 여는 앱은 정책이 한 번도 지목하지 않은 프로세스로 넘어간다. 끊길 때 종료하는 옵션도 패킷 필터가 아니다—설정한 앱을 죽일 뿐, 자식 프로세스나 큐 작업자, 브라우저 탭은 기존 소켓을 계속 살려 둘 수 있다.
잠금은 앱별 정책이 볼 수 없는 것을 덮는다
기기 전체 잠금은 선택을 없앤다. 터널에 속하지 않는 모든 아웃바운드 패킷이 버려지며, 앱 정책이 전혀 몰랐던 프로세스의 트래픽도 포함된다. Android에서는 상시 켜짐 VPN과 연결 차단 설정의 조합이고, 적용은 클라이언트 창이 아니라 시스템에서 일어난다. 데스크톱에서는 영구 방화벽 규칙이거나 도달할 수 없는 게이트웨이를 향한 기본 경로다.
대가는 나머지가 모두 멈춘다는 것이며, 그래서 예외는 나중에 덧붙이는 것이 아니라 설계의 일부가 된다. 로컬 프린터, 서비스 검색, 캡티브 포털 로그인, 관리 에이전트, OS 업데이트는 각각 문서화된 구멍이 필요하다—각각이 터널이 꺼져 있을 때 열린 채로 남는 경로이기 때문이다. 잠금은 그 목록에서 가장 짧은 항목만큼만 강하다.
DNS, IPv6, 백그라운드 도우미가 누출을 숨긴다
보호된 앱이 이름을 해석하지 못한다고 해서 캐시된 응답이나 직접 IP 트래픽이 차단되었다는 증거는 아니다. 확인자가 터널 밖에서 여전히 도달 가능하면 이름은 해석되고 연결은 실패한다—그것은 작동하는 킬 스위치처럼 보이지만 아니다. 더 나쁜 경우, 캐시된 레코드가 터널이 나르지 않는 주소를 가리킬 수 있어 연결은 직접 나가는데 앱은 VPN 오류를 보고한다.
IPv6는 그것을 실행하는 모든 플랫폼에서 자체 규칙이 필요하다—v4용 차단 규칙이 v6 경로를 덮지 않기 때문이다. 모바일에서는 비공개 DNS 설정이 해석을 기기 정책이 검사하지 않는 암호화 채널로 옮길 수 있다. 그리고 백그라운드 도우미는 데스크톱의 흔한 범인이다—트레이의 업데이터나 동기화 프로세스가 VPN 클라이언트보다 먼저 시작해 자체 연결을 유지하므로, 바뀐 경로를 결코 보지 못한다.
앱 세 개와 전환 두 개를 시험하라
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
각 행을 두 번 실행하라—한 번은 호스트 이름으로, 한 번은 리터럴 주소로, 네트워크가 제공하면 IPv6로 한 번 더. 통과란 포함된 앱이 멈추고, 제외된 앱이 적어 둔 대로 동작했으며, 도우미가 빠져나가지 않았다는 뜻이다. 수용 가능하다고 결정한 직접 동작을 기록해 두면, 다음 관리자가 의도된 예외와 고장을 구별할 수 있다.
그다음 앱과 조건을 지목하는 한 문장으로 결과를 설명하라—예를 들어 급여 클라이언트는 터널 밖 경로가 없고, 브라우저는 설계상 직접이며, 터널이 꺼지면 나머지는 모두 멈춘다. 그 문장을 쓰기 어렵다면 정책은 아직 서로 싸우는 두 정책이다.