Varför ett OpenVPN /24 tar slut på klienter tidigare än du tror

Pooler byggda på ett /24 som slutar ta emot klienter i sextiotalet beter sig som designat och träffar ingen licensgräns. Med net30 får varje klient en virtuell punkt-till-punkt-länk som förbrukar fyra adresser, så ett subnät med 256 adresser stöder ungefär en fjärdedel av vad prefixet antyder. Talet som räknas är tilldelningar, inte adresser. Att läsa prefixet som ett klientantal är felet som leder till jakten på en dold användargräns.

Två topologier, två aritmetiska modeller, och bara en av dem matchar prefixet folk antar.

net30 förbrukar fyra adresser per klient

net30 tilldelar ett /30-block per klient, eftersom varje session modelleras som en punkt-till-punkt-länk med en adress i varje ände. Fyra adresser går in i det blocket och två är användbara, vilket är varför det effektiva klientantalet är en fjärdedel av subnätet. På ett /24 lämnar det 64 block innan serverns eget block och fasta tilldelningar räknas bort. Ett rapporterat tak runt 63 är aritmetik som syns, inte ett konfigurerat maximum.

Servern behöver också sin egen tilldelning, och statiska klientposter förbrukar block oavsett om klienterna ansluter eller inte. Båda minskar det dynamiska intervallet utan att ändra prefixet du började med.

Poolgränserna spelar större roll än prefixet

Serverdirektivet kan definiera en pool som är snävare än subnätet det namnger, och ett hjälpskript kan expandera till extra inställningar som inte syns i profilen du öppnade. Fasta adresser från en client-config-katalog ligger inom det intervallet och kan inte delas ut två gånger. Prefixet beskriver det maximalt möjliga utrymmet; den effektiva poolen är det den körande konfigurationen faktiskt erbjuder.

Jämför de två innan du drar någon slutsats om kapacitet, eftersom ett mindre konfigurerat intervall förklarar taket lika bra som topologin.

Hitta gränsen som faktiskt avvisade klienten

Läs topologin och den effektiva poolen först och räkna sedan in fasta tilldelningar och reserverade adresser. Innan du skyller på adressutrymmet, kontrollera max-clients och all antagningskontroll utanför OpenVPN. Jämför till sist serverns eget meddelande i avvisningsögonblicket med de kandidaterna. Meddelandet namnger begränsningen; antalet snävar bara in fältet.

Ett avslag som kommer med ett samtidighetsfel och ett avslag som kommer med ett tilldelningsfel har olika åtgärder, och gissningar mellan dem slösar bort ett underhållsfönster.

Ett byte av topologi ändrar adressplanen

Byt till subnätstopologi ger varje klient en adress i stället för ett block, vilket är rätt drag när prefixet verkligen är för litet. Det ändrar också vad klientadressparametrarna betyder, så varje fastnålad tilldelning och varje klientspecifik fil måste härledas på nytt i stället för att numreras om för hand. Planera det nya intervallet, migrera de statiska posterna och uppdatera de rutter som hänvisar till dem.

Bytet är inte en synonym till den gamla konfigurationen. Behandla det som en ändring av adressplanen med egen granskning, och räkna med att minst en klient behåller en adress från det tidigare schemat.

Dimensionera poolen från planen, inte från masken

Välj storleken från antalet samtidiga klienter plus utrymme för återanslutningar och tester, och välj sedan det minsta prefix som täcker det under den valda topologin. Att bredda till ett /16 för att lösa ett tak på sextio klienter byter ett kapacitetsproblem mot ett routing- och överlappningsproblem, eftersom ett större privat intervall lättare krockar med något klienten redan når.

Dokumentera topologin, poolen, de fasta tilldelningarna och det resulterande klienttaket tillsammans. Nästa kapacitetsfråga blir då aritmetik i stället för en utredning.