A stabil OpenVPN-címek az identitást kövessék, ne a forrás-IP-t
A statikus cím identitásról szóló állítás, nem forrás-IP-ről szóló. Válassza ki a kulcsot, tartsa a foglalásokat a poolon kívül, majd válassza ki a hozzárendelés tulajdonosát.
Azok a címsémák, amelyek azt mondják, hogy „ez a laptop 10.90.0.10-et kap”, valójában identitásról szóló állítások: melyik hitelesített eszköz tarthatja ezt a címet. Az eszköz jelenlegi nyilvános IP-je ehhez szinte semmi közvetlenül nem kapcsolódik, mert a NAT és a barangolás megváltoztatja anélkül, hogy megváltoztatná, ki a felhasználó. Ha a sémát a forráscímre építjük, olyan szabályok születnek, amelyek az első hotelszobai hálózaton eltörnek. Ha a hitelesített identitásra építjük, a terv túléli az utazást.
Kezdje azzal, amit a szerver ellenőrizni tud, majd döntse el, mire való a cím.
A cím előtt válassza ki az identitáskulcsot
Eszközönként külön ügyféltanúsítvány stabil, ellenőrizhető kulcsot ad a szervernek minden taghoz, ami a statikus hozzárendelés legtisztább alapja. A felhasználónkénti hitelesítést használó telepítés helyette a felhasználónévre támaszkodhat, feltéve, hogy a konfiguráció kiválasztása ugyanazt a mezőt követi. A két modell keverése olyan hozzárendeléseket eredményez, amelyek az egyik ügyfélnél tanúsítványhoz, a másiknál felhasználónévhez illeszkednek, és senki sem tudja megjósolni, melyik győz. Döntse el, melyik kulcsot használja a terv, mielőtt egyetlen foglalást is ír.
duplicate-cn használatával több egyidejű munkamenet is bemutathatja ugyanazt a közös nevet, így egy rögzített cím nem tudja őket egyenként azonosítani. Ez az identitásmodell tulajdonsága, nem valami, amit egy jobb címséma orvosolhat.
A dinamikus tartományon kívül foglaljon címeket
Egy alhálózati topológiájú hálózatban, például 10.90.0.0/24, tartsa az alacsony címeket a névvel ellátott tagoknak, és tegye a dinamikus poolt külön tartományba. A rögzített tag hozzárendelése így néz ki ifconfig-push 10.90.0.10 255.255.255.0 abban a fájlban, amelyet a szerver ehhez az identitáshoz kiválaszt. A második argumentum a net30 alatt mást jelent, ezért a példa nem topológiasemleges. Olvassa el a topológiát, mielőtt lemásolja.
A pool tartóssága rögzíti a legutóbbi bérleteket, és hajlamos ugyanazt a címet visszaadni, ami kényelem, nem foglalás. Ne hagyja, hogy a tartóssági fájl a tulajdon nyilvántartása legyen, mert a kapcsolatok történetével változik, nem a szabályzattal.
A hozzárendelés elsőbbsége dönti el, ki győz
A kézikönyv sorrendet dokumentál: a client-connect során létrehozott kifejezett hozzárendelés a client-config-dir bejegyzés előtt léphet életbe, amely viszont megelőzi a szokásos pool-kiosztást. Ez a sorrend magyarázza a „a rögzített cím nem érvényesült” jelentések többségét. Azt is jelenti, hogy egy dinamikus kiosztó, amely munkamenetenként ír konfigurációt, csendben felülírhat egy statikus fájlt, amelyet mérvadónak hitt.
Válasszon egy réteget, amely a hozzárendeléseket birtokolja, a többit tegye írásvédetté. Két réteg, amely mindkettő döntést követel, időzítéstől függő hozzárendeléseket eredményez.
A dinamikus kiosztónak ugyanarra a modellre van szüksége
A client-connect integráció, amely munkamenetenként oszt címeket, egy kis kiosztó a szokásos kiosztóproblémákkal. Ellenőriznie kell a kérő identitását, atomikusan le kell foglalnia egy címet, csak a támogatott kapcsolatonkénti kimenetet adhatja ki, és a foglalást kapcsolatbontáskor vagy hiba esetén fel kell szabadítania. Az egyidejű kérésekhez zár vagy adatbázis-megkötés kell, nem olvasás-majd-írás sorrend. Tisztítás nélkül a pool címeket szivárogtat az újraindításig.
Tartsa a kiosztó állapotát ott, ahol a következő üzemeltető elolvashatja, és naplózza az identitás-cím döntést, ne csak a címet.
Döntse el, a cím szabályzat vagy kényelem
Ha egy tűzfal-szabály vagy útvonal engedélyezi a forgalmat egy alagútcímről, akkor a cím részt vesz a hozzáférési szabályzatban, és az újrahozzárendelés örökli ezt az engedélyt. Hangolja össze az identitás, a cím és a tűzfal életciklusát, vagy kösse a szabályt valamihez, ami nem rendelhető újra. A stabil címzés olvashatóvá teszi a konfigurációt; nem helyettesíti a hitelesítést.
Írja a tervet leltárként, bejegyzésenként egy tulajdonossal, majd vizsgálja felül, amikor egy eszközt kivonnak a használatból. A használatlan foglalás az, amelyet véletlenül újra felhasználnak.