De ce un /24 OpenVPN rămâne fără clienți mai repede decât te aștepți

Pool-urile construite pe un /24 care încetează să mai accepte clienți în jurul valorii de șaizeci se comportă conform proiectării, nu lovesc o limită de licență. În net30 fiecare client primește o legătură virtuală punct-la-punct care consumă patru adrese, așa că o subrețea de 256 de adrese susține cam un sfert din ce sugerează prefixul. Numărul care contează sunt alocările, nu adresele. Citirea prefixului ca număr de clienți este greșeala care duce la căutarea unei limite ascunse de utilizatori.

Două topologii, două modele aritmetice și doar unul dintre ele se potrivește cu prefixul pe care oamenii îl presupun.

net30 consumă patru adrese pe client

net30 alocă un bloc /30 pe client, pentru că fiecare sesiune este modelată ca o legătură punct-la-punct cu o adresă la fiecare capăt. În acel bloc intră patru adrese și două sunt utilizabile, motiv pentru care numărul efectiv de clienți este un sfert din subrețea. Pe un /24 asta lasă 64 de blocuri înainte să iasă blocul propriu al serverului și orice alocări fixe. Un plafon raportat în jur de 63 este aritmetică ce iese la iveală, nu un maxim configurat.

Și serverul are nevoie de propria alocare, iar intrările statice de client consumă blocuri indiferent dacă acei clienți se conectează sau nu. Ambele reduc intervalul dinamic fără a schimba prefixul cu care ai început.

Limitele pool-ului contează mai mult decât prefixul

Directiva de server poate defini un pool mai îngust decât subrețeaua pe care o numește, iar un script auxiliar se poate extinde în setări suplimentare care nu sunt vizibile în profilul deschis. Adresele fixe dintr-un director client-config stau în acel interval și nu pot fi date de două ori. Prefixul descrie spațiul maxim posibil; pool-ul efectiv este ceea ce configurația aflată în rulare oferă de fapt.

Compară cele două înainte de a trage vreo concluzie despre capacitate, pentru că un interval configurat mai mic explică plafonul la fel de bine ca topologia.

Găsește limita care a refuzat de fapt clientul

Citește mai întâi topologia și pool-ul efectiv, apoi ia în calcul alocările fixe și adresele rezervate. Înainte să dai vina pe spațiul de adrese, verifică max-clients și orice control de admitere din afara OpenVPN. La final, compară mesajul propriu al serverului din momentul refuzului cu acei candidați. Mesajul numește constrângerea; numărul doar îngustează câmpul.

Un refuz care vine cu o eroare de concurență și un refuz care vine cu o eroare de alocare au remedii diferite, iar ghicitul între ele risipește o fereastră de mentenanță.

Schimbarea topologiei schimbă planul de adrese

Trecerea la topologia de subrețea îi dă fiecărui client o adresă în loc de un bloc, ceea ce este mișcarea corectă atunci când prefixul este cu adevărat prea mic. Schimbă și ce înseamnă parametrii de adresă ai clientului, așa că fiecare alocare fixată și fiecare fișier specific clientului trebuie rederivat, nu renumerotat manual. Planifică noul interval, migrează intrările statice și actualizează rutele care le referă.

Trecerea nu este un sinonim pentru configurația veche. Tratează-o ca o schimbare de plan de adrese cu propria revizuire și așteaptă-te ca cel puțin un client să păstreze o adresă din schema anterioară.

Dimensionează pool-ul din plan, nu din mască

Alege dimensiunea din numărul de clienți simultani plus spațiu liber pentru reconectări și teste, apoi alege cel mai mic prefix care îl acoperă în topologia aleasă. Lărgirea la un /16 pentru a rezolva un plafon de șaizeci de clienți schimbă o problemă de capacitate pe una de rutare și suprapunere, pentru că un interval privat mai mare are șanse mai mari să se ciocnească de ceva ce clientul atinge deja.

Documentează împreună topologia, pool-ul, alocările fixe și plafonul de clienți rezultat. Următoarea întrebare de capacitate devine atunci aritmetică în loc de investigație.