Az OpenVPN nem találja a ca.crt fájlt, pedig a profil betöltődik

A szolgáltatás elindul, panasz nélkül beolvassa a profilt, majd meghal egy soron, amely nem tűnik összefüggőnek: nem tudja megnyitni a ca.crt fájlt. A tanúsítványon semmi nem változott, és a profil útvonala az unit fájlban abszolút. Pont ez a kombináció az árulkodó jel. A megadott útvonal egy fájlt azonosít, és az abban a fájlban lévő nevek egészen máshol oldódnak fel, így egy teljesen minősítettnek látszó indítás még mindig olyan könyvtárból olvashatja a kulcsait, amelyet senki nem szánt rá.

A hibának kevés oka van, és érdemes sorrendben szétválasztani őket: az alapkönyvtár, amely a folyamatnak valójában volt, a szolgáltatás indítási környezete, valamint a fájl körüli jogosultságok vagy sandbox, amikor az útvonal már helyes. Mindegyik más nyomot hagy — az unit fájlban, a folyamatban és a fájlrendszeren.

A profil útvonala nem alapkönyvtár

Képzeljen el egy folyamatot, amely a /tmp könyvtárban indul, és megkapja a /etc/vpn/prod/tenant-a.ovpn útvonalat. A profilon belül a ca ca.crt sor relatív útvonalat nevez meg. Semmi a profilra mutató argumentumban nem írja át ezt a nevet, ezért a folyamat a /tmp/ca.crt útvonalat keresi, és hiányzó fájlt jelent.

A zavaró a hibák sorrendje. Az OpenVPN először elemzi a konfigurációt, és a hivatkozott fájlokat akkor nyitja meg, amikor eléri őket, ezért a profilban lévő elírás jelentése még azelőtt megtörténik, hogy bármely kulcshoz hozzáérnének, míg a hiányzó tanúsítvány csak akkor jelenik meg, amikor az elemzés odáig jut. A betöltődő profil tehát a szintaxis helyességének bizonyítéka, nem annak, hogy a megnevezett fájlok megtalálhatók.

Mit választ szét a kézikönyv: --config és --cd

Az OpenVPN 2.6 kézikönyve két különböző kapcsolót ír le. Az egyik konfigurációs fájlt tölt be. A másik a folyamat könyvtárát változtatja meg, mielőtt a konfiguráció, a kulcs, a szkript és más fájlok beolvasásra kerülnek, és abszolút könyvtárat követel, az aktuálisra való hivatkozás nélkül.

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

Ez a hívás forma, nem utasítás valaki más profiljának indítására. Amit ad, az a determinizmus: a lánc minden relatív nevének alapja a parancsban szerepel, nem pedig a folyamatot indító héjból vagy kezelőből öröklődik. Az alternatíva ugyanolyan érvényes, és szolgáltatás esetén gyakran jobb: hagyja békén a munkakönyvtárat, és tegyen minden hivatkozott fájlt abszolúttá a profilon belül.

Bármelyiket választja, az egész láncot vizsgálja, ne az első hibát. Egy profil behúzhat egy másik konfigurációs fájlt, és a beemelt fájl relatív nevei ugyanahhoz a folyamatkönyvtárhoz oldódnak fel, nem a beemelő fájl könyvtárához. A naplóútvonalak, a hitelesítési fájlok és a segédszkriptek ugyanezt a szabályt követik.

A szolgáltatás máshol indul

A profil könyvtárában futó interaktív héj semmit nem bizonyít egy csomagolt unitról. A kezelők saját munkakönyvtárat állítanak be, és egy burkoló szkript ezt újra megváltoztathatja, mielőtt a bináris elindul. A hibát adó unit az egyetlen indítás, amelyről érdemes gondolkodni.

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

A második parancs megmutatja, melyik könyvtárat tartja valójában a futó folyamat, és ez megbízhatóbb az unit fájlnál, ha burkoló van a folyamatban. Ha a kettő nem egyezik, a burkoló a válasz, az unit pedig hamis nyom.

A keresés után: jogosultságok, chroot és sandbox

Egy helyes alapkönyvtár még mindig ugyanazt az üzenetet adhatja, mert a feloldás és a hozzáférés külön lépés. A folyamatnak minden szülőkönyvtáron végrehajtási, a fájlon pedig olvasási jogosultságra van szüksége, és egy olyan szolgáltatás-unit, amely elrejti a fájlrendszer egy részét, megváltoztatja, mit láthat egyáltalán a folyamat.

Három gyakori változat azonos hibát ad. A fájl csak root számára olvasható, miközben a szolgáltatás a megnyitás előtt leadja a jogosultságokat. Az unit olyan védő fájlrendszer-nézetet állít be, amely nem tartalmazza a profil könyvtárát. A démon chroottal fut, ezért a gazdagépen létező útvonal nem létezik ezen a nézeten belül.

A fájl tulajdonosa és a folyamat identitása alapján diagnosztizáljon, ne a jogosultságok lazításával. Egy privát kulcs mindenki számára olvashatóvá tétele, hogy elnémítsa ezt a hibát, hangos hibát cserél csendesre, és a kulcs éppen a könyvtár azon része, amelyet a legkevésbé szeretne kitenni.

Bizonyítsa a javítást a saját indítással

Indítsa újra az igazi unitot a profilhoz nem kapcsolódó könyvtárból, és figyelje ugyanazt az indítási sort. Utána erősítse meg, hogy a folyamat futás közben a szándékolt könyvtárat tartja, és hogy a betöltött tanúsítvány a várt.

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

Amikor az útvonalak betöltése sikerül, a hitelesítés és az útválasztás továbbra is külön szakasz a saját hibáikkal, és egy feljövő, de forgalmat nem átengedő kapcsolat más vizsgálat. Az itteni javítás csak arról szól, melyik könyvtárból jöttek a fájlok, és a hívásban látszania kell, nem pedig annak kell emlékeznie rá, aki utoljára kézzel futtatta.

Ha a profilt konfigurációkezelő telepíti, tegye oda az alapkönyvtárat vagy az abszolút fájlneveket is. Az egy gazdagépen végzett kézi javítás a probléma azon változata, amely a következő újraépítés után visszatér.