Įrenginys -.mount užmaskuotas: OpenVPN klientas nepasileidžia

Jūsų tarnybą sugenda dar prieš tai, kai OpenVPN apskritai paleidžiamas, o klaidos pranešime kalbama apie prijungimo įrenginį, kurio niekada nekūrėte. Tai ir yra ženklas: systemd atmeta visą operaciją, nes šakninis prijungimo įrenginys yra užmaskuotas, o jūsų VPN profilis dar neperskaitytas. Įprasta priežastis – pasilikęs failas vykdymo laiko įrenginių kataloge, o ne sugadintas fstab ir ne trūkstamas sertifikatas. Pirmiausia patikrinkite failą, nes tai pigiausias paaiškinimas, kurį galima atmesti.

Klaida nurodo šakninį prijungimą, o ne jūsų profilį

systemd pats sukuria šakninio prijungimo įrenginį iš branduolio prijungimo informacijos ir pavadina įrenginį -.mount, nes brūkšnelis žymi šaknies kelią. Šis įrenginys paprastai egzistuoja tik atmintyje ir neturi jokio failo. Kai klaida sako, kad jis užmaskuotas, kažkas įdėjo įrenginio failą ten, kur systemd jį įkels, ir nukreipė tą failą į /dev/null. Užmaskavimas yra reali būsena, o ne rašybos klaida pranešime.

Egzemplioriaus įrenginys sugenda, nes jo užduočių grafas pasiekia šakninį prijungimą per eiliškumą ir per savo paties prijungimo reikalavimus. Operacija atmetama prieš paleidžiant OpenVPN dvejetainį failą, todėl niekas kliento konfigūracijoje negali būti priežastis. Štai kodėl profilių, sertifikatų ar prisijungimo duomenų keitimas neturi jokios įtakos šiam konkrečiam gedimui.

Patikrinkite vykdymo laiko katalogą prieš derindami OpenVPN

Ieškokite failo tiksliai tokiu pavadinimu vykdymo laiko įrenginių kataloge, tada paklauskite systemd, kuo jis mano esant įrenginį. Abu atsakymai greiti, o kartu jie atskiria pasilikęs failą nuo tikros prijungimo problemos.

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

Įprastoje mašinoje tokio failo nėra, o užmaskuotų sąraše nėra šakninio prijungimo. Jei pirmoji komanda išspausdina simbolinę nuorodą į /dev/null, diagnozė aiški. Tame pačiame kataloge gali būti tų pačių įrankių sukurtas tmp.mount užmaskavimas, ir jis sukelia tą pačią gedimų klasę kitu pavadinimu. Žiūrėkite į visą katalogą, o ne tik į klaidoje nurodytą pavadinimą.

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

Jei katalogas švarus, o įrenginys vis dar užmaskuotas, užmaskavimas yra kitur paieškos kelyje, ir systemctl cat -.mount parodys, kuris failas įkeliamas.

Ištrinkite failą, įkelkite iš naujo ir paleiskite iš naujo

Pakanka pašalinti vykdymo laiko failą ir iš naujo įkelti valdytoją, ir tai neliečia nieko, kas atėjo iš paketo. Įkelkite iš naujo prieš paleisdami, nes systemd išlaiko įkelto įrenginio būseną, kol dar kartą perskaitys katalogą.

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

Tada skaitykite pačios tarnybos žurnalą, o ne darykite prielaidą, kad pataisymas suveikė. Švarus paleidimas įrodo tik tai, kad systemd priėmė įrenginį; klientas vis tiek gali žūti dėl trūkstamo profilio, nepasiekiamo partnerio ar sertifikato, kuris nevaliduoja. Tai įprastos OpenVPN problemos, kurios buvo paslėptos už užmaskuoto įrenginio. Žurnalas užrašo, kuris profilis įkeltas ir ar tunelis tikrai buvo sukurtas. Jei įrenginys paleidžiamas, o tunelis ne, perėjote prie kitos problemos, ir tai yra pažanga.

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

Kadangi /run yra laikina failų sistema, perkrovimas taip pat ištrina failą. Todėl perkrovimas yra naudingas bandymas: jei tarnyba veikia po perkrovimo ir vėl sugenda po kito diegimo, failas įkepamas į atvaizdą.

Užkirkite kelią, kad jis negrįžtų iš atvaizdo

Konteinerio ar virtualios mašinos šablonas, kuris kūrimo metu užmaskuoja prijungimo įrenginius, perneš tą užmaskavimą į kiekvieną kloną. Kitas dalykas, kuriam reikia failų sistemos, sugenda, o pranešimas kaltina prijungimą, o ne atvaizdą, iš kurio jis atėjo. Sutaisymas viename veikiančiame egzemplioriuje paslepia problemą iki kito egzemplioriaus sukūrimo.

Kūrimo kontekste ieškokite failo pavadinimo ir jį sukuriančios komandos, tada pašalinkite užmaskavimą iš šablono ir kurkite iš naujo. Jei užmaskavimo tikrai reikia kūrimo metu, pašalinkite jį tame pačiame sluoksnyje, kuris užbaigia kūrimą, kad siunčiamas atvaizdas prasidėtų švariai. Patikrinkite naujame klone, o ne mašinoje, kurią taisėte rankomis. Tai vienintelis bandymas, įrodantis, kad atvaizdas pasikeitė.

Simptomas, kurį verta atsiminti, yra neatitikimas tarp klaidos ir to, ką konfigūravote. Kai systemd skundžiasi prijungimu, o jūs paleidžiate VPN klientą, pirmiausia perskaitykite pranešime esantį įrenginio pavadinimą, o tik paskui tarnybos pavadinimą.