Waarom een OpenVPN /24 eerder door zijn clients heen is dan je verwacht

Pools op een /24 die rond de zestig geen clients meer aannemen, gedragen zich zoals ontworpen en raken geen licentielimiet. Onder net30 krijgt elke client een virtuele point-to-point-verbinding die vier adressen verbruikt, dus een subnet van 256 adressen ondersteunt ongeveer een kwart van wat het prefix suggereert. Het getal dat telt is toewijzingen, niet adressen. Het prefix als clientaantal lezen is de fout die een zoektocht naar een verborgen gebruikerslimiet oplevert.

Twee topologieën, twee rekenmodellen, en slechts één ervan past bij het prefix dat mensen aannemen.

net30 gebruikt vier adressen per client

net30 wijst per client een /30-blok toe, omdat elke sessie als point-to-point-verbinding met een adres aan elk uiteinde wordt gemodelleerd. In dat blok gaan vier adressen en twee zijn bruikbaar, waardoor het effectieve clientaantal een kwart van het subnet is. Op een /24 blijven er 64 blokken over voordat het eigen blok van de server en vaste toewijzingen eruit gaan. Een gemeld plafond rond 63 is rekenwerk dat zichtbaar wordt, geen geconfigureerd maximum.

De server heeft ook zijn eigen toewijzing nodig, en statische clientregels verbruiken blokken of die clients nu verbinden of niet. Beide verkleinen het dynamische bereik zonder het prefix te veranderen waarmee je begon.

De poolgrenzen zijn belangrijker dan het prefix

De serverrichtlijn kan een pool definiëren die smaller is dan het subnet dat hij noemt, en een hulpscript kan uitbreiden naar extra instellingen die niet zichtbaar zijn in het profiel dat je opende. Vaste adressen uit een client-config-map liggen binnen dat bereik en kunnen niet twee keer worden uitgegeven. Het prefix beschrijft de maximaal mogelijke ruimte; de effectieve pool is wat de draaiende configuratie feitelijk biedt.

Vergelijk de twee voordat je iets over capaciteit concludeert, want een kleiner geconfigureerd bereik verklaart het plafond net zo goed als de topologie.

Vind de limiet die de client daadwerkelijk weigerde

Lees eerst de topologie en de effectieve pool, en reken dan vaste toewijzingen en gereserveerde adressen mee. Controleer max-clients en elke toelatingscontrole buiten OpenVPN voordat je de adresruimte de schuld geeft. Vergelijk tot slot het eigen bericht van de server op het moment van weigering met die kandidaten. Het bericht noemt de beperking; het aantal vernauwt alleen het veld.

Een weigering met een gelijktijdigheidsfout en een weigering met een toewijzingsfout hebben verschillende oplossingen, en gokken tussen beide kost een onderhoudsvenster.

Een andere topologie verandert het adresplan

Overstappen op subnettopologie geeft elke client één adres in plaats van een blok, wat de juiste stap is wanneer het prefix echt te klein is. Het verandert ook de betekenis van de clientadresparameters, dus elke vastgezette toewijzing en elk clientspecifiek bestand moet opnieuw worden afgeleid in plaats van met de hand hernummerd. Plan het nieuwe bereik, migreer de statische regels en werk de routes bij die ernaar verwijzen.

De overstap is geen synoniem voor de oude configuratie. Behandel het als een wijziging van het adresplan met een eigen beoordeling, en verwacht dat minstens één client een adres uit het vorige schema houdt.

Bepaal de poolgrootte uit het plan, niet uit het masker

Kies de grootte op basis van het aantal gelijktijdige clients plus ruimte voor herverbindingen en tests, en neem daarna het kleinste prefix dat dat onder de gekozen topologie dekt. Uitbreiden naar een /16 om een plafond van zestig clients op te lossen, ruilt een capaciteitsprobleem in voor een routerings- en overlapprobleem, omdat een groter privébereik eerder botst met iets dat de client al bereikt.

Documenteer de topologie, de pool, de vaste toewijzingen en het resulterende clientplafond samen. De volgende capaciteitsvraag is dan rekenwerk in plaats van een onderzoek.