Due client OpenVPN su un solo gateway Linux: dividere la politica

Due demoni OpenVPN possono entrambi segnalare un tunnel riuscito mentre il gateway manda ogni client attraverso lo stesso. Nulla nella stretta di mano decide quale tunnel usa un client; è il kernel a decidere, pacchetto per pacchetto, percorrendo le regole di politica e poi la tabella che ogni regola nomina. Visto così, la configurazione smette di riguardare le opzioni di OpenVPN e diventa una matrice di routing con due proprietari.

Decide il kernel, non il demone

Un pacchetto inoltrato arriva sull’interfaccia LAN e il codice di routing valuta l’elenco delle regole in ordine di priorità. La prima regola il cui selettore corrisponde nomina una tabella, e le rotte di quella tabella scelgono il dispositivo di uscita. Se la tabella non ha una rotta corrispondente, la ricerca passa alla regola successiva, e proprio questo dettaglio fa fallire in silenzio, invece che rumorosamente, una configurazione a metà.

Il processo del tunnel non ha voce in quel percorso. Crea un’interfaccia e può installare rotte, ma se il pacchetto di un dato client entra in quell’interfaccia dipende interamente dalla tabella a cui è stato inviato. Due tunnel con rotte importate identiche competono quindi tra loro, e l’ultimo che scrive vince per tutti. È per questo che una configurazione può sembrare equilibrata nei file e mandare comunque tutti i client attraverso un solo demone.

Date a ogni istanza il proprio insieme di risorse

Iniziate dai nomi, perché i nomi riutilizzati sono il modo in cui le due istanze finiscono per condividere stato per caso. Assegnate dispositivi di tunnel distinti, file di configurazione distinti, credenziali distinte e unità di servizio distinte. Annotate l’endpoint esterno e l’indirizzo del tunnel di ogni istanza nella stessa tabella della matrice di politica, così una modifica successiva ha un solo posto dove guardare.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull tiene le rotte spinte da un server fuori dalla tabella locale, ed è esattamente ciò che volete quando le tabelle di politica devono essere esplicite. Se un dato server spinge anche un’opzione redirect-gateway, e se la vostra versione client supporta la forma con filtro, vale la pena verificarlo nel manuale invece di darlo per scontato.

Scrivete la matrice: origine, tabella, dispositivo

Per ogni gruppo di client, aggiungete una regola che selezioni una tabella per indirizzo di origine, poi mettete il percorso voluto in quella tabella:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

La tabella ha bisogno delle rotte di destinazione che il gruppo dovrebbe avere, più le eccezioni locali o di gestione che mantengono utilizzabile il gateway. Una tabella che contiene solo una rotta predefinita è una politica di tunnel completo per quel gruppo, il che può essere esattamente giusto, ma dovrebbe essere una decisione e non una dimenticanza.

Il trasporto del tunnel stesso non è in un gruppo di client

I pacchetti cifrati di ogni demone nascono sul gateway stesso, indirizzati al peer esterno. Una regola che corrisponde solo a un prefisso di origine client lascia in pace quei pacchetti, ed è per questo che le regole limitate all’origine sono più sicure delle regole che corrispondono a tutto. Una regola senza selettore può catturare il trasporto del tunnel stesso e rimandarlo attraverso un tunnel, e allora la connessione fallisce in un modo che sembra un problema del fornitore.

Tenete la sessione di gestione locale e il percorso del sottolivello esplicitamente fuori dalle tabelle di politica. Scrivete quelle eccezioni accanto alla matrice; fanno parte del progetto, non sono un espediente da riscoprire durante un incidente.

Scegliere un percorso non lo autorizza

L’autorizzazione al forwarding è una seconda decisione presa più avanti nel percorso. Una regola del firewall che accetta i pacchetti in uscita dal secondo tunnel non fa sì che il codice di routing lo scelga, e una tabella corretta non concede il permesso di inoltrare. Devono esistere entrambe, e un test che ne dimostra solo una vi porterà fuori strada sull’altra. Quando un gruppo funziona e l’altro no, controllate quei due passaggi separatamente invece di riscrivere le tabelle.

La traduzione dell’origine è una terza decisione, e andrebbe limitata al gruppo di origine e al dispositivo di tunnel che effettivamente la trasporta. Aggiungete una catena dedicata per le due istanze invece di svuotare la catena postrouting, perché servizi non correlati possono avervi voci e uno svuotamento le rimuove in silenzio.

Cosa succede quando un tunnel cade

Decidete il comportamento in caso di guasto in anticipo. Quando una tabella di tunnel perde la sua rotta, la ricerca ricade sulla regola successiva e il traffico del gruppo continua attraverso l’altro tunnel o il normale collegamento in uscita senza alcun errore. Se ciò non è accettabile, aggiungete una regola terminale con un numero di priorità più basso che restituisca un risultato irraggiungibile per quell’origine, così la perdita è visibile invece di essere assorbita.

Inviate una richiesta nuova da ogni gruppo di origine e annotate quattro fatti: la tabella selezionata, il dispositivo di uscita, l’origine tradotta e se la risposta è tornata per lo stesso percorso. Poi abbassate un tunnel e ripetete. Due dispositivi TUN in un elenco di interfacce dimostrano che entrambi i demoni sono partiti; non dicono nulla su quale abbia usato un dato client. La seconda esecuzione, con un tunnel in meno, è quella che mostra se la vostra regola di ripiego fa ciò che volevate.