Windowsos alkalmazásonkénti VPN-eseményindító kontra osztott alagút: mi izolál

Két Windows-beállítás ugyanúgy néz ki a Beállításokban, és semmiben sem viselkedik hasonlóan. Az egyik egy másolt VPN-profil alkalmazás-eseményindítóval, így egyetlen végrehajtható fájl indítása felhozza az alagutat. A másik egy osztott alagútas profil, amelynek útvonallistája épp lefedi azt, amivel az az alkalmazás beszél. Az első arra válaszol, mikor létezik az alagút. A második arra, mely csomagok lépnek be, és csak a második hagyja a gép többi részét a fizikai kapcsolaton, miközben az alkalmazás kapcsolva marad.

Az eseményindító életciklus-szabály, nem útvonalazási szabály

Add-VpnConnectionTriggerApplication egy végrehajtható útvonalat köt egy profilnévhez. Amikor ez a folyamat elindul, a Távoli hozzáférési kapcsolatkezelő tárcsázza a profilt, és amikor az eseményindító feltétele megszűnik, a kapcsolat megszakadhat. Ebben a cserében semmi sem vizsgálja a socketeket. A parancsmaghoz emelt szintű shell, a bináris fájl teljes útvonala és -Force amikor egy meglévő bejegyzést cserél. Erősítse meg, hogy a társítás megmaradt ezzel: Get-VpnConnectionTrigger ahelyett, hogy bízna a parancssorban; a Microsoft Add-VpnConnectionTriggerApplication-referenciája felsorolja a paramétereket és a példákat.

Két korlát magyarázza a „az eseményindító semmit sem tesz” jelentések többségét. Az eseményindítók minden felhasználóra vonatkozó profilok köré épülnek, ezért a profil hatóköre az első tisztázandó dolog, és az alkalmazás útvonalának azzal a bináris fájllal kell egyeznie, amely valóban fut, nem egy parancsikonnal vagy egy indítóval, amely második folyamatot indít. A másik korlát szándékos: olyan hálózaton, amelyet a Windows megbízhatónak minősít, az eseményindító tétlen marad, mert a profil az irodán kívüli használatra készült.

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

Az osztott alagút dönti el, mi halad át az alagúton

Osztott alagút kikapcsolva a Windows egy osztályalapú alapértelmezett útvonalat telepít alacsony metrikával a VPN-felületen. Minden socket ezt követi, a böngésző és a frissítési szolgáltatás is, így az eseményindító ebben a konfigurációban az egész gépet mozgatja, amíg a profil kapcsolva van. Az eseményindító továbbra is csak életciklus-szabály; a hatás sugarát az útvonal adta.

Osztott alagút bekapcsolva a profil csak azokat a prefixeket hordozza, amelyeket az átjáró tol vagy amelyeket a VPN-felülethez ad. Minden más továbbra is a fizikai alapértelmezett útvonalat használja. Ez az az elrendezés, amelyre az emberek általában „egy alkalmazás külön kijáraton” gondolnak, és ez végig útvonalazási döntés.

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

Ahol az útvonalazott osztás abbahagyja az alkalmazás izolálását

A gyakori hiba egy cél, amely soha nem jelenik meg az alagút útvonallistáján. Egy alkalmazás, amely egy címre bejelentkezik, majd CDN-ről streamel, vagy egy tucat forgó végpontot old fel, néhány kapcsolatot a VPN-felületre tesz, a többit Wi-Fi-re. Az IPv6 külön tábla, így egy csak IPv4-prefixeket toló profil helyesnek tűnhet, miközben az alkalmazás IPv6-forgalma helyi marad.

Két kisebb hatás ugyanannyit számít. A leghosszabb prefix egyezése nyer, így egy konkrétabb on-link útvonal, egy felügyeleti hoszthoz tolt /32 vagy egy második adapter alhálózata megverheti az alagutat épp azon a címen, amely érdekli. A névfeloldás szintén az útvonalazás előtt történik: hacsak a profil DNS-kiszolgálói vagy egy NRPT-szabály nem fedi le a nevet, az alkalmazás a fizikai adapteren át oldhat fel, majd olyan címet tárcsázhat, amely soha nem volt az alagútba vont prefixeken belül.

Három forma, és mit ad mindegyik

A táblázat az a rész, amelyet a falra ragasztanék, mert a döntés a hatás sugárról szól, nem a funkciókról. Ha az alkalmazás céljai felsorolható stabil prefixek, az útvonalazott osztás a legkisebb lábnyommal ad izolációt. Ha nem, az alapértelmezett útvonalas profil egy VM vagy egy második eszköz mögött tisztességesen tartja a szétválasztást azon az áron, hogy egynél több folyamatot mozgat.

Amit egyik sem nyújt, az a socket szintű kötés a gazdagépen. A klasszikus Windows VPN-kliensnek nincs szabálya arra, hogy ennek a folyamatnak ezt az adaptert kell használnia; az eseményindítók és az útvonalszűrők külön rétegekben élnek, és a felületet kiválasztó réteg az útvonaltábla. Ha egy útmutató alkalmazásonkénti kikényszerítést ígér pusztán egy másolt profilból, kérdezze meg, melyik útvonal vagy melyik szűrő végzi a munkát.

Egy menetben ellenőrizze a párost

Az életciklust és az útvonalazást külön tesztelje, ebben a sorrendben. Zárja be az alkalmazást, erősítse meg, hogy a profil Disconnected állapotot jelez, majd indítsa el az alkalmazást, és ellenőrizze, hogy az állapot megváltozott. Csak azután kérdezze meg, hova megy egy adott cél, hogy az alagút fel van hozva, és az alkalmazás által ténylegesen tárcsázott címet használja, ne egy találgatást.

$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 megnevezi a felületet és a következő ugrást, amely azt a célt vinné. A fizikai alias ott azt jelenti, hogy az alagút fel van hozva, és erre a folyamra nézve irreleváns: ellenőrizze a tolt prefixeket, majd a konkrétabb útvonalakat, majd az IPv6-ot. Ha az állapot egyáltalán nem változik, az eseményindító nem lépett működésbe, és a végrehajtható fájl útvonala, a profil hatóköre és a VPN-kliens működési naplója az a három hely, ahol keresni kell.

Takarítson tisztán, hogy a következő teszt őszinte legyen

A fordított sorrendben távolítsa el, ahogy építette: először az alkalmazás-eseményindítót, majd a profilt. A profil törlése, miközben az eseményindító megmarad, lógó társítást hagy, amely zavaróvá teszi a következő kísérletet, és Remove-VpnConnection -Force nem mindig töröl egy olyan telefonkönyv-bejegyzést, amely a parancsmagokon kívül jött létre.

A felhasználónkénti bejegyzések a felhasználó rasphone.pbk fájljában élnek a Roaming profil alatt; a minden felhasználóra vonatkozó bejegyzések a ProgramData alatt élnek. Ellenőrizze a profil hatóköréhez illő tárolót, csatlakoztassa újra a megtartott profilt, és erősítse meg, hogy az útvonalai és a DNS továbbra is működnek, hogy egy későbbi teszt a végrehajtott változást mérje, ne a maradék állapotot.

• Az alagút folyamatindításkor indul, nem bejelentkezéskor.
• Csak a szánt prefixek jelennek meg a VPN-felületen.
• Az alkalmazás valódi távoli címe a VPN-aliasra oldódik fel.
• A profil eltávolítása után nem marad lógó eseményindító.