Jou diens misluk voordat OpenVPN ooit loop, en die fout praat van 'n monteringseenheid wat jy nooit opgestel het nie. Dit is die teken: systemd weier die hele transaksie omdat die wortelmonteringseenheid gemaskeer is, en jou VPN-profiel is nog nie gelees nie. Die gewone oorsaak is 'n oorblywende lêer in die gids vir runtime-eenhede, nie 'n stukkende fstab nie en nie 'n ontbrekende sertifikaat nie. Volg eers die lêer, want dit is die goedkoopste verklaring om uit te skakel.

Die fout noem die wortelmontering, nie jou profiel nie

systemd genereer die wortelmonteringseenheid self uit die monteringsinligting van die kern, en dit noem die eenheid -.mount omdat 'n strepie vir die wortelpad staan. Daardie eenheid bestaan gewoonlik net in die geheue en het geen lêer daaragter nie. Wanneer die fout sê dit is gemaskeer, het iets 'n eenheidslêer neergesit waar systemd dit sal laai en daardie lêer na /dev/null laat wys. Die maskering is 'n werklike toestand, nie 'n tikfout in die boodskap nie.

Die instansie-eenheid misluk omdat sy taakgrafiek die wortelmontering bereik deur ordening en deur sy eie monteringsvereistes. Die transaksie word geweier voordat die OpenVPN-program uitgevoer word, so niks in die kliënt se opstelling kan die oorsaak wees nie. Daarom het die verandering van profiele, sertifikate of geloofsbriewe geen effek op hierdie spesifieke mislukking nie.

Kyk in die runtime-gids voordat jy OpenVPN ontfout

Soek 'n lêer met daardie presiese naam in die gids vir runtime-eenhede en vra dan vir systemd wat hy dink die eenheid is. Albei antwoorde is vinnig, en saam skei hulle 'n verdwaalde lêer van 'n werklike monteringsprobleem.

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

Op 'n normale masjien is daar geen sulke lêer nie, en die gemaskeerde lys bevat nie die wortelmontering nie. As die eerste opdrag 'n simskakel na /dev/null druk, is die diagnose klaar. Dieselfde gids kan 'n tmp.mount-maskering bevat wat deur dieselfde gereedskap geskep is, en dit veroorsaak dieselfde soort mislukking onder 'n ander naam. Kyk na die hele gids, nie net na die naam in die fout nie.

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

As die gids skoon is en die eenheid is steeds gemaskeer, woon die maskering elders in die soekpad, en systemctl cat -.mount sal wys watter lêer gelaai word.

Skrap die lêer, herlaai en begin weer

Om die runtime-lêer te verwyder en die bestuurder te herlaai is genoeg, en dit raak niks wat uit 'n pakket kom nie. Herlaai voordat jy begin, want systemd hou die gelaai eenheidstoestand totdat dit die gids weer lees.

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

Lees dan die diens se eie joernaal in plaas daarvan om te aanvaar die regstelling het gewerk. 'n Skoon begin bewys net dat systemd die eenheid aanvaar het; die kliënt kan steeds sterf op 'n ontbrekende profiel, 'n onbereikbare portuur of 'n sertifikaat wat nie valideer nie. Dit is gewone OpenVPN-probleme wat agter die gemaskeerde eenheid versteek was. Dit teken op watter profiel gelaai is en of die tonnel werklik tot stand gekom het. As die eenheid begin en die tonnel nie, het jy na 'n ander probleem beweeg, wat vooruitgang is.

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

Omdat /run 'n tydelike lêerstelsel is, wis 'n herbegin ook die lêer. Dit maak 'n herbegin 'n nuttige toets: as die diens ná 'n herbegin werk en weer misluk ná die volgende ontplooiing, word die lêer in die beeld ingebak.

Keer dat dit uit die beeld terugkom

'n Houer- of virtuele-masjien-sjabloon wat monteringseenhede tydens sy bou maskeer, sal daardie maskering na elke kloon dra. Wat volgende die lêerstelsel nodig het, breek, en die boodskap blameer die montering in plaas van die beeld waar dit vandaan kom. Om dit binne een lopende instansie reg te maak, verberg die probleem tot die volgende instansie geskep word.

Soek in die bou-konteks na die lêernaam en na die opdrag wat dit skep, verwyder dan die maskering uit die sjabloon en bou weer. As die maskering werklik tydens die bou nodig is, verwyder dit in dieselfde laag wat die bou voltooi, sodat die verskepte beeld skoon begin. Verifieer op 'n vars kloon eerder as op die masjien wat jy met die hand herstel het. Dit is die enigste toets wat bewys die beeld het verander.

Die simptoom om te onthou is die wanverhouding tussen die fout en die ding wat jy opgestel het. Wanneer systemd oor 'n montering kla terwyl jy 'n VPN-kliënt begin, lees die eenheidsnaam in die boodskap voordat jy die diensnaam lees.

Verwante artikels