I pool costruiti su una /24 che smettono di accettare client intorno ai sessanta si comportano come previsto, non stanno raggiungendo un limite di licenza. Con net30 a ogni client viene assegnato un collegamento virtuale punto-punto che consuma quattro indirizzi, quindi una sottorete da 256 indirizzi ne supporta circa un quarto di quanto suggerisce il prefisso. Il numero che conta sono le allocazioni, non gli indirizzi. Leggere il prefisso come numero di client è l’errore che porta a cercare un tetto utenti nascosto.

Due topologie, due modelli aritmetici, e solo uno dei due corrisponde al prefisso che le persone danno per scontato.

net30 consuma quattro indirizzi per client

net30 assegna un blocco /30 per client, perché ogni sessione è modellata come un collegamento punto-punto con un indirizzo a ciascuna estremità. In quel blocco finiscono quattro indirizzi e due sono utilizzabili, ed è per questo che il numero effettivo di client è un quarto della sottorete. Su una /24 restano 64 blocchi prima che escano il blocco del server stesso e le eventuali assegnazioni fisse. Un tetto dichiarato intorno a 63 è aritmetica che si fa vedere, non un massimo configurato.

Anche il server ha bisogno della propria allocazione, e le voci statiche dei client consumano blocchi indipendentemente dal fatto che quei client si colleghino. Entrambe le cose riducono l’intervallo dinamico senza cambiare il prefisso da cui sei partito.

I confini del pool contano più del prefisso

La direttiva del server può definire un pool più stretto della sottorete che nomina, e uno script ausiliario può espandere in impostazioni aggiuntive che non sono visibili nel profilo che hai aperto. Gli indirizzi fissi di una directory client-config stanno dentro quell’intervallo e non possono essere assegnati due volte. Il prefisso descrive lo spazio massimo possibile; il pool effettivo è quello che la configurazione in esecuzione offre davvero.

Confronta i due prima di concludere qualcosa sulla capacità, perché un intervallo configurato più piccolo spiega il tetto altrettanto bene della topologia.

Trova il limite che ha davvero rifiutato il client

Leggi prima la topologia e il pool effettivo, poi tieni conto delle assegnazioni fisse e degli indirizzi riservati. Controlla max-clients e qualsiasi controllo di ammissione esterno a OpenVPN prima di dare la colpa allo spazio degli indirizzi. Infine confronta il messaggio del server al momento del rifiuto con quei candidati. Il messaggio nomina il vincolo; il conteggio restringe solo il campo.

Un rifiuto che arriva con un errore di concorrenza e un rifiuto che arriva con un errore di allocazione hanno correzioni diverse, e tirare a indovinare tra i due spreca una finestra di manutenzione.

Cambiare topologia cambia il piano degli indirizzi

Passare alla topologia subnet dà a ogni client un indirizzo invece di un blocco, che è la mossa giusta quando il prefisso è davvero troppo piccolo. Cambia anche il significato dei parametri di indirizzo del client, quindi ogni assegnazione fissata e ogni file specifico del client va ricalcolato invece che rinumerato a mano. Pianifica il nuovo intervallo, migra le voci statiche e aggiorna le route che vi fanno riferimento.

Il passaggio non è un sinonimo della vecchia configurazione. Trattalo come un cambio di piano degli indirizzi con la sua revisione, e aspettati almeno un client che conservi un indirizzo dello schema precedente.

Dimensiona il pool dal piano, non dalla maschera

Scegli la dimensione dal numero di client simultanei più un margine per riconnessioni e test, poi prendi il prefisso più piccolo che lo copre con la topologia scelta. Allargare a una /16 per risolvere un tetto di sessanta client scambia un problema di capacità con un problema di routing e sovrapposizione, perché un intervallo privato più grande ha più probabilità di scontrarsi con qualcosa che il client raggiunge già.

Documenta insieme la topologia, il pool, le assegnazioni fisse e il tetto client risultante. La prossima domanda di capacità diventa allora aritmetica invece che un’indagine.

Articoli correlati