Windows VPN trigger per app vs split tunneling: ano ang naghihiwalay

Dalawang setup ng Windows ang magkamukha sa Mga Setting at hindi magkapareho ang kilos. Ang isa ay kinopyang VPN profile na may trigger ng application, kaya ang pag-start ng isang executable ay nag-aangat ng tunnel. Ang isa pa ay profile ng split tunnel na ang listahan ng ruta ay nagkataong sumasaklaw sa kausap ng app na iyon. Ang una ay sumasagot kung kailan umiiral ang tunnel. Ang pangalawa ay sumasagot kung aling mga packet ang pumapasok dito, at tanging ang pangalawa ang nag-iiwan sa natitirang bahagi ng makina sa pisikal na link habang nananatiling konektado ang app.

Ang trigger ay patakaran ng lifecycle, hindi patakaran ng routing

Add-VpnConnectionTriggerApplication nag-uugnay ng path ng executable sa pangalan ng profile. Kapag nagsimula ang prosesong iyon, tinatawag ng Remote Access Connection Manager ang profile, at kapag natapos ang kondisyon ng trigger, maaaring bumagsak ang koneksyon. Walang anumang bagay sa pagpapalitang iyon ang sumusuri sa mga socket. Kailangan ng cmdlet ang naka-elevate na shell, ang buong path sa binary, at -Force kapag pinapalitan mo ang umiiral na entry. Kumpirmahin na nanatili ang asosasyon gamit ang Get-VpnConnectionTrigger sa halip na magtiwala sa prompt; ang reference ng Add-VpnConnectionTriggerApplication naglilista ng mga parameter at halimbawa.

Dalawang limitasyon ang nagpapaliwanag sa karamihan ng ulat na “walang ginagawa ang trigger”. Ang mga trigger ay binuo sa paligid ng mga profile para sa lahat ng user, kaya ang saklaw ng profile ang unang dapat ayusin, at ang path ng application ay dapat tumugma sa binary na talagang tumatakbo, hindi sa shortcut o launcher na gumagawa ng pangalawang proseso. Ang isa pang limitasyon ay sinadya: sa network na inuuri ng Windows bilang pinagkakatiwalaan, nananatiling idle ang trigger, dahil ang profile ay para umandar sa labas ng opisina.

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

Pinapasya ng split tunnel kung ano ang tumatawid sa tunnel

Kapag patay ang split tunnel, nag-i-install ang Windows ng default route na nakabatay sa klase na may mababang metric sa interface ng VPN. Sinusundan ito ng bawat socket, kabilang ang browser at ang serbisyo ng update, kaya ang trigger sa setup na iyon ay naglilipat sa buong makina habang konektado ang profile. Ang trigger ay patakaran pa rin ng lifecycle; ang lawak ng epekto ay galing sa ruta.

Kapag buhay ang split tunnel, dala lang ng profile ang mga prefix na itinutulak ng gateway o idinadagdag mo sa interface ng VPN. Ang lahat ng iba ay gumagamit pa rin ng pisikal na default route. Iyon ang setup na karaniwang ibig sabihin ng mga tao sa “isang app sa hiwalay na labasan”, at ito ay desisyon sa routing mula simula hanggang dulo.

Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix

Saan tumitigil ang naka-route na split sa paghihiwalay ng app mo

Ang karaniwang kabiguan ay destinasyong hindi kailanman lumilitaw sa listahan ng ruta ng tunnel. Ang app na nagla-log in sa isang address at pagkatapos ay nag-stream mula sa CDN, o nagre-resolve ng dose-dosenang umiikot na endpoint, ay maglalagay ng ilang koneksyon sa interface ng VPN at ang iba sa Wi-Fi. Hiwalay na talahanayan ang IPv6, kaya ang profile na nagtutulak lang ng IPv4 prefix ay maaaring magmukhang tama habang nananatiling lokal ang IPv6 traffic ng app.

