Vaše služba selže dřív, než se OpenVPN vůbec spustí, a chyba mluví o jednotce připojení, kterou jste nikdy nenastavili. To je ten příznak: systemd odmítá celou transakci, protože jednotka kořenového připojení je maskovaná, a váš profil VPN ještě nebyl přečten. Obvyklou příčinou je zbytek souboru v adresáři runtime jednotek, ne rozbité fstab a ne chybějící certifikát. Jděte nejdřív po souboru, protože je to nejlevnější vysvětlení, které lze vyloučit.

Chyba jmenuje kořenové připojení, ne váš profil

systemd generuje jednotku kořenového připojení sám z informací o připojení z jádra a jednotku pojmenuje -.mount, protože pomlčka zastupuje kořenovou cestu. Tato jednotka obvykle existuje jen v paměti a nemá za sebou žádný soubor. Když chyba říká, že je maskovaná, někdo umístil soubor jednotky tam, kde ho systemd načte, a nasměroval ho na /dev/null. Maska je skutečný stav, ne překlep ve zprávě.

Jednotka instance selže, protože její graf úloh dosáhne na kořenové připojení přes řazení a přes vlastní požadavky na připojení. Transakce je odmítnuta dřív, než se spustí binárka OpenVPN, takže nic v konfiguraci klienta nemůže být příčinou. Proto změna profilů, certifikátů nebo přihlašovacích údajů na tuto konkrétní závadu nemá vliv.

Než začnete ladit OpenVPN, prohlédněte adresář runtime

Hledejte soubor s tímto přesným názvem v adresáři runtime jednotek a pak se systemd zeptejte, co si o jednotce myslí. Obě odpovědi jsou rychlé a dohromady oddělí zbloudilý soubor od skutečného problému s připojením.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

Normální stroj takový soubor nemá a seznam maskovaných jednotek kořenové připojení neobsahuje. Pokud první příkaz vypíše symbolický odkaz na /dev/null, je diagnóza jasná. Ve stejném adresáři může být i maska tmp.mount vytvořená stejnými nástroji, a ta způsobuje stejnou třídu závady pod jiným názvem. Prohlédněte celý adresář, ne jen název z chyby.

ls -la /run/systemd/system/*.mount

Pokud je adresář čistý a jednotka je stále maskovaná, maska žije jinde v prohledávané cestě a systemctl cat -.mount ukáže, který soubor se načítá.

Soubor smažte, znovu načtěte a spusťte znovu

Odstranit soubor z runtime a znovu načíst správce stačí a ničeho z balíčku se to nedotkne. Načtěte znovu před spuštěním, protože systemd drží stav načtené jednotky, dokud adresář znovu nepřečte.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Pak si přečtěte vlastní log služby, místo abyste předpokládali, že oprava zabrala. Čisté spuštění dokazuje jen to, že systemd jednotku přijal; klient může stále padnout na chybějícím profilu, nedostupném protějšku nebo certifikátu, který se neověří. To jsou obyčejné problémy OpenVPN, které byly schované za maskovanou jednotkou. Log zaznamená, který profil se načetl a zda se tunel skutečně navázal. Pokud jednotka startuje a tunel ne, přesunuli jste se k jinému problému, což je pokrok.

journalctl -u [email protected] -b --no-pager

Protože /run je dočasný souborový systém, restart soubor také smaže. To dělá z restartu užitečný test: pokud služba po restartu funguje a po dalším nasazení znovu selže, soubor se peče do image.

Zabraňte tomu, aby se vrátil z image

Šablona kontejneru nebo virtuálního stroje, která při sestavování maskuje jednotky připojení, přenese tuto masku do každého klonu. Co bude příště potřebovat souborový systém, se rozbije, a zpráva viní připojení místo image, ze kterého přišlo. Oprava uvnitř jedné běžící instance problém skryje až do vytvoření další instance.

Prohledejte kontext sestavení kvůli názvu souboru a příkazu, který ho vytváří, pak masku ze šablony odstraňte a sestavte znovu. Pokud je maska během sestavování opravdu potřeba, odstraňte ji ve stejné vrstvě, která sestavení dokončuje, aby dodávaný image startoval čistý. Ověřte to na čerstvém klonu, ne na stroji, který jste opravili ručně. To je jediný test, který dokazuje, že se image změnil.

Příznak, který si zapamatujte, je nesoulad mezi chybou a věcí, kterou jste nastavovali. Když si systemd stěžuje na připojení, zatímco spouštíte klienta VPN, přečtěte si nejdřív název jednotky ve zprávě a pak název služby.

Související články