분할 터널에서 제외한 앱을 킬 스위치가 차단할까요?

킬 스위치가 켜져 있고, 앱이 의도적으로 터널에서 제외되어 있으며, 두 요구가 이제 서로 충돌합니다. 하나는 터널 밖으로 아무것도 나갈 수 없다고 하고, 다른 하나는 이 프로그램이 직접 나가야 한다고 합니다. 클라이언트마다 이 충돌을 다르게 해결하며, 설정 화면은 어느 규칙이 이기는지 거의 설명하지 않습니다. 어떤 라벨도 믿기 전에 앱별 정책을 적으세요.

두 정책, 한 대의 기계

킬 스위치는 터널이 트래픽을 보호하지 않으면 트래픽이 멈춘다는, 장애에 대한 약속입니다. 분할 터널은 이 프로그램이나 목적지는 터널을 쓰고 저것들은 쓰지 않는다는, 선택에 대한 약속입니다. 두 번째 약속은 첫 번째가 판단해야 할 트래픽을 만듭니다. 어느 약속도 틀리지 않았고, 다만 서로 다른 사람이 서로 다른 위협을 위해 썼습니다.

결과는 세 가지이며 그중 하나만 배포가 의도한 것입니다. 제외된 앱은 장애 중에도 직접 경로로 남아 분할을 지키고 킬 스위치를 깨뜨릴 수 있습니다. 다른 모든 것과 함께 차단되어 킬 스위치를 지키고 분할을 깨뜨릴 수도 있습니다. 또는 인터페이스가 사라진 뒤 플랫폼이 규칙을 어떻게 평가하느냐에 따라 가끔만 차단될 수도 있습니다. 티켓을 만드는 것은 마지막 경우입니다.

규칙보다 앱 목록을 먼저

터널을 써야 하는 프로그램, 직접 나가야 하는 프로그램, 두 목록 어디에도 절대 나타나서는 안 되는 이름이나 목적지를 나열하세요. 리졸버 동작과 IPv6 쪽은 둘 다 페이지 트래픽과 다른 정책을 따를 수 있으므로 따로 포함하세요.

앱별 규칙은 보통 실행 파일이나 패키지에 맞고 그 안의 프로필에는 맞지 않습니다. 브라우저 프로필, 시크릿 창, 확장 프로그램은 자체 네트워크 신원을 갖지 않으므로 프로세스가 받은 것을 그대로 물려받습니다. 그 브라우저가 띄운 보조 프로세스는 같은 규칙을 전혀 물려받지 않을 수 있습니다.

목록은 하나가 아니라 둘이 필요하며, 터널이 실어야 할 것과 어떤 이유로도 그 밖으로 나가서는 안 되는 것입니다. 둘 다에 오르는 앱은 구현 세부가 아니라 요구 충돌이며, 클라이언트를 구성하기 전에 정리해야 합니다.

장애 중에 클라이언트가 하는 일

일부 구현은 장애 중에 제외된 앱을 차단하고 다시 연결되면 접근을 복원합니다. 다른 구현은 직접 경로를 계속 유지하며, 이는 분할과 일관되지만 보안 속성으로는 약합니다. 플랫폼 수준의 잠금은 클라이언트의 앱별 선택을 완전히 덮어쓸 수 있습니다. 이 차이는 겉모습이 아니라, 제외된 앱이 정책 예외인지 구멍인지를 결정합니다.

VPN 없이 연결을 차단하는 옵션이 있는 Android의 상시 VPN이 가장 분명한 예로, 잠금을 강제하는 것은 클라이언트가 아니라 플랫폼이고, 터널이 내려가 있는 동안 제외된 패키지는 다른 모든 것과 함께 차단됩니다. 앱별 예외를 자체 드라이버에서 적용하는 데스크톱 클라이언트는 애초에 그 프로세스의 트래픽을 소유한 적이 없기에 보통 제외된 프로세스를 물리 인터페이스에 남깁니다. 두 동작 모두 옹호할 수 있지만, 제외된 앱이 사용 가능하게 남아야 한다는 요구에 맞는 것은 하나뿐입니다. 결과를 해석하기 전에 어느 구성 요소가 규칙을 강제하는지 물으세요.

눈앞의 운영 체제 동작을 읽고, 다른 곳의 같은 이름 설정을 읽지 마세요. 강제 API가 다르며, 체크박스 하나가 데스크톱과 휴대폰에서 전혀 다른 의미일 수 있습니다. 버전도 중요한데, 잠금 제어는 Android 릴리스마다 화면 사이를 옮겨 다녔고, 클라이언트 측 제외 목록은 플랫폼 잠금과 같은 제어가 아닙니다.

세 순간: 터널 올라감, 터널 내려감, 다시 연결

무해한 요청을 터널이 동작할 때, 관심 있는 장애가 나는 동안, 다시 연결된 뒤의 세 순간에 쓰세요. 브라우저 결과 하나로는 제외된 앱의 동작을 확정할 수 없습니다.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

출구 주소는 어느 경로로 나갔는지 보여 주고, 명시적 인터페이스 시험은 터널이 유일한 출구일 때 무슨 일이 일어나는지 보여 줍니다. 하나를 실행하기 전에 그러지 않으면 출력이 나중에 해석되므로 각 줄 옆에 기대하는 결과를 적으세요.

제외된 앱이 오프라인이 되면, 그 수정은 시험하던 구분을 파괴하므로 넓은 방화벽 허용을 추가하기 전에 정책 우선순위를 살피세요. 직접 경로로 남는다면 그것이 문서화된 예외이며 우연한 후퇴가 아님을 확인하세요. 기기 전체에 대한 엄격한 요구라면 손으로 시험할 수 있을 때까지 예외 목록을 줄이세요.