status=200/CHDIR: systemd OpenVPN vůbec nespustil

Služba selhává, v logech se objevuje spawn a adresář a prvním instinktem je zkontrolovat konfiguraci VPN. V tom souboru zatím nebylo nic přečteno. systemd selhal při přípravě procesu, ještě před spuštěním spustitelného souboru, takže nebyl konzultován žádný parser, žádný certifikát ani vzdálený hostitel. Číst stavový kód jako výpověď o systemd, a ne o OpenVPN, je to, co z toho dělá krátké vyšetřování.

Přečtěte stavový kód dřív než aplikaci

Číselný kód za názvem služby pojmenovává fázi, která selhala. Selhání adresáře se hlásí jako stav CHDIR, zatímco spustitelný soubor, který se nepodařilo spustit, je úplně jiný kód. Ty dva vypadají v souhrnném řádku podobně a na svých příčinách nemají nic společného.

Ten rozdíl je důležitý, protože opravy jsou v různých souborech. Selhání CHDIR se týká cesty a toho, jak ji služba vidí. Selhání exec se týká binárky, jejího interpretu nebo nesouvisejícího připojení. Změna vzdáleného bodu VPN, seznamu šifer nebo cesty k certifikátu nevyřeší ani jedno.

Potvrďte, že selhání je na startu, a ne po úspěšném běhu. Pokud služba včera fungovala a teď selhává ve stejné fázi, něco se změnilo na adresáři, jeho oprávněních nebo na samotné unitě, a ta změna je důkaz, který máte hledat.

Zeptejte se unity, kde chce být

Čtěte efektivní unitu, ne soubor, o kterém si myslíte, že je nainstalovaný, protože drop-iny mohou přepsat pracovní adresář, aniž byste kdy upravili hlavní unitu. Výstup show odpovídá na otázku přímo:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

U šablony upstream serveru je pracovním adresářem adresář konfigurace serveru a název instance vybírá profil uvnitř něj. Instance jménem branch tedy očekává svůj vlastní soubor ve stejném adresáři a profil umístěný jinde požadavek na pracovní adresář vůbec nesplňuje.

Porovnejte, co uníta žádá, s tím, co existuje. Cesta, která dřív existovala, symbolický odkaz, který teď míří jinam, nebo název instance, který už neodpovídá adresáři, jsou běžné změny, které způsobují právě tuto chybu.

Zkontrolujte cestu tak, jak ji vidí služba

Váš shell a služba nesdílejí stejný pohled na souborový systém. Nastavený kořenový adresář nebo root image mění, co znamená absolutní cesta uvnitř unity, a cesta, která je na hostiteli zjevně přítomná, může v tom namespace chybět. Přečtěte si nastavení unity, než uvěříte ručnímu testu.

Oprávnění problém ještě zhoršují. Služba běží jako konkrétní uživatel a ten musí být schopen projít každým nadřazeným adresářem, aby se dostal k cíli, ne jen přečíst samotný cíl. Adresář čitelný pro root a neprostupný pro uživatele služby vytváří selhání, které vypadá jako chybějící cesta.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

Do tohoto obrazu patří i nastavení zpevnění. Uníta, která skrývá domovské adresáře nebo dělá část souborového systému jen pro čtení, dělá přesně to, co bylo nakonfigurováno, a pracovní adresář musí žít někde, kde ho sandbox ještě vystavuje.

Opravte vlastníka a pak čekejte jinou chybu

Opravte rozložení nebo unitu prostřednictvím toho, kdo tu konfiguraci vlastní. Přesunutí profilu do očekávaného adresáře je legitimní oprava, když je rozložení špatné, ale nevysvětluje adresář, do kterého nelze vstoupit, takže to neberte jako obecnou odpověď.

Odolejte zkratce rozšíření oprávnění na konfiguračním stromu nebo odstranění sandboxu. Obojí odstraní symptom, ale zároveň odstraní ochrany, které tam byly dány záměrně, a další selhání bude těžší interpretovat.

Restartujte instanci a čtěte další událost, místo abyste předpokládali úspěch. Pravděpodobná další chyba je, že OpenVPN nemůže otevřít svůj konfigurační soubor, což je pokrok: do pracovního adresáře se vstoupilo a parser už běží. Od té chvíle sledujte skutečné mapování souborů unity, místo abyste se vraceli k síťovému troubleshootingu.

Referenční příručka systemd k provádění definuje, jak se pracovní adresář vykládá spolu s kořenovými adresáři a sandboxem. Vzorec k zapamatování je jednoduchý: každý stavový kód pojmenovává jinou fázi a aplikaci popisují jen její vlastní chyby.