Gli indirizzi stabili di OpenVPN devono seguire l’identità, non l’IP di origine

I piani di indirizzamento che dicono «questo portatile riceve 10.90.0.10» sono in realtà affermazioni sull’identità: quale dispositivo autenticato può detenere quell’indirizzo. L’IP pubblico attuale di quel dispositivo non c’entra quasi nulla, perché NAT e roaming lo cambiano senza cambiare chi è l’utente. Costruire il piano sull’indirizzo di origine produce regole che si rompono sulla prima rete d’albergo. Costruirlo sull’identità autenticata produce un piano che sopravvive ai viaggi.

Parti da ciò che il server può verificare, poi decidi a cosa serve l’indirizzo.

Scegli la chiave d’identità prima dell’indirizzo

Un certificato client separato per dispositivo dà al server una chiave stabile e verificabile per ogni membro, che è la base più pulita per un’assegnazione statica. Un’implementazione con autenticazione per utente può invece basarsi sul nome utente, purché la selezione della configurazione segua lo stesso campo. Mescolare i due modelli produce assegnazioni che corrispondono a un certificato per un client e a un nome utente per un altro, e nessuno può prevedere quale vincerà. Decidi quale chiave usa il piano prima di scrivere anche una sola prenotazione.

Con duplicate-cn, più sessioni simultanee possono presentare lo stesso nome comune, quindi un indirizzo fissato non può identificarle singolarmente. È una proprietà del modello d’identità, non qualcosa che un piano di indirizzamento migliore possa correggere.

Prenota indirizzi fuori dall’intervallo dinamico

In una rete con topologia a sottorete come 10.90.0.0/24, tieni gli indirizzi bassi per i membri nominati e metti il pool dinamico in un intervallo disgiunto. Un’assegnazione per un membro fissato appare così ifconfig-push 10.90.0.10 255.255.255.0 nel file che il server seleziona per quell’identità. Il secondo argomento significa qualcosa di diverso con net30, quindi l’esempio non è neutro rispetto alla topologia. Leggi la topologia prima di copiarlo.

La persistenza del pool registra i lease recenti e tende a restituire lo stesso indirizzo, il che è una comodità e non una prenotazione. Non lasciare che il file di persistenza diventi il registro di proprietà, perché cambia con la cronologia delle connessioni e non con la politica.

La precedenza dell’assegnazione decide chi vince

Il manuale documenta un ordine: un’assegnazione esplicita generata durante client-connect può avere effetto prima di una voce client-config-dir, che a sua volta precede l’assegnazione ordinaria dal pool. Questo ordine spiega la maggior parte dei rapporti «l’indirizzo fissato non è stato applicato». Significa anche che un allocatore dinamico che scrive configurazione per sessione può sovrascrivere silenziosamente un file statico che credevi autorevole.

Scegli un solo strato che possieda le assegnazioni e rendi gli altri in sola lettura. Due strati che entrambi pretendono di decidere producono assegnazioni che dipendono dal momento.

Un allocatore dinamico ha bisogno dello stesso modello

Un’integrazione client-connect che distribuisce indirizzi per sessione è un piccolo allocatore con i soliti problemi degli allocatori. Deve validare l’identità richiedente, prenotare un indirizzo in modo atomico, emettere solo l’output per connessione supportato e rilasciare la prenotazione alla disconnessione o in caso di errore. Le richieste concorrenti necessitano di un lock o di un vincolo di database, non di una sequenza leggi-poi-scrivi. Senza pulizia, il pool perde indirizzi fino al riavvio.

Tieni lo stato dell’allocatore dove l’operatore successivo può leggerlo e registra la decisione identità-a-indirizzo, non solo l’indirizzo.

Decidi se l’indirizzo è politica o comodità

Se una regola del firewall o una rotta consente traffico da un indirizzo del tunnel, allora l’indirizzo partecipa alla politica di accesso e una riassegnazione eredita quel permesso. Coordina il ciclo di vita di identità, indirizzo e firewall, oppure lega la regola a qualcosa che non può essere riassegnato. L’indirizzamento stabile rende leggibile la configurazione; non sostituisce l’autenticazione.

Scrivi il piano come inventario con un proprietario per voce, poi riesaminalo quando un dispositivo viene ritirato. La prenotazione inutilizzata è quella che viene riutilizzata per errore.