Waarom ’n OpenVPN /24 gouer kliënte opraak as wat jy verwag

Poelle wat op ’n /24 gebou is en omtrent ses- en sestig kliënte ophou aanvaar, werk soos ontwerp en tref nie ’n lisensiegrens nie. Onder net30 kry elke kliënt ’n virtuele punt-tot-punt-skakel wat vier adresse verbruik, so ’n subnet van 256 adresse ondersteun ongeveer ’n kwart van wat die voorvoegsel voorstel. Die getal wat saak maak, is toekennings, nie adresse nie. Om die voorvoegsel as kliëntgetal te lees, is die fout wat ’n soektog na ’n verborge gebruikerlimiet veroorsaak.

Twee topologieë, twee rekenmodelle, en net een van hulle pas by die voorvoegsel wat mense aanvaar.

net30 spandeer vier adresse per kliënt

net30 ken ’n /30-blok per kliënt toe, omdat elke sessie as ’n punt-tot-punt-skakel met ’n adres aan elke kant gemodelleer word. Vier adresse gaan in daardie blok in en twee is bruikbaar, daarom is die effektiewe kliëntgetal ’n kwart van die subnet. Op ’n /24 laat dit 64 blokke oor voordat die bediener se eie blok en enige vaste toekennings uitgekom het. ’n Gerapporteerde plafon naby 63 is rekenkunde wat deurskyn, nie ’n gekonfigureerde maksimum nie.

Die bediener het ook sy eie toekenning nodig, en statiese kliëntinskrywings verbruik blokke ongeag of daardie kliënte konnekteer. Albei verminder die dinamiese bereik sonder om die voorvoegsel waarmee jy begin het, te verander.

Die poelgrense maak meer saak as die voorvoegsel

Die bedienerdirektief kan ’n poel definieer wat smaller is as die subnet wat dit noem, en ’n hulpskrip kan uitbrei na bykomende instellings wat nie in die profiel sigbaar is wat jy oopgemaak het nie. Vaste adresse uit ’n client-config-gids lê binne daardie reeks en kan nie twee keer uitgedeel word nie. Die voorvoegsel beskryf die maksimum moontlike ruimte; die effektiewe poel is wat die lopende konfigurasie werklik bied.

Vergelyk die twee voordat jy enigiets oor kapasiteit aflei, want ’n kleiner gekonfigureerde reeks verklaar die plafon net so goed soos die topologie.

Vind die limiet wat die kliënt werklik geweier het

Lees eers die topologie en die effektiewe poel, en verreken dan vaste toekennings en gereserveerde adresse. Kyk ook na max-clients en enige toegangsbeheer buite OpenVPN voordat jy die adresruimte blameer. Pas laastens die bediener se eie boodskap op die oomblik van weiering by daardie kandidate. Die boodskap noem die beperking; die getal vernou net die veld.

’n Weiering wat met ’n gelyktydigheidsfout opdaag en ’n weiering wat met ’n toekenningsfout opdaag, het verskillende oplossings, en om tussen hulle te raai mors ’n onderhoudsvenster.

Om die topologie te verander, verander die adresplan

Om na subnet-topologie oor te skakel gee elke kliënt een adres in plaas van ’n blok, wat die regte skuif is wanneer die voorvoegsel werklik te klein is. Dit verander ook wat die kliëntadresparameters beteken, so elke vasgepende toekenning en elke kliëntspesifieke lêer moet herlei word eerder as om met die hand hernommer te word. Beplan die nuwe reeks, migreer die statiese inskrywings en werk die roetes by wat daarna verwys.

Die oorskakeling is nie ’n sinoniem vir die ou konfigurasie nie. Behandel dit as ’n adresplanverandering met sy eie hersiening, en verwag dat ten minste een kliënt ’n adres uit die vorige skema sal hê.

Bepaal die poelgrootte uit die plan, nie uit die masker nie

Kies die grootte op grond van die aantal gelyktydige kliënte plus ruimte vir herverbindings en toetsing, en kies dan die kleinste voorvoegsel wat dit onder die gekose topologie dek. Om na ’n /16 te verbreed om ’n plafon van sestig kliënte op te los, ruil ’n kapasiteitsprobleem vir ’n roeterings- en oorvleuelingsprobleem, want ’n groter private reeks bots makliker met iets wat die kliënt reeds bereik.

Dokumenteer die topologie, die poel, die vaste toekennings en die gevolglike kliëntplafon saam. Die volgende kapasiteitsvraag is dan rekenkunde in plaas van ’n ondersoek.