Due client VPN, una tabella di routing: chi si aggiudica la rotta predefinita

Sembra che due client VPN si contendano lo stesso socket, e la correzione ovvia deve essere disinstallarne uno. In pratica toccano raramente lo stesso socket. Ogni connessione riscrive la tabella di routing del sistema operativo, e un profilo a tunnel completo rivendica la rotta predefinita. Di solito vince chi si è connesso per ultimo, ed è per questo che il sintomo sembra spostarsi tra i client.

Il conflitto vive nella tabella di routing

Un adattatore virtuale più una rotta predefinita è come un tunnel completo cattura il traffico. Quando il secondo client installa la propria rotta predefinita, la voce più vecchia viene sostituita o abbassata dalla metrica, e ogni destinazione viaggia ora attraverso il tunnel più recente. Il primo client resta connesso e mostra ancora un'icona verde, quindi l'interfaccia è attiva mentre il percorso è sparito. È proprio questa separazione tra stato della connessione e stato del routing a rendere il comportamento confuso.

I client sono editori di un'unica tabella condivisa. Sapere quale modifica è avvenuta per ultima spiega quasi ogni sintomo.

Leggi quale tunnel possiede il percorso attuale

Controlla la decisione reale invece di fidarti del client che dichiara di essere connesso. Chiedi al sistema quale interfaccia porterebbe una destinazione specifica.

ip route get 10.20.0.5
route print -4

Il primo comando indica l'interfaccia e l'indirizzo di origine per una destinazione, ed è esattamente la domanda che ti interessa. Il dump delle rotte mostra su Windows le voci predefinite in competizione e le loro metriche, così vedi quale vince adesso. Esegui la ricerca per un host in ogni rete remota, perché una destinazione può essere corretta mentre l'altra rete è irraggiungibile. Se la risposta indica il tunnel sbagliato, riconnettersi non aiuterà; la politica di routing deve cambiare.

Impedisci al secondo client di rivendicare tutto

Un client dovrebbe possedere la rotta predefinita, e l'altro dovrebbe portare solo i propri prefissi. OpenVPN i client possono rifiutare ciò che il server spinge.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ignora ogni rotta spinta, mentre pull-filter ignore "redirect-gateway" scarta solo la direttiva della rotta predefinita e conserva il DNS e le altre opzioni spinte. Scegli tra i due in base a quanta configurazione del server vuoi ancora, poi aggiungi i prefissi specifici che servono alla seconda rete. Tieni presente il DNS, perché un resolver spinto da un tunnel che non porta le richieste non restituisce nulla. Prova un host noto in ogni rete e conferma l'indirizzo di origine che vede il lato remoto.

Le sottoreti sovrapposte non si possono aggirare

Quando entrambe le reti pubblicano lo stesso prefisso, il kernel tiene una voce per due luoghi diversi e deve scegliere. Una rotta host non può inventare la distinzione mancante, e nemmeno un ritocco della metrica. Rinumerare un lato, o fai tradurre l'intervallo remoto dal suo amministratore in modo che i prefissi differiscano. Controlla le sottoreti reali prima di dare la colpa ai client, perché il valore predefinito 192.168.1.0/24 di un router domestico entra in collisione con un intervallo d'ufficio più spesso di quanto ci si aspetti. Annota entrambi gli intervalli nel ticket così la modifica successiva non ricrea la sovrapposizione.

Separa anche due obiettivi: raggiungere entrambe le reti è un problema di routing, mentre concatenare tunnel per la privacy è un progetto diverso, con un operatore in più sul percorso. Non usare l'uno per risolvere l'altro.