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

Due profili sono connessi, e uno dei due trasporta silenziosamente traffico destinato all’altro. Un host Linux può eseguire entrambi i client OpenVPN contemporaneamente senza difficoltà. Ciò che non può fare è decidere al posto vostro quale processo possa rivendicare quale prefisso. Quella decisione va presa prima che salga il secondo tunnel, non dopo che una risorsa smette di rispondere.

Partite dal lavoro che il secondo collegamento deve svolgere

Un ufficio raggiungibile tramite un profilo e un laboratorio raggiungibile tramite un altro richiedono entrambi i tunnel attivi e nessuno dei due che rivendichi tutto. Una singola applicazione ostinata che deve uscire dal secondo profilo ha bisogno di una regola di policy anziché di una seconda rotta predefinita. Un collegamento di riserva ha bisogno di un solo tunnel attivo alla volta, quindi la scorta non dovrebbe partire con la macchina.

Sono tre configurazioni diverse, e vengono confuse perché tutte e tre iniziano allo stesso modo: un secondo profilo e una connessione riuscita. Scrivete prima la disposizione prevista, poi configurate in quella direzione. Una frase di intento risparmia un’ora di cattura pacchetti.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Il primo comando elenca le istanze in esecuzione, comprese quelle avviate a mano fuori dal gestore. Il secondo stampa la rivendicazione predefinita attuale, cioè lo stato che dovrete spiegare più avanti.

I pool sovrapposti si rompono prima del routing

Due server assegneranno volentieri indirizzi dallo stesso 10.8.0.0/24. Il client tiene allora due interfacce dentro un unico prefisso senza nulla che dica quale destinazione appartenga a quale, e il comportamento risultante sembra un guasto di routing ma in realtà è un guasto di numerazione. Rinumerare un pool costa una modifica di configurazione; ogni aggiramento di routing successivo costa un fine settimana. Controllate il pool prima di aggiungervi una rotta.

Guardate anche la LAN locale. Una LAN domestica numerata 192.168.1.0/24 che un tunnel espone anch’esso produce la stessa ambiguità, e il sintomo è un nome host che si risolve mentre la connessione non si completa mai. Sembra un guasto di risoluzione dei nomi finché non stampate le rotte.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Confrontate entrambi gli output con le due configurazioni server prima di toccare il client. Se i prefissi si sovrappongono, fermatevi e rinumerate, perché nessun riavvio li separerà.

Date a ogni profilo la sua unità e a ogni prefisso un proprietario

Ogni profilo ha il proprio nome di istanza e il proprio file di configurazione, quindi l’istanza chiamata office carica office.conf mentre quella chiamata lab carica lab.conf. Confermate questa mappatura tramite il gestore dei servizi invece di fidarvi di un elenco di directory, perché un drop-in può cambiare quale file viene caricato. Sbagliare la mappatura significa che state regolando il profilo che non è in esecuzione.

Poi decidete chi installa le rotte. Quando i server spingono insiemi incompatibili, o rifiutate la spinta e elencate voi stessi i prefissi, oppure lasciate che un profilo mantenga la predefinita e guidate l’altro con regole di policy. Due processi che installano entrambi una predefinita finiscono con un vincitore silenzioso e senza alcuna traccia scritta della decisione.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Il primo mostra l’unità con qualsiasi override che ne cambi gli argomenti. Il secondo mostra se il profilo accetta del tutto le rotte spinte, ed è l’interruttore che decide tutto il resto.

I marcatori tengono le risposte sull’interfaccia da cui sono arrivate

Quando ogni tunnel serve sorgenti diverse, una risposta può uscire dal collegamento sbagliato e la connessione muore dopo il primo pacchetto. Lo schema che regge è marcare i pacchetti in arrivo per interfaccia d’ingresso, ripristinare quel marcatore sulla risposta e dare a ogni marcatore una tabella con il proprio gateway predefinito.

Il filtraggio lasco del percorso inverso di solito va allentato per le interfacce interessate, perché una risposta arriva legittimamente da un collegamento che la tabella principale non sceglierebbe mai. Tenete i marcatori stretti perché non catturino mai il traffico cifrato dei tunnel stessi, il che manderebbe il tunnel attraverso se stesso.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Leggete le regole esistenti prima di aggiungerne un’altra. Le priorità duplicate e le tabelle dimenticate sono la ragione abituale per cui una policy di marcatori sembra non avere alcun effetto.

Dimostrate l’isolamento fermando un collegamento

Con entrambi i tunnel attivi, registrate l’indirizzo di ogni interfaccia, la rotta verso un host dietro ciascun tunnel e il percorso che prende una destinazione non correlata. Chiedete la ricerca al kernel invece di leggere una sola tabella, perché una tabella non mostra mai la decisione finale.

Poi fermate un’istanza e osservate la sua interfaccia e le sue rotte sparire mentre l’altra continua. Una rottura nella sopravvissuta significa che le due condividono ancora un nome di dispositivo, una rotta o una regola di firewall che nessuno ha separato.

Riportate in vita il profilo fermato e ripetete gli stessi controlli. Quando un tunnel sopravvive solo al primo avvio dopo un riavvio, state guardando un difetto del ciclo di vita e non un progetto di routing.