Melyik címet osztja a pool a következő újracsatlakozáskor?
A pool címei nem véletlenszerű sorrendet követnek: először a megjegyzett cím, aztán a legrégebben használt szabad cím. Olvasd el, mielőtt szabályt rögzítesz.
Egy tegnap illeszkedő szabály ma már nem illeszkedik, mert a kliens másik alagútcímmel tért vissza. Az osztó azonban nem véletlenszerű, és a sorrendjének ismerete kiszámítható eseménnyé teszi ezt a meglepetést. Előnyben részesíti azt a címet, amely korábban ugyanazon kliensé volt, visszaesik a legrégebben használt szabad címre, és mindent elfelejt, ha nem adsz neki helyet az emlékezésre. A bérletet feltételező szabályok addig illeszkednek tovább, amíg egy nap csendben már nem teszik ezt.
A sorrend, amelyet az osztó követ
common name-enként egy munkamenettel az osztó először olyan címet keres, amelyet ugyanaz a kliens korábban használt, és amely most szabad. Ha az a cím eltűnt, a legrégebben tétlen szabad címet veszi. Ha ugyanahhoz a névhez egyidejű munkamenetek vannak engedélyezve, a korábbi cím előnye nem érvényes, és helyette az első szabad címet használja, mert a munkameneteket különálló peer csomópontként kezeli.
| 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 |
Ebből azonnal két következmény adódik. A gyorsan újracsatlakozó kliens általában megtartja a címét, ezért senki sem veszi észre a mechanizmust, amíg meg nem változik. És egy másik eszköz, amely abban a kis ablakban csatlakozik, elveheti a címet, amíg az rövid ideig szabad, utána az első kliens mást kap, és minden a régi számra épülő szabály hibás. A két esemény egyike sem hoz létre hibaüzenetnek látszó naplósort.
Miért tűnik stabilnak a bérlet, aztán mégis elmozdul
A stabilitás itt az újracsatlakozások emergens tulajdonsága, amelyek azelőtt érkeznek, hogy bárki más igényt tartana a címre. Ez nem ígéret, és nem érvényesül, amíg a kliens le van csatlakozva. Számolj azzal, hogy a cím megváltozik, ahelyett hogy meglepődnél rajta. Egy alig nagyobb pool a készülékszámnál mindennapossá teszi az ütközéseket, mert a legrégebben használt címre való visszaesésnek szinte semmi választási lehetősége nincs.
A csúcsbeli egyidejűség az a szám, amelyhez méretezni kell, nem a felhasználók száma. Aki egyszerre két eszközről tesztel, vagy egy kliens, amely a régi munkamenet lejárta előtt újracsatlakozik, egy ideig két bérletet foglal. A csak a létszámra méretezett pool pontosan azt a cserét hozza létre, amelyet az emberek a szerverre fognak.
A perzisztenciafájl emlékszik, nem foglal
Egy szolgáltatás-újraindítást túlélő címhez perzisztenciafájl kell. Ez leállításkor eltárolja a kliens nevét és a címet, és a szolgáltatás indulásakor visszaolvassa őket, ezért a tervezett újraindítás már nem keveri össze az összes általad írt szabályt.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Amit nem tesz, az az, hogy megtartja a címet, amíg a kliens távol van. Ebben a résben az osztó szabadon odaadhatja a számot valaki másnak, és a fájl ekkor egy elavult preferenciát rögzít, amelyet a következő kapcsolat nem tud teljesíteni. Kezeld úgy, mint az újraindítási viselkedést javító tippet, nem mint statikus címzést.
Ellenőrizd a poolt minden irányított alhálózat ellen, amíg a fájlban vagy. Egy átfedő tartomány olyan címeket oszt ki, amelyekre a szerver nem tud irányítani, és a tünet egy kliens, amely csatlakozik, címet kap, és semmit sem ér el.
A cím helyes rögzítése
Amikor egy tűzfal-szabály vagy egy DNS-rekord valóban fix címet igényel, oszd ki, ahelyett hogy reménykednél benne. Egy kliensenkénti konfigurációs bejegyzés közvetlenül küldhet címet és maszkot, és ez a bejegyzés a tényleges kliensnévhez van kulcsolva.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Tartsd a fix címeket a dinamikus poolon kívül, hogy az osztó soha ne adja ugyanazt a számot egy másik munkamenetnek. Utána ellenőrizd az alagút topológiáját, mert az megváltoztatja, hogy mennyi pool-címet fogyaszt egy kliens: a régebbi pont-pont elrendezés kis blokkot fogyaszt klienenként, míg az alhálózati elrendezés egy-egy címet használ. Egy pool, amely az egyik topológiánál bőségesnek tűnik, a másiknál kimerítő lehet.
Erősítsd meg az eredményt a kliensen, ahelyett hogy a szerver könyvelésében bíznál. Amikor a munkamenet visszatér, nézd meg az interfész címét és a küldött útvonalat, mert a szerver naplója a kért címet jelentheti, miközben az interfész maga másikat tart.
A távoli cím külön kérdés
A kliens távoli sorában lévő címnek elérhetőnek kell lennie, mielőtt bármilyen alagút létezik. Ha oda pool-címet tesz, például a szerver saját alagút-végpontját, a kliens egy még fel nem épített alagúton keresztül próbálja elérni a végpontot, és az eredmény hurok vagy csendes időtúllépés a rövidítés helyett.
Használd az üzemeltető által biztosított nyilvános végpontot, és tartsd a poolt arra, amire tervezték: az alagúton belüli címekre. A pool tartományának, a fix hozzárendeléseknek és a perzisztenciaútvonalnak egy helyen való feljegyzése megkíméli a következő embert attól, hogy minden bérletet önkényesnek tekintsen.