Declanșator VPN pe aplicație în Windows vs tunel divizat: ce izolează

Două configurări Windows arată la fel în Setări și nu se comportă deloc la fel. Una este un profil VPN copiat cu un declanșator de aplicație, astfel încât pornirea unui executabil ridică tunelul. Cealaltă este un profil cu tunel divizat a cărui listă de rute acoperă din întâmplare ceea cu ce vorbește acea aplicație. Prima răspunde când tunelul există. A doua răspunde ce pachete intră în el, și doar a doua lasă restul mașinii pe legătura fizică în timp ce aplicația rămâne conectată.

Declanșatorul este o regulă de ciclu de viață, nu o regulă de rutare

Add-VpnConnectionTriggerApplication leagă o cale executabilă de un nume de profil. Când acel proces pornește, Managerul de conexiuni de acces la distanță apelează profilul, și când condiția declanșatorului se termină, conexiunea poate cădea. Nimic din acel schimb nu inspectează socketuri. Cmdletul are nevoie de un shell ridicat, de calea completă către binar și de -Force când înlocuiești o intrare existentă. Confirmă că asocierea a supraviețuit cu Get-VpnConnectionTrigger în loc să te bazezi pe prompt; referința Add-VpnConnectionTriggerApplication enumeră parametrii și exemplele.

Două limite explică majoritatea rapoartelor că „declanșatorul nu face nimic”. Declanșatoarele sunt construite în jurul profilelor pentru toți utilizatorii, deci domeniul profilului este primul lucru de lămurit, iar calea aplicației trebuie să corespundă binarului care rulează efectiv, nu unei scurtături sau unui lansator care creează un al doilea proces. Cealaltă limită este intenționată: într-o rețea pe care Windows o clasifică drept de încredere, declanșatorul rămâne inactiv, pentru că profilul este gândit să funcționeze în afara biroului.

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

Tunelul divizat decide ce traversează tunelul

Cu tunelul divizat oprit, Windows instalează o rută implicită bazată pe clasă, cu o metrică mică, pe interfața VPN. Fiecare socket o urmează, inclusiv browserul și serviciul de actualizări, așa că un declanșator în acea configurație mută toată mașina atât timp cât profilul este conectat. Declanșatorul rămâne doar o regulă de ciclu de viață; raza de impact a venit de la rută.

Cu tunelul divizat pornit, profilul poartă doar prefixele pe care le împinge gateway-ul sau pe care le adaugi la interfața VPN. Tot restul continuă să folosească ruta implicită fizică. Aceasta este aranjamentul pe care oamenii îl înțeleg de obicei prin „o aplicație printr-o ieșire separată”, și este o decizie de rutare de la un capăt la altul.

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

Unde o divizare rutată nu mai izolează aplicația

Eșecul obișnuit este o destinație care nu apare niciodată în lista de rute a tunelului. O aplicație care se autentifică la o adresă și apoi transmite în flux de la un CDN, sau care rezolvă o duzină de puncte finale rotative, va pune unele conexiuni pe interfața VPN și restul pe Wi-Fi. IPv6 este un tabel separat, așa că un profil care împinge doar prefixe IPv4 poate părea corect în timp ce traficul IPv6 al aplicației rămâne local.

Două efecte mai mici contează la fel de mult. Câștigă potrivirea celui mai lung prefix, așa că o rută on-link mai specifică, un /32 împins pentru un host de administrare sau subrețeaua unui al doilea adaptor pot bate tunelul exact pentru adresa care te interesează. Rezolvarea are loc și înainte de rutare: dacă serverele DNS ale profilului sau o regulă NRPT nu acoperă numele, aplicația poate rezolva prin adaptorul fizic și apoi poate forma o adresă care nu a fost niciodată în prefixele tunelate.

Trei forme și ce oferă fiecare

Tabelul este partea pe care aș lipi-o pe perete, pentru că decizia ține de raza de impact, nu de funcții. Dacă destinațiile aplicației sunt prefixe stabile pe care le poți lista, divizarea rutată oferă izolare cu cea mai mică amprentă. Dacă nu sunt, un profil cu rută implicită în spatele unei VM sau al unui al doilea dispozitiv păstrează separarea onestă cu prețul mutării mai mult de un proces.

Ce nu oferă niciuna dintre acestea este legarea la nivel de socket pe gazdă. Clientul VPN clasic din Windows nu are nicio regulă care să spună că acest proces trebuie să folosească acel adaptor; declanșatoarele și filtrele de rute trăiesc în straturi diferite, iar stratul care alege o interfață este tabelul de rutare. Dacă un ghid promite aplicare pe aplicație doar dintr-un profil copiat, întreabă ce rută sau ce filtru face treaba.

Verifică perechea într-o singură trecere

Testează ciclul de viață și rutarea separat, în această ordine. Închide aplicația, confirmă că profilul raportează Disconnected, apoi pornește aplicația și verifică dacă starea s-a schimbat. Abia după ce tunelul este ridicat ar trebui să întrebi unde merge o destinație anume, și ar trebui să folosești adresa pe care aplicația o apelează efectiv, nu o presupunere.

$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 numește interfața și următorul salt care ar purta acea destinație. Un alias fizic acolo înseamnă că tunelul este ridicat și irelevant pentru acel flux: verifică prefixele împinse, apoi rutele mai specifice, apoi IPv6. Dacă starea nu se schimbă deloc, declanșatorul nu a pornit, iar calea executabilului, domeniul profilului și jurnalul operațional al clientului VPN sunt cele trei locuri de privit.

Curăță ordonat ca următorul test să fie onest

Elimină în ordinea inversă celei în care ai construit: mai întâi declanșatorul aplicației, apoi profilul. Ștergerea profilului în timp ce declanșatorul rămâne lasă o asociere atârnată care face următoarea încercare confuză, și Remove-VpnConnection -Force nu șterge întotdeauna o intrare de cartea de telefon creată în afara cmdleturilor.

Intrările pe utilizator stau în rasphone.pbk al utilizatorului, sub profilul Roaming; intrările pentru toți utilizatorii stau sub ProgramData. Verifică depozitul care corespunde domeniului profilului, reconectează profilul pe care l-ai păstrat și confirmă că rutele și DNS-ul lui se comportă în continuare, pentru ca un test ulterior să măsoare schimbarea făcută și nu starea rămasă.

• Tunelul pornește la pornirea procesului, nu la autentificare.
• Doar prefixele prevăzute apar pe interfața VPN.
• Adresa la distanță reală a aplicației se rezolvă la aliasul VPN.
• Nu rămâne niciun declanșator atârnat după eliminarea profilului.