Windows 앱별 VPN 트리거와 분할 터널링: 무엇이 격리하는가
앱으로 시작되는 Windows VPN 프로필은 터널만 열어 줍니다. 라우팅된 분할 터널이 무엇이 들어갈지 정하며, 둘은 한 앱에 대해 서로 다르게 실패합니다.
Windows의 두 구성은 설정 화면에서 똑같아 보이지만 전혀 다르게 동작합니다. 하나는 애플리케이션 트리거가 있는 복사된 VPN 프로필로, 실행 파일 하나를 시작하면 터널이 올라옵니다. 다른 하나는 분할 터널 프로필로, 그 라우트 목록이 우연히 해당 앱이 통신하는 대상을 덮고 있습니다. 전자는 터널이 언제 존재하는지 답하고, 후자는 어떤 패킷이 들어가는지 답합니다. 나머지 머신을 물리 링크에 남겨 두는 것은 후자뿐입니다.
트리거는 수명 주기 규칙이지 라우팅 규칙이 아니다
Add-VpnConnectionTriggerApplication 실행 파일 경로를 프로필 이름에 연결합니다. 그 프로세스가 시작되면 원격 액세스 연결 관리자가 프로필로 전화를 걸고, 트리거 조건이 끝나면 연결이 끊길 수 있습니다. 이 교환에서 소켓을 검사하는 부분은 없습니다. 이 cmdlet에는 관리자 권한 셸, 바이너리 전체 경로, 그리고 -Force 기존 항목을 바꿀 때는 -Force가 필요합니다. 연결이 남았는지는 다음 명령으로 확인하십시오: Get-VpnConnectionTrigger 프롬프트를 믿는 대신, Microsoft의 Add-VpnConnectionTriggerApplication 참조 문서에 매개변수와 예제가 정리되어 있습니다.
“트리거가 아무것도 하지 않는다”는 보고의 대부분은 두 가지 한계로 설명됩니다. 트리거는 모든 사용자 프로필을 전제로 만들어지므로 프로필 범위를 먼저 확정해야 하고, 앱 경로는 실제로 실행되는 바이너리와 일치해야 합니다. 바로 가기나 두 번째 프로세스를 만드는 실행기가 아니라요. 다른 한계는 의도된 것이며, Windows가 신뢰할 수 있다고 분류한 네트워크에서는 프로필이 사무실 밖에서 쓰이도록 설계되었으므로 트리거가 대기 상태로 남습니다.
Add-VpnConnectionTriggerApplication -Name "APP_VPN" -ApplicationID "C:\Program Files\Vendor\app.exe" -Force
Get-VpnConnectionTrigger -Name "APP_VPN" | Format-List *
Get-VpnConnection -Name "APP_VPN" | Format-List Name,ConnectionStatus,SplitTunneling,AllUserConnection분할 터널이 터널을 건너는 것을 정한다
분할 터널이 꺼져 있으면 Windows는 VPN 인터페이스에 낮은 메트릭의 클래스 기반 기본 라우트를 설치합니다. 브라우저와 업데이트 서비스를 포함한 모든 소켓이 이를 따르므로, 이 구성의 트리거는 프로필이 연결된 동안 머신 전체를 움직입니다. 트리거는 여전히 수명 주기 규칙일 뿐이고, 영향 범위는 라우트에서 왔습니다.
분할 터널이 켜져 있으면 프로필은 게이트웨이가 밀어 주는 프리픽스나 VPN 인터페이스에 추가한 프리픽스만 나릅니다. 나머지는 계속 물리 기본 라우트를 씁니다. 사람들이 흔히 “한 앱만 별도 출구로”라고 말할 때 뜻하는 구성이 이것이며, 처음부터 끝까지 라우팅 결정입니다.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix라우팅된 분할이 앱을 격리하지 못하게 되는 지점
흔한 실패는 터널의 라우트 목록에 절대 나타나지 않는 목적지입니다. 한 주소로 로그인한 뒤 CDN에서 스트리밍하거나, 십여 개의 순환 엔드포인트를 해석하는 앱은 일부 연결을 VPN 인터페이스에, 나머지를 Wi-Fi에 두게 됩니다. IPv6는 별도 테이블이므로 IPv4 프리픽스만 밀어 주는 프로필은 올바르게 보여도 앱의 IPv6 트래픽은 로컬에 남습니다.
더 작은 두 영향도 똑같이 중요합니다. 최장 프리픽스 일치가 이기므로, 더 구체적인 on-link 라우트, 관리 호스트용으로 밀어 준 /32, 두 번째 어댑터의 서브넷이 당신이 신경 쓰는 주소에서 터널을 이길 수 있습니다. 이름 해석도 라우팅보다 먼저 일어납니다. 프로필의 DNS 서버나 NRPT 규칙이 이름을 덮지 않으면 앱은 물리 어댑터로 해석한 뒤 터널 프리픽스 안에 없던 주소로 전화를 걸 수 있습니다.
세 가지 형태와 각각이 사는 것
표는 벽에 붙여 둘 부분입니다. 결정은 기능이 아니라 영향 범위의 문제이기 때문입니다. 앱의 목적지가 나열할 수 있는 안정적인 프리픽스라면 라우팅된 분할이 가장 작은 발자국으로 격리를 줍니다. 아니라면 VM이나 두 번째 기기 뒤의 기본 라우트 프로필이 하나 이상의 프로세스를 옮기는 대가로 분리를 정직하게 유지합니다.
| Shape | What starts the tunnel | What enters it | Pick it when |
|---|---|---|---|
| Trigger plus routed split | Process start | Only pushed or added prefixes | The app's endpoints are stable prefixes and the host should stay direct |
| Trigger plus default route | Process start | Everything, machine-wide | You need one exit for all traffic and accept the wider scope |
| Separate VM or device | Guest boot or login | Everything inside that guest | The app's destinations rotate, or the host must keep its own public address |
이 중 어느 것도 호스트의 소켓 수준 바인딩을 제공하지 않습니다. 클래식 Windows VPN 클라이언트에는 “이 프로세스는 이 어댑터를 써야 한다”는 규칙이 없습니다. 트리거와 라우트 필터는 서로 다른 계층에 있고, 인터페이스를 고르는 계층은 라우팅 테이블입니다. 어떤 안내서가 복사한 프로필만으로 앱별 강제를 약속한다면, 어느 라우트나 어느 필터가 그 일을 하는지 물어보십시오.
한 번에 둘 다 확인하기
수명 주기와 라우팅을 따로, 이 순서로 시험합니다. 앱을 닫고 프로필이 Disconnected를 보고하는지 확인한 다음, 앱을 시작해 상태가 바뀌었는지 봅니다. 터널이 올라온 뒤에야 특정 목적지가 어디로 가는지 물어야 하고, 추측 대신 앱이 실제로 거는 주소를 써야 합니다.
$app = Get-Process app | Select-Object -First 1
Get-VpnConnection -Name "APP_VPN" | Select-Object ConnectionStatus
Get-NetTCPConnection -OwningProcess $app.Id -State Established | Select-Object RemoteAddress,RemotePort
Find-NetRoute -RemoteIPAddress 203.0.113.10Find-NetRoute 그 목적지를 실어 나를 인터페이스와 다음 홉을 알려 줍니다. 거기에 물리 별칭이 나오면 터널은 올라와 있지만 그 흐름에는 무관하다는 뜻입니다. 밀어 준 프리픽스, 더 구체적인 라우트, IPv6 순으로 확인하십시오. 상태가 전혀 바뀌지 않으면 트리거가 발동하지 않은 것이며, 실행 파일 경로, 프로필 범위, VPN 클라이언트 운영 로그 세 곳을 보면 됩니다.
다음 시험이 정직하도록 깔끔하게 되돌리기
먼저 애플리케이션 트리거, 다음 프로필 순으로 구성한 역순으로 제거합니다. 트리거를 남긴 채 프로필을 지우면 다음 시도를 헷갈리게 하는 매달린 연결이 남고, Remove-VpnConnection -Force cmdlet 밖에서 만든 phonebook 항목을 항상 지우지는 못합니다.
사용자별 항목은 사용자의 rasphone.pbk 아래 Roaming 프로필에 있고, 모든 사용자 항목은 ProgramData 아래에 있습니다. 프로필 범위에 맞는 저장소를 확인하고, 남겨 둔 프로필을 다시 연결해 그 라우트와 DNS가 여전히 제대로 동작하는지 확인하십시오. 그래야 나중 시험이 남은 상태가 아니라 당신이 바꾼 것을 측정합니다.
- 터널은 프로세스가 시작될 때 올라오며 로그인할 때가 아닙니다.
- VPN 인터페이스에는 의도한 프리픽스만 나타납니다.
- 앱의 실제 원격 주소가 VPN 별칭으로 해석됩니다.
- 프로필을 제거한 뒤 매달린 트리거가 남지 않습니다.