Az OpenVPN nem indul el hiba nélkül? Nézze meg a journalt

A parancs visszatér, a szolgáltatás hibásnak látszik, és semmi magyarázatra emlékeztető nem érkezik a terminálra. Ez a csend az a tünet, amelyet az emberek úgy írnak le, hogy „az OpenVPN nem indul el”, és ez szinte soha nem azt jelenti, hogy a program szó nélkül halt meg. Azt jelenti, hogy az üzenet olyan csatornára ment, amelyet nem olvasott, vagy hogy amit elindított, nem az volt, amit beállított. Mindkét eset egy percnél rövidebb idő alatt diagnosztizálható, amint felhagy azzal, hogy a profilt tekinti gyanúsnak.

Négy hely nyeli el a kimenetet: az unit journalje, a kapcsolatot birtokló beépülő modul, az alagút másik vége és egy másik bináris, mint amelyikről azt hiszi, hogy fut. Mindegyiknek megvan a maga ellenőrzése.

A csend azt jelenti, hogy nem a megfelelő csatornát figyelte

Az előtérben indított parancs a terminálra ír. Egy unit a journalba ír, és egy hibás unit már az előtt kiléphet, hogy bármit is írna, ha a hiba abban van, hogyan indították el, és nem abban, hogy mit mondtak neki. A különbség számít: ha nincs bejegyzés a journalban, a folyamat soha nem futott igazán, míg egy bejegyzés és utána egy kilépés azt jelenti, hogy futott és elutasított valamit.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Adja hozzá a systemctl show -p Result -p ExecMainStatus openvpn-client@office parancsot, hogy elválassza a tiszta kilépést a jeltől. Az 1 állapot egy Result=exit-code esetén a program döntése; Result=signal vagy egy időtúllépés inkább a környezetre utal, és semmilyen profil szerkesztése nem változtat ezen. Jegyezze fel mindkét értéket, mielőtt bármit újraindít, mert az újraindítás törli azt az átmeneti állapotot, amely létrehozta őket.

Az instance neve az útvonal része

A csomagolt sablonunit nem fájlútvonalat vár. Instance-nevet vár, és ezt a nevet egy könyvtárhoz fűzi, hogy megtalálja a profilt: office a Debian és Ubuntu csomagolásban erre oldódik fel: /etc/openvpn/client/office.conf. Egy office-v2.conf nevű fájl, amelyet @office néven indítottak, soha nem olvasódik be, és az unit csendben kilép, mert a maga szemszögéből nem volt mit tennie. A keresési könyvtár eltér kliens- és szerver módban, ezért ugyanaz a hiba egészen máshova mutat, amikor sablont vált.

Ez az eltérés a leggyakoribb oka a csendes hibának, és a profilban láthatatlan, mert a profil rendben van. Sorolja fel, ami valóban létezik, és hasonlítsa össze a két nevet karakterről karakterre, beleértve minden kiterjesztést, amelyet a csomagolás elvár.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Ha az unit engedélyezve van, de egyetlen instance sincs listázva, maga az engedélyezés hivatkozhat egy később átnevezett névre. A helyes instance újraengedélyezése általában elég, és érdemes törölni a hátrahagyott régi unit-fájlt, hogy ne zavarja meg a következő embert. A hátrahagyott unit-fájl apróság, amely később egy órába kerül valakinek.

Amikor a beépülő modul birtokolja az alagutat, a terminál semmit nem lát

A munkaasztal-appletből indított kapcsolat a NetworkManager tulajdona, és az OpenVPN kimenete ennek a szolgáltatásnak a journaljába megy, nem pedig valamelyik megnyitott shellbe. A kliens kézi futtatása és a semmi nem látása ebben az elrendezésben várható, mert a kézzel futtatott folyamat nem az, amely a kapcsolatot viszi.

Keresse meg a journalban a szolgáltatást, amely birtokolja, majd ismételje meg az elemzést egy olvasható részletességgel. Az alábbi két parancs ugyanannak a hibának különböző tulajdonosait nézi.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Az önálló futtatás üzenetek olvasására való, nem a kezelt kapcsolat lecserélésére, és a kettő utána különbözik: a DNS-integráció, az útvonalak és az élettartam a beépülő modulé. Egy elemzési hiba javítása az önálló futtatásban nem javítja automatikusan a névfeloldást, amikor az applet átveszi az irányítást, ezért tartsa külön a két megfigyelést.

Két bináris, egy PATH

A /usr/local alá telepített kézi build nyer egy shell-hívásnál, mert /usr/local/sbin megelőzi a /usr/sbin elemet az Ubuntu alapértelmezett PATH-jában. Az unit nem a saját PATH-ját használja; a ExecStart beírt abszolút útvonalat futtatja. Így a terminálban működő verzió és a szolgáltatásként elbukó verzió valóban különböző programok lehetnek.

Hasonlítsa össze a kettőt, mielőtt bármit újraépít. A harmadik parancs az, amely eldönti a vitát.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Még egy környezeti különbség bújik meg ugyanazon a helyen. A csomagolt unit a /run alatti futásidejű könyvtárra támaszkodik, amelyet a systemd hoz létre neki; egy kézzel írt helyettesítő unit, amely kihagyja ezt a beállítást, még az első fájl megnyitása előtt elbukhat, és a hiba általános elutasításnak tűnik OpenVPN-üzenet nélkül.

Hibák, amelyekről a kliens nem tud beszámolni

Egyes kimenetelek a távoli végén dőlnek el. Egy átjáró, amely HTTP-állapottal válaszol és bezárja a kapcsolatot, elmondta a saját állapotát, és a hasznos következő lépés az ő naplója vagy a hitelesítő adatok mögötti fiók, nem a helyi fájljai. Ebben a forgatókönyvben semmi helyi nem sérült meg, és a profil kompenzáló szerkesztése megnehezíti a következő diagnózist. Olvassa el azt a naplót, mielőtt hozzányúl a kliens konfigurációjához.

Egy másik csendes eset a helyesen működő kliens. A kliens módú alagút soha nem figyel egy porton, ezért egy nyitott figyelőt váró ellenőrzés semmit nem jelent, és hibának tűnik. Erősítse meg, melyik módot indította, mielőtt következtetést von le egy üres portlistából.

A rétegeket sorrendben dolgozza fel: létezik-e az unit és helyes-e az instance neve, eljutott-e valami a journalba vagy a --log fájlba, melyik bináris és profil futott valójában, és a hiba helyi-e vagy távoli. Minden válasz eltávolít egy réteget. A profilból indulni azt jelenti, hogy olyan fájlt ír át, amelyet talán soha nem nyitottak meg.