Il tunnel segnala di essere connesso e la wiki si carica ancora. Poi un download si blocca e la condivisione sullo scaffale smette di rispondere. Il tunnel ha fatto il suo lavoro, e il profilo rivendicava semplicemente ogni destinazione.

Windows tratta una connessione VPN come una decisione di routing. Finché quella decisione non viene ristretta, la macchina si comporta come se si fosse trasferita in ufficio.

Perché un tunnel che funziona sembra un'interruzione

Un profilo autorizzato a usare il gateway remoto installa una rotta predefinita attraverso il tunnel. Ogni destinazione che non è sul collegamento locale esce allora dal firewall dell'ufficio. Le condivisioni locali smettono di rispondere perché il loro traffico ora viaggia verso un altro continente e torna. Niente nello stato del client lo riflette.

I sintomi sono fuorvianti di proposito. La risoluzione dei nomi può ancora funzionare mentre la condivisione va in timeout, o il contrario. L'utente segnala che la VPN è rotta, il client segnala di stare bene, ed entrambe le affermazioni sono esatte.

La casella nascosta nella finestra IPv4

L'impostazione sta diversi dialoghi più in profondità. Aprite ncpa.cpl, fate clic con il tasto destro sulla connessione, poi su proprietà IPv4, poi su Avanzate, e deselezionate l'opzione che permette alla connessione di diventare il gateway predefinito remoto. Quella sola casella decide se il profilo è un tunnel completo. Tutto il resto del profilo vale ancora.

Confrontate route print -4 prima e dopo la riconnessione. La voce 0.0.0.0 che prima puntava al tunnel dovrebbe essere sparita, e i prefissi aziendali dovrebbero essere ancora lì.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Cambiare la metrica dell'interfaccia non è un sostituto. Una metrica decide solo tra due rotte predefinite in competizione, e un client che reinstalla la propria rotta predefinita a ogni connessione vince quella gara qualunque sia il numero impostato.

Il prefisso che nessuno ha elencato

Il tunnel diviso espone esattamente i prefissi registrati nel profilo. Una sottorete d'ufficio aggiunta dopo la stesura del profilo resta irraggiungibile mentre il tunnel è perfettamente sano. Il rapporto arriva allora come un server rotto invece che come una VPN rotta.

Una rotta aggiunta a mano copre il vuoto finché l'indirizzo del gateway cambia. Registrare il prefisso nella connessione è più solido, perché il prefisso segue poi la connessione invece di un indirizzo indovinato.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Leggete l'elenco memorizzato e la tabella attiva insieme. Un prefisso memorizzato può esistere mentre la tabella non lo riceve mai, cosa che accade quando un agente di gestione filtra le rotte dopo che la connessione è attiva. Accade anche il contrario, con una rotta di registro che punta a un adattatore spento. Nessuna delle due viste da sola racconta tutta la storia.

Dimostrare il risultato dopo un riavvio

Tracciate in entrambe le direzioni e risolvete per nome. Una traccia pubblica dovrebbe uscire dal provider, una traccia interna dovrebbe entrare nel tunnel, e un host interno dovrebbe rispondere per nome e non solo per indirizzo.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Ripetete dopo una disconnessione, una riconnessione e un riavvio. Un prefisso che sopravvive a una riconnessione manuale e sparisce dopo un riavvio non è mai stato memorizzato nel profilo.

Tenete anche la stampante e il NAS nella prova, perché un tunnel diviso che taglia i dispositivi accanto al portatile ha risolto un problema creandone uno più piccolo e più irritante. Il riferimento Microsoft per Add-VpnConnectionRoute è il posto dove controllare l'ortografia dei parametri rispetto alla versione del vostro modulo.

Articoli correlati