Varování OpenVPN o více skriptech --up: běží jen jeden

Varování o více skriptech zní jako stížnost na plánování, takže zřejmá oprava je přehazovat řádky, dokud nezmizí. Není to stížnost na plánování. Pozdější definice --up nahrazuje příkaz, který už byl pro tuto fázi uložen, a parser to říká, což znamená, že z vašich dvou skriptů kdy běžel právě jeden. Druhý nečeká ve frontě za ním; je pryč.

Proto si varování zaslouží pozornost, i když není fatální: předpovídá aktualizaci DNS nebo změnu trasy, které tiše přestaly probíhat.

Varování není o pořadí

OpenVPN ukládá jediný příkaz uživatelského skriptu pro fázi up. Když parser narazí na jinou definici, z profilu, vloženého souboru nebo příkazového řádku, nahradí to, co už držel, a vydá varování. Nic se neslučuje, nic neběží dvakrát a otázka pořadí neexistuje. Přežije příkaz, který parser viděl naposledy, proto přesunutí řádku může změnit vítěze, zatímco druhý skript zůstane mrtvý.

Stejný vzor platí pro ostatní fáze skriptů: jeden příkaz na každou. Pokud se mají stát obě práce, potřebují jediný vstupní bod, ne dvě direktivy připomínající seznam.

Najděte obě definice ve skutečném spuštění

Začněte tím, co daemon skutečně dostal, ne profilem, který jste upravili. ps -ef a ExecStart unitu ukazují příkazový řádek, do kterého může přidat --up vstupní bod kontejneru nebo obal; init soubor distribuce může udělat totéž. systemctl cat openvpn-server@server odhaluje, co přispívá sama služba, a rekurzivní grep v konfiguračním adresáři najde definice na úrovni souborů. Duplikáty obvykle pocházejí z různých vrstev, a právě proto úprava jednoho souboru nic nezmění.

Kopírování skriptu do jiného adresáře nebo jeho přejmenování také direktivu neodstraní. Parser počítá definice, ne soubory.

Ať práci vlastní jeden hook

Trvalé řešení je jediný dispečer, který provádí obě akce v promyšleném pořadí. Krátký shell skript s set -eu, který zavolá požadovanou integraci a poté místní akci a předá "$@", aby hranice argumentů přežily, drží chování na jednom místě, které lze auditovat. Předání argumentů je jen zachová; nedokazuje, že oba pomocníci očekávají stejné rozhraní, proto si přečtěte smlouvu každého z nich. Rozhodněte, co má selhání udělat a zda je třeba částečné změny vrátit.

Pokud spouštěč nabízí podporovaný rozšiřující hook, dejte mu přednost před ručním řetězením. Obraz kontejneru nebo balíček dodavatele má často dokumentované místo pro další práci a jeho použití zabrání tomu, aby upgrade přepsal váš dispečer.

Úklid patří do odpovídající fáze down. Akce up, která přepisuje DNS nebo přidává trasy, potřebuje dokumentované vrácení zpět, a dispečer, který se stará jen o start, je polovina návrhu.

Potvrďte integraci, ne jen ticho

Odstranit varování o duplikátu je ta snadná část; integrace stále musí fungovat. Zkontrolujte stav resolveru po připojení pomocí resolvectl status nebo čtením /etc/resolv.conf a potvrďte trasy pomocí ip route. Pak se odpojte a znovu připojte, protože narychlo zřetězený hook obvykle nechá něco z předchozí relace. journalctl -u openvpn-server@server -b ukáže, zda váš dispečer běžel a co vypsal.

Držte oprávnění hooku tam, kam patří. Zvyšování script-security nebo spouštění daemonu s většími právy není oprava nahrazeného hooku; rozšiřuje, co může udělat každý budoucí skript, včetně toho, který pojmenuje útočník.

Známkou skutečné opravy není ticho v logu. Je to odpověď DNS, záznam trasy a úklid, které fungují po dvou opětovných připojeních.