Kliens horog vagy szerver horog? Hol fut egy OpenVPN-szkript

A feladat világos: amikor egy laptop csatlakozik, valaminek meg kell változnia a laptopon. A szerkesztett konfiguráció a szerverhez tartozik, és itt törik meg a feltevés. A szerverfájlban lévő útvonal azon a szerveren lévő fájlt nevez meg, és semmi push nem változtatja meg, kinek a folyamata hajtja végre. A két horog közötti választás főként annak eldöntése, melyik gép birtokolja a munkát, és az abból következő korlátok elfogadása.

Két gép, két kérdés, amire először válaszolni kell

Kérdezze meg, hol kell az állapotváltozásnak megtörténnie, majd azt, melyik esemény felel meg neki. Ha a változás felhasználónkénti engedélyezés vagy kliensenkénti konfigurációs döntés, ott a helye, ahol a felhasználói könyvtár ismert: a szerveren. Ha a változás egy útvonal, egy feloldó beállítás vagy egy helyi segéd a végponton, akkor a végponton a helye, és csak a végpont tudja megtenni.

Ha erre a két kérdésre fordított sorrendben válaszol, akkor jut oda az ember, hogy batch-fájlt próbál pusholni egy Windows-os laptopra. A szerver tudja, ki csatlakozott; a laptop tudja, milyen a saját hálózati verme. Egyik sem rendelkezik a másik információjával, és a kísérlet általában csendben kudarcot vall, nem világos hibával.

Mindkettő előtt érdemes feltenni egy harmadik kérdést: egyáltalán kínálja-e a platform a kívánt horgot? Lehet, hogy a saját konfigurációját előállító készülék nem ugyanazokat az eseményneveket kínálja, és az a desktop kliens, amely .ovpn fájlt importál, nem feltétlenül az a kliens, amelynek a fájlt írták. A platform előzetes megerősítése megkíméli attól, hogy olyan horog köré tervezzen, amely ott nem létezik. Azt is megmondja, melyik dokumentáció vonatkozik valójában az Ön előtti gépre.

A szerveroldali lehetőség: esemény kapcsolatonként

A client-connect szkript a szerver folyamatkörnyezetében fut, amikor egy hitelesített kliens csatlakozik, és dokumentált kapcsolati adatokat kap, például a common name-t és a kiosztott címet. Ez a megfelelő hely kliensenkénti konfigurációs töredék írására, szabályzatdöntés érvényesítésére vagy a szerver tulajdonában lévő állapot rögzítésére.

A különbség, amit az emberek kihagynak, az e horog és a szerver up horga közötti különbség. Az up horog akkor lép működésbe, amikor a szerver megnyitja az alagút-eszközét, ami többklienses szerveren a démon indításakor egyszer történik meg. Ez nem bejelentkezésenkénti esemény, és az ott elhelyezett kód a szolgáltatás indításakor fut, nem akkor, amikor a felhasználók csatlakoznak.

Webes felülettel rendelkező készüléken a támogatott bővítési mechanizmust használja a generált démonfájlok szerkesztése helyett. A generált fájlok a következő mentéskor újraíródnak, és az újraírás csendben eltávolítja a módosítását a lehető legrosszabb pillanatban. Őrizze meg a bővítési szöveg másolatát a készüléken kívül, hogy egy firmware-frissítés ne veszítse el a szándékot is.

A kliensoldali lehetőség: munkának helyben kell futnia

Egy közösségi kliens helyi szkriptet futtathat, amikor az alagút-eszköz megjelenik, és újra, amikor az útvonalak telepítésre kerülnek. Ez két különböző pillanat, és a rossz kiválasztása hozza létre azt a klasszikus versenyt, amelyben egy segéd elindul, mielőtt még létezne az útvonal, amelytől függ.

A segédnek léteznie kell azon a kliensen, olvashatónak és futtathatónak kell lennie a klienst futtató fiók számára, és egy kifejezett script-security beállításnak engedélyeznie kell. Egy szkript, amely akkor működik, amikor rendszergazdaként indítja a klienst, semmit sem mond a bejelentkezés előtti szolgáltatásról vagy egy másik felhasználó munkamenetéről.

Az elnevezés is számít. Az up horog az eszköz létrehozásának felel meg, a route-up az útvonalak telepítésének, de egy olyan feladatnak, amelynek elérhető magánhálózatra van szüksége, az elérhetőséget ellenőriznie kell, nem pedig feltételeznie, hogy az eszköz létrehozása azt jelenti, hogy minden útvonal, feloldóbejegyzés és alkalmazás készen áll.

Miért nincs a menün a futtatható kód pusholása

A pusholt beállítások szándékosan korlátozottak, és a szkripteket futtató beállítások azon kategóriák közé tartoznak, amelyeket a szerver nem adhat tovább. Ez a korlátozás azért létezik, mert az alternatíva lehetővé tenné egy kompromittált vagy hibásan konfigurált szerver számára, hogy tetszőleges parancsokat futtasson minden egyes kliensen, amely valaha csatlakozik.

A szkriptfuttatás helyi engedélyezése ezen nem változtat. Az Ön script-security beállítása az Ön által választott helyi szkripteket engedélyezi; nem hatalmazza fel a szervert új szkriptek szállítására.

Ha a cél egyszerűen VPN-útvonalak telepítése, használja a támogatott útvonalkonfigurációt ahelyett, hogy távoli végrehajtási sémát találna ki. Ha a cél valóban helyi kódot igényel, ossza el a szervezet végpontkezelési eszközeivel, és tekintse át úgy, mint bármely más szoftvert, amely a felhasználó jogosultságaival fut.

Mit ellenőrizzen, mielőtt megbízik bármelyik horogban

Írjon le négy dolgot minden horoghoz: a gépet, az esemény nevét, a fiókot, amely alatt fut, és az állapotváltozást, amelyet elő kell állítania. Ezután tesztelje a kapcsolatot, az újracsatlakozást és a tisztítási útvonalat, mert az a horog, amely újracsatlakozáskor állapotot szivárogtat, rosszabb, mint amelyik soha nem futott.

Tesztelje azon fiók alatt, amely valóban végrehajtja, abban a pillanatban, amikor valóban végrehajtják. Az openvpn(8) kézikönyv dokumentálja mindkét horogcsaládot és a push korlátait; a platform, amelyre telepít, dokumentálja, hogy egyáltalán kínálja-e ezeket. Egy szkript, amely egy interaktív rendszergazdai terminálban sikeres, hipotézis, nem ellenőrzés.