기능 목록에 적힌 킬 스위치는 터널이 끊길 때 무슨 일이 일어나는지 거의 말해 주지 않습니다. 어떤 구현은 선택한 프로세스를 닫고, 다른 구현은 운영 체제 경계에서 패킷 필터를 설치하며, 세 번째는 그저 다시 연결을 시도합니다. 차이는 장애 후 몇 초 안에 드러나며 설정 화면에서는 보이지 않습니다. 다음 점검을 순서대로 진행하고 정직하게 답할 수 없는 첫 항목에서 멈추십시오. 그곳이 실제 보호 범위의 끝입니다.

먼저 적용 메커니즘을 확인한다

프로세스 종료는 응용 프로그램 수명 주기 기능입니다. 감지된 터널 장애 후 선택된 프로그램을 찾아 닫습니다. 주 프로세스가 아닌 것은 모두 살아남습니다. 보조 서비스, 백그라운드 동기화, 일 초 뒤에 시작된 앱은 저마다의 수명 주기와 시점을 가집니다.

패킷 필터링은 운영 체제 기능입니다. 허용된 경로를 따르지 않는 트래픽을 거부하며, 이는 더 강한 약속이지만 규칙이 실제로 일치하는 범위에서만 그렇습니다. 주소 체계, 인터페이스, 제외된 앱과 예외가 그것을 결정하며 클라이언트의 표시 이름이 아닙니다.

차단이 클라이언트보다 오래가는가

이 순서로 네 가지를 물으십시오. 충돌 시, 수동 종료 시, 로그아웃 시, 재부팅 시에 무슨 일이 일어나는가. 클라이언트가 스스로 관리하는 규칙은 보통 정상 종료 때 제거되고 흔히 충돌 후 남습니다. 플랫폼 저장소에 설치된 규칙은 반대로 행동할 수 있어 클라이언트와 때로는 제거까지 견딥니다.

긴 다운로드 도중 클라이언트를 종료하고 전송이 멈추는지 계속되는지 보십시오.

흔한 구멍을 찾는다

첫째는 IPv6입니다. IPv4 주소용으로 작성된 규칙은 IPv6 트래픽을 그대로 통과시키며 많은 클라이언트는 v4 절반만 씁니다. 둘째는 인터페이스입니다. USB 테더링, 두 번째 Wi-Fi 어댑터, 셀룰러 모뎀은 기본 연결로 한정된 규칙에 포함되지 않을 수 있습니다. 제외된 앱 과 로컬 네트워크 예외가 셋째입니다.

Windows에서는 토글을 믿는 대신 설치된 규칙을 읽을 수 있습니다. Get-NetFirewallRule -DisplayName '*VPN*' 과 netsh wfp show filters 은 둘 다 무엇이 존재하는지 보여 줍니다. Linux에서는 iptables -S, ip6tables -S, nft list ruleset 이 흔한 경우를 포괄하며 셋을 비교하는 것이 핵심입니다.

DNS가 흔한 누출 지점

UDP 53을 열어 둔 채 TCP를 막으면 모든 호스트 이름 질의에 여전히 응답하는 아주 그럴듯한 킬 스위치가 됩니다. DNS가 다른 인터페이스의 리졸버로 넘어가거나, 클라이언트가 v4만 막고 리졸버가 v6로 도달 가능할 때도 같습니다.

터널이 내려간 상태에서 알려진 이름 하나를 해석해 보고 응답이 돌아오는지 확인하십시오. 돌아온다면 상태 아이콘이 무엇을 말하든 트래픽은 완전히 차단되지 않은 것입니다.

토글이 아니라 전환을 시험한다

VPN을 자체 메뉴에서 끄는 것은 정상 종료이며 정상적인 경우는 모든 구현이 잘 처리합니다. 중요한 전환은 거친 쪽입니다. 터널 프로세스를 죽이고, 네트워크를 뽑고, 서버가 응답을 멈추게 하십시오. 그다음 요청을 시작해 실패하는지 아니면 조용히 물리 링크를 쓰는지 보십시오.

노트북 한 대의 결과가 휴대폰이나 라우터로 이어지지 않습니다. 플랫폼 API도 기본값도 다르고, Android에서는 차이가 뚜렷합니다. 차단을 포함한 상시 연결은 클라이언트가 아니라 시스템이 강제하므로 클라이언트가 작동하지 않을 때도 계속 작동합니다. Android VPN 안내 가 그 구분을 설명합니다.

돌아갈 길을 남긴다

시스템 수준 차단은 반대의 실패 모드를 가집니다. 클라이언트보다 오래 사는 필터는 제거 후 컴퓨터를 네트워크 없이 남길 수 있으며 이는 원인을 알 수 없는 지원 요청입니다. 플랫폼 규칙을 쓰는 킬 스위치를 켜기 전에 그것이 어떻게 제거되는지 기록하고 공급업체의 복구 경로를 찾을 수 있는 곳에 두십시오.

클라이언트에 대해 충돌, IPv6, DNS, 전환 점검에 답할 수 없다면 알려진 구멍이 있는 앱 수준 스위치로 취급하고 그에 맞게 계획하십시오.

관련 글