Perché la tabella di routing VPN di Windows mostra 0.0.0.0/1 e 128.0.0.0/1

Connettetevi a una VPN Windows e aprite la tabella di routing, e due voci saltano all’occhio: 0.0.0.0/1 e 128.0.0.0/1. Non sono errori di battitura e non sostituiscono la route predefinita. La loro comparsa dipende da un’opzione del profilo, e la coppia è il modo in cui si costruisce un tunnel completo, non una funzione di split tunnel. Leggete l’opzione, il prefisso e l’interfaccia insieme prima di cambiare una sola riga.

Cosa installa l’opzione gateway predefinito

L’opzione del profilo che manda tutto attraverso il tunnel funziona aggiungendo quei due prefissi. Togliete l’opzione e spariscono, lasciando una route che copre solo la subnet assegnata all’adattatore del tunnel. La casella controlla la coppia; non riscrive l’unica route predefinita. Per questo la tabella dopo aver tolto la spunta sembra una riscrittura parziale invece di una cancellazione.

0.0.0.0/1 copre la metà inferiore dello spazio IPv4 e 128.0.0.0/1 la metà superiore, quindi insieme coprono ogni indirizzo unicast. Ciascuna è più specifica di una route predefinita 0.0.0.0/0, il che significa che la corrispondenza del prefisso più lungo manda il traffico ordinario nel tunnel mentre la route predefinita fisica resta dov’era. Mantenere quella route predefinita non è cosmetico: i pacchetti che incapsulano il payload cifrato sono indirizzati all’indirizzo pubblico del server e devono uscire dall’adattatore fisico. Sostituite la route predefinita invece di dividerla, e il trasporto del tunnel stesso cercherà di entrare nel tunnel, il che è un ciclo e non una connessione.

Un 0.0.0.0/0 letterale che punta all’adattatore VPN merita quindi una pausa. Il client nativo di solito non scrive una cosa del genere, quindi una route manuale o la configurazione di un altro client ha modificato la tabella alle vostre spalle. Trovatela prima di fare debug di qualsiasi cosa più a valle.

Smontare costa meno che conservare un gateway

Smontare è l’argomento pratico a favore di due voci invece di una. Il client possiede esattamente due route mentre è connesso e le elimina alla disconnessione, lasciando quello che l’adattatore fisico ha in quel momento. Un client che avesse sostituito l’unica route predefinita dovrebbe ricordare il gateway precedente e, dopo un cambio di lease DHCP, potrebbe ripristinarne uno che non esiste più. Due voci possedute non portano con sé questo stato.

Altri client arrivano allo stesso disegno. Un profilo OpenVPN con redirect-gateway def1 installa quei due prefissi invece di eliminare la route predefinita, e il client Windows segue lo stesso schema per lo stesso motivo di routing.

È anche per questo che una tabella può sembrare un tunnel completo quando vi aspettavate una divisione. La coppia è il modo in cui si costruisce il tunnel completo, non la prova di un errore di split tunnel. Se il profilo è impostato per usare il gateway remoto, tutto viene instradato, qualunque cosa un’applicazione locale riesca ancora a raggiungere.

Il prefisso più lungo vince prima di qualsiasi metrica

La lunghezza del prefisso decide la ricerca prima di ogni altro campo. La metrica risolve solo i pareggi tra route con prefisso identico, quindi una voce /1 batte una route predefinita /0 anche quando la sua metrica è peggiore. Il binding all’interfaccia decide cosa resta quando due route condividono un prefisso e Windows deve scegliere quale adattatore invia il pacchetto.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Una tabella di split tunnel contiene la route fisica predefinita, le due semi-route, la route della subnet del tunnel e qualsiasi prefisso di ufficio abbiate aggiunto. La route fisica predefinita può stare su una metrica più bassa o più alta a seconda del client e del profilo, e finché esiste la coppia /1 quella differenza non cambia nulla. Cambia tutto nel momento in cui la coppia viene rimossa, ed è allora che emerge un gateway obsoleto o un’interfaccia sbagliata. Leggete l’intera tabella invece della riga che vi aspettavate di cambiare.

Scegliete un solo proprietario per il prefisso dell’ufficio

Per uno split tunnel, nominate solo il prefisso che deve usare la VPN e scegliete un solo modo di possederlo. Puntare la route all’indirizzo del tunnel assegnato funziona finché quell’indirizzo non cambia, mentre il binding all’interfaccia sopravvive al cambio di indirizzo ma si rompe quando l’indice viene riassegnato dopo la ricostruzione del profilo. Il cmdlet legato al profilo evita entrambi i problemi, al costo di richiedere il profilo.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

Il cmdlet lega il prefisso al profilo denominato, così la route appare con la connessione e scompare con essa, che è ciò che vuole un portatile gestito. Una route persistente sopravvive ai riavvii e sopravvive al profilo che l’ha motivata, ed è così che una VPN dismessa lascia voci per anni. Scegliete un metodo per prefisso e annotate la scelta, perché una route persistente più una route di profilo per lo stesso prefisso producono duplicati dolorosi da districare durante lo smontaggio. Qualunque scegliate, la proprietà dovrebbe essere visibile nel ticket e non solo sulla macchina.

La proprietà è la domanda a cui risponde questa sezione, non la sintassi. Due proprietari per un prefisso è la modalità di guasto che vale la pena evitare.

Verificate con una destinazione, non con un sito web

Provate la destinazione che deve attraversare il tunnel, non un sito web che riporta un indirizzo di uscita. Find-NetRoute restituisce la route scelta e l’indirizzo di origine, così vedete se ha vinto il prefisso dell’ufficio o la route fisica predefinita, e poi aprite la condivisione stessa.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Un sito dell’indirizzo di uscita è un controllo debole, perché DNS, IPv6 e un proxy del browser possono inviare quella richiesta ciascuno per un percorso diverso. IPv4 e IPv6 hanno anche impostazioni separate nella stessa finestra, e togliere una casella lascia l’altra famiglia intatta, quindi una macchina a doppio stack può portare IPv6 attraverso il tunnel mentre IPv4 segue la route divisa. Controllate entrambe le famiglie prima di definire il profilo diviso. Se la route è corretta e il servizio fallisce ancora, lo strato rimanente è il filtraggio e non il routing.

Un firewall gestito dal client può bloccare la subnet dell’ufficio con una tabella di routing perfetta. Quella politica appartiene a chi ha distribuito il profilo, non a chi modifica le route.