La VPN di Windows prende tutto il traffico? Rimuovete la route predefinita

Vi collegate alla VPN dell'ufficio e ogni pagina del browser comincia a passare attraverso quella rete: il file server è veloce, tutto il resto è lento, filtrato o sparito. Il client non si comporta male; il profilo ha chiesto un tunnel completo. L'interruttore che lo ferma è una casella in una finestra di dialogo che l'app Impostazioni moderna non mostra, e il gateway ha di nuovo voce a ogni connessione. Questa guida segue l'ordine che l'interfaccia di Windows presenta davvero, poi copre i controlli che falliscono ancora quando la tabella delle route sembra corretta.

Iniziate dalle proprietà della scheda, non da Impostazioni

L'app Impostazioni elenca il profilo in Rete e Internet e poi in VPN, ma espone solo opzioni generali. La decisione sul gateway predefinito vive sulla scheda. Aprite l'elenco classico delle schede con Win+R e ncpa.cpl, fate clic con il pulsante destro sulla connessione VPN, scegliete Proprietà, selezionate Protocollo Internet versione 4, scegliete di nuovo Proprietà e poi Avanzate. Deselezionate Usa gateway predefinito sulla rete remota e confermate l'uscita dalle tre finestre.

Riconnettetevi prima di provare, perché la casella si applica quando il tunnel viene stabilito e una sessione esistente conserva la tabella che ha costruito. Se la scheda manca mentre il client è disconnesso, collegatevi una volta e riaprite la finestra. Un client di fornitore che installa una scheda TAP o Wintun senza pagina delle proprietà IPv4 non ha affatto questa finestra; per quelli la stessa decisione è un'opzione di split tunneling nelle impostazioni del client, e la casella della scheda è il posto sbagliato dove cercare.

La stessa modifica da PowerShell

Per un profilo creato nell'archivio VPN di Windows, l'impostazione è gestibile via script, che è ciò che volete se la macchina viene ricostruita spesso:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

Quel cmdlet raggiunge solo i profili di quell'archivio. Una connessione aggiunta da un client di terze parti non apparirà, e il comando fallisce con un errore di nome che sembra un refuso. Notate anche cosa non fa l'interruttore: impedisce al client di installare una route predefinita, ma non rimuove le route che il gateway invia al momento della connessione, quindi la sezione successiva serve ancora su molte reti.

Quando il gateway rimanda la route predefinita

Leggete prima la tabella. Due voci predefinite con metriche diverse significano che la modifica del profilo ha funzionato e che la route inviata l'ha comunque sostituita:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Eliminate la route predefinita che appartiene al tunnel e conservate quella fisica. Usate l'indice dell'interfaccia del terzo comando, non l'alias della scheda, perché gli script che passano un alias si rompono appena cambia il nome visualizzato:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

L'eliminazione porta via con sé l'ufficio, quindi riaggiungete i prefissi aziendali attraverso il gateway del tunnel. È la riga che le persone saltano, ed è il motivo per cui «la VPN ha smesso di funzionare» segue una modifica di split tunneling riuscita:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Nulla di tutto questo sopravvive a una riconnessione, il che è un comportamento onesto e non un bug: la scheda viene ricostruita e il client riapplica ciò su cui il profilo e il gateway si sono accordati. Se la predefinita riappare ogni volta, il gateway è configurato per rifiutare lo split tunneling e continuerà a inviarla, oppure interromperà la sessione. È la politica dell'operatore di rete, e la richiesta appartiene a loro e non a uno script locale che la combatte una volta per connessione.

Ricontrollate DNS, IPv6 e le metriche dopo una riconnessione

Rimuovere una route predefinita IPv4 non dimostra nulla sull'altra famiglia né sulla risoluzione dei nomi. Un tunnel può trasportare IPv6 mentre la predefinita IPv4 resta locale, e un elenco di resolver inviato può mantenere i nomi interni funzionanti mentre le query che lo usano passano per un'altra strada. Controllate tutte e tre prima di considerarlo fatto:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

Se lo stato torna a ogni connessione, spostate i comandi in un'azione per connessione invece di modificare la tabella a mano: un'attività pianificata avviata dall'evento di connessione, o l'impostazione di split tunneling del client quando esiste. Tenete l'indice dell'interfaccia in una variabile e cercatelo in fase di esecuzione, perché può cambiare quando si aggiungono o rimuovono schede.

Decidete a cosa avete rinunciato

Il traffico Internet locale non è più ispezionato né filtrato dall'ufficio, e tutto ciò che viene pubblicato solo attraverso il tunnel ora ha bisogno della propria route. Alcune organizzazioni considerano lo split tunneling una violazione della policy, quindi confermatelo prima di modificare un dispositivo gestito; una predefinita inviata è talvolta il meccanismo di applicazione e non un incidente. La documentazione di Set-VpnConnection elenca il parametro di split tunneling e i tipi di profilo a cui si applica.

Poi verificate in un ordine fisso: chi possiede la route predefinita, la navigazione ordinaria, un host aziendale per indirizzo, un nome interno e gli stessi quattro dopo una sola riconnessione. Se la navigazione funziona e l'host aziendale fallisce, manca la route di prefisso e non la predefinita che avete rimosso, ed è molto più economico sistemarla che ricostruire il profilo.