La metrica della rotta VPN cambia dopo la connessione: cosa significa
Una metrica più bassa risolve solo la parità tra rotte ugualmente specifiche. Leggi la regola di policy, il prefisso e la rotta host dell’endpoint prima di modificare qualsiasi numero di rotta VPN.
Connetti la VPN, esegui route print e la rotta predefinita ora porta una metrica molto più bassa di prima. La conclusione naturale è che la VPN ha preso la rotta predefinita perché il suo numero è più piccolo. A volte è esattamente quello che è successo. Spesso la metrica non è affatto il fattore decisivo, e modificarla non cambia nulla perché la scelta è stata fatta prima, dalla lunghezza del prefisso o da una regola di policy.
Il sintomo è reale: il traffico che prima usciva dall’adattatore Wi-Fi ora esce dal tunnel, o viceversa. La metrica è un input di una ricerca che viene eseguita in un ordine fisso, e quell’ordine è quello che devi leggere prima di toccare un numero.
Con cosa compete davvero il numero
Il primo confronto è la specificità, non la preferenza. Una rotta per 10.20.0.0/16 batte 10.0.0.0/8, ed entrambe battono 0.0.0.0/0, qualunque cosa dicano le loro metriche. Una VPN che installa una rotta predefinita con la metrica più bassa sulla macchina perde comunque contro qualsiasi rotta più specifica che corrisponda alla destinazione, compresa la rotta host che il client installa per il proprio server.
Per questo abbassare la metrica di una rotta predefinita non può forzare una sottorete collegata direttamente dentro il tunnel. Se vuoi quella sottorete dentro la VPN, aggiungi una rotta per il prefisso o seleziona la tabella del tunnel con una regola di policy. La metrica è la leva sbagliata per quel lavoro.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux sceglie la tabella prima della metrica
Su Linux il kernel consulta prima il database delle policy. ip rule elenca le regole e le tabelle che selezionano, e ip route get 203.0.113.10 riporta la tabella, la rotta e l’indirizzo sorgente che il kernel userebbe davvero per quella destinazione. Una metrica dentro la tabella 100 non compete mai con una rotta della tabella principale, perché la regola ha scelto la tabella prima che qualsiasi metrica fosse confrontata.
Per questo una rotta può sembrare corretta in ip route show table all e comunque non portare traffico. Leggi la regola che ha corrisposto, poi la tabella che ha selezionato, poi confronta le rotte al suo interno. Se è stata selezionata la tabella sbagliata, nessuna modifica di metrica nell’altra tabella aiuterà.
Windows combina due metriche
Windows non ha un database delle policy per impostazione predefinita, ma combina una metrica di rotta con una metrica di interfaccia, e la metrica automatica dell’interfaccia può cambiare con la velocità del collegamento e lo stato dell’adattatore. Per questo la stessa rotta può comportarsi diversamente dopo la comparsa di una docking station o di un adattatore virtuale. Find-NetRoute -RemoteIPAddress 203.0.113.10 riporta l’indirizzo sorgente, il salto successivo e l’interfaccia scelti, il che è più vicino alla decisione reale della tabella grezza.
Leggi insieme i valori di rotta e di interfaccia. Alzare la metrica di un’interfaccia può spostare il traffico senza che nessuna voce di rotta cambi, e un client VPN che possiede le proprie rotte le reinstallerà alla riconnessione scartando la tua modifica.
Tieni l’endpoint del tunnel fuori dal tunnel
Ogni tunnel ha bisogno di un percorso verso il proprio server che non passi dal tunnel. I client installano una rotta host per l’endpoint attraverso il gateway fisico, e quella rotta deve restare più specifica della rotta predefinita che il client aggiunge. Cancellala, o lascia che il tunnel vinca la ricerca per quell’indirizzo, e i pacchetti incapsulati cercheranno di entrare nel tunnel che dovrebbero costruire. La connessione fallisce o va in loop.
Controlla quella rotta host prima e dopo ogni modifica di metrica: deve puntare al salto successivo fisico e sopravvivere a una riconnessione. Se è il client a possederla, cambia il profilo o la configurazione gestita invece di un valore di runtime che verrà sovrascritto.
Controlla entrambe le famiglie di indirizzi e il contesto dell’applicazione
IPv4 e IPv6 sono decisioni separate con tabelle separate. Una VPN può trasportare IPv4 mentre IPv6 continua a usare il router locale, e un cambio di metrica in una famiglia non dice nulla sull’altra. Controlla entrambe, poi controlla il contesto dell’applicazione. Un processo legato a un’interfaccia, un namespace di container o una VPN per applicazione può vedere una tabella diversa dalla tua shell.
Verifica con lo strumento che riporta la decisione per la destinazione reale, non con l’elenco completo della tabella. Se la rotta scelta è quella che il progetto intende, fermati. Una metrica che non è il numero più piccolo sullo schermo non è un difetto, e forzarla a esserlo può rompere il percorso dell’endpoint da cui dipende il tunnel.