status=200/CHDIR: systemd OpenVPN vôbec nespustil
Zlyhanie CHDIR znamená, že systemd nedokázal vstúpiť do adresára, nie že OpenVPN nedokázal prečítať profil. Prečítajte si unit skôr, než siahnete na konfiguráciu VPN.
Služba zlyháva, v logoch sa objavuje spawn a adresár a prvým inštinktom je skontrolovať konfiguráciu VPN. Z toho súboru zatiaľ nebolo nič prečítané. systemd zlyhal pri príprave procesu, ešte pred spustením spustiteľného súboru, takže nebol konzultovaný žiadny parser, žiadny certifikát ani vzdialený hostiteľ. Čítať stavový kód ako tvrdenie o systemd, a nie o OpenVPN, je to, čo z toho robí krátke vyšetrovanie.
Prečítajte stavový kód skôr než aplikáciu
Číselný kód za názvom služby pomenúva fázu, ktorá zlyhala. Zlyhanie adresára sa hlási ako stav CHDIR, kým spustiteľný súbor, ktorý sa nepodarilo spustiť, je úplne iný kód. Tie dva vyzerajú v súhrnnom riadku podobne a na svojich príčinách nemajú nič spoločné.
Ten rozdiel je dôležitý, pretože opravy sú v rôznych súboroch. Zlyhanie CHDIR sa týka cesty a toho, ako ju služba vidí. Zlyhanie exec sa týka binárky, jej interpreta alebo nesúvisiaceho pripojenia. Zmena vzdialeného bodu VPN, zoznamu šifier alebo cesty k certifikátu nevyrieši ani jedno.
Potvrďte, že zlyhanie je pri štarte a nie po úspešnom behu. Ak služba včera fungovala a teraz zlyháva v tej istej fáze, niečo sa zmenilo na adresári, jeho oprávneniach alebo na samotnej unite, a tá zmena je dôkaz, ktorý máte hľadať.
Opýtajte sa unity, kde chce byť
Čítajte efektívnu unitu, nie súbor, o ktorom si myslíte, že je nainštalovaný, pretože drop-iny môžu prepísať pracovný adresár bez toho, aby ste kedy upravili hlavnú unitu. Výstup show odpovedá na otázku priamo:
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
Pri šablóne upstream servera je pracovným adresárom adresár konfigurácie servera a názov inštancie vyberá profil v ňom. Inštancia s názvom branch teda očakáva svoj vlastný súbor v tom istom adresári a profil umiestnený inde požiadavku na pracovný adresár vôbec nespĺňa.
Porovnajte, čo unit žiada, s tým, čo existuje. Cesta, ktorá kedysi existovala, symbolický odkaz, ktorý teraz ukazuje inam, alebo názov inštancie, ktorý už nezodpovedá adresáru, sú bežné zmeny, ktoré spôsobujú presne túto chybu.
Skontrolujte cestu tak, ako ju vidí služba
Váš shell a služba nezdieľajú rovnaký pohľad na súborový systém. Nastavený koreňový adresár alebo root image mení, čo znamená absolútna cesta vnútri unity, a cesta, ktorá je na hostiteľovi zjavne prítomná, môže v tom namespace chýbať. Prečítajte si nastavenia unity skôr, než uveríte ručnému testu.
Oprávnenia problém ešte zhoršujú. Služba beží ako konkrétny používateľ a ten musí byť schopný prejsť každým nadradeným adresárom, aby sa dostal k cieľu, nielen prečítať samotný cieľ. Adresár čitateľný pre root a nepriechodný pre používateľa služby vytvára zlyhanie, ktoré vyzerá ako chýbajúca cesta.
namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths
Do tohto obrazu patria aj nastavenia spevnenia. Unita, ktorá skrýva domovské adresáre alebo robí časť súborového systému iba na čítanie, robí presne to, na čo bola nakonfigurovaná, a pracovný adresár musí žiť niekde, kde ho sandbox ešte vystavuje.
Opravte vlastníka a potom očakávajte inú chybu
Opravte rozloženie alebo unitu prostredníctvom toho, kto tú konfiguráciu vlastní. Presun profilu do očakávaného adresára je legitímna oprava, keď je rozloženie zlé, ale nevysvetľuje adresár, do ktorého sa nedá vstúpiť, takže to neberte ako všeobecnú odpoveď.
Odolajte skratke rozšírenia oprávnení na konfiguračnom strome alebo odstránenia sandboxu. Oboje odstráni symptóm, ale zároveň odstráni ochrany, ktoré tam boli dané zámerne, a ďalšie zlyhanie bude ťažšie interpretovať.
Reštartujte inštanciu a čítajte ďalšiu udalosť namiesto predpokladu úspechu. Pravdepodobná ďalšia chyba je, že OpenVPN nemôže otvoriť svoj konfiguračný súbor, čo je pokrok: do pracovného adresára sa vstúpilo a parser už beží. Odvtedy sledujte skutočné mapovanie súborov unity namiesto návratu k sieťovému riešeniu problémov.
Referenčná príručka systemd k vykonávaniu definuje, ako sa pracovný adresár interpretuje spolu s koreňovými adresármi a sandboxom. Vzorec na zapamätanie je jednoduchý: každý stavový kód pomenúva inú fázu a aplikáciu opisujú len jej vlastné chyby.