VPN 앱이 시작되기 전에 킬 스위치가 트래픽을 차단할까?

킬 스위치는 자신의 앱이 시작되기 전 구간을 덮을 수도 있고 덮지 않을 수도 있으며, 그 차이는 클라이언트의 홍보 페이지가 아니라 운영체제 정책이 결정합니다. 자동 실행 체크박스는 무언가가 시작되도록 예약되어 있다는 것만 증명합니다. 네트워크가 올라오는 순간에 차단 규칙이 존재한다는 것은 증명하지 않습니다. 이는 두 개의 사건이며, 그중 하나만 트래픽을 보호합니다.

점검 목록을 순서대로 진행하십시오. 각 단계는 실제로 무엇을 시험하는지를 좁혀 줍니다.

차단은 실제로 어디에서 오는가

구현에는 두 계열이 있습니다. 앱이 실행되기 전에 터널을 알고 있는 플랫폼이 차단을 설치하거나, 아니면 클라이언트가 시작된 뒤 스스로 차단을 설치합니다. 전자는 로그인 전에도 존재할 수 있습니다. 후자는 자신의 프로세스보다 먼저 존재할 수 없습니다. 그 프로세스가 아무리 일찍 예약되어 있어도 마찬가지입니다. 무엇이든 시험하기 전에 어느 계열에 기대고 있는지 확인하십시오.

Android에서는 항상 켜짐 VPN과 VPN 없이 연결 차단 설정이 결합된 것이 플랫폼 정책이며, 클라이언트 내부만이 아니라 시스템 설정에서 구성합니다. 관리되는 기기에서는 미리 설정되어 있을 수 있습니다. 단지 부팅 시 시작되는 클라이언트는 같은 메커니즘이 아닙니다.

구간과 서비스를 분리하라

닫힌 구간은 차단이 멈췄다는 증거가 아니고, 열린 구간은 터널이 준비되었다는 증거가 아닙니다. 많은 클라이언트는 인터페이스, 데몬, 트레이 앱을 분리합니다. 트레이는 눈에 보이는 부분이고, 데몬은 규칙을 들고 있는 부분입니다.

아이콘이 아니라 구성 요소를 시험하십시오.

시작 구간을 안전하게 시험하라

시험할 구간은 재부팅이나 로그인에서 시작해 터널이 인증될 때 끝납니다. 그동안 백그라운드 앱이 연결되며, 업데이트 확인이 흔한 주범입니다. 자신의 접근을 차단하는 대신 무해한 활동과 공급업체가 문서화한 절차를 사용하십시오. 그다음 정상 재연결 후에 반복하십시오. 재연결 경로와 콜드 스타트 경로는 다른 코드를 실행하기 때문입니다.

터널이 이미 올라온 뒤에 하는 시험은 시작에 대해 아무것도 증명하지 않습니다.

지속성이 요구 사항이라면 재부팅 동작을 읽으십시오. 설정은 구성에 남아 있는데 그 시행은 나중에 시작될 수 있으며, 두 사실이 모두 중요합니다. 저장된 정책과 그것이 활성화되는 순간입니다.

플랫폼별로 정책을 읽어라

Android는 항상 켜짐과 차단을 별도의 스위치로 노출하며, 시작 전 보호를 위해서는 둘 다 켜져 있어야 합니다. Windows에는 정책으로 구성하는 항상 켜짐 장치 터널 개념이 있으며, 이는 일찍 시작하는 사용자 모드 클라이언트와 같지 않습니다. OpenVPN Connect는 플랫폼별 킬 스위치 동작을 문서화하며, 문서화된 범위가 바로 시험 대상입니다. 한 시스템의 설정 이름을 다른 시스템으로 옮기면서 의미도 함께 이동했다고 가정하지 마십시오.

대화형 암호를 요구하는 프로필은 머신 터널과 시작 의존성이 다릅니다.

무엇을 기록할까

어떤 메커니즘이 시행 중인지, 어느 단계에서 활성화되는지, 그 단계 전에 어떤 트래픽을 시도했는지 적으십시오. 플랫폼 버전도 기록하십시오. 이 동작은 릴리스 사이에서, 그리고 관리형과 개인 구성 사이에서 달라집니다. 정책을 클라이언트가 소유하는지 시스템이 소유하는지도 적으십시오. 누가 빈틈을 고칠 수 있는지가 그것으로 결정됩니다. 그런 다음 클라이언트나 OS 업데이트가 있을 때마다 다시 시험하십시오.

빈틈이 중요하다면 지속적인 해결책은 플랫폼 정책이며, 더 짧은 시작 지연이 아닙니다.

이것이 원래 질문에 대한 답입니다. 조건으로 말하면, 킬 스위치는 앱보다 먼저 존재하는 무언가가 차단을 설치할 때만 앱 시작 전에 트래픽을 보호합니다.