OpenVPN felügyeleti socket: vezérlőcsatorna, nem metrikák

Kérj egyszer állapotot a felügyeleti felülettől, és máris állapotportnak tűnik. De nem az. Amint egy klienst beengednek, kiadhatja a protokoll vezérlőparancsait, és az a fiók, amely ezt a klienst futtatja, örökli mindazt, amit ezek a parancsok a daemonnal tehetnek. Csak olvasható adatfolyamként kezelni az a hiba, amely a monitorozási integrációt hitelesítés nélküli konzollá változtatja.

A hit, és hogy mi az ára

A hit az, hogy a felügyeleti figyelő egyenértékű egy metrikavégponttal: csatlakoztass gyűjtőt, olvasd a számlálókat, lépj tovább. Valójában a gyűjtő vezérlési képességekkel rendelkező munkamenetet nyit, és minden más, a telepítésről alkotott feltevésed most attól függ, hogy ez a gyűjtő jól viselkedik-e.

A felületen semmi sem hirdet csak olvasható módot. Nincs választható megfigyelői szerep, és a konfigurációban szereplő felhasználónév nem hoz létre egyet.

Mit tart valójában egy elfogadott kliens

A közösségi daemon egyszerre csak egy aktív felügyeleti klienst fogad. Ez az egyetlen hely azt jelenti, hogy egy GUI, egy szkript és egy monitorozó ügynök nem tud mind csatlakozni; a második vár vagy meghiúsul, míg az első tartja a munkamenetet. Ha a tervezésed egyidejű olvasókat feltételez, már most hibás.

Ahol elég egy időszakos pillanatkép, az állapotfájl kimenete ugyanazokat a számokat adja élő munkamenet nélkül. A fájl rendszeres írása és szokásos fájljogosultságokkal való olvasása teljesen a vezérlési síkon kívül tartja a gyűjtőt, és ez az az elrendezés, amelyre a legtöbb monitorozásnak valóban szüksége van.

Saját socket, nem nyitott

A Unix-tartomány socket a vezérlési útvonalat a hálózaton kívül tartja, ami kiveszi a problémából a változó alagútcímet. Az engedélykérdést azonban nem szünteti meg. A szülőkönyvtárnak írhatónak kell lennie a szolgáltatásfiók számára és elérhetőnek a vezérlő fiókja számára, és ez két külön engedély:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

A jelszófájl az első sorában hordozza a felügyeleti titkot. Védd ezt a fájlt, mint bármely más hitelesítő adatot, és tartsd a tartalmát távol a naplóktól és a támogatási jegyektől. A felhasználói és csoportos korlátozások társellenőrzések a Unix socketen, nem fájlrendszer-jogosultságok, ezért a szándékolt folyamatnak egyszerre van szüksége a fájlhozzáférésre és a megfelelő identitásra.

A socket világ számára elérhetővé tétele egy engedélyhiba elhárítására az az egyetlen javítás, amelyet el kell kerülni. Egy helyi vezérlőcsatornát olyasmivé változtat, amit a gazdagép bármely folyamata vezérelhet.

A TCP-n való közzététel nem ugyanaz a tervezés

A figyelő TCP-portra költöztetése nem teszi biztonságosabbá vagy kényelmesebbé. A felügyeleti jelszó nyílt szövegben megy, így a TCP-figyelő a hitelesítő adatot és a munkamenetet is feltárja bárki előtt, aki megfigyelheti az útvonalat. Más gazdagépről való elérése engedélyezett adminisztrációs csatornát vagy egy kis helyi ügynököt igényel, amely csak a szükséges megfigyeléseket teszi elérhetővé.

A jelszó nyílt szövegű átvitelen hitelesítés bizalmasság nélkül, és ez a kombináció rosszabb, mint amilyennek látszik, mert védettnek érződik.

Olyan indítási függőségek, amelyeket nem kértél

Több felügyeleti beállítás megváltoztatja a daemon életciklusát. Az indítás visszatartása, amíg egy vezérlő csatlakozik, vagy a leállítás, amikor a vezérlő eltűnik, egy opcionális megfigyelőt kemény függőséggé változtat. Egy összeomló monitorozó ügynök akkor magával rántaná az alagutat is.

Tekintsd át ezeket a beállításokat, mielőtt bármit engedélyeznél a socketen túl. Az opcionális megfigyelés maradjon opcionális, és az újraindítási szabályzatot ne kapcsold egy grafikonok miatt hozzáadott gyűjtőhöz.

Egy sikertelen folyamat után hátramaradt socketfájl nem bizonyíték arra, hogy létezik figyelő. Állapítsd meg, melyik példány birtokolja az útvonalat, mielőtt eltávolítanád, és a szolgáltatás saját helyreállítási folyamatát használd a futó daemon alatti fájlok törlése helyett.

Hogyan néz ki az elfogadás

Négy ellenőrzés fedi le a tervezést: a szándékolt vezérlőidentitás csatlakozik, az e nélküli identitású folyamat elutasításra kerül, a daemon túléli a figyelmeztetés nélkül lecsatlakozó vezérlőt, és az alagút egy ellenőrzött újraindításon át is visz forgalmat. Egy sikeres felügyeleti kapcsolat csak a vezérlési síkot bizonyítja. Semmit sem mond arról, hogy működik-e a privát alkalmazások forgalma, ezért azt külön teszteld. Írd le a négy eredményt ott, ahol a következő üzemeltető megtalálja őket.

A felügyeleti felület dokumentációja az egyklienses modellt és a protokoll kiváltságos természetét írja le, és ez az a rész, amelyet érdemes elolvasni, mielőtt egy irányítópultot ráirányítasz.