Un hub OpenVPN, tre LAN: piano degli indirizzi e file iroute

Tre LAN private possono incontrarsi su un unico hub senza che nessuna sede debba conoscere la struttura interna delle altre, e l'intero progetto poggia su quattro brevi decisioni di configurazione. A farlo funzionare non è una funzione di protocollo esotica, ma un piano di indirizzi che nessuno deve indovinare, insieme a rotte per singolo client che dicono all'hub quale filiale possiede quale prefisso. Se una delle due cose è sbagliata il tunnel si alza comunque, ed è proprio questo a rendere il guasto confuso.

Segui i passaggi nell'ordine indicato. Ognuno dipende dal piano del passaggio precedente e nessuno richiede una nuova autorità di certificazione.

Parti da un piano che nessuno deve indovinare

Annota quattro prefissi disgiunti prima di toccare un file di configurazione: la LAN dell'hub, la LAN di ogni filiale e il pool assegnato ai client in roaming. La disgiunzione è ciò che mantiene semplice tutto il resto, perché intervalli sovrapposti trasformano l'instradamento in un rompicapo di corrispondenza più lunga che nessuna configurazione per client riesce a riparare. Poi verifica quale macchina è il gateway predefinito di ogni LAN, dato che un router di filiale che non è il gateway della propria LAN ha bisogno delle rotte remote installate altrove. Infine fissa i nomi autenticati che identificano ogni filiale, perché quei nomi sono le chiavi con cui vengono cercati i file per client.

Un piano illustrativo tiene il pool ben lontano dalle tre LAN. Il tuo sarà diverso, e l'unica regola ferrea è che nessuna coppia di intervalli si sovrapponga.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Di' al kernel dell'hub dove si trovano le filiali

L'hub ha bisogno di due informazioni per filiale: una rotta kernel che manda il prefisso nel dispositivo tunnel e una voce iroute che dice al processo OpenVPN quale client la possiede. La sola rotta kernel consegna i pacchetti al tunnel e si ferma lì, perché il daemon deve ancora decidere quale peer debba riceverli. La sola voce iroute lascia quei pacchetti nel kernel senza una rotta da seguire. Entrambe le righe appartengono alla configurazione che il daemon carica davvero, e conviene verificarlo prima di cercare guasti altrove.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Tieni disattivato client-to-client quando il kernel deve essere il punto di applicazione delle regole. Quell'opzione inoltra il traffico tra peer dentro il daemon, il che è comodo e significa anche che le tue regole di forwarding non vedono mai il flusso. Tutto quanto segue presuppone che il kernel veda ogni pacchetto tra filiali.

Dai a ogni filiale le rotte di cui ha bisogno

Ogni filiale ha bisogno delle rotte verso le altre filiali e verso la LAN dell'hub, e non ne ha bisogno per la propria LAN collegata. Spingi i prefissi remoti dall'hub invece di incollarli in ogni router, così una quarta sede in futuro significherà un solo nuovo file per client invece di quattro modifiche. Il file per client contiene anche la riga iroute, che tiene proprietà e annuncio nello stesso posto. Rendi la directory e i suoi file leggibili secondo il modello di privilegi del server, altrimenti la ricerca fallisce senza un messaggio.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Una quarta sede segue lo stesso schema: un nome autenticato distinto, un prefisso posseduto, una rotta kernel sull'hub, una voce iroute e annunci solo verso le sedi autorizzate a raggiungerla.

Collauda in entrambe le direzioni prima di dichiarare finito

Abilita l'inoltro IPv4 su tutti e tre i router, poi conferma che il firewall consenta i flussi previsti in entrambe le direzioni, perché un test a senso unico passa con un percorso di ritorno rotto più spesso di quanto chiunque si aspetti. Non serve alcuna traduzione degli indirizzi tra le sedi, e conservare l'indirizzo originale è proprio ciò che permette a ogni filiale di applicare la propria politica a una richiesta.

Prova da un host su una LAN di filiale a un servizio su un'altra, poi inverti la direzione, poi prova da una filiale alla LAN dell'hub. Quei tre risultati sono prove diverse e nessuno implica gli altri. Se un router di filiale non è il gateway predefinito della sua LAN, installa i prefissi remoti sul gateway reale e includi anche il pool quando i client del tunnel devono avviare connessioni verso quella LAN.

Registra il piano, i file per client e le regole del firewall in un unico documento, perché la prossima aggiunta di sede sarà valutata rispetto a esso.

Il progetto regge perché ogni livello ha un solo compito: il piano mantiene unici i prefissi, la rotta kernel sposta i pacchetti, iroute indica il proprietario e il firewall decide cosa è consentito. Quando qualcosa si rompe, quell'elenco è anche l'ordine in cui controllare.