Pooler bygget på et /24, der holder op med at acceptere klienter omkring de tres, opfører sig som designet og rammer ikke en licensgrænse. Under net30 får hver klient et virtuelt punkt-til-punkt-link, der bruger fire adresser, så et subnet med 256 adresser understøtter cirka en fjerdedel af det, præfikset antyder. Det tal, der betyder noget, er tildelinger, ikke adresser. At læse præfikset som et klienttal er den fejl, der starter jagten på et skjult brugerloft.

To topologier, to regnemodeller, og kun én af dem passer til det præfiks, folk antager.

net30 bruger fire adresser per klient

net30 tildeler en /30-blok per klient, fordi hver session modelleres som et punkt-til-punkt-link med en adresse i hver ende. Fire adresser går ind i den blok, og to er brugbare, og derfor er det effektive klienttal en fjerdedel af subnettet. På et /24 efterlader det 64 blokke, før serverens egen blok og faste tildelinger kommer ud. Et rapporteret loft nær 63 er aritmetik, der skinner igennem, ikke et konfigureret maksimum.

Serveren skal også have sin egen tildeling, og statiske klientposter bruger blokke, uanset om de klienter forbinder. Begge dele reducerer det dynamiske interval uden at ændre det præfiks, du startede med.

Poolens grænser betyder mere end præfikset

Serverdirektivet kan definere en pool, der er smallere end det subnet, det navngiver, og et hjælpescript kan udvide til yderligere indstillinger, som ikke er synlige i den profil, du åbnede. Faste adresser fra en client-config-mappe ligger inden for det interval og kan ikke uddeles to gange. Præfikset beskriver det maksimalt mulige rum; den effektive pool er det, den kørende konfiguration faktisk tilbyder.

Sammenlign de to, før du konkluderer noget om kapacitet, for et mindre konfigureret interval forklarer loftet lige så godt som topologien.

Find den grænse, der faktisk afviste klienten

Læs topologien og den effektive pool først, og tag derefter højde for faste tildelinger og reserverede adresser. Se også på max-clients og enhver adgangskontrol uden for OpenVPN, før du giver adresserummet skylden. Til sidst skal du matche serverens egen besked i afvisningsøjeblikket med de kandidater. Beskeden navngiver begrænsningen; tallet indsnævrer kun feltet.

En afvisning, der kommer med en samtidighedsfejl, og en afvisning, der kommer med en tildelingsfejl, har forskellige løsninger, og at gætte mellem dem spilder et vedligeholdelsesvindue.

Ændring af topologi ændrer adresseplanen

Skift til subnet-topologi giver hver klient én adresse i stedet for en blok, hvilket er det rigtige træk, når præfikset virkelig er for lille. Det ændrer også, hvad klientadresseparametrene betyder, så hver fastgjort tildeling og hver klientspecifik fil skal udledes igen i stedet for at blive omnummereret manuelt. Planlæg det nye interval, migrer de statiske poster, og opdater de ruter, der henviser til dem.

Skiftet er ikke et synonym for den gamle konfiguration. Behandl det som en ændring af adresseplanen med sin egen gennemgang, og forvent, at mindst én klient beholder en adresse fra det tidligere skema.

Dimensioner poolen ud fra planen, ikke ud fra masken

Vælg størrelsen ud fra antallet af samtidige klienter plus plads til genforbindelser og test, og vælg derefter det mindste præfiks, der dækker det under den valgte topologi. At udvide til et /16 for at løse et loft på tres klienter bytter et kapacitetsproblem for et routing- og overlapningsproblem, fordi et større privat interval lettere støder sammen med noget, klienten allerede når.

Dokumentér topologien, poolen, de faste tildelinger og det resulterende klientloft sammen. Det næste kapacitetsspørgsmål er så aritmetik i stedet for en undersøgelse.

Relaterede artikler