Miksi OpenVPN /24 loppuu kesken asiakkaista odotettua aiemmin

/24:n päälle rakennetut poolit, jotka lakkaavat hyväksymästä asiakkaita kuudenkymmenen tienoilla, toimivat suunnitellusti eivätkä osu lisenssirajaan. net30:ssä jokainen asiakas saa virtuaalisen piste-piste-yhteyden, joka kuluttaa neljä osoitetta, joten 256 osoitteen aliverkko tukee noin neljäsosaa siitä, mitä etuliite antaa ymmärtää. Merkitsevä luku on varaukset, ei osoitteet. Etuliitteen lukeminen asiakasmääränä on se virhe, joka käynnistää etsinnän piilotetusta käyttäjärajasta.

Kaksi topologiaa, kaksi laskentamallia, ja vain yksi niistä vastaa sitä etuliitettä, jota ihmiset olettavat.

net30 kuluttaa neljä osoitetta asiakasta kohden

net30 varaa /30-lohkon asiakasta kohden, koska jokainen istunto mallinnetaan piste-piste-yhteydeksi, jonka molemmissa päissä on osoite. Lohkoon menee neljä osoitetta ja kaksi on käytettävissä, minkä vuoksi tehokas asiakasmäärä on neljäsosa aliverkosta. /24:ssä se jättää 64 lohkoa ennen kuin palvelimen oma lohko ja mahdolliset kiinteät varaukset tulevat ulos. Raportoitu katto lähellä 63:aa on läpi näkyvää aritmetiikkaa, ei määritetty maksimi.

Palvelin tarvitsee myös oman varauksensa, ja staattiset asiakastietueet kuluttavat lohkoja riippumatta siitä, yhdistävätkö ne asiakkaat. Molemmat pienentävät dynaamista aluetta muuttamatta etuliitettä, jolla aloitit.

Poolin rajat merkitsevät enemmän kuin etuliite

Palvelindirektiivi voi määritellä poolin, joka on kapeampi kuin sen nimeämä aliverkko, ja apuskripti voi laajentua lisäasetuksiin, jotka eivät näy avaamassasi profiilissa. client-config-hakemiston kiinteät osoitteet ovat tuon alueen sisällä eikä niitä voi jakaa kahdesti. Etuliite kuvaa suurimman mahdollisen tilan; tehokas pool on se, mitä käynnissä oleva kokoonpano todella tarjoaa.

Vertaa näitä kahta ennen kuin päättelet kapasiteetista mitään, sillä pienempi määritetty alue selittää katon yhtä hyvin kuin topologia.

Löydä raja, joka todella hylkäsi asiakkaan

Lue ensin topologia ja tehokas pool, sitten huomioi kiinteät varaukset ja varatut osoitteet. Tarkista myös max-clients ja kaikki OpenVPN:n ulkopuolinen pääsynvalvonta ennen kuin syytät osoiteavaruutta. Vertaa lopuksi palvelimen omaa viestiä hylkäyshetkellä näihin ehdokkaisiin. Viesti nimeää rajoitteen; luku vain kaventaa kenttää.

Hylkäys, joka tulee samanaikaisuusvirheen kanssa, ja hylkäys, joka tulee varausvirheen kanssa, tarvitsevat eri korjaukset, ja niiden välillä arvaaminen tuhlaa huoltokatkon.

Topologian vaihtaminen muuttaa osoitesuunnitelmaa

Siirtyminen aliverkkotopologiaan antaa jokaiselle asiakkaalle yhden osoitteen lohkon sijaan, mikä on oikea siirto, kun etuliite on todella liian pieni. Se muuttaa myös asiakkaan osoiteparametrien merkitystä, joten jokainen kiinnitetty varaus ja jokainen asiakaskohtainen tiedosto on johdettava uudelleen eikä numeroitava käsin uudelleen. Suunnittele uusi alue, siirrä staattiset tietueet ja päivitä reitit, jotka viittaavat niihin.

Vaihto ei ole vanhan kokoonpanon synonyymi. Käsittele sitä osoitesuunnitelman muutoksena, jolla on oma tarkastuksensa, ja odota, että ainakin yksi asiakas pitää osoitteen aiemmasta mallista.

Mitoita pool suunnitelman, älä maskin mukaan

Valitse koko samanaikaisten asiakkaiden määrästä plus uudelleenyhdistämisille ja testaukselle varattu tila ja valitse sitten pienin etuliite, joka kattaa sen valitussa topologiassa. /16:een laajentaminen kuudenkymmenen asiakkaan katoksi vaihtaa kapasiteettiongelman reititys- ja päällekkäisyysongelmaan, koska suurempi yksityinen alue osuu todennäköisemmin johonkin, mihin asiakas jo yltää.

Dokumentoi topologia, pool, kiinteät varaukset ja niistä seuraava asiakaskatto yhdessä. Seuraava kapasiteettikysymys on silloin aritmetiikkaa tutkinnan sijaan.