Come verificare cosa instrada davvero una VPN su Windows in PowerShell

Ho collegato il client VPN su un portatile con Windows 11, il riquadro è passato a Connesso, una condivisione file interna si è aperta e un sito pubblico si caricava ancora direttamente dal Wi-Fi dell'ufficio. Questo misto sembra un tunnel rotto. È l'output normale di un profilo che invia parte del traffico tramite la VPN e lascia il resto sull'adattatore fisico. Il tunneling forzato cambia quale rotta predefinita preferisce Windows; non elimina le rotte più specifiche e non promette che il traffico si fermi quando la connessione cade. Quello che segue è l'ordine che seguo quando un client dichiara copertura: stato del client, profilo salvato, rotte applicate, resolver, poi flussi reali.

Parti dal client, poi smetti di fidarti di lui

Il client è il posto giusto da cui partire solo perché ti dice quale profilo è attivo. Apri le proprietà della connessione e annota il nome esatto del profilo, se è stato creato per l'utente corrente o per tutti sulla macchina, e quale adattatore compare in ncpa.cpl dopo la connessione. Sul mio portatile di test l'adattatore portava il nome del profilo, il che rendeva facile leggere l'output delle rotte. Su altre macchine compare come voce WAN Miniport e il nome non ti dice nulla.

Quello che il client non può dirti è la copertura. Un riquadro connesso descrive lo stato del tunnel, non un inventario delle destinazioni. Anche i client di terze parti tengono la propria configurazione, quindi il profilo nativo di Windows, e ogni proprietà che leggerai da esso, potrebbe non avere nulla a che fare con ciò che quel client ha installato. Se la VPN è arrivata tramite AnyConnect, OpenVPN GUI, WireGuard o un agente del fornitore, i controlli PowerShell qui sotto in genere non si applicano e dovresti invece leggere le impostazioni di split-tunnel e di routing di quel client.

Leggi il profilo salvato, non il riquadro

Per un profilo nativo di Windows (IKEv2, L2TP, SSTP o uno spinto da MDM), la decisione salvata di split-tunnel è una sola proprietà:

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

Aggiungi -AllUserConnection quando il profilo è stato creato per tutti sul dispositivo. Senza di esso leggi l'elenco dell'utente corrente, che può essere vuoto o contenere un'altra voce con un nome simile. Un valore False in SplitTunneling significa che il profilo è stato salvato come tunnel completo: Windows installa una rotta predefinita attraverso l'adattatore VPN. True significa split tunnel, e la copertura dipende allora interamente dalle rotte e dalle regole di risoluzione dei nomi che quel profilo spinge.

Tratta quel valore come configurazione, non come osservazione. Registra ciò che il profilo ha chiesto al momento della connessione. Windows può ritrovarsi con rotte applicate diverse, per una rotta più specifica di un'altra interfaccia, un'impostazione di criterio o una voce residua di una connessione precedente, quindi il booleano non risolve mai la questione da solo.

Confronta il valore salvato con la tabella di routing applicata

Dopo la connessione, elenca le rotte sull'adattatore del tunnel invece di scorrere l'intera tabella:

$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1

Find-NetRoute è la metà utile. Risponde alla domanda che il client non risponde mai: per questa destinazione, quale interfaccia e quale indirizzo sorgente userà davvero Windows? Eseguilo per un host interno, un host pubblico e qualsiasi cosa tu ritenga un'eccezione deliberata. Un profilo a tunnel completo dovrebbe mostrare l'interfaccia del tunnel per l'indirizzo pubblico. Un profilo split tunnel di solito mostra lì l'adattatore fisico mentre i prefissi interni si risolvono ancora tramite la VPN.

Due trappole spiegano la maggior parte delle segnalazioni «instrada dalla parte sbagliata». Il prefisso più specifico vince sempre, quindi un /24 sull'adattatore fisico batte una rotta predefinita sulla VPN per quanto bassa sia la metrica del tunnel. La metrica decide solo i pareggi tra rotte dello stesso prefisso. E IPv4 e IPv6 vengono decisi separatamente: un profilo che copre 0.0.0.0/0 può lasciare IPv6 sul collegamento locale, il che fa sembrare un sito dual-stack mezzo in tunnel. Controlla Get-NetRoute -AddressFamily IPv6 prima di concludere che il tunnel va bene.

Controlla la risoluzione dei nomi separatamente con NRPT

I nomi interni che falliscono mentre gli indirizzi IP interni funzionano indicano la politica del resolver, non il routing. Windows decide il DNS per spazio dei nomi tramite la tabella dei criteri di risoluzione dei nomi, indipendente dalla tabella di routing:

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

Quando una regola corrisponde a *.corp.example, le query per quello spazio dei nomi vanno ai server DNS del tunnel anche se il percorso dati verso quei server resta sull'adattatore fisico in modalità split tunnel. È il progetto, ed è per questo che un test del browser che apre un sito pubblico non ti dice nulla sui nomi interni. Se l'adattatore elenca i server attesi ma le ricerche vanno ancora altrove, confronta l'ordine delle regole NRPT e verifica se uno spazio dei nomi più specifico corrisponde per primo.

Verifica i flussi, poi decidi cosa hai chiesto davvero

Percorri le destinazioni in un ordine fisso così i risultati sono confrontabili tra macchine: un indirizzo pubblico, un indirizzo interno, un nome interno e un'eccezione deliberata come una stampante locale o una videochiamata. Annota l'interfaccia e l'indirizzo sorgente che Find-NetRoute restituisce per ciascuna. Dopo qualsiasi modifica dei criteri, riconnettiti e ripeti gli stessi quattro controlli; la tabella di routing dopo la riconnessione è l'unica prova che il nuovo profilo ha avuto effetto.

Poi separa il routing dall'applicazione forzata. Il tunneling forzato preferisce il tunnel per il traffico coperto finché è attivo. Non è un kill switch. Se il requisito è che nulla esca dalla macchina quando il tunnel cade, deve venire da un progetto bloccante: un profilo firewall legato allo stato del tunnel, un profilo sempre attivo con filtri di traffico o l'opzione propria di chiusura in caso di errore del client del fornitore. Il tunneling forzato deve anche lasciare raggiungibile l'indirizzo del server VPN stesso fuori dal tunnel, e bloccarlo in nome di «forzare tutto» è un modo affidabile per chiudersi fuori dalla connessione che stai cercando di applicare.

Prima di cambiare qualsiasi cosa, ripercorri questo elenco. Ogni voce che fallisce restringe dove sta il problema reale.

• Nome e ambito del profilo confermati, con -AllUserConnection per i profili a livello di macchina.
• SplitTunneling letto e trattato come configurazione, non come prova di copertura.
• Rotte dell'adattatore del tunnel elencate separatamente per IPv4 e IPv6.
• Find-NetRoute eseguito per una destinazione pubblica, una interna e una di eccezione.
• Regole NRPT controllate prima di dare la colpa alle rotte per un fallimento di nome.
• Requisito di blocco riletto: il routing preferito non è la stessa cosa del blocco applicato.

La decisione di tunnel completo o diviso appartiene a chi possiede il profilo, e le note di routing di Microsoft descrivono il comportamento che Windows implementa quando un profilo lo imposta. Microsoft: tunneling forzato e diviso è il riferimento che tengo aperto mentre leggo l'output.