Wêrom't in OpenVPN /24 earder troch klanten hinne is as jo ferwachtsje

Pools boud op in /24 dy't om de sechstich hinne gjin klanten mear oannimme, dogge wat se ûntwurpen binne en reitsje gjin lisinsjegrins. Under net30 kriget elke klant in firtuele punt-nei-punt-ferbining dy't fjouwer adressen brûkt, dus in subnet fan 256 adressen stipet sawat in fearn fan wat it foarheaksel suggerearret. It getal dat telt binne de taskenningen, net de adressen. It foarheaksel lêze as in klantental is de flater dy't in syktocht nei in ferburgen brûkerslimyt feroarsaket.

Twa topologyen, twa rekkenmodellen, en mar ien fan beide past by it foarheaksel dat minsken oannimme.

net30 brûkt fjouwer adressen per klant

net30 jout in /30-blok per klant, om't elke sesje modellearre wurdt as in punt-nei-punt-ferbining mei in adres oan elk ein. Fjouwer adressen geane yn dat blok en twa binne brûkber, dêrom is it effektive klantental in fearn fan it subnet. Op in /24 lit dat 64 blokken oer foardat it eigen blok fan de tsjinner en eventuele fêste taskenningen derút komme. In rapportearre plafond by 63 is rekkenjen dat trochskynt, net in konfigurearre maksimum.

De tsjinner hat ek syn eigen taskenning nedich, en statyske klantyngongen brûke blokken oft dy klanten no ferbine of net. Beide ferminderje it dynamyske berik sûnder it foarheaksel te feroarjen wêrmei't jo begûn binne.

De grinzen fan 'e pool binne wichtiger as it foarheaksel

De tsjinnerdirektive kin in pool definiearje dy't smeller is as it subnet dat it neamt, en in helpskript kin útwreidzje nei ekstra ynstellings dy't net yn it profyl te sjen binne dat jo iepene hawwe. Fêste adressen út in client-config-map sitte binnen dat berik en kinne net twa kear útjûn wurde. It foarheaksel beskriuwt de maksimaal mooglike romte; de effektive pool is wat de rinnende konfiguraasje eins biedt.

Fergelykje de beide foardat jo eat oer kapasiteit konkludearje, want in lytser konfigurearre berik ferklearret it plafond like goed as de topology.

Fyn de limyt dy't de klant echt wegere

Lês earst de topology en de effektive pool, hâld dan rekken mei fêste taskenningen en reservearre adressen. Kontrolearje ek max-clients en elk tagongsbehear bûten OpenVPN foardat jo de adresromte de skuld jouwe. Ferlykje ta beslút it berjocht fan de tsjinner sels op it momint fan 'e wegering mei dy kandidaten. It berjocht neamt de beheining; it getal beheint allinnich it fjild.

In wegering dy't komt mei in tagelykheidsflater en in wegering dy't komt mei in taskenningsflater hawwe ferskillende oplossings, en tusken beide riede fergriemt in ûnderhâldsfenster.

Topology feroarje feroaret it adresplan

Oerstap nei subnet-topology jout elke klant ien adres ynstee fan in blok, wat de goede set is as it foarheaksel echt te lyts is. It feroaret ek wat de klantadresparameters betsjutte, dus elke fêstsette taskenning en elk klantspecifyk bestân moat op 'e nij ôflaat wurde ynstee fan mei de hân oernûmere. Plan it nije berik, migrearje de statyske yngongen en bywurkje de rûtes dy't dernei ferwize.

De oerstap is gjin synonym foar de âlde konfiguraasje. Behannelje it as in feroaring fan it adresplan mei syn eigen beoardieling, en ferwachtsje dat teminsten ien klant in adres út it eardere skema hâldt.

Mjit de pool út it plan, net út it masker

Kies de grutte út it oantal tagelyk aktive klanten plus romte foar werferbiningen en testen, en nim dan it lytste foarheaksel dat dat ûnder de keazen topology dekt. Útwreidzje nei in /16 om in plafond fan sechstich klanten op te lossen ruilet in kapasiteitsprobleem foar in routing- en oerlaappobleem, om't in grutter privee berik earder botsing makket mei eat dat de klant al berikt.

Dokumintearje de topology, de pool, de fêste taskenningen en it resultearjende klantplafond tegearre. De folgjende kapasiteitsfraach is dan rekkenjen ynstee fan in ûndersyk.