Trigger VPN per app di Windows contro split tunneling: cosa isola

Due configurazioni di Windows si somigliano in Impostazioni e non si comportano affatto allo stesso modo. Una è un profilo VPN copiato con un trigger di applicazione, così avviare un eseguibile alza il tunnel. L’altra è un profilo con split tunneling la cui lista di route copre per caso ciò con cui parla quell’applicazione. Il primo risponde a quando il tunnel esiste. Il secondo risponde a quali pacchetti vi entrano, e solo il secondo lascia il resto della macchina sul collegamento fisico mentre l’app resta connessa.

Il trigger è una regola del ciclo di vita, non una regola di routing

Add-VpnConnectionTriggerApplication associa un percorso eseguibile a un nome di profilo. Quando quel processo parte, Connection Manager di Accesso remoto compone il profilo, e quando la condizione del trigger termina, la connessione può cadere. Nulla in quello scambio ispeziona i socket. Il cmdlet richiede una shell elevata, il percorso completo del binario e -Force quando sostituisci una voce esistente. Conferma che l’associazione è sopravvissuta con Get-VpnConnectionTrigger invece di fidarti del prompt; la referenza di Add-VpnConnectionTriggerApplication elenca i parametri e gli esempi.

Due limiti spiegano la maggior parte delle segnalazioni «il trigger non fa nulla». I trigger sono costruiti attorno a profili per tutti gli utenti, quindi l’ambito del profilo è la prima cosa da chiarire, e il percorso dell’applicazione deve corrispondere al binario che gira davvero, non a un collegamento o a un launcher che genera un secondo processo. L’altro limite è voluto: su una rete che Windows classifica come attendibile, il trigger resta inattivo, perché il profilo è pensato per funzionare fuori dall’ufficio.

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

Lo split tunneling decide cosa attraversa il tunnel

Con lo split tunneling disattivato, Windows installa una route predefinita basata sulla classe con metrica bassa sull’interfaccia VPN. Ogni socket la segue, incluso il browser e il servizio di aggiornamento, quindi un trigger in quella configurazione sposta l’intera macchina finché il profilo è connesso. Il trigger resta solo una regola del ciclo di vita; il raggio d’impatto veniva dalla route.

Con lo split tunneling attivo, il profilo porta solo i prefissi che il gateway spinge o che aggiungi all’interfaccia VPN. Tutto il resto continua a usare la route predefinita fisica. È la disposizione che la gente intende di solito con «un’app attraverso un’uscita separata», ed è una decisione di routing da capo a fondo.

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

Dove uno split instradato smette di isolare la tua app

Il guasto comune è una destinazione che non compare mai nella lista di route del tunnel. Un’app che accede a un indirizzo e poi fa streaming da una CDN, o che risolve una dozzina di endpoint rotanti, mette alcune connessioni sull’interfaccia VPN e le altre sul Wi-Fi. IPv6 è una tabella separata, quindi un profilo che spinge solo prefissi IPv4 può sembrare corretto mentre il traffico IPv6 dell’app resta locale.

Due effetti più piccoli contano altrettanto. Vince la corrispondenza del prefisso più lungo, quindi una route on-link più specifica, un /32 spinto per un host di gestione o la sottorete di un secondo adattatore possono battere il tunnel proprio per l’indirizzo che ti interessa. Anche la risoluzione avviene prima del routing: a meno che i server DNS del profilo o una regola NRPT coprano il nome, l’app può risolvere tramite l’adattatore fisico e poi comporre un indirizzo che non è mai stato dentro i prefissi incapsulati.

Tre forme, e cosa compra ciascuna

La tabella è la parte che attaccherei al muro, perché la decisione riguarda il raggio d’impatto e non le funzioni. Se le destinazioni dell’app sono prefissi stabili che puoi elencare, lo split instradato dà isolamento con l’impronta più piccola. Se non lo sono, un profilo con route predefinita dietro una VM o un secondo dispositivo mantiene la separazione onesta al costo di spostare più di un processo.

Ciò che nessuna di queste opzioni offre è il binding a livello di socket sull’host. Il client VPN classico di Windows non ha una regola che dica che questo processo deve usare quell’adattatore; trigger e filtri di route vivono in livelli diversi, e il livello che sceglie un’interfaccia è la tabella di routing. Se una guida promette l’applicazione per app solo da un profilo copiato, chiedi quale route o quale filtro fa il lavoro.

Verifica la coppia in un solo passaggio

Testa il ciclo di vita e il routing separatamente, in quest’ordine. Chiudi l’app, conferma che il profilo riporti Disconnected, poi avvia l’app e controlla che lo stato sia cambiato. Solo dopo che il tunnel è su dovresti chiedere dove va una destinazione specifica, e dovresti usare l’indirizzo che l’app compone davvero invece di una supposizione.

$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 nomina l’interfaccia e il prossimo hop che porterebbero quella destinazione. Un alias fisico lì significa che il tunnel è su e irrilevante per quel flusso: controlla i prefissi spinti, poi le route più specifiche, poi IPv6. Se lo stato non cambia affatto, il trigger non è scattato, e il percorso dell’eseguibile, l’ambito del profilo e il log operativo del client VPN sono i tre posti da guardare.

Disfa con ordine perché il prossimo test sia onesto

Rimuovi nell’ordine inverso a quello in cui hai costruito: prima il trigger dell’applicazione, poi il profilo. Eliminare il profilo mentre il trigger resta lascia un’associazione pendente che rende confuso il tentativo successivo, e Remove-VpnConnection -Force non sempre cancella una voce della rubrica telefonica creata fuori dai cmdlet.

Le voci per utente vivono nel rasphone.pbk dell’utente sotto il profilo Roaming; le voci per tutti gli utenti vivono sotto ProgramData. Controlla l’archivio che corrisponde all’ambito del profilo, riconnetti il profilo che hai tenuto e conferma che le sue route e il DNS si comportino ancora, così un test successivo misura la modifica fatta e non lo stato residuo.

• Il tunnel parte all’avvio del processo, non al login.
• Solo i prefissi previsti compaiono sull’interfaccia VPN.
• L’indirizzo remoto reale dell’app si risolve nell’alias VPN.
• Nessun trigger pendente resta dopo la rimozione del profilo.