분할 터널링이 앱 업데이트를 다루지 못하는 이유

애플리케이션을 분할 터널 제외 목록에 추가했고, 앱은 인터넷에 직접 연결되는데도 업데이트는 여전히 실패하거나 여전히 터널을 통해 기어갑니다. 제외는 제대로 작동했습니다. 다만 다운로드를 수행하는 프로세스와 다른 프로세스를 덮었을 뿐이며, 현대의 업데이트 프로그램은 앱 창과 같은 실행 파일인 경우가 드물기 때문입니다.

오해: 앱을 제외하면 그 트래픽도 제외된다

앱별 분할 터널링은 플랫폼에 따라 프로세스, 패키지 또는 앱 경로를 일치시킵니다. 브랜드나 기능, 사용자의 의도를 일치시키지는 않습니다. 앱이 다운로드를 도우미, 공유 플랫폼 서비스 또는 브라우저 구성 요소에 넘기면, 그 도우미는 고유한 정체성과 터널을 지나는 고유한 경로를 가집니다. 제외 목록은 두 프로세스가 같은 제품에 속한다는 것을 전혀 모릅니다. 여러분이 지목한 쪽이 어느 것인지만 압니다.

그래서 규칙은 지시받은 그대로 하고 있습니다. 전송을 누가 소유하는지에 대한 가정이 틀렸고, 해결은 제외를 더 추가하는 것이 아니라 그 주인을 식별하는 데서 시작합니다.

전송의 주인을 찾으세요

Android에서는 제외한 앱 패키지가 아니라 공유 서비스 패키지가 업데이트를 가져올 수 있으며, 앱별 VPN 규칙 은 소켓을 여는 패키지에 적용됩니다. Windows에서는 업데이터 서비스가 앱과 다른 실행 경로에서 실행될 수 있어 앱 경로와 일치하는 규칙이 이를 놓칩니다. macOS에서는 권한 있는 도우미나 시스템 업데이트 데몬이 전송을 수행하고 앱은 이를 요청만 할 수 있습니다.

증거로 주인을 식별하려면 플랫폼의 네트워크 활동 보기, 프로세스로 필터링한 패킷 캡처, 업데이터 구성 요소를 지목한 공급업체 문서를 사용하십시오. 프로세스 이름으로 짐작하는 것이 바로 비슷하게 생긴 두 바이너리를 혼동하고 잘못된 쪽을 제외하는 방식입니다.

업데이트 시스템은 작업을 나누기도 합니다. 작은 메타데이터 요청이 버전을 확인하고, 훨씬 큰 패키지 다운로드는 콘텐츠 전송 호스트나 다른 도메인으로 갑니다. 메타데이터 확인은 터널을 통해 성공할 수 있지만 패키지 전송은 터널이 다르게 라우팅하는 호스트에서 멈춥니다. 이 분할이 업데이트가 감지되지만 설치되지 않는 혼란스러운 보고를 설명합니다. 앱이 열리는지 시험하는 대신 같은 기기와 같은 네트워크에서 패키지 다운로드 자체를 시험하세요.

검증은 경로 변경에서도 살아남습니다

경로를 바꾸는 것이 TLS, 게시자 신원 또는 패키지 서명 검증을 대체하지는 않습니다. 설명되지 않는 인증서 경고를 넘긴 뒤에야 다운로드가 성공한다고 해서 그 검사를 꺼서는 안 됩니다. 제외된 경로에서만 나타나는 경고는 장애물이 아니라 발견 사항입니다. 우회를 넓히기 전에 조사하십시오.

관리되는 기기에서는 모든 시스템 서비스에 대해 광범위한 규칙을 추가하는 대신 지원되는 예외를 요청하십시오. 업데이터 하나를 고치려고 모든 공유 서비스를 제외하는 규칙은 우회를 원래 요청보다 훨씬 넓힙니다.

업데이트를 시험하고 나서 주인을 기록하세요

변경 후에는 일부 클라이언트가 터널 재연결 시 라우팅을 다시 구성하므로 다시 연결해 적용된 규칙을 확인하십시오. 확인, 다운로드, 검증, 설치로 구성된 업데이트 주기를 한 번 완전히 실행하십시오. 확인이 성공해도 경로의 아주 작은 부분만 증명할 뿐입니다.

전송의 주인, 대상 호스트, 의도한 경로를 분할 터널 규칙과 같은 곳에 기록하십시오. 그렇지 않으면 다음 번 업데이트 방식 변경이 예외를 조용히 무효화하고, 이를 물려받는 사람은 규칙이 어느 프로세스를 위해 작성되었는지 알 방법이 없습니다.