journalctl a VPN-naplókhoz: melyik unit birtokolja a kapcsolatot?

Kezdje azzal a systemd-unittal, amely valóban birtokolja a VPN-kapcsolatot, ne azzal a naplóparanccsal, amelyre emlékszik. Egy közvetlen OpenVPN-szolgáltatás, egy wg-quick-unit és egy NetworkManager-profil különböző unitekbe helyezi hasznos üzeneteit, és a rossz unithoz intézett lekérdezés üres eredményt ad, amely csendnek látszik. Hasonlítsa össze a három gyakori tulajdonost, szűkítse az ablakot, majd olvassa el a szakaszokat sorrendben.

Hasonlítsa össze a három gyakori tulajdonost

Az OpenVPN kliensszolgáltatás általában a profilról elnevezett példányunit, például [email protected]. Üzenetei közé tartozik a konfigurációs útvonal, az opciók feldolgozása, a TLS-kézfogás és az útvonal telepítése, amelyet az ügyfél végez.

A wg-quick-unit tervezésénél fogva csendesebb. Az interfész konfigurációja induláskor történik, a kézfogást a kernel kezeli, a rutinszerű kulcsfrissítések pedig alapértelmezés szerint nem kerülnek naplóba, ezért a wg show gyakran beszédesebb a naplónál. Ez a különbség akkor számít, amikor egy tárgyalást naplózó protokollt hasonlít össze egy olyannal, amely nem naplózza.

A NetworkManager birtokolja az általa létrehozott profilokat, és üzenetei a NetworkManager.service alatt élnek akkor is, amikor a mögöttes bővítmény VPN-segéd. Kérdezze le a kezelőt és a segédunitt is, amikor a profil így van kezelve.

Szűkítse a lekérdezést egy unitra és egy ablakra

Kérdezze le az azonosított unitot, és korlátozza az időt a vizsgált kísérletre. Egy nap általában elég, és a rövidebb ablak jobb, amikor a gép gyakran újracsatlakozik.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

Ellenőrizze a telepített nevet, mielőtt bízik a lekérdezésben. A disztribúció csomagolása átnevezi a unitokat, és előfordulhat, hogy egy fájlként létező profil soha nem lett szolgáltatásként engedélyezve. Ha az unit nem létezik, az üres napló a telepítésről beszél, nem az alagútról.

Olvassa el az első sikertelen szakaszt

Olvassa az eseményeket a bekövetkezésük sorrendjében: végpont keresése, szállítás, identitás, hitelesítés, útvonal telepítése és az alkalmazás későbbi kudarca. Az első konkrét kudarc az, amelyet érdemes vizsgálni, mert minden utána következmény.

Egy sikeresen induló szolgáltatás nem bizonyítja, hogy minden szükséges erőforrás elérhető. Az újracsatlakozási hurok több külön tárgyalást is létrehozhat, ezért tartsa a profil nevét és a kísérlet idejét az események mellett, és egy kísérletet olvasson összefésült adatfolyam helyett. Egyetlen kísérlet okkal rendelkező sorozat, míg az összefésült adatfolyam ismétlődő sorok fala. Írja be az első hibát a jegybe, mielőtt tovább olvasna.

Ne keverje össze a sikertelen szolgáltatást egy kézi klienssel

Ha a szolgáltatás kudarca után kézzel indított klienst, annak kimenete máshová megy, és a viselkedése eltérhet. Egy támogatott javítás után ugyanattól a tulajdonostól és ugyanazzal a kéréssel rögzítse az új eredményt, hogy az összehasonlítás megmutassa, mi változott, ahelyett hogy két különböző programot keverne össze.

Ne módosítsa az eredeti időbélyegeket, hogy egy másik gazdagéphez igazítsa őket. Jegyezze fel külön az időzónát és az ismert óraelérést, mert egy szerkesztett idővonal már nem bizonyíték.

Részletet osszon meg, ne exportot

A naplóbejegyzések felhasználóneveket, végpontcímeket, privát topológiát és szkriptkörnyezeti információkat tartalmazhatnak. Tekintse át a tényleges részletet, és takarja ki az érzékeny részeket, ahelyett hogy teljes, korlátlan exportot tenne közzé. Idézze azokat a sorokat, amelyek bizonyítják a kudarcot, és foglalja össze a többit. Egy rövid, átnézett részlet könnyebben használható, mint egy fájl, amelyet senki sem olvas.

Küldje el a szűk ablakot, az unit nevét és az első sikertelen szakaszt, és mondja el, mit zárt már ki. A systemd journalctl kézikönyve dokumentálja a szelektorokat és a kimeneti beállításokat, ha olyan formára van szüksége, amelyet a disztribúció verziója támogat.