Windows VPN тригер по приложение срещу разделено тунелиране: какво изолира

Две Windows конфигурации изглеждат еднакво в Настройки и се държат напълно различно. Едната е копиран VPN профил с тригер за приложение, така че стартирането на един изпълним файл вдига тунела. Другата е профил с разделено тунелиране, чийто списък с маршрути случайно покрива това, с което говори приложението. Първата отговаря кога тунелът съществува. Втората отговаря кои пакети влизат в него, и само втората оставя останалата част от машината на физическата връзка, докато приложението остава свързано.

Тригерът е правило за жизнения цикъл, а не правило за маршрутизация

Add-VpnConnectionTriggerApplication свързва път до изпълним файл с име на профил. Когато този процес стартира, Диспечерът на връзките за отдалечен достъп набира профила, и когато условието на тригера приключи, връзката може да падне. Нищо в този обмен не проверява сокети. Командата изисква повишена обвивка, пълния път до двоичния файл и -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 не покриват името, приложението може да го разреши през физическия адаптер и после да набере адрес, който никога не е бил вътре в тунелираните префикси.

Три форми и какво дава всяка

Таблицата е частта, която бих залепил на стената, защото решението е за радиуса на поражение, а не за функции. Ако дестинациите на приложението са стабилни префикси, които можете да изброите, маршрутизираното разделяне дава изолация с най-малка следа. Ако не са, профил с маршрут по подразбиране зад виртуална машина или второ устройство пази разделението честно на цената на местене на повече от един процес.

Това, което нито един от тези варианти не дава, е обвързване на ниво сокет на хоста. Класическият 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.10

Find-NetRoute назовава интерфейса и следващия преход, който би понесъл тази дестинация. Физически псевдоним там означава, че тунелът е вдигнат и за този поток е без значение: проверете избутаните префикси, после по-конкретните маршрути, после IPv6. Ако състоянието изобщо не се променя, тригерът не е задействал, и пътят до изпълнимия файл, обхватът на профила и оперативният журнал на VPN клиента са трите места за проверка.

Изчистете грижливо, за да е честен следващият тест

Премахвайте в обратния ред на изграждането: първо тригера на приложението, после профила. Изтриването на профила, докато тригерът остава, оставя висяща връзка, която обърква следващия опит, и Remove-VpnConnection -Force не винаги изчиства запис в телефонния указател, създаден извън командите.

Записите за отделни потребители са в rasphone.pbk на потребителя под профила Roaming; записите за всички потребители са под ProgramData. Проверете хранилището, съответстващо на обхвата на профила, свържете отново запазения профил и потвърдете, че маршрутите и DNS му още се държат, така че по-късен тест да измерва направената промяна, а не останалото състояние.

• Тунелът се вдига при стартиране на процеса, а не при вход.
• На интерфейса VPN се появяват само предвидените префикси.
• Истинският отдалечен адрес на приложението се разрешава до псевдонима на VPN.
• След премахване на профила не остава висящ тригер.