공유 서비스가 데이터를 가져올 때 앱별 VPN 예외가 깨진다

애플리케이션 하나를 VPN에서 제외했는데 필요한 다운로드가 계속 실패하거나, 더 나쁘게는 작동하기 시작하고 무관한 것이 멈춥니다. 보이는 창이 모든 연결을 여는 프로세스라는 보장은 없으며, 애플리케이션은 작업을 도우미, 백그라운드 전송 서비스 또는 전혀 다른 패키지에 넘길 수 있습니다. 따라서 앱별 규칙에는 익숙한 실행 파일 이름이 아니라 플랫폼의 실제 ID 모델이 필요합니다. 아래 점검은 관찰에서 시작해 요청을 실제로 보낸 쪽으로 되돌아갑니다.

이 티켓에서는 보통 잘못된 구성 요소가 제외되고 그 예외가 이후에 좁혀지지 않는 두 가지 일이 함께 일어납니다.

창이 아니라 프로세스를 찾으십시오

실패한 작업을 재현하고 그 일이 일어나는 동안 연결을 소유한 프로세스나 패키지를 식별합니다. Windows에서는 백그라운드 전송이 자체 ID로 실행되는 서비스에 의해 중개될 수 있으므로 어느 창에 포커스가 있는지와는 다른 질문입니다. Linux와 macOS에서는 같은 분리가 도우미 프로세스와 시스템 데몬으로 나타납니다.

세부 정보 세 가지(실행 파일이나 패키지의 ID, 연결하던 대상, 워크플로에서 그것이 일어난 시점)를 적습니다. 시작 단계에서 실패하는 다운로드는 중간에 실패하는 다운로드와 다른 구성 요소의 메타데이터 가져오기인 경우가 많습니다. 그 차이만으로도 보통 규칙을 건드리기 전에 올바른 ID를 고르기에 충분합니다. ID가 앱이 아니라 서비스로 밝혀지면 그 한 가지 사실이 규칙 전체를 바꾸므로 먼저 확정하십시오.

작업이 너무 짧아 프로세스를 관찰할 수 없다면 더 큰 페이로드나 더 느린 대상으로 반복합니다. 목표는 재현 가능한 관찰 하나이지, 어떤 도우미가 관련됐는지에 대한 이론이 아닙니다.

DNS를 별도의 경로로 다루십시오

시스템 이름 확인이 제외된 애플리케이션을 전혀 따르지 않을 수 있어서, 제외된 브라우저가 사설 호스트 이름에서 계속 실패해도 트래픽은 올바르게 터널 밖에 있을 수 있습니다. 제외된 것은 브라우저이고 확인자는 아닙니다.

앱별 규칙이 적용될 때 플랫폼이 DNS를 어떻게 처리하는지 확인하고, HTTP 요청과 별도로 확인합니다. 확인자가 공유 서비스라면 기기의 모든 애플리케이션에 서비스를 제공하므로, 검토 중인 예외는 테스트한 것보다 훨씬 넓은 대상을 가집니다.

어떤 확인자가 어떤 인터페이스를 통해 응답했는지 기록합니다. 그 관찰 하나로 «앱은 제외됐지만 이름이 확인되지 않는다»는 보고의 상당 부분이 해결되므로 티켓과 함께 보관하십시오.

공유 도우미를 넓히지 마십시오

공유 서비스는 여러 애플리케이션을 위해 일하므로, 워크플로 하나를 고치려고 제외하면 무관한 트래픽도 바뀝니다. Windows의 Background Intelligent Transfer Service가 이 형태의 좋은 예로, 많은 애플리케이션이 사용할 수 있는 인프라이며 그 ID는 전송을 요청한 앱의 ID가 아닙니다.

그 예외를 추가하기 전에 클라이언트가 지원하는 규칙 모델과 조직의 요구 사항을 확인합니다. 구성 요소를 또 무엇이 사용하는지, 작성하려는 규칙을 공유 프로세스가 아니라 대상에 대해 표현할 수 있는지 물으십시오.

요구 사항을 애플리케이션 경계로 전혀 표현할 수 없다면 대상 기반 정책이나 다른 승인된 설계가 늘어나는 도우미 예외 목록보다 이해하기 쉽고 안전할 수 있습니다.

실패한 단계가 아니라 워크플로 전체를 테스트하십시오

지원되는 변경 후 의도한 작업을 새 요청으로 처음부터 끝까지 실행하고, 이어서 공유 구성 요소를 사용하는 다른 워크플로를 하나 실행합니다. 넓은 우회는 바로 거기서 자신을 드러내기 때문입니다. 첫 번째를 고치고 두 번째를 조용히 깨뜨리는 수정은 수정이 아닙니다. 두 결과를 모두 티켓에 남기고 두 번째 워크플로를 명시적으로 이름 붙여 검토자가 반복할 수 있게 하십시오.

테스트는 같은 대상, 같은 계정, 같은 조건으로 작고 반복 가능하게 유지합니다. 두 번째 워크플로가 문서화되어 있지 않다면 변경이 안전하다고 판단하기 전에 그 소유자에게 무엇에 의존하는지 물으십시오.

이름 목록이 아니라 이유를 남기십시오

구성 요소, 그것이 제공하는 워크플로, 제외한 이유를 문서화합니다. 목적이 연결되지 않은 도우미 이름 목록은 두 번의 릴리스 주기 안에 유지할 수 없게 되고, 다음 엔지니어가 정리하다가 잘못된 항목을 지웁니다.

예외마다 한 줄이면 충분합니다. 그것이 없으면 무엇이 깨지는지, 그 워크플로의 소유자는 누구인지, 마지막으로 언제 검증했는지라는 세 필드가 수수께끼 목록을 누군가 방어할 수 있는 정책으로 바꿉니다.