Miért fogy el az OpenVPN /24 ügyfelekkel hamarabb, mint gondolná

A /24-re épülő poolok, amelyek hatvan körül felhagynak az ügyfelek fogadásával, a tervezés szerint viselkednek, és nem licenckorlátba ütköznek. net30 alatt minden ügyfél egy virtuális pont-pont kapcsolatot kap, amely négy címet használ el, így egy 256 címes alhálózat nagyjából a negyedét támogatja annak, amit az előtag sugall. A szám, ami számít, a kiosztás, nem a címek. Az előtagot ügyfélszámként olvasni az a hiba, amely elindítja a rejtett felhasználói korlát keresését.

Két topológia, két számítási modell, és csak az egyik felel meg annak az előtagnak, amelyet az emberek feltételeznek.

net30 ügyfelenként négy címet használ el

net30 ügyfelenként egy /30-as blokkot oszt ki, mert minden munkamenetet pont-pont kapcsolatként modelleznek, mindkét végén egy címmel. Négy cím kerül abba a blokkba, és kettő használható, ezért a tényleges ügyfélszám az alhálózat negyede. Egy /24-en ez 64 blokkot hagy, mielőtt a kiszolgáló saját blokkja és bármilyen rögzített kiosztás kikerül. A 63 körül jelentett plafon átszűrődő aritmetika, nem beállított maximum.

A kiszolgálónak is szüksége van saját kiosztásra, a statikus ügyfélbejegyzések pedig blokkokat foglalnak, akár csatlakoznak azok az ügyfelek, akár nem. Mindkettő csökkenti a dinamikus tartományt anélkül, hogy megváltoztatná az előtagot, amellyel indult.

A pool határai fontosabbak az előtagnál

A kiszolgáló direktívája szűkebb poolt definiálhat, mint az általa megnevezett alhálózat, és egy segédszkript további beállításokra terjedhet ki, amelyek a megnyitott profilban nem láthatók. A client-config könyvtárból származó rögzített címek ezen a tartományon belül vannak, és nem adhatók ki kétszer. Az előtag a lehetséges legnagyobb teret írja le; a tényleges pool az, amit a futó konfiguráció valóban kínál.

Hasonlítsa össze a kettőt, mielőtt bármit megállapítana a kapacitásról, mert egy kisebb beállított tartomány ugyanolyan jól megmagyarázza a plafont, mint a topológia.

Találja meg a korlátot, amely valóban elutasította az ügyfelet

Először olvassa el a topológiát és a tényleges poolt, majd vegye figyelembe a rögzített kiosztásokat és a fenntartott címeket. Ellenőrizze továbbá a max-clients értékét és minden OpenVPN-en kívüli belépésvezérlést, mielőtt a címtartományt hibáztatja. Végül felelje meg a kiszolgáló saját üzenetét az elutasítás pillanatában ezeknek a jelölteknek. Az üzenet megnevezi a korlátot; a szám csak szűkíti a mezőt.

Az egyidejűségi hibával érkező elutasítás és a kiosztási hibával érkező elutasítás javítása eltér, és a kettő közötti találgatás karbantartási ablakot pazarol el.

A topológia váltása megváltoztatja a címtervet

Áttérés alhálózati topológiára ügyfelenként egy címet ad blokk helyett, ami a helyes lépés, ha az előtag valóban túl kicsi. Megváltoztatja azt is, mit jelentenek az ügyfél címparaméterei, ezért minden rögzített kiosztást és minden ügyfélspecifikus fájlt újra le kell vezetni, nem pedig kézzel újraszámozni. Tervezze meg az új tartományt, migrálja a statikus bejegyzéseket, és frissítse az ezekre hivatkozó útvonalakat.

A váltás nem szinonimája a régi konfigurációnak. Kezelje saját felülvizsgálattal járó címtérv-változásként, és számítson rá, hogy legalább egy ügyfél megtartja az előző séma címét.

A címtervből méretezze a poolt, ne a maszkból

A méretet az egyidejű ügyfelek számából plusz az újracsatlakozásra és tesztelésre szánt tartalékból válassza, majd vegye a legkisebb előtagot, amely a választott topológia mellett lefedi. A /16-ra szélesítés egy hatvan ügyfélből álló plafon megoldására a kapacitásproblémát útvonalválasztási és átfedési problémára cseréli, mert egy nagyobb privát tartomány nagyobb eséllyel ütközik valamivel, amit az ügyfél már elér.

Dokumentálja együtt a topológiát, a poolt, a rögzített kiosztásokat és az ebből adódó ügyfélplafont. A következő kapacitáskérdés akkor aritmetika lesz vizsgálat helyett.