Dalawang mas maliit na epekto ang kasinghalaga. Nanalo ang pinakamahabang prefix match, kaya ang mas espesipikong on-link na ruta, isang /32 na itinulak para sa host ng pamamahala, o ang subnet ng pangalawang adapter ay maaaring manalo sa tunnel para sa eksaktong address na pinapahalagahan mo. Nangyayari rin ang resolution bago ang routing: maliban kung sakop ng DNS server ng profile o ng NRPT rule ang pangalan, maaaring mag-resolve ang app sa pisikal na adapter at pagkatapos ay tumawag sa address na hindi kailanman nasa loob ng naka-tunnel na prefix.

Tatlong hugis, at ano ang binibili ng bawat isa

Ang talahanayan ang bahaging ididikit ko sa dingding, dahil ang desisyon ay tungkol sa lawak ng epekto at hindi sa features. Kung ang mga destinasyon ng app ay matatag na prefix na malilista mo, ang naka-route na split ay nagbibigay ng paghihiwalay na may pinakamaliit na bakas. Kung hindi, ang profile na default route sa likod ng VM o pangalawang device ay nagpapanatili ng malinis na paghihiwalay kapalit ng paglipat ng higit sa isang proseso.

Ang hindi ibinibigay ng alinman sa mga ito ay ang pagbubuklod sa antas ng socket sa host. Ang klasikong Windows VPN client ay walang patakarang nagsasabing dapat gamitin ng prosesong ito ang adapter na iyon; magkaibang layer ang mga trigger at route filter, at ang layer na pumipili ng interface ay ang routing table. Kung nangangako ang gabay ng pagpapatupad per app mula lamang sa kinopyang profile, itanong kung aling ruta o aling filter ang gumagawa ng trabaho.

I-verify ang pares sa isang pasada

Subukan nang hiwalay ang lifecycle at ang routing, sa ganoong pagkakasunod-sunod. Isara ang app, kumpirmahing Disconnected ang ulat ng profile, pagkatapos ay simulan ang app at tingnan kung nagbago ang estado. Pagkatapos lang umangat ang tunnel dapat mong itanong kung saan pupunta ang isang partikular na destinasyon, at dapat mong gamitin ang address na aktuwal na tinatawag ng app sa halip na hula.

$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.10

Find-NetRoute pinapangalanan ang interface at ang susunod na hop na magdadala sa destinasyong iyon. Ang pisikal na alias doon ay nangangahulugang nakataas ang tunnel at walang kaugnayan sa daloy na iyon: tingnan ang mga itinulak na prefix, pagkatapos ang mas espesipikong ruta, pagkatapos ang IPv6. Kung hindi talaga nagbabago ang estado, hindi pumutok ang trigger, at ang path ng executable, ang saklaw ng profile at ang operational log ng VPN client ang tatlong lugar na titingnan.

Linisin nang maayos upang maging matapat ang susunod na test

Alisin sa kabaligtaran ng ayos ng pagbuo: una ang trigger ng application, pagkatapos ang profile. Ang pagbura ng profile habang naiwan ang trigger ay nag-iiwan ng nakabitin na asosasyon na nagpapagulo sa susunod na pagsubok, at Remove-VpnConnection -Force hindi laging nililinis ang entry sa phonebook na ginawa sa labas ng mga cmdlet.

Ang mga entry per user ay nasa rasphone.pbk ng user sa ilalim ng Roaming profile; ang mga entry para sa lahat ng user ay nasa ilalim ng ProgramData. Suriin ang tindahan na tumutugma sa saklaw ng profile, muling ikonekta ang profile na itinago mo, at kumpirmahing gumagana pa rin ang mga ruta at DNS nito, upang ang susunod na test ay sukatin ang pagbabagong ginawa mo at hindi ang natirang estado.

• Nagsisimula ang tunnel sa pag-start ng proseso, hindi sa pag-log in.
• Tanging ang mga sinadyang prefix ang lumilitaw sa interface ng VPN.
• Ang tunay na remote address ng app ay nare-resolve sa VPN alias.
• Walang nakabiting trigger na natitira pagkatapos alisin ang profile.