Due client OpenVPN su un solo host Linux: a chi appartiene la rotta?

Entrambi i profili riportano la connessione e uno dei due trasporta in silenzio traffico destinato all’altro. Due client su un solo host è una disposizione supportata; due client senza proprietario per ogni prefisso non lo è. Il lavoro riguarda meno l’attivazione del secondo tunnel e più la decisione su quale processo possa rivendicare quale rotta. Segui l’ordine qui sotto e la configurazione discende dalle risposte.

Inizia chiedendo a cosa serve il secondo tunnel

Tre situazioni sembrano identiche sulla riga di stato e richiedono progetti diversi. Una suddivisione per destinazione manda un prefisso attraverso il profilo ufficio e un altro attraverso il profilo laboratorio, senza che nessuno rivendichi una rotta predefinita. Una suddivisione per applicazione di solito mantiene un tunnel completo e indirizza traffico specifico con regole di policy. Il failover tiene attivo esattamente un tunnel alla volta, il che significa che il secondo non deve avviarsi automaticamente.

Scrivi il caso prima di aprire qualsiasi file di configurazione, perché quella risposta decide tutto ciò che segue.

La disposizione rotta più comune sono due tunnel completi che hanno entrambi spinto una rotta predefinita, dove vince chi si è connesso per ultimo e il primo continua a fingere. Quello stato sembra intenzionale dalla riga di stato e spreca un giorno dalla tabella di routing. Dare un nome al caso per primo lo rende impossibile, non solo improbabile.

Guarda i pool prima delle rotte

Due server possono facilmente distribuire indirizzi da un unico intervallo privato e, quando lo fanno, il client finisce con due interfacce dentro un solo prefisso. Nessuna destinazione può allora essere attribuita a un’interfaccia per indirizzo, perché entrambe sembrano ugualmente corrette. Rinumera un pool invece di inventare una regola per rompere la parità.

Controlla anche la rete locale, perché una LAN domestica o d’ufficio che si sovrappone a un intervallo del tunnel crea la stessa ambiguità dall’altro lato. Confronta gli indirizzi dell’host con entrambe le configurazioni server prima di dare la colpa al client. Un cambio di pool su un server di laboratorio è una correzione di cinque minuti, mentre una deviazione di routing basata su policy per un prefisso sovrapposto è una tassa permanente per chiunque legga la configurazione in seguito. Decidi quale delle due vuoi prima di scegliere dove intervenire.

Due famiglie di indirizzi significano due giri di questo controllo. I pool IPv6 si scontrano con la stessa discrezione degli IPv4.

Dai a ogni profilo un proprietario

Un’istanza per profilo, un file di configurazione per istanza e un nome che identifica la coppia. Nel packaging in stile Debian il nome dopo il segno @ seleziona il file, ed è per questo che due profili che condividono un nome di istanza non possono mai funzionare entrambi. Conferma la mappatura dall’unità installata, non da un tutorial.

systemctl cat [email protected]
ip -4 addr show

Poi decidi chi installa le rotte, che è una questione di policy e non di sintassi.

Quando i due server spingono insiemi incompatibili, o aggiungi route-nopull e elenca solo i prefissi che ogni profilo richiede, oppure lascia che uno conservi la sua rotta predefinita e indirizza il resto con una regola di policy. Due processi che installano entrambi una rotta predefinita finiscono con un solo vincitore e nessuno sa dire perché. Non appena i due tunnel portano traffico di origini diverse, una risposta può uscire da quello sbagliato, e il modello che regge è un marchio di connessione ripristinato sulle risposte e indirizzato nella propria tabella. Limita i marchi perché i pacchetti cifrati dei tunnel stessi non vi corrispondano mai.

Verifica per tunnel, poi fermane uno

Quando entrambi sono attivi, prendi tre letture: l’indirizzo di ciascun dispositivo di tunnel, la rotta verso un host che vive dietro ognuno e il percorso che prenderebbe una destinazione fuori da entrambi. Un normale elenco di rotte smette di descrivere la ricerca finale non appena entrano in gioco le regole, quindi chiedi al kernel cosa sceglierebbe davvero. Poi ferma un’istanza e guarda cosa scompare. Se fermare la prima disturba la seconda, qualcosa è ancora condiviso tra loro: una rotta, un nome di dispositivo o una regola del firewall che nessuno ha separato.

ip rule show
ip route get 203.0.113.9

Rimetti in funzione il profilo fermato e ripeti gli stessi controlli, perché un tunnel che funziona una volta dopo un riavvio e mai più è un bug del ciclo di vita travestito da routing.

Annota nelle note di distribuzione quale profilo possiede quale prefisso, accanto agli intervalli dei pool. Due tunnel sono una disposizione deliberata, e il prossimo lettore deve vedere il confine prima di toccare uno dei profili. Senza quella nota, il confine viene riscoperto da chi è di turno quando il prefisso condiviso alla fine si rompe.