Metrica di route di OpenVPN: perché la route scelta perde ancora

Hai aggiunto una metrica a una route nel profilo, ti sei riconnesso e il traffico esce ancora dall’interfaccia sbagliata. Il numero è raramente il problema. Una metrica ordina solo i candidati che il sistema operativo sta già confrontando, e un prefisso più specifico o una tabella di policy precedente decide prima che venga letta qualsiasi metrica.

Ripercorri prima il profilo, poi la tabella installata, poi le regole di selezione. Quest’ordine corrisponde al modo in cui il client costruisce la route e ti impedisce di regolare un valore che non entra mai nel confronto.

Leggi la riga di route nell’ordine dei campi

Un client della community OpenVPN 2.6 accetta quattro campi su una riga route IPv4: rete, maschera di rete, gateway e una metrica facoltativa. La posizione del gateway è dove va la parola chiave speciale vpn_gateway. Significa il salto successivo lato VPN per questa connessione, non un numero di tabella di routing e non il tuo router fisico. Se lo salti, il resto della riga viene letto con un’idea sbagliata di cosa fa. riferimento delle opzioni di rete documenta tutti e quattro i campi.

Per una destinazione privata la riga può essere:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Il 30 esplicito vale per quella route, e il 50 resta il valore predefinito per ogni altra route del profilo che omette un numero. Leggere la riga da sinistra a destra basta per capire quale valore vale dove.

route-metric è un valore predefinito, non un rango

route-metric imposta il valore di riserva per le route che non portano il proprio numero. Non mette una route sopra qualcos’altro e non riordina le route installate con metriche esplicite.

Questa distinzione conta quando un profilo mescola le due forme. Una singola riga route-metric vicino all’inizio sembra autorevole ed è facile incolparla, mentre la route che porta davvero il traffico può portare la propria metrica tre righe più in basso.

Se vuoi che una route preferisca un percorso, metti il numero su quella route. Se vuoi un valore predefinito coerente su un profilo generato, usa route-metric e lascia in pace le singole righe. Mescolare le due senza motivo è come un profilo finisce con una route che nessuno riesce a spiegare.

Ispeziona cosa ha installato il client

Quando la riconnessione è completa, chiedi al kernel, non al profilo.

ip route show elenca le route che il client ha aggiunto, e ip route get 172.20.5.10 risponde alla domanda più utile: quale route userebbe davvero questa destinazione e con quale indirizzo sorgente. Se la destinazione manca dalla tabella, il client non l’ha installata.

Una direttiva locale, un push dal server o un altro gestore di rete possono aggiungere o togliere lo stesso prefisso, e vince l’ultimo che scrive. Tieni a vista la route dell’endpoint mentre lavori, perché la connessione ha bisogno di un percorso verso il server remoto che non passi dal tunnel che sta costruendo.

Perché una metrica più piccola perde ancora

Le metriche confrontano route verso la stessa destinazione. Non rendono un prefisso ampio più specifico. Quando redirect-gateway def1 è in gioco, il client installa 0.0.0.0/1 e 128.0.0.0/1, e quei due prefissi coprono tutto lo spazio IPv4 in modo più specifico di 0.0.0.0/0. Una metrica di 1 sulla route predefinita non li supera.

La stessa logica vale per qualsiasi coppia sovrapposta. Una /24 batte una /16 per un indirizzo al suo interno indipendentemente dai numeri associati, perché la ricerca sceglie prima la corrispondenza più specifica e solo dopo confronta le metriche tra pari.

Questa è la parte che sembra un bug della metrica e non lo è. Controlla la lunghezza del prefisso su entrambi i candidati prima di cambiare qualsiasi numero.

Le regole di policy girano prima della tabella

Su Linux, ip rule decide quale tabella di routing viene consultata. Le regole sono valutate in ordine di priorità, quindi una tabella precedente può restituire una route prima che la tabella principale venga letta. Una metrica dentro main non può superare una corrispondenza in una tabella consultata prima.

Usa ip rule show e poi interroga la tabella specifica, per esempio ip route show table 100, per vedere cosa restituirebbe quella regola. Se un client VPN o un ambiente di container ha aggiunto una regola, la risposta potrebbe essere lì invece che nella tabella che stavi leggendo. Anche l’indirizzo sorgente conta, perché una regola può corrispondere alla sorgente e risolvere la stessa destinazione in modo diverso per il traffico del tunnel e il traffico LAN.

Verifica la destinazione, non la classifica

Il test che chiude la discussione è una sola query verso un host nella sottorete prevista, più un controllo dell’indirizzo sorgente scelto dal kernel. Se quella coppia corrisponde al progetto, la metrica fa il suo lavoro anche quando l’elenco non sembra una classifica pulita.

Lascia IPv6 e DNS fuori da questo controllo. Sono configurati da direttive diverse e risolti da meccanismi diversi, e una route IPv4 funzionante non dice nulla su nessuno dei due. Cambia un livello alla volta e ripeti la query.