OpenVPN 3 Linux: olvasd el a D-Bus hibát, mielőtt visszagörgetnél

Az OpenVPN 3 Linux hibái D-Bus metódushibaként érkeznek egy ismeretlen névvel, és a kísértés az, hogy visszasorolj egy csomagot és reménykedj. A kliens nem egyetlen program: egy parancssori frontend beszél a buszon olyan szolgáltatásokkal, amelyek a profilokat, a munkameneteket, a VPN-motort és a jogosult hálózati változtatásokat birtokolják. Annak eldöntése, hogy ezek közül az öt közül melyik birtokolja a hibázó hívást, a diagnózis nagy része, és egy parancsba kerül visszagörgetés helyett. A következőkben ez a döntés áll, abban a sorrendben, ahogy a hibák általában megjelennek.

Öt tulajdonos egy parancs mögött

Öt folyamat számít, és mindegyiknek saját buszneve van: a frontend, amely elfogadja a parancsodat, a konfigurációkezelő, amely a profilokat és azok hozzáférési szabályzatát tárolja, a munkamenet-kezelő, amely a munkamenet élettartamát birtokolja, a háttérrendszer, amely az OpenVPN 3 Core Engine-en keresztül futtatja a kapcsolatot, és a hálózati konfigurációs szolgáltatás, amely telepíti az interfészt, az útvonalakat és a DNS-beállításokat. Egy konfigurációs objektumot megnevező hiba tehát nem háttérrendszer-hiba, és egy el nem induló háttérrendszer nem hitelesítési hiba. Az üzenet besorolását valamelyik sorba minden változtatás előtt el kell végezni, mert minden későbbi lépés attól függ, melyik sor igaz. A sor kitalálása az, ahogy egy rövid javításból egy délutáni csomagmunkálkodás lesz.

Kérdezd meg a rendszerbuszt, mely szolgáltatások vannak jelen, mielőtt bármi mást kérdeznél, majd erősítsd meg, hogy a telepített darabok egy verzióban egyetértenek. Az OpenVPN 3 Linux ezeket a szolgáltatásokat rendszeregységként regisztrálja, tehát a kérdezendő busz a rendszerbusz, a verziólekérdezéshez adminisztratív jogosultság kell, és a --user kapcsolóval készült lista a bejelentkezési munkamenetedet olvassa, ahol az egységek soha nem jelennek meg. A szolgáltatások igény szerint aktiválódnak, és némelyik tétlenség esetén kilép, tehát az első kérésed előtt hiányzó szolgáltatást egyszerűen még semmiről sem kérdezték. Az alábbi három parancs a jelenlétre, a verzióra és az egység állapotára válaszol anélkül, hogy VPN-munkamenetet nyitna.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Mit bizonyít valójában az egyes listák

A kliens saját nézetei a legolcsóbb rendelkezésre álló bizonyítékok, és mindegyik kevesebbet bizonyít, mint amilyennek látszik. Egy profil a konfigurációs listában azt mutatja, hogy egy profil importálva van, és semmit arról, hogy bárki csatlakozhat-e hozzá. Egy munkamenet a munkamenet-listában azt mutatja, hogy létezik munkamenet-objektum, és semmit arról, hogy a távoli hitelesítés befejeződött-e.

openvpn3 configs-list
openvpn3 sessions-list

Az objektumútvonalak azokban a kimenetekben a buszon kezelt objektumokat jelölnek, nem fájlokat, tehát nem szerkeszthetők, és egy korábban feljegyzett útvonal elavul abban a pillanatban, amikor az a munkamenet lecsatlakozik. Egy útvonal újrahasználata a jegyzeteidből "no such object" hibákat okoz, amelyeknek semmi közük a VPN-hez. Az alábbi szakasztáblázat elválasztja, mit épít fel a kapcsolat egyes lépése attól, mit hagy nyitva, és pontosan ettől a különbségtől függ egy visszagörgetési döntés. Olvasd el a bizonyítékodhoz illő sort, majd olvasd el újra a hiba szövegét.

A kapcsolódási hívás visszatér, mielőtt az alagút létezik

