OpenVPN-kiszolgáló nopool-lal: adjon meg egy explicit pooltartományt

A kiszolgáló súgói beállítanak egy alhálót, majd saját választású dinamikus pool-lal töltik fel. Ez az alapértelmezés kényelmes addig, amíg néhány címnek a kiosztáson kívül kell maradnia — akár rögzített hozzárendelésekhez vannak fenntartva, akár egy jövőbeli szegmens számára tartják vissza. Az automatikus pool letiltása és a tartomány saját megadása két sort és egy tudatos döntést igényel arról, mely címek nem a kiosztásé. A többi üzemeltetési fegyelem: leltár, alkalmazás, ellenőrzés, visszaállítás.

Ez egy működő szolgáltatás módosítása, ezért üzemeltetési feladatként kezelje: először leltár, majd alkalmazás a szokásos életcikluson keresztül, ellenőrzés friss klienssel, és kész visszaállítási terv.

Azzal az alhálóval kezdje, amely már megvan

Olvassa el az aktuális kiszolgálókonfigurációt és azokat a címeket, amelyeket a kliensek valóban birtokolnak. A pool módosítása csak ehhez az alapvonalhoz képest értelmes, és az alapvonal nem mindig az, amit a fájl sugall, mert egy felügyelt termék vagy konfigurációgenerátor birtokolhatja az olvasott fájlt.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Erősítse meg az érvényes topológiát. Alháló-topológia esetén minden kliens egy címet vesz a poolból; a régebbi net30-elrendezések kliensenként egy kis blokkot osztanak ki, és az aritmetika teljesen más. Ha a kiszolgáló még mindig net30-on van, ez az oldal a rossz migrációs útmutató, és a pool számai nem azt fogják jelenteni, amire számít. Ellenőrizze ezt a sort, mielőtt máshonnan átvenné a címek aritmetikáját.

Írja fel a kiszolgáló saját címét, minden rögzített hozzárendelést a klienskonfigurációk könyvtárában, és minden olyan címet, amelytől egy útvonal vagy hozzáférési szabály függ. Ezek azok a címek, amelyeknek a dinamikus tartományon kívül kell maradniuk. Ha előbb felírja őket, a tartomány döntéssé válik találgatás helyett. Ez a visszaállításnak is ad valami konkrétat, amit helyre lehet állítani.

Adja hozzá a nopool-t, és adja meg a tartományt

A súgó kulcsszó elfogadja a nopool kapcsolót, amely megtartja az alháló konfigurációját és letiltja az automatikus dinamikus poolt, ahogy az OpenVPN 2.6 kézikönyve leírja. Az explicit ifconfig-pool sor ezután megadja a szándékolt zárt tartományt, és a hálózati maszkja megegyezik az alhálóval. Mindkét sor ugyanabba a kiszolgálóblokkba tartozik, mert az alhálója nélküli pool értelmetlen. A sorrendjük csak az olvashatóság miatt számít, mivel a súgó a szolgáltatás indításakor bontja ki a párt.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Mindkét határ zárt, így a példa hetvenegy címet kínál. Tartsa a kiszolgáló címét és minden rögzített hozzárendelést ezen a sávon kívül; a dinamikus tartományba eső rögzített hozzárendelés a csatlakozási sorrendtől függő ütközést okoz, ami a legrosszabb fajta a hibakereséshez. Ha a rögzített hozzárendelések valószínűleg növekedni fognak, hagyjon rést a fenntartott halmaz és a tartomány között.

A tartomány mérete és az egyidejűség külön korlátok. Száz cím nem jelent száz egyidejű klienst, ha a max-clients mást mond, és az egyidejűségi korlátnál nagyobb pool normális, nem pazarlás. Az a fontos, hogy a két korlátot tudatosan válasszák, ne egy alapértelmezésből örököljék.

Tartsa a rögzített hozzárendeléseket a dinamikus tartományon kívül

Az ügyfélspecifikus ifconfig-push más mechanizmus, mint a poolból való kiosztás, és az aktív topológiához illő paramétereket kell használnia. Alháló módban ez egyetlen cím és hálózati maszk; a net30 pár átvitele csak azért, mert egy régi példában szerepelt, gyakori hiba.

A kiosztási előzmény nyom, nem tekintély. A persist fájl emlékszik arra, melyik kliensnek melyik cím volt, így az újracsatlakozó kliensek általában ugyanazt kapják, és nem foglal le címeket, nem szabadít fel, és nem helyettesít rögzített hozzárendelést. Ha egy adott eszköznek mindig adott címet kell birtokolnia, használjon rögzített hozzárendelést ahelyett, hogy a persist fájlra támaszkodna.

Ezután ellenőrizze a címektől függő útvonalakat. A klienseknek küldött útvonal, egy alhálót beengedő tűzfal-szabály vagy egy adott gazdagépet váró felügyeleti ellenőrzés mind a régi tartományt feltételezheti. A pool módosítása ezek elolvasása nélkül olyan helyre viszi a hibát, amely nem tűnik összefüggőnek.

Alkalmazza az életcikluson keresztül, majd ellenőrizze

Úgy alkalmazza a módosítást, ahogy a szolgáltatás rendszerint konfigurációt kap — akár közvetlen fájl és újraindítás, akár a fájlt újrageneráló felügyeleti réteg. A generált fájl kézi szerkesztése a következő generálásig él, és nem tovább. Jegyezze fel, melyik mechanizmus birtokolja a fájlt, mert a következő üzemeltetőnek tudnia kell, hol kell ugyanezt a módosítást elvégezni. Ezután indítsa újra egyszer, és olvassa el a naplót, mielőtt klienst hív.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Csatlakoztasson egy klienst, amely korábban nem csatlakozott, és erősítse meg, hogy a cím a megadott tartományon belülre és a fenntartott halmazon kívülre esik. Ezután erősítse meg a visszautat: a kliensnek el kell érnie azt, amit a házirend enged, és nem többet. Az a cím, amely illik a tervhez, de nincs működő útvonala, nem sikeres változás.

Csatlakoztassa újra azt a klienst, amely a régi tartományból birtokolt címet. Új címet kell kapnia az új tartományból, és a régi címhez kötött munkamenet-szintű állapotnak el kell tűnnie. Ha megtartja a régi címet, valami más osztja ki neki, és a pool nem az a tulajdonos, akire gondol.

Tartományváltozás visszaállítása

Tartsa meg az előző három sort a változásnyilvántartásában, ne csak az előző fájlt. Ezek visszaállítása és az újraindítás visszaviszi a kiosztást a régi viselkedésre, és az ezután újracsatlakozó kliensek abból kapnak címeket.

Két figyelmeztetés tartozik a nyilvántartásba. A visszaállításkor már csatlakozott kliensek megtartják jelenlegi címeiket, amíg újra nem csatlakoznak, így a visszaállítás nem azonnali az egész flottán. És ha a régi tartomány egy rögzített hozzárendeléssel átfedésben volt, a visszaállítás az ütközést is visszaállítja; éppen ez az átfedés volt a változás oka, és ez más javítást igényel, mint egy visszaállítás.

Egy poolváltozás akkor van kész, amikor egy friss kliens a tartományon belüli címet kap, fenntartott cím soha nem kerül kiadásra, és a címeket fogyasztó útvonalak és szabályok továbbra is a szándéknak megfelelően viselkednek. Bármi ennél kevesebb a következő emberre hagyja annak kiderítését, melyik a három közül nem igaz.