OpenVPN figyelmeztetése több --up szkriptről: csak egy fut

A több szkriptre vonatkozó figyelmeztetés ütemezési panasznek hangzik, így a kézenfekvő javítás a sorok átrendezése, amíg el nem tűnik. Ez nem ütemezési panasz. Egy későbbi --up definíció lecseréli az adott szakaszhoz már tárolt parancsot, és az elemző ezt ki is mondja, ami azt jelenti, hogy a két szkriptje közül pontosan egy futott valaha. A másik nem sorakozik mögötte; eltűnt.

Ezért érdemel figyelmet a figyelmeztetés, még ha nem is végzetes: azt jelzi előre, hogy egy DNS-frissítés vagy útvonal-változás csendben abbamaradt.

A figyelmeztetés nem a sorrendről szól

OpenVPN egyetlen felhasználói szkriptparancsot tárol a up szakaszhoz. Amikor az elemző újabb definícióval találkozik, a profilból, egy beillesztett fájlból vagy a parancssorból, lecseréli, amit már tartott, és kiadja a figyelmeztetést. Semmi nem fűződik össze, semmi nem fut kétszer, és sorrendkérdés nem létezik. Az a parancs marad meg, amelyet az elemző utoljára látott, ezért egy sor áthelyezése megváltoztathatja a győztest, miközben a másik szkript halott marad.

Ugyanez a minta érvényes a többi szkriptszakaszra: egy parancs mindegyikre. Ha két munkának mindkettőnek meg kell történnie, egyetlen belépési pontra van szükségük, nem két listára emlékeztető direktívára.

Keresse meg mindkét definíciót a tényleges indításban

Abból induljon ki, amit a daemon valóban megkapott, ne abból a profilból, amelyet szerkesztett. ps -ef és az unit ExecStart mutatja a parancssort, amelybe egy konténer belépési pont vagy egy burkoló hozzáadhatja a --up kapcsolót; egy disztribúció init fájlja ugyanezt teheti. systemctl cat openvpn-server@server feltárja, mit tesz hozzá maga a szolgáltatás, és a konfigurációs könyvtáron futtatott rekurzív grep megtalálja a fájlszintű definíciókat. A duplikátumok általában különböző rétegekből származnak, és pont ezért nem változtat semmit egy fájl szerkesztése.

Egy szkript másik könyvtárba másolása vagy átnevezése sem távolít el egy direktívát. Az elemző definíciókat számol, nem fájlokat.

Egy hook tulajdonolja a munkát

A tartós megoldás egyetlen diszpécser, amely a két műveletet megfontolt sorrendben futtatja. Egy rövid shell-szkript set -eu beállítással meghívja a szükséges integrációt, majd a helyi műveletet, és továbbadja a "$@" kifejezést, hogy az argumentumhatárok megmaradjanak, így a viselkedés egyetlen ellenőrizhető helyen marad. Az argumentumok továbbadása csak megőrzi őket; nem bizonyítja, hogy a két segéd ugyanazt a felületet várja, ezért olvassa el mindegyik szerződését. Döntse el, mit tegyen egy hiba, és hogy a részleges változásokat vissza kell-e vonni.

Ha az indító támogatott bővítési hookot kínál, részesítse előnyben a kézzel épített láncolással szemben. Egy konténerkép vagy egy gyártói csomag gyakran rendelkezik dokumentált hellyel a további munkához, és ennek használata megakadályozza, hogy egy frissítés felülírja a diszpécserét.

A takarítás a megfelelő down szakaszhoz tartozik. Egy up művelet, amely átírja a DNS-t vagy útvonalakat ad hozzá, dokumentált visszafordítást igényel, és a csak az indítást kezelő diszpécser fél tervezés.

Az integrációt igazolja, ne csak a csendet

A duplikált figyelmeztetés megszüntetése a könnyebb rész; az integrációnak még működnie kell. Csatlakozás után ellenőrizze a feloldó állapotát a resolvectl status paranccsal vagy a /etc/resolv.conf olvasásával, és igazolja az útvonalakat a ip route paranccsal. Ezután bontsa a kapcsolatot és csatlakozzon újra, mert a sietve láncolt hook hajlamos otthagyni valamit az előző munkamenetből. journalctl -u openvpn-server@server -b megmutatja, futott-e a diszpécser, és mit írt ki.

Tartsa a hook jogosultságait ott, ahol a helyük van. A script-security növelése vagy a daemon nagyobb jogokkal való futtatása nem megoldás egy lecserélt hookra; kiterjeszti, hogy mit tehet minden jövőbeli szkript, beleértve azt is, amelyet egy támadó nevezhet el.

A valódi javítás jele nem a napló csendje. Az a DNS-válasz, az útvonalbejegyzés és a takarítás, amelyek két újracsatlakozás után is működnek.