A kapcsolódási hívás ad neked egy figyelendő munkamenetet, majd visszatér, ezért egy látszólag sikeres, csenddel folytatódó hívás normális köztes állapot, nem ellentmondás. A frontendnek továbbra is követnie kell az állapotváltozásokat, és válaszolnia kell minden interakciós kérésre. Egy profil, amelynek hitelesítő adat kell, és nem kap választ, olyan állapotban vár, amely pontosan úgy néz ki, mint egy megakadt háttérrendszer. Ez a várakozó állapot felismerést érdemel, mert rossz komponenshez küldi az embereket.

Amíg egy kísérlet fut, figyeld a munkamenet-listát és a frontend saját naplóját arra a profilra. Egy munkamenet, amely soha nem hagyja el kezdeti állapotát, megnevezi a leállt komponenst, és a napló általában az első néhány sorban meg is nevezi. Tartsd kéznél a profil nevét, mivel a naplóparancs profilt vesz, nem munkamenet-útvonalat, ami még egy ok arra, hogy újraolvasd a listát ahelyett, hogy egy útvonalat újrahasználnál.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Egy komponens naplójának olvasása munkamenet nyitása nélkül

Amikor a frontend semmi hasznosat nem jelent, menj ahhoz a komponenshez, amely a hibát naplózta, ahelyett hogy új kapcsolatot indítanál. Beállított systemd-journald naplózó esetén az adminisztrátor határolt naplónézete egy komponens eseményeit olvassa anélkül, hogy hozzányúlna a buszszabályzathoz vagy munkamenetet nyitna, ami számít, mert az a diagnózis, amely megváltoztatja a mért rendszert, nagyon keveset bizonyít. Egység szerint szűrj, ne syslog-címke szerint: az egyes szolgáltatásegységek nem garantálnak közös azonosítót, így egy címkekérés üres oldalt adhat vissza, miközben maga az egység rögzítette a hibát.

Jegyezz fel négy mezőt, mielőtt bárkitől segítséget kérsz: a hiba teljes nevét, az érintett szolgáltatást és objektumot, az időbélyeget és a telepített csomagok verzióit. Ezekre van szüksége egy karbantartónak, és egyik sem igényli profil vagy hitelesítő adat beillesztését egy jegybe. A busz hozzáférési szabályzatának kiszélesítése a hiba elnémítására nem diagnózis, kitörli a határt, amely megnevezte neked a komponenst. A profilok privát tartalma kimarad a megosztott jelentésekből ugyanazon okból, mint a hitelesítő adatok.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Az elutasító határ javítása

A térkép minden sorának megvan a maga javítása, és a sorok nem helyettesítik egymást. Egy profilon megtagadott művelet szabályzat és tulajdonjog kérdése, míg az aktiválódni nem hajlandó háttérrendszer szolgáltatások és csomagolás kérdése. Egy kiszolgáló, amely elutasítja a hitelesítést, egyik sem, tehát ismételt jelszóváltoztatások nem javíthatnak egy helyi aktiválási problémát. A rossz javítás kiválasztása az, ahogy egy szabályzati probléma újratelepítéssé válik.

Csomagváltoztatás után ellenőrizz egy összefüggő, támogatott telepítést ahelyett, hogy egy régi binárist másolnál a helyére. Egy ellenőrzött visszagörgetés jogszerű válasz egy megerősített regresszióra, feltéve hogy a csomagok kompatibilisek maradnak, és létezik út vissza a támogatott karbantartáshoz. Alakítsd ki ezt az utat, mielőtt a szolgáltatás leáll az indulástól, ne utána.

Egy másik platform megoszthatja ugyanazt a VPN-alapkönyvtárat anélkül, hogy megosztaná a Linux buszszolgáltatásait, tehát egy hasonlóan kinéző hiba Windowson semmit sem mond erről. A D-Bus áttekintés dokumentálja a konfigurációkhoz és munkamenetekhez kitett objektumútvonalakat, és ez az az architektúrarész, amelyre ez a diagnózis támaszkodik. Olvasd el egyszer, és a következő hiba már egy odakapcsolt komponenssel érkezik.