Zein helbide emango du poolak hurrengo berrikonexioan?
Poolaren helbideek ordena bat jarraitzen dute, ez da ausazkoa: lehenik gogoratutako helbidea, gero libre den erabili berriena ez dena. Irakurri arau bat finkatu aurretik.
Atzo bat zetorren arau bat gaur ez da bat dato, bezeroa beste tunel-helbide batekin itzuli delako. Alokatzailea ez da ausazkoa, ordea, eta bere ordena ezagutzeak ezusteko hori gertaera aurreikusteko moduko bihurtzen du. Berak lehenago bezero berak zuen helbidea hobesten du, erabili berriena ez den librean erortzen da, eta dena ahazten du gogoratzeko tokiren bat ematen ez badiozu. Lease bat suposatzen duten arauak bat datoz isilik bat ez datozen egunera arte.
Alokatzaileak jarraitzen duen ordena
Common name bakoitzeko sesio batekin, alokatzaileak lehenago bezero berak erabilia eta orain libre dagoen helbide bat bilatzen du lehenik. Helbide hori desagertu bada, denbora luzeenean inaktibo egon den helbide librea hartzen du. Izen bererako sesio paraleloak gaituta badaude, aurreko helbidearekiko lehentasuna ez da aplikatzen eta lehen helbide librea erabiltzen da horren ordez, sesioak peer bereizi gisa tratatzen direlako.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
Hortik bi ondorio datoz berehala. Azkar berrikonektatzen den bezero batek normalean bere helbidea mantentzen du, eta horregatik inork ez du mekanismoa nabaritzen aldatzen den arte. Eta leiho txiki horretan konektatzen den beste gailu batek helbidea hartu dezake une laburrez libre dagoen bitartean, eta ondoren lehen bezeroak beste zerbait jasotzen du eta zenbaki zaharrean oinarritutako arau guztiak okerrak dira. Bi gertaera horietako batek ere ez du errore baten itxura duen erregistro-lerro bat sortzen.
Zergatik dirudien lease batek egonkorra eta gero mugitu egiten den
Egonkortasuna hemen berrikonexioek helbidea beste inork aldarrikatu aurretik iristearen propietate emergentea da. Ez da promesa bat, eta ez da betearazten bezeroa deskonektatuta dagoen bitartean. Planifikatu helbidea aldatuko dela horrek harritu beharrean. Gailu-kopurua baino apenas handiagoa den pool batek talkak ohiko bihurtzen ditu, erabili berriena ez den helbidera jotzeak ia ez duelako aukeran.
Gailur-konkurrentzia da dimentsionatzeko zenbakia, ez erabiltzaile-kopurua. Bi gailutatik aldi berean probatzen duen norbaitek, edo sesio zaharra iraungi aurretik berrikonektatzen den bezero batek, lease bi hartzen ditu aldi batez. Besterik gabe pertsona-kopururako dimentsionatutako pool batek jendeak zerbitzariari leporatzen dion txandakatze bera sortuko du.
Persistentzia-fitxategiak gogoratzen du, ez du erreserbatzen
Zerbitzuaren berrabiarazte bat gainditzen duen helbide batek persistentzia-fitxategi bat behar du. Itzaltzean bezeroaren izena eta helbidea gordetzen ditu eta zerbitzua abiatzean berrirakurtzen ditu, eta horregatik berrabiarazte planifikatu batek ez ditu idatzi dituzun arau guztiak nahasten.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Egiten ez duena helbidea atxikitzea da bezeroa kanpoan dagoen bitartean. Tarte horretan alokatzailea libre da zenbakia beste norbaiti emateko, eta fitxategiak orduan hurrengo konexioak bete ezin duen lehentasun zaharkitu bat jasotzen du. Hartu zantzu gisa berrabiarazteko jokaera hobetzen duena, ez helbideratze estatikotzat.
Egiaztatu pool-a bideratutako azpisare bakoitzaren aurka fitxategian zauden bitartean. Gainjartzen den tarte batek zerbitzariak bideratu ezin dituen helbideak banatzen ditu, eta sintoma bezero bat da, konektatu, helbide bat jaso eta inora iristen ez dena.
Helbide bat behar bezala finkatzea
Suhormako arau batek edo DNS erregistro batek benetan helbide finko bat behar duenean, esleitu ezazu itxaron beharrean. Bezero bakoitzeko konfigurazio-sarrera batek helbidea eta maskara zuzenean bultza ditzake, eta sarrera hori bezeroaren izen eraginkorrarekin gakotuta dago.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Eduki helbide finkoak pool dinamikotik kanpo, alokatzaileak inoiz zenbaki bera beste sesio bati eman ez diezaion. Ondoren berrikusi tunelaren topologia, bezero bakoitzak zenbat pool-helbide kontsumitzen dituen aldatzen duelako: puntu-puntuko antolamendu zaharragoak bloke txiki bat kontsumitzen du bezero bakoitzeko, azpisare-antolamendu batek bakoitzak helbide bat erabiltzen duen bitartean. Topologia batekin eskuzabala dirudien pool bat agortzailea gerta daiteke bestearekin.
Berretsi emaitza bezeroan zerbitzariaren kontabilitatean fidatu beharrean. Sesioa itzuli ondoren, begiratu interfazearen helbidea eta bidalitako bidea, zerbitzariko erregistro batek eskatutako helbidea eman dezakeelako interfazeak beste bat duen bitartean.
Urrutiko helbidea beste galdera bat da
Bezeroaren remote lerroko helbidea erdietsgarria izan behar da edozein tunel existitu aurretik. Han pool-helbide bat jartzen baduzu, esaterako zerbitzariaren beraren tunel-muturra, bezeroak oraindik eraiki ez duen tunel baten bidez helmuga erdiesten saiatzen da, eta emaitza begizta bat edo itxaronaldi isil bat da, lasterbidea beharrean.
Erabili operadoreak emandako mutur publikoa, eta gorde pool-a pentsatuta dagoenerako: tunelaren barruko helbideak. Pool-tartea, esleipen finkoak eta persistentzia-bidea leku bakarrean idazteak hurrengo pertsonari aurrezten dio lease bakoitza arbitrariotzat hartzea.