Quale indirizzo assegnerà il pool alla prossima riconnessione?
Gli indirizzi del pool seguono un ordine non casuale: prima l’indirizzo memorizzato, poi quello libero usato meno di recente. Leggilo prima di fissare una regola.
Una regola che ieri corrispondeva oggi non corrisponde più, perché il client è tornato con un altro indirizzo del tunnel. L’allocatore però non è casuale, e conoscere il suo ordine trasforma quella sorpresa in un evento prevedibile. Preferisce l’indirizzo che lo stesso client aveva prima, ripiega su quello libero usato meno di recente e dimentica tutto se non gli dai un posto in cui ricordare. Le regole che presuppongono un lease continuano a corrispondere fino al giorno in cui smettono silenziosamente di farlo.
L’ordine che segue l’allocatore
Con una sessione per common name, l’allocatore cerca prima un indirizzo che lo stesso client ha usato in precedenza e che al momento è libero. Se quell’indirizzo è sparito, prende l’indirizzo libero rimasto inattivo più a lungo. Con le sessioni simultanee abilitate per lo stesso nome, la preferenza per l’indirizzo precedente non vale e viene usato invece il primo indirizzo libero, perché le sessioni sono trattate come peer separati.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
Ne derivano subito due conseguenze. Un client che si riconnette in fretta di solito mantiene il suo indirizzo, ed è per questo che nessuno nota il meccanismo finché non cambia. E un altro dispositivo che si connette in quella piccola finestra può prendere l’indirizzo mentre è brevemente libero, dopodiché il primo client riceve qualcos’altro e ogni regola legata al vecchio numero è sbagliata. Nessuno dei due eventi produce una riga di log che sembri un guasto.
Perché un lease sembra stabile e poi si sposta
La stabilità qui è una proprietà emergente delle riconnessioni che arrivano prima che qualcun altro rivendichi l’indirizzo. Non è una promessa, e non viene imposta mentre il client è disconnesso. Pianifica che l’indirizzo cambi invece di esserne sorpreso. Un pool appena più grande del numero di dispositivi rende le collisioni normali, perché il ripiego sull’indirizzo usato meno di recente non ha quasi nulla tra cui scegliere.
La concorrenza di picco è il numero su cui dimensionare, non il numero di utenti. Chi prova da due dispositivi insieme, o un client che si riconnette prima che la vecchia sessione scada, occupa due lease per un po’. Un pool dimensionato solo sul numero di persone produrrà esattamente quel ricambio che le persone imputano al server.
Il file di persistenza ricorda, non prenota
Un indirizzo che sopravvive al riavvio del servizio richiede un file di persistenza. Salva il nome del client e l’indirizzo allo spegnimento e li rilegge all’avvio del servizio, ed è per questo che un riavvio pianificato non rimescola più tutte le regole che hai scritto.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Quello che non fa è trattenere l’indirizzo mentre il client è assente. In quel vuoto l’allocatore è libero di dare il numero a qualcun altro, e il file registra allora una preferenza obsoleta che la connessione successiva non può onorare. Trattalo come un suggerimento che migliora il comportamento al riavvio, non come indirizzamento statico.
Controlla il pool rispetto a ogni subnet instradata mentre sei nel file. Un intervallo sovrapposto assegna indirizzi a cui il server non può instradare, e il sintomo è un client che si connette, riceve un indirizzo e non raggiunge nulla.
Fissare un indirizzo nel modo giusto
Quando una regola del firewall o un record DNS ha davvero bisogno di un indirizzo fisso, assegnalo invece di sperarci. Una voce di configurazione per client può inviare direttamente indirizzo e maschera, e quella voce è indicizzata sul nome effettivo del client.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Tieni gli indirizzi fissi fuori dal pool dinamico, così l’allocatore non assegna mai lo stesso numero a un’altra sessione. Poi controlla la topologia del tunnel, perché cambia quanti indirizzi del pool consuma ogni client: la vecchia disposizione punto a punto consuma un piccolo blocco per client, mentre una disposizione a subnet usa un indirizzo ciascuno. Un pool che sembra generoso con una topologia può essere insufficiente con l’altra.
Conferma il risultato sul client invece di fidarti della contabilità del server. Una volta tornata la sessione, guarda l’indirizzo dell’interfaccia e la rotta inviata, perché un log sul server può riportare l’indirizzo richiesto mentre l’interfaccia ne detiene un altro.
L’indirizzo remoto è una questione separata
L’indirizzo nella riga remote del client deve essere raggiungibile prima che esista un tunnel. Metterci un indirizzo del pool, come l’endpoint del tunnel del server stesso, significa che il client prova a raggiungere l’endpoint attraverso un tunnel che non ha ancora costruito, e il risultato è un loop o un timeout silenzioso invece di una scorciatoia.
Usa l’endpoint pubblico fornito dall’operatore e tieni il pool per ciò per cui è pensato: indirizzi dentro il tunnel. Annotare l’intervallo del pool, le assegnazioni fisse e il percorso di persistenza in un unico posto risparmia alla persona successiva di trattare ogni lease come arbitrario.