Az OpenVPN active (exited) állapotot mutat? Keresse meg az általa indított példányt

Ellenőrzi az alagutat, lefuttatja a systemctl status openvpn parancsot, és active (exited) állapotot kap Main PID nélkül és üres folyamatlistával. A természetes olvasat az, hogy a szolgáltatás elindult és meghalt, ezért megnyitja az unitot, megtalálja a /bin/true-t, és arra a következtetésre jut, hogy a csomag törött. A Debian csomagolásában ez az állapot a wrapper, amely úgy működik, ahogy tervezték, és az alagút az általa indított instance-unitok egyikében él. Az összesítő unit soha nem fogja megmondani, melyik példány építette fel.

Mit jelent valójában az active (exited) ezen az uniton

A csomagolt unit egyszeri feladat: az ExecStart /bin/true, és a RemainAfterExit=yes az, ami egy befejezett unitot active (exited) állapotúként jelent. Vegye el ezt a direktívát, és ugyanaz a sikeres /bin/true feladat inactive (dead) állapotban ér véget, ami pontosan az az állapot, amelyet az emberek várnak, és az ellenkező irányban félreolvasnak. A parancs csak helyőrző, és az unit arról számol be, amit más unitok végeznek. Ebben az elrendezésben semmi sem törött, és a /bin/true lecserélése a csomagolási szerződést változtatja meg, nem az alagutat.

A wrapper delegál. Elindítja azokat az instance-unitokat, amelyeket a csomag konfigurációja vagy annak systemd-generátora biztosít, ezért az üres folyamatlista semmit sem bizonyít az alagútról. Ha nincs kiválasztva példány, a wrapper akkor is sikeres, és akkor sem indít semmit. Az állapot arra válaszol, hogy a wrapper futott-e, nem arra, hogy létezik-e alagút.

Olvassa a status kimenetének három sorát, ne a zárójelben lévő szót. A Loaded megnevezi az unitfájlt, amelyet a systemd beolvasott, az Active az utolsó sikeres futás időbélyegét hordozza, és a hiányzó Main PID egy befejezett egyszeri feladatnak felel meg. Ez a három sor az is, amivel megkülönböztetheti ezt a wrappert egy szolgáltatástól, amely egy másodperccel az indítás után összeomlott.

Listázza az unitokat, mielőtt újra olvasná a statust

Kérdezze meg a systemdtől, mi létezik, mielőtt azt kérdezné, mi fut. Egy sablon telepítve lehet, miközben nincs példány létrehozva, és csak egy létrehozott unit hordoz alagutat. Kezdje a betöltött készlettel:

systemctl list-units 'openvpn*'

Ez a lista az, amit a systemd ebben a pillanatban betöltött, és ez áll legközelebb egy alagútleltárhoz. A telepített unitfájlok más kérdésre válaszolnak, és ez a lista még mindig sablont mutat, ha semmi sincs létrehozva:

systemctl list-unit-files 'openvpn*'

Olvassa a két listát együtt, mert a másodikban egy sablon és az elsőben egy példány két különböző válasz. Egy létező sablon és egy futó példány nem ugyanaz a tény, és csak a második jelent alagutat. A csomagelrendezések disztribúciónként és OpenVPN-verziónként is eltérnek. Egy régebbi openvpn@ sablon, egy különálló client és server pár és egy disztribúciós wrapper mind legitim lehet a saját csomagolásában.

A saját gépéhez alkalmazkodjon, ne a talált útmutatóhoz. Egy másik kimenetében a példány neve office lehet, míg az öné home vagy work. A módszer adódik át, nem a karakterlánc.

Kövesse a példány nevét addig a fájlig, amelyet olvas

Az upstream client sablonban az unit munkakönyvtára /etc/openvpn/client, és a parancsa onnan veszi a %i.conf fájlt, tehát az openvpn-client@office az /etc/openvpn/client/office.conf fájlt olvassa. Erősítse meg ezt a leképezést a telepített uniton ahelyett, hogy a példában bízna, mert a sablonja régebbi vagy disztribúciós átírás lehet:

systemctl cat [email protected]

Olvassa a kimenet alján megjelenő drop-inokat, mert a .d/ alatti fájl megváltoztathatja az ExecStartot, a munkakönyvtárat vagy a konfigurációs útvonalat. Az office.ovpn néven letöltött profil nem az a fájl, amelyet a példány megnyit. Ez a rés az oka annak, hogy egy hiba olyan útvonalat nevez meg, amelyet soha nem szerkesztett.

A profilon belüli relatív útvonalak a következő csapda. A fő fájl áthelyezése, miközben a ca, cert és key hivatkozások relatívak maradnak, egy hiányzó fájl hibát egy másik hiányzó fájl hibára cserél. A második olyan fájlra mutat, amelyről biztos volt, hogy létezik, ezért a profil könyvtára fontosabb, mint a fájlnév.

Indítsa el, majd olvassa el annak a példánynak a naplóját

Indítsa el az éppen megvizsgált példányt, mert az összesítő unit naplója nem fogja tartalmazni az alagút hibáit. Ezután olvassa el ennek az indításnak a naplóját, és ebben a sorrendben keressen konfigurációs hibát, fájlhozzáférési hibát és kapcsolódási hibát, mert mindegyik az indítás más szakaszában hibázik.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Az indítás és az engedélyezés külön döntések: a start most futtatja az unitot, az enable a következő indítást rendezi, az enable --now pedig mindkettőt egy lépésben teszi. A daemon-reload újraolvassa az unitdefiníciókat, és nem indít újra egy futó folyamatot, és nem alkalmaz egy szerkesztett profilt. A profil módosítása után indítsa újra a példányt, mert az olvassa újra a fájlt.

Ne tegyen második kezelőt ugyanarra az alagútra

A NetworkManager és az OpenVPN 3 munkamenet-kezelői saját kapcsolati állapottal rendelkeznek, és egy systemd-példány mellettük két tulajdonost tesz ugyanarra az alagútra. A tünet egy alagút, amely feljön, majd másodpercekkel később lecserélődik, vagy egy olyan, amely megtagadja, hogy leállva maradjon. Válassza azt a kezelőt, amelyet a disztribúciója az asztali környezethez dokumentál, és szerveren használja szándékosan a systemd-t.

Indítson példányt csak akkor, ha előbb ellenőrizte a meglévő tulajdonost. Amikor egy asztali applet mutatja a kapcsolatot, az általa indított példány verseng vele ahelyett, hogy kiegészítené. Tiltsa le a nem használt kezelőt ahelyett, hogy mindkettőt futtatná, és abban bízna, hogy a sorrend tartja magát. Ez az ütközés magyarázza azokat a naplókat is, ahol egy alagút felépül, majd egy olyan folyamat bontja le, amelyet soha nem indított.

Válaszoljon az eredeti kérdésre a példány nevével, az általa olvasott fájllal és a meghiúsult naplósorral. Az OpenVPN systemd-integrációról szóló megjegyzései leírják a sablon elrendezését és azt a fájlleképezést, amelyen keresztül a példány neve feloldódik.