A client-config-dir figyelmen kívül marad, miután az OpenVPN szolgáltatás lett

Az alagút feljön és a kliens csatlakozik, de a fix cím és azok a tolt útvonalak, amelyeket ehhez az egy felhasználóhoz definiáltál, hiányoznak. A napló nem írja, hogy “file not found”, és éppen ez küldi az embereket tanúsítványokat újragenerálni. A legtöbb ilyen esetben a daemon más könyvtárból fut, mint a héj, amelyben teszteltél, és client-config-dir soha nem úgy oldódott fel, ahogy feltételezted. A javítás útvonal-javítás, nem hitelesítő adatok visszaállítása.

Olvasd el az unitot, mielőtt a konfigurációhoz nyúlsz

A ténylegesen futó folyamattal kezdd, ne a szerkesztett fájllal. Kérdezd meg a systemd-től a végrehajtási sort, a munkakönyvtárat és azt a fiókot, amelyre levált. Ez a három válasz magyarázza az ebbe az osztályba tartozó hibák többségét:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

Egy üres WorkingDirectory azt jelenti, hogy az unit a / könyvtárban indul, így a relatív client-config-dir ccd /ccd alatt keresendő. Az a könyvtár szinte soha nem létezik, és a daemon nem tekinti végzetesnek a hiányát.

Hasonlítsd össze ezt azzal az interaktív indítással, amelyet tesztelés közben használtál, ahol a héjad aktuális könyvtára valószínűleg a konfigurációs könyvtár volt. Ugyanaz a fájl, ugyanazok a kulcsszavak, két különböző eredmény.

Mihez képest oldódik fel egy relatív útvonal

A kulcsszó a folyamat munkakönyvtárához képest oldódik fel abban a pillanatban, amikor az opciót használják. Nem azt jelenti, hogy “a --config kapcsolóval átadott konfigurációs fájl mellett”. Az OpenVPN szívesen olvas konfigurációt abszolút útvonalról, és a relatív értékeket mégis máshol oldja fel, és pontosan ez a csapda itt. Az OpenVPN 2.6 kézikönyve a --client-config-dir alatt és ismét a --cd alatt mondja ki a szabályt.

A cd kulcsszó megváltoztatja ezt a kontextust, mielőtt más fájlokat olvasnának, így egy unit, amely cd /etc/openvpn/server majd client-config-dir ccd beállítást tartalmaz, /etc/openvpn/server/ccd-ra oldódik fel. Ha hozzáadod a cd beállítást, ellenőrizd a direktívák sorrendjét, és ne feledd, hogy hatással van az ugyanabban a fájlban szereplő minden más relatív hivatkozásra.

Járd végig az útvonalat a daemon fiókjaként

Egy útvonal lehet helyes és mégis olvashatatlan. A jogosultságok csökkentése után a daemon már nem root, ezért minden szülőkönyvtárnak keresési jog kell ehhez a fiókhoz, és magának a kliensfájlnak olvasási jog. Egyetlen hiányzó végrehajtási bit egy szülőn elég ahhoz, hogy elrejtse a fájlt, és a hiba csak úgy jelenik meg, mint egy kliens, amely csendben megkapja az alapértelmezett készletet.

A namei sorban kiírja az egyes összetevők jogosultságát, ami gyorsabb, mint a könyvtárak egyenkénti ellenőrzése:

namei -l /etc/openvpn/server/ccd/client1

Ezután a szolgáltatásfiókkal teszteld az olvasást, ne saját magadként:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Ha az unit a chroot lehetőséget használja, a könyvtárnak a börtönön belül kell léteznie, és a konfigurációban szereplő útvonal a chroot alkalmazása után értelmeződik. Egy fájl, amely a gazdagépen a börtönön kívül van, belülről láthatatlan.

Igazold a keresést a találgatás helyett

Emeld a naplószintet egy újraindításra, és olvasd el, mit mond a szerver a kliensspecifikus opciókról. A verb 4 szinten a daemon jelenti az importált kliensenkénti konfigurációt, így egy hiányzó sor közvetlen bizonyíték arra, hogy ehhez a kapcsolathoz nem olvasott be fájlt.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Futtasd ezt előtérben egy másik porton, és csatlakoztass egy klienst. Ez teljesen kiveszi a systemd-t a képből: ha a felülírások itt jelennek meg és nem a szolgáltatás alatt, a különbség az unit kontextusában van, nem a fájlban.

Döntsd el, mi történjen, ha egyetlen fájl sem illeszkedik. A ccd-exclusive nélkül a klienst csak a globális készletbeállításokkal fogadják el, és ez a fent leírt csendes hiba. Vele egy hiányzó fájl elutasított kapcsolattá válik, és ez az elutasítás könnyebben észrevehető, de terhelés alatt nehezebben hibakereshető.

Javíts, indíts újra, ellenőrizz

Tedd abszolúttá a könyvtárat a konfigurációban, és hagyd így. A relatív útvonalak csak akkor biztonságosak, ha az unit rögzíti a munkakönyvtárat, a rögzítés pedig egy további mozgó alkatrész, amelyet valaki később eltávolít.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Indítsd újra a példányt, csatlakoztass újra egy ismert klienst, és olvasd el a kapott címet, valamint a hozzá tolt útvonalakat. Ha a cím megegyezik a kliens fájljában lévő ifconfig-push sorral, a keresés működött. Ha a kliens továbbra is az általános készletbe esik, térj vissza a naplósorok számához: nulla import azt jelenti, hogy az útvonal vagy az azonosság hibás, egy rossz tartalmú import pedig azt, hogy más fájlt szerkesztesz, mint amelyet a daemon olvas.

Lépj vissza az előző unit és konfiguráció együttes visszaállításával, majd indítsd újra. Tanúsítványokat ehhez nem kell újra kiadni, és a könyvtárproblémát hitelesítőadat-problémaként kezelni az az út, amelyen egy ötperces javításból karbantartási ablak lesz.