OpenVPN se nespustí: čtěte první řádek, ne konfiguraci

VPN, které zemře v první sekundě, je jiné zvíře než to, které se připojí a pak selže, a obvyklá chyba je považovat je za totéž. Není tu žádný handshake, žádná výměna certifikátů a žádná trasa k prozkoumání. Jeden řádek v journalu rozhoduje, která z několika nesouvisejících oprav platí, a jeho přeskočení stojí odpoledne úprav konfigurace, která nebyla nikdy přečtena. Přečtěte ten řádek jako první.

Tři příkazy jen pro čtení vás tam dostanou: nejprve journalctl -u openvpn@server -b --no-pager, potom systemctl status openvpn@server a ss -lunp pro UDP posluchače a jejich vlastníky.

První řádek vybírá větev

Konflikt portů i chybějící binárka zabijí start během sekundy a zanechají různé první řádky. Zpráva, že adresa je již používána, pojmenuje port; chybějící spustitelný soubor pojmenuje cestu, která už neexistuje; nesplněná podmínka nebo chybějící konfigurační soubor pojmenuje soubor. Ty tři vedou k různým opravám a žádnou z nich nezlepší přeinstalace klienta. Zkopírujte první selhání do poznámek, než spustíte cokoli dalšího.

Sledujte smyčku opakovaných pokusů, která skrývá původní řádek. Unit s restart politikou může pohřbít první selhání pod desítkami identických, takže journalctl -b filtrovaný podle unitu a čtený od začátku je lepší než konec.

Kdo další drží port 1194

Viník obvykle není druhý server, který někdo záměrně nastavil. Čekejte ručně spuštěného klienta stále živého v jiném terminálu, druhý profil, který náhodou zvolil stejný port, nebo balík dodavatele, jehož vlastní tunel drží 1194. Vlastník socketu se objeví v ss -lunp; předejte to PID do systemctl status a zjistěte, zda je odpovědný nějaký unit. Sundejte ho vlastní řídicí cestou, ne signálem.

Signál procesu spravovanému unitem obvykle vyvolá restart a stejné selhání se po chvíli vrátí jako nový problém. Použijte systemctl stop pro unit, vlastní servisní příkaz balíku pro instalaci dodavatele a signál jen pro něco, co jste sami spustili v tomto shellu.

Zbytkové unity po odinstalaci

Odinstalace smaže binárky; ručně psané soubory unitů, obvykle v /etc/systemd/system, to přežijí. Systemd pak znovu zkouší unit ukazující na cestu, která už neexistuje, a zpráva se týká toho chybějícího souboru, ne včerejšího odstranění. systemctl status ukazuje cestu fragmentu unitu blízko začátku, takže ji před smazáním čehokoli zkontrolujte pomocí dpkg -S. Jakmile sirotek zmizí, systemctl daemon-reload a systemctl reset-failed vyčistí stav; jinak ho každá další kontrola stavu zdědí.

Když which openvpn odpoví něčím pod /usr/local, použitá binárka pochází z instalátoru dodavatele, ne z apt. Takový instalátor obvykle přináší vlastní posluchač, vlastní položku pro boot a vlastní konfigurační adresář, takže odstranění viditelného příkazu nechá socket obsazený.

Odinstalujte ho tak, jak dokumentuje dodavatel, ověřte pomocí ss -lunp, že je port volný, a klientský balíček distribuce přidejte jen tehdy, když ho potřebujete.

Srovnejte stav před dalším pokusem

Vyčistěte stav selhání, než z něj vyvodíte závěry: systemctl reset-failed odstraní počítadla a systemctl status pak hlásí aktuální stav unitu, ne jeho historii. Spusťte ho jednou a čtěte journal této instance, ne souhrnný stav stroje. Unit hlásící aktivitu, zatímco tunel nic nepřenáší, je samostatný problém a mnohem běžnější. Oba se v hlášeních chyb slévají, protože oba končí slovy uživatele, že VPN nefunguje.

Poznamenejte si větev, kterou jste zvolili: konflikt portů, chybějící binárka, chybějící konfigurace. Příště ji poznáte rychleji.