OpenVPN client-connect hook: hová kerül valójában a címed

Cím visszaadása client-connect szkriptből úgy tűnik, mintha beállítaná az ügyfél IP-címét. Nem teszi: a hook egyetlen csatornája a kiszolgáló felé egy ideiglenes fájl, amelynek útvonala a szkript utolsó argumentumaként érkezik, és a címet ott kell megírni ifconfig-push szintaxissal. Az a szkript, amely kiírja a címet, vagy nulla kóddal lép ki anélkül, hogy bármit írna, a készletből származó címmel rendelkező csatlakozott ügyfelet hoz létre, és a kiszolgálónapló teljesen egészségesnek tűnik.

A zavar érthető, mert több más hook valóban válaszol kilépési kódokon vagy környezeti változókon keresztül. Ennek saját szerződése van, és a szerződés egy fájlnévvel kezdődik.

A hook fájlt ír, nem visszatérési értéket

A deklaráció két sor: script-security 2, hogy engedélyezze a hívást, majd client-connect /etc/openvpn/server/assign-address.sh. Amikor egy ügyfél hitelesíti magát, a kiszolgáló lefuttatja ezt a szkriptet a létrehozott fájlútvonallal utolsó argumentumként hozzáfűzve, amely csak akkor $1, ha a deklaráció nem ad át saját további argumentumokat. Minden, ami erre az ügyfélre vonatkozik, abba a fájlba kerül közönséges irányelvekként, soronként egy, pontosan úgy, ahogy egy konfigurációban megjelenne. Egy saját paramétereket hozzáadó burkoló eltolja a pozíciót, és a klasszikus tünet az a szkript, amely egy --verbose-ra hasonlító útvonalra ír.

A kilépési állapot a szerződés másik fele. A nulla azt jelenti: fogadd el és olvasd a fájlt; bármi más elutasítja a kapcsolatot, és így a nem leképezett identitás elutasításra kerül ahelyett, hogy csendben visszaesne a készletbe. Írja meg a teljes irányelvet, mielőtt sikert ad vissza, hogy a félig megírt fájl soha ne váljon egy ügyfél konfigurációjává.

Két irányelv érdemel figyelmet, mert minden mással kölcsönhatnak. Az ifconfig-push rögzíti a címet, míg egy küldött route megmondja az ügyfélnek, mi érhető el az alagúton keresztül; adja vissza az elsőt és feledkezzen meg a másodikról, és címmel rendelkező, de úti cél nélküli ügyfelet kap. A fájlon belüli sorrend nem számít, a teljesség viszont igen. Az a hook, amely olyan előtaghoz küld útvonalat, amelyet egyetlen partner sem ér el, ugyanaz a hiba a másik oldalról nézve.

A bemenetek környezeti változókon keresztül érkeznek: common_name, trusted_ip, ifconfig_pool_remote_ip és a többi. Kezelje mindet a kiszolgálón kívülről jövő karakterláncként, soha ne shell-töredékként.

A címleképezés szabályzat, nem aritmetika

Csábító rövidítés a tanúsítvány nevének elemzése és számjegyeinek használata utolsó oktettként. Ez nem kiosztó, és szokásos módokon vall kudarcot: két azonos utótagú név ütközik, a 300-ra végződő név nem cím, és egy rendszergazda által átnevezett tanúsítvány csendben áthelyez egy eszközt. Minden híváskor ellenőrizze az alhálózati tagságot, a használható gazdatartományt, a fenntartott címeket és az egyediséget, és tartsa a leképezést egy ember számára olvasható táblázatban.

Aki a nevet irányítja, a címet is irányítja, ezért döntse el, mit jelent valójában a common_name ebben a telepítésben. Ha a username-as-common-name engedélyezett, az identitás a bejelentkezés, nem a tanúsítvány tulajdonosa. Soha ne adja át ezt az értéket shell-kiértékelésnek, és soha ne engedje, hogy az ügyfél befolyásoljon egy fájlútvonalat.

A nyilvántartás-alapú kiosztónak túl kell élnie a párhuzamosságot. Foglalja le a címet atomikusan, kezelje a sikertelen írást anélkül, hogy félig konfigurált ügyfelet fogadna el, és címkézze meg minden kiosztást az őt birtokló kapcsolattal, hogy egy régebbi munkamenet késői bontása ne szabadíthasson fel egy címet, amelyet egy újabb már tart. Ha több kiszolgálópéldány osztozik egy készleten, ez a követelmény élesebb lesz, nem opcionális.

A topológia dönti el, mit jelent az ifconfig-push

A topology subnet használatával a 10.77.0.0/24-en az ifconfig-push 10.77.0.20 255.255.255.0 egy cím plusz a hálózati maszkja. A topology net30 alatt a második argumentum egyáltalán nem maszk, hanem a partner címe, tehát az alhálózati forma átmásolása egy net30 kiszolgálóra olyan ügyfelet ad, amely csatlakozik, de nem tud forgalmat átvinni. Szándékosan változtassa meg a topológiát, soha azért, hogy egy példa konzisztensnek tűnjön. Egy már net30-at futtató kiszolgálónak élő ügyfelei vannak a régi címzésen, ezért a váltás karbantartási ablakkal járó migráció, nem egysoros szerkesztés.

A statikus címeknek a dinamikus készleten kívül és minden más statikus hozzárendelésen kívül kell lenniük, beleértve a közönséges client-config-dir fájlok által kiosztottakat is. Ha két mechanizmus ugyanazt a címet tudja előállítani különböző ügyfeleknek, egyikük előbb-utóbb megteszi.

Négy esetet teszteljen, mielőtt megbízik benne

Futtassa ugyanazokat az ellenőrzéseket leképezett identitáson, nem leképezett identitáson, újracsatlakozáson és szimulált nyilvántartáshibán. Az openvpn --config client.ovpn --verb 4 megmutatja a hozzárendelt címet a push válaszban, a kiszolgálón pedig a grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log megerősíti, mi lett ténylegesen elküldve. A nem leképezett identitás esetében a várt eredmény egy elutasított kapcsolat, nem egy készletcím.

Ezután vizsgálja meg azt a könyvtárat, amelybe a démon ezeket az ideiglenes fájlokat írja. A szkript a lecsökkentett szolgáltatáskörnyezetben fut, ezért egy root által írható, de a démon által nem írható útvonal minden kapcsolatot elutasítássá tesz, amelynek engedélyhibája több sorral lejjebb van eltemetve a naplóban.

A kiosztás nem jogosultság: a rögzített cím továbbra sem ad hozzáférést a kiszolgáló mögötti minden célponthoz. Tartsa az útválasztási és tűzfal-szabályzatot a saját rétegében, és ellenőrizze az éppen rögzített címhez képest.