Pooler bygget på et /24 som slutter å ta imot klienter i sekstiårene, oppfører seg som designet og treffer ikke en lisensgrense. Med net30 får hver klient en virtuell punkt-til-punkt-lenke som bruker fire adresser, så et subnett med 256 adresser støtter omtrent en fjerdedel av det prefikset antyder. Tallet som betyr noe er tildelinger, ikke adresser. Å lese prefikset som et klienttall er feilen som fører til leting etter en skjult brukergrense.

To topologier, to aritmetiske modeller, og bare én av dem passer med prefikset folk antar.

net30 bruker fire adresser per klient

net30 tildeler en /30-blokk per klient, fordi hver økt modelleres som en punkt-til-punkt-lenke med en adresse i hver ende. Fire adresser går inn i den blokken og to er brukbare, og derfor er det effektive klienttallet en fjerdedel av subnettet. På et /24 gir det 64 blokker før serverens egen blokk og faste tildelinger kommer ut. Et rapportert tak rundt 63 er aritmetikk som synes, ikke et konfigurert maksimum.

Serveren trenger også sin egen tildeling, og statiske klientoppføringer bruker blokker enten klientene kobler til eller ikke. Begge reduserer det dynamiske området uten å endre prefikset du startet med.

Poolgrensene betyr mer enn prefikset

Serverdirektivet kan definere en pool som er smalere enn subnettet det nevner, og et hjelpeskript kan utvide til flere innstillinger som ikke er synlige i profilen du åpnet. Faste adresser fra en client-config-katalog ligger innenfor det området og kan ikke deles ut to ganger. Prefikset beskriver det maksimalt mulige rommet; den effektive poolen er det den kjørende konfigurasjonen faktisk tilbyr.

Sammenlign de to før du konkluderer noe om kapasitet, fordi et mindre konfigurert område forklarer taket like godt som topologien.

Finn grensen som faktisk avviste klienten

Les topologien og den effektive poolen først, og ta deretter hensyn til faste tildelinger og reserverte adresser. Før du gir adresserommet skylden, sjekk max-clients og enhver opptakskontroll utenfor OpenVPN. Til slutt sammenligner du serverens egen melding i avvisningsøyeblikket med disse kandidatene. Meldingen navngir begrensningen; tallet snevrer bare inn feltet.

En avvisning som kommer med en samtidighetsfeil og en avvisning som kommer med en tildelingsfeil har forskjellige rettelser, og gjetting mellom dem sløser bort et vedlikeholdsvindu.

Å bytte topologi endrer adresseplanen

Bytte til subnettopologi gir hver klient én adresse i stedet for en blokk, som er det riktige trekket når prefikset virkelig er for lite. Det endrer også hva klientadresseparameterne betyr, så hver fastlåste tildeling og hver klientspesifikk fil må utledes på nytt i stedet for å omnummereres for hånd. Planlegg det nye området, flytt de statiske oppføringene og oppdater rutene som refererer til dem.

Byttet er ikke et synonym for den gamle konfigurasjonen. Behandle det som en endring av adresseplanen med sin egen gjennomgang, og forvent at minst én klient beholder en adresse fra den forrige ordningen.

Dimensjoner poolen fra planen, ikke fra masken

Velg størrelsen fra antall samtidige klienter pluss slingringsmonn for gjenoppkoblinger og testing, og velg deretter det minste prefikset som dekker det under den valgte topologien. Å utvide til et /16 for å løse et tak på seksti klienter bytter et kapasitetsproblem mot et ruting- og overlappproblem, fordi et større privat område lettere kolliderer med noe klienten allerede når.

Dokumenter topologien, poolen, de faste tildelingene og det resulterende klienttaket sammen. Det neste kapasitetsspørsmålet er da aritmetikk i stedet for en undersøkelse.

Relaterte artikler