Kvifor eit OpenVPN /24 går tom for klientar raskare enn du trur
Med net30 tek kvar klient ein /30, så eit /24 stoppar kring 64. Tel tildelingar, finn den faktiske avvisinga, og dimensjoner deretter poolen på nytt frå adresseplanen.
Poolar bygde på eit /24 som sluttar å ta imot klientar i sekstiåra, oppfører seg som designa og treff ikkje ei lisensgrense. Med net30 får kvar klient ei virtuell punkt-til-punkt-lenke som brukar fire adresser, så eit subnett med 256 adresser støttar omtrent ein fjerdedel av det prefikset antydar. Talet som tel er tildelingar, ikkje adresser. Å lese prefikset som eit klienttal er feilen som fører til leiting etter ei skjult brukargrense.
To topologiar, to aritmetiske modellar, og berre éin av dei passar med prefikset folk føreset.
net30 brukar fire adresser per klient
net30 tildeler ein /30-blokk per klient, fordi kvar økt vert modellert som ei punkt-til-punkt-lenke med ei adresse i kvar ende. Fire adresser går inn i den blokka og to er brukbare, og difor er det effektive klienttalet ein fjerdedel av subnettet. På eit /24 gjev det 64 blokker før serveren si eiga blokk og faste tildelingar kjem ut. Eit rapportert tak kring 63 er aritmetikk som syner seg, ikkje eit konfigurert maksimum.
Serveren treng også si eiga tildeling, og statiske klientoppføringar brukar blokker anten klientane koplar til eller ikkje. Begge reduserer det dynamiske området utan å endre prefikset du starta med.
Poolgrensene tyder meir enn prefikset
Serverdirektivet kan definere ein pool som er smalare enn subnettet det nemner, og eit hjelpeskript kan utvide til fleire innstillingar som ikkje er synlege i profilen du opna. Faste adresser frå ein client-config-katalog ligg innanfor det området og kan ikkje delast ut to gonger. Prefikset skildrar det maksimalt moglege rommet; den effektive poolen er det den køyrande konfigurasjonen faktisk tilbyr.
Samanlikn dei to før du konkluderer noko om kapasitet, fordi eit mindre konfigurert område forklarer taket like godt som topologien.
Finn grensa som faktisk avviste klienten
Les topologien og den effektive poolen først, og ta så omsyn til faste tildelingar og reserverte adresser. Før du gjev adresserommet skulda, sjekk max-clients og kvar opptakskontroll utanfor OpenVPN. Til slutt samanliknar du meldinga til serveren i avvisingsaugneblinken med desse kandidatane. Meldinga namngjev avgrensinga; talet snevrar berre inn feltet.
Ei avvising som kjem med ein samtidigheitsfeil og ei avvising som kjem med ein tildelingsfeil har ulike rettingar, og gjetting mellom dei sløser bort eit vedlikehaldsvindauge.
Byte av topologi endrar adresseplanen
Byte til subnettopologi gjev kvar klient éi adresse i staden for ein blokk, som er det rette trekket når prefikset verkeleg er for lite. Det endrar også kva klientadresseparametrane tyder, så kvar fastlåste tildeling og kvar klientspesifikk fil må utleiast på nytt i staden for å omnummererast for hand. Planlegg det nye området, flytt dei statiske oppføringane og oppdater rutene som viser til dei.
Byttet er ikkje eit synonym for den gamle konfigurasjonen. Handter det som ei endring av adresseplanen med si eiga vurdering, og rekn med at minst éin klient held på ei adresse frå den førre ordninga.
Dimensjoner poolen frå planen, ikkje frå maska
Vel storleiken ut frå talet på samtidige klientar pluss slingringsmonn for attkopling og testing, og vel så det minste prefikset som dekkjer det under den valde topologien. Å utvide til eit /16 for å løyse eit tak på seksti klientar byter eit kapasitetsproblem mot eit ruting- og overlappproblem, fordi eit større privat område lettare kolliderer med noko klienten alt når.
Dokumenter topologien, poolen, dei faste tildelingane og det resulterande klienttaket saman. Det neste kapasitetsspørsmålet er då aritmetikk i staden for ei gransking.