Az OpenVPN nem indul: az első sort olvassa, ne a konfigurációt
Az első másodpercben meghaló VPN-nek nincs kézfogása, amin hibakeresést lehetne végezni. A napló első sora választja ki az ágat: foglalt port, hiányzó bináris vagy hiányzó konfiguráció.
Az első másodpercben meghaló VPN más állat, mint amelyik csatlakozik, majd elbukik, és a szokásos hiba, hogy ugyanúgy kezeljük őket. Itt nincs kézfogás, nincs tanúsítványcsere és nincs megvizsgálandó útvonal. A napló egyetlen sora dönti el, hogy több, egymástól független javítás közül melyik érvényes, és ennek kihagyása egy délutánba kerül olyan konfiguráció szerkesztésével, amelyet soha nem olvastak be. Először azt a sort olvassa el.
Három csak olvasható parancs visz oda: először journalctl -u openvpn@server -b --no-pager, aztán systemctl status openvpn@server, és ss -lunp az UDP-figyelőkhöz és azok tulajdonosaihoz.
Az első sor választja ki az ágat
A portütközés és a hiányzó bináris is egy másodpercen belül megöli az indítást, és különböző első sorokat hagynak maguk után. A cím már használatban van üzenet a portot nevezi meg; a hiányzó futtatható fájl egy már nem létező útvonalat nevez meg; a meghiúsult feltétel vagy a hiányzó konfigurációs fájl a fájlt nevezi meg. Ez a három különböző javításokhoz vezet, és egyiket sem javítja a kliens újratelepítése. Másolja az első hibát a jegyzeteibe, mielőtt bármi mást futtatna.
Figyeljen az újrapróbálkozási hurokra, amely elrejti az eredeti sort. Egy újraindítási házirenddel rendelkező egység tucatnyi azonos hiba alá temetheti az első hibát, ezért az egység szerint szűrt és felülről olvasott journalctl -b jobb, mint a farok.
Ki más tartja még az 1194-es portot
A bűnös általában nem egy második kiszolgáló, amelyet valaki szándékosan beállított. Számítson egy kézzel indított kliensre, amely még él egy másik terminálban, egy második profilra, amely véletlenül ugyanazt a portot választotta, vagy egy szállítói csomagra, amelynek saját alagútja tartja az 1194-et. A socket tulajdonosa az ss -lunp kimenetben jelenik meg; adja át ezt a PID-et a systemctl status-nek, hogy megtudja, felelős-e valamelyik egység. Saját vezérlési útvonalán keresztül állítsa le, ne szignállal.
Az egység által kezelt folyamatnak küldött szignál általában újraindítást vált ki, és ugyanaz a hiba pillanatokkal később új problémaként jelenik meg. Egységhez használja a systemctl stop-öt, szállítói telepítéshez a csomag saját szolgáltatásparancsát, szignált pedig csak olyasmihez, amit maga indított kézzel abban a shellben.
Eltávolítás után megmaradó egységek
Az eltávolítás törli a binárisokat; a kézzel írt egységfájlok, jellemzően a /etc/systemd/system alatt, túlélik. A Systemd ezután újra megpróbál egy egységet, amely már nem létező útvonalra mutat, és az üzenet arról a hiányzó fájlról szól, nem a tegnapi eltávolításról. A systemctl status az egység töredékútvonalát mutatja a tetejéhez közel, ezért a dpkg -S-szel ellenőrizze, mielőtt bármit törölne. Amint az árva eltűnik, a systemctl daemon-reload és a systemctl reset-failed tisztázza az állapotot; különben minden későbbi állapotellenőrzés örökli.
Amikor a which openvpn valamivel a /usr/local alatt válaszol, a szóban forgó bináris szállítói telepítőtől származik, nem az apt-tól. Egy ilyen telepítő általában saját figyelőt, saját rendszerindítási bejegyzést és saját konfigurációs könyvtárat hoz, ezért a látható parancs eltávolítása foglaltan hagyja a socketet.
Távolítsa el úgy, ahogy a szállító dokumentálja, ellenőrizze a ss -lunp-gyel, hogy a port szabad, és csak akkor adja hozzá a disztribúció kliensét, ha szüksége van rá.
Az újrapróbálkozás előtt rendezze az állapotot
Tisztítsa meg a hibás állapotot, mielőtt következtetéseket vonna le belőle: a systemctl reset-failed eltávolítja a számlálókat, és a systemctl status ezután az egység jelenlegi állapotát jelenti, nem a történetét. Indítsa el egyszer, és annak a futásnak a naplóját olvassa, ne a gép összesített állapotát. Egy egység, amely aktívnak jelentkezik, miközben az alagút semmit sem szállít, külön probléma, és sokkal gyakoribb. A kettő összeolvad a hibajelentésekben, mert mindkettő azzal végződik, hogy a felhasználó szerint a VPN nem működik.
Jegyezze fel a választott ágat: portütközés, hiányzó bináris, hiányzó konfiguráció. Legközelebb gyorsabb lesz felismerni.