Perché la tua VPN di Windows uccide la stampante locale e come fermarlo

Connetti la VPN e la stampante scompare, la condivisione NAS smette di aprirsi e una sessione Desktop remoto verso la macchina accanto a te va in timeout. Nulla si è rotto. Il client ha aggiunto una rotta predefinita e ora possiede ogni destinazione che il portatile può nominare, comprese quelle a tre metri. È tutto il meccanismo, e chiamarlo guasto della VPN è ciò che trasforma una correzione di una riga in un caso di assistenza.

Leggi prima la tabella delle rotte

Prima di cambiare qualsiasi cosa, cattura la tabella IPv4 con route print -4 e conserva l’output. Connettiti, cattura di nuovo e confronta le righe 0.0.0.0: la rotta predefinita attiva nomina un’interfaccia, e se quell’interfaccia è il tunnel, stampa e navigazione locali vengono inviate prima all’ufficio.

Il numero di interfaccia nella seconda colonna è ciò a cui una rotta persistente dovrà riferirsi più tardi, quindi annotalo mentre il tunnel è attivo. È anche il valore che cambia quando l’adattatore viene ricreato, ed è per questo che le rotte fissate a esso possono sopravvivere in silenzio alla loro utilità.

Rimuovi la rotta predefinita, in tre modi

Su un profilo Windows integrato il controllo è una casella di controllo. Apri le proprietà della connessione, IPv4, poi Avanzate, e deseleziona Use default gateway on remote network; l’app Impostazioni più recente nasconde la stessa finestra di un livello più in profondità. Da un prompt elevato la stessa modifica è un cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

Un profilo OpenVPN funziona diversamente, ed è per questo che il suo comportamento confonde chi si aspetta una casella di controllo. La sua direttiva redirect-gateway def1 non sostituisce affatto la rotta predefinita; installa due rotte a mezzo intervallo, 0.0.0.0/1 e 128.0.0.0/1, che insieme vincono sulla predefinita senza cancellarla. Poiché la predefinita originale sopravvive, aggiungere un prefisso puntato a net_gateway rimanda solo quel prefisso al router locale. Quel dettaglio spiega perché la soluzione per un profilo def1 è una rotta di prefisso e non una casella di controllo che nessuno trova.

Riaggiungi solo ciò che appartiene al lavoro

Senza la rotta predefinita il tunnel non trasporta nulla, quindi i prefissi di lavoro vanno nominati esplicitamente. Il cmdlet che lega un prefisso alla connessione è più sicuro di una rotta persistente, perché viene installato solo mentre quella connessione è attiva e non dipende da un numero di interfaccia:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

L’approccio più vecchio funziona ancora ed è ancora in ogni lista di controllo: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, con l’indice di interfaccia e l’indirizzo di gateway del tunnel stesso. Persiste tra i riavvii, che è lo scopo e anche il pericolo, dato che l’indice al prossimo avvio può appartenere a qualcos’altro.

Le metriche decidono il resto. Se sia l’adattatore fisico sia quello del tunnel rivendicano una rotta per lo stesso prefisso, vince la metrica più bassa, e alzare la metrica del tunnel è un controllo legittimo lato client e non un trucco.

Quando il server decide per te

Un client che ignora la tua casella di controllo di solito sta obbedendo a un criterio. I profili Cisco portano un’impostazione Allow Local LAN Access, e un headend può spingere un criterio tunnel-all che annulla ciò che il client preferirebbe; in una distribuzione a tunnel obbligatorio non c’è alcun interruttore locale da cambiare. Leggi il log del client per le rotte e le righe di criterio spinte invece di ricontrollare la stessa finestra.

Poi guarda la risoluzione dei nomi, che è un interruttore separato dall’instradamento. Un tunnel diviso può comunque ricevere un resolver interno e un suffisso di ricerca, quindi un dispositivo locale è raggiungibile per indirizzo e introvabile per nome finché anche il lato DNS non è sistemato.

Le sovrapposizioni sono un problema diverso

Se la LAN di casa e la LAN dell’ufficio condividono un prefisso come 192.168.0.0/24, nessuna rotta può distinguerle. Ogni pacchetto per quell’intervallo ha un solo risultato di ricerca, e la soluzione è rinumerare un lato o raggiungere l’ufficio tramite un indirizzo tradotto dal pool. Aggiungere rotte più specifiche sposta solo quale metà della rete si rompe.

Chiudi con una verifica invece di cinque: connettiti, poi esegui tracert verso un host interno e uno pubblico. Il primo salto dovrebbe differire, e se non lo fa, la separazione non è in vigore qualunque cosa riporti il client. Poi riconnettiti una volta e ripeti, perché le rotte spinte tornano a ogni sessione.