분할 터널: 설정한 VPN 밖에서 링크가 열리는 이유

앱을 터널에 통과시켜도 그 앱이 실행하는 모든 것에 라우팅이 함께 가지는 않으며, 화면은 반대로 보여 주지만 실제로는 그렇습니다. 링크는 요청을 다른 프로그램에 넘기고, 그 프로그램이 자기 소켓을 열며, 플랫폼은 텍스트를 보여 준 쪽이 아니라 새 프로세스에 규칙을 적용합니다. 터널 정책이 실제로 보는 것은 두 번째 프로세스이고, 그것은 설정한 프로세스가 아닙니다.

따라서 포함된 앱이 터널 밖에 있는 브라우저를 열 수 있습니다. 제외된 브라우저가 터널 안의 앱에 작업을 되돌려 줄 수도 있습니다. 이 놀라움은 양방향 모두 정상 동작입니다.

아무도 설정하지 않은 작업 흐름의 부분

앱별 정책은 실행 파일이나 패키지의 식별자를 기준으로 작성되며, 모든 연결은 만들어지는 순간 평가됩니다. 브라우저, 문서 뷰어, 미디어 플레이어, 시스템 공유 시트는 각자 다른 식별자를 지니고 각자 다른 판정을 받습니다. 딥 링크가 나르는 것은 데이터이지 정책이 아닙니다.

관찰 결과가 임의적으로 보이는 것은 같은 클릭도 어느 핸들러가 응답하느냐에 따라 두 방향으로 라우팅되기 때문입니다. 터널 안의 메일 클라이언트가 링크를 열면 터널 밖에 사는 브라우저가 페이지를 띄우고, 그 페이지는 집 주소에서 받아 옵니다. 터널 밖의 브라우저가 문서를 열면 터널 안의 뷰어로 파일이 도착합니다. 두 결과 중 어느 것도 클라이언트의 결함이 아닙니다.

이미 실행 중인 핸들러는 상황을 더 나쁘게 만듭니다. 브라우저가 이미 열려 있으면 링크는 기존 프로세스로 가는 메시지가 되고, 그 프로세스는 시작할 때의 라우팅을 그대로 유지합니다. 핸들러를 닫았다 다시 열면 결과가 달라지며, 그래서 이 문제는 요청해도 재현되지 않습니다.

실제로 연결을 만든 프로세스

추론하지 말고 받는 쪽을 측정하세요. 터널을 켜 둔 채 무해한 링크를 클릭하고 새 프로그램이 쥔 소켓을 보세요.

ss -tnp state established '( dport = :443 )'
Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess

첫 명령은 리눅스에서 설정된 각 소켓 뒤의 프로세스 이름을 보여 주고, 둘째는 윈도우에서 소유 프로세스 식별자를 풀어 같은 일을 합니다. 프로세스 이름을 정책에 있는 이름과 비교하세요. 이름이 브라우저이고 그 브라우저가 제외되어 있다면, 클릭은 결함이 아니라 설계대로 터널을 떠난 것입니다. 정책 규칙을 살아 있는 소켓과 맞추는 것이 방법의 전부입니다.

핸들러가 이미 실행 중일 때와 닫혀 있을 때 검사를 반복하세요. 두 결과가 다를 수 있고, 그 차이가 터널을 빠져나가는 링크에 관한 대부분의 간헐적 보고를 설명합니다.

커버리지는 작업 흐름의 속성

작업이 처음부터 끝까지 터널 안에 있어야 한다면, 도달할 수 있는 모든 구성 요소, 곧 실행기와 핸들러와 뷰어, 그리고 플랫폼이 그 사이에 넣는 모든 중개자가 정책 안에 있어야 합니다. 더 넓은 커버리지가 정직한 답인 경우가 많고, 모든 공유 대상을 감사하는 것보다 저렴합니다.

앱 하나를 고치려고 시스템 중개자를 제외하는 것은 흔한 실수입니다. 중개자는 공유되기 때문에 제외는 같은 경로를 쓰는 다른 모든 앱에까지 따라가며, 보통 몇 주 뒤 보고서가 올 때까지 아무도 알아차리지 못합니다. 구성 요소를 제외하기 전에 그것에 무엇이 더 의존하는지 읽어 보세요.

식별자와 라우팅도 분리하세요. 링크는 어느 출구가 요청을 받든 세션 토큰이나 계정 식별자를 나를 수 있습니다. 올바르게 라우팅된 클릭도 목적지에 누가 그것을 따라왔는지 정확히 알려 줄 수 있습니다.

문서화할 것은 작업 흐름이지 첫 번째 체크박스가 아닙니다. 작업이 네 프로그램에 걸쳐 있으면, 네 프로그램이 그려진 도표가 트래픽이 어디로 가는지 예측하며, 단일 앱 설정은 그 도표의 한 줄일 뿐입니다.