Server OpenVPN con nopool: dichiarare un intervallo di pool esplicito

Gli helper del server configurano una sottorete e poi la riempiono con un pool dinamico di loro scelta. Quel valore predefinito è comodo finché alcuni indirizzi devono restare fuori dall’assegnazione, che siano riservati per assegnazioni fisse o tenuti da parte per un segmento futuro. Sopprimere il pool automatico e dichiarare l’intervallo da soli richiede due righe e una decisione consapevole su quali indirizzi non sono per l’assegnazione. Il resto è disciplina operativa: inventario, applicazione, verifica, rollback.

Questa è una modifica a un servizio in funzione, quindi trattatela come un’attività operativa: prima l’inventario, poi l’applicazione tramite il normale ciclo di vita, la verifica con un client nuovo e un rollback pronto.

Partite dalla sottorete che avete già

Leggete la configurazione attuale del server e gli indirizzi che i client detengono davvero. La modifica del pool ha senso solo rispetto a quella base, e la base non è sempre ciò che suggerisce il file, perché un prodotto gestito o un generatore di configurazione può possedere il file che state leggendo.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Confermate la topologia in vigore. Con la topologia a sottorete ogni client prende un indirizzo dal pool; i layout net30 più vecchi assegnano un piccolo blocco per client e l’aritmetica è del tutto diversa. Se il server è ancora su net30, questa pagina è la guida di migrazione sbagliata e i numeri del pool non significheranno ciò che vi aspettate. Controllate quella riga prima di copiare aritmetica degli indirizzi da altrove.

Annotate l’indirizzo del server stesso, ogni assegnazione fissa nella directory delle configurazioni client e ogni indirizzo da cui dipende una rotta o una regola di accesso. Sono questi gli indirizzi che devono restare fuori dall’intervallo dinamico. Annotarli per primi è ciò che rende l’intervallo una decisione anziché una congettura. Dà anche al rollback qualcosa di concreto da ripristinare.

Aggiungete nopool e dichiarate l’intervallo

La parola chiave di aiuto accetta nopool, che conserva la configurazione della sottorete e sopprime il pool dinamico automatico, come descrive il manuale di OpenVPN 2.6. La riga esplicita ifconfig-pool fornisce poi l’intervallo inclusivo desiderato, e la sua maschera di rete corrisponde alla sottorete. Entrambe le righe appartengono allo stesso blocco server, perché un pool senza la sua sottorete non ha significato. L’ordine tra loro conta solo per la leggibilità, dato che l’helper espande la coppia all’avvio del servizio.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Entrambi i limiti sono inclusivi, quindi l’esempio offre settantuno indirizzi. Tenete l’indirizzo del server e ogni assegnazione fissa fuori da quell’intervallo; un’assegnazione fissa che cade dentro l’intervallo dinamico produce una collisione che dipende dall’ordine di connessione, ed è il tipo peggiore da diagnosticare. Lasciate un margine tra l’insieme riservato e l’intervallo se le assegnazioni fisse è probabile che crescano.

La dimensione dell’intervallo e la concorrenza sono limiti separati. Cento indirizzi non significano cento client simultanei se max-clients dice il contrario, e un pool più grande del limite di concorrenza è normale anziché uno spreco. L’importante è che i due limiti siano scelti deliberatamente invece di essere ereditati da un valore predefinito.

Tenete le assegnazioni fisse fuori dall’intervallo dinamico

Un ifconfig-push specifico per client è un meccanismo diverso dall’assegnazione dal pool e deve usare parametri adatti alla topologia attiva. In modalità sottorete è un solo indirizzo e una maschera di rete; riportare una coppia net30 perché compariva in un vecchio esempio è un errore frequente.

La cronologia delle assegnazioni è un indizio, non un’autorità. Un file persist ricorda quale client aveva quale indirizzo, così i client che si riconnettono tendono a ricevere lo stesso, e non riserva indirizzi, non li libera e non sostituisce un’assegnazione fissa. Se un dispositivo specifico deve tenere sempre un indirizzo specifico, usate un’assegnazione fissa invece di affidarvi al file persist.

Poi controllate i percorsi che dipendono dagli indirizzi. Una rotta inviata ai client, una regola del firewall che ammette una sottorete o un controllo di monitoraggio che si aspetta un host particolare possono tutti presupporre il vecchio intervallo. Cambiare il pool senza leggerli sposta il guasto in un punto che sembra non correlato.

Applicate tramite il ciclo di vita, poi verificate

Applicate la modifica come il servizio riceve di norma la configurazione, che sia un file diretto più un riavvio o uno strato di gestione che rigenera il file. Una modifica manuale a un file generato sopravvive fino alla generazione successiva, e non oltre. Registrate quale meccanismo possiede il file, perché l’operatore successivo dovrà sapere dove fare la stessa modifica. Poi riavviate una volta e leggete il registro prima di invitare un client.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Collegate un client che non si era mai connesso e confermate che l’indirizzo cade dentro l’intervallo dichiarato e fuori dall’insieme riservato. Poi confermate il percorso di ritorno: il client deve raggiungere ciò che la politica consente e nulla di più. Un indirizzo che corrisponde al piano ma non ha una rotta funzionante non è una modifica riuscita.

Ricollegate un client che deteneva un indirizzo del vecchio intervallo. Dovrebbe ricevere un indirizzo dal nuovo intervallo, e qualsiasi stato a livello di sessione legato al vecchio indirizzo dovrebbe essere sparito. Se conserva il vecchio indirizzo, qualcos’altro glielo sta assegnando e il pool non è il proprietario che pensate.

Annullare una modifica dell’intervallo

Conservate le tre righe precedenti nel vostro registro delle modifiche, non solo il file precedente. Ripristinarle e riavviare riporta l’assegnazione al vecchio comportamento, e i client che si riconnettono dopo ne riceveranno gli indirizzi.

Due avvertenze appartengono al registro. I client già connessi quando fate il rollback mantengono gli indirizzi attuali finché non si riconnettono, quindi un rollback non è istantaneo su tutta la flotta. E se il vecchio intervallo si sovrapponeva a un’assegnazione fissa, ripristinarlo ripristina anche la collisione; proprio quella sovrapposizione era il motivo della modifica, e richiede una correzione diversa da un rollback.

Una modifica del pool è conclusa quando un client nuovo riceve un indirizzo dentro l’intervallo, un indirizzo riservato non viene mai distribuito e le rotte e regole che consumano quegli indirizzi continuano a comportarsi come previsto. Qualsiasi cosa in meno lascia alla persona successiva scoprire quale delle tre non è vera.