OpenVPN не стартира без грешка? Проверете журнала

Командата се връща, услугата показва неуспех и до терминала не стига нищо, което да прилича на обяснение. Тази тишина е симптомът, който хората описват като „OpenVPN не стартира“, и почти никога не означава, че програмата е умряла, без да каже нищо. Тя означава, че съобщението е отишло в канал, който не сте чели, или че това, което сте стартирали, не е това, което сте конфигурирали. И двата случая се диагностицират за по-малко от минута, след като спрете да смятате профила за заподозрян.

Изхода поемат четири места: журналът на unit-а, плъгинът, който притежава връзката, другият край на тунела и различен изпълним файл от този, който смятате, че работи. Всяко от тях има своя проверка.

Тишината означава, че не сте наблюдавали правилния канал

Извикването на преден план печата в терминала ви. Unit печата в журнала и неуспешен unit може да излезе, преди да запише каквото и да е, ако причината е в начина, по който е стартиран, а не в това, което му е казано. Разликата е важна: липсата на запис в журнала означава, че процесът никога не е работил наистина, докато един запис, последван от изход, означава, че е работил и е отхвърлил нещо.

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

Добавете systemctl show -p Result -p ExecMainStatus openvpn-client@office за да отделите чисто излизане от сигнал. Състояние 1 с Result=exit-code е решение на програмата; Result=signal или таймаут сочат вместо това към средата и никакво редактиране на профила няма да го промени. Запишете и двете стойности, преди да рестартирате каквото и да е, защото рестартът изчиства преходното състояние, което ги е създало.

Името на инстанцията е част от пътя

Пакетираният шаблонен unit не приема път до файл. Той приема име на инстанция и това име се добавя към директория, за да намери профила: office се разрешава до /etc/openvpn/client/office.conf в пакетирането за Debian и Ubuntu. Файл с име office-v2.conf стартиран като @office никога не се чете и unit излиза тихо, защото от негова гледна точка е нямало какво да прави. Директорията за търсене се различава между клиентски и сървърен режим, така че същата грешка сочи съвсем другаде, когато смените шаблона.

Това несъответствие е най-честата причина за тихия отказ и е невидимо в профила, защото профилът е наред. Избройте какво реално съществува и сравнете двете имена знак по знак, включително всяко разширение, което пакетът очаква.

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

Ако unit е включен, но не е изброена нито една инстанция, самото включване може да сочи към име, което по-късно е преименувано. Повторното включване на правилната инстанция обикновено е достатъчно, а старият останал unit файл си заслужава да бъде изтрит, за да не обърква следващия човек. Останалият unit файл е дреболия, която струва на някого час по-късно.

Когато плъгинът притежава тунела, терминалът не вижда нищо

Връзка, стартирана от аплета на работния плот, се притежава от NetworkManager и изходът ѝ от OpenVPN отива в журнала на тази услуга, а не в който и да е отворен от вас shell. Стартирането на клиента на ръка и липсата на каквото и да е са нормални при тази подредба, защото процесът, стартиран на ръка, не е този, който носи връзката.

Потърсете в журнала услугата, която го притежава, след което възпроизведете разбора с подробност, която можете да четете. Двете команди по-долу гледат различни собственици на един и същ отказ.

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

Отделното стартиране е за четене на съобщения, а не за заместване на управляваната връзка, и двете се различават след това: интеграцията с DNS, маршрутите и животът принадлежат на плъгина. Поправянето на грешка в разбора при отделното стартиране не поправя автоматично разрешаването на имена, след като аплетът поеме, затова пазете двете наблюдения отделно.

Два изпълними файла, един PATH

Ръчно изградена инсталация под /usr/local печели при извикване от shell, защото /usr/local/sbin стои преди /usr/sbin в стандартния PATH на Ubuntu. Unit не използва вашия PATH; той изпълнява абсолютния път, записан в ExecStart. Затова версията, която работи в терминала ви, и версията, която се проваля като услуга, може да са наистина различни програми.

Сравнете двете, преди да преизграждате каквото и да е. Третата команда е тази, която решава спора.

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

Още една разлика в средата се крие на същото място. Пакетираният unit разчита на директория за време на изпълнение под /run , която systemd създава за него; ръчно написан заместващ unit, който пропуска тази настройка, може да се провали, преди да отвори дори един файл, и отказът изглежда като общ отказ без съобщение от OpenVPN.

Откази, за които клиентът не може да съобщи

Някои изходи се решават в далечния край. Шлюз, който отговаря с HTTP статус и затваря връзката, ви е казал за собственото си състояние и полезният следващ ход е неговият журнал или акаунтът зад идентификационните данни, а не вашите локални файлове. В този сценарий нищо локално не е счупено и редактирането на профила за компенсация прави следващата диагностика по-трудна. Прочетете този журнал, преди да пипате конфигурацията на клиента.

Друг случай на тишина е клиент, който работи правилно. Тунел в клиентски режим никога не слуша на порт, така че проверка, която очаква отворен слушател, няма да съобщи нищо и ще изглежда като отказ. Потвърдете кой режим сте стартирали, преди да правите извод от празен списък с портове.

Работете слоевете по ред: съществува ли unit и правилно ли е името на инстанцията, стигна ли нещо до журнала или до файла --log, кой изпълним файл и профил реално са работили и дали отказът е локален или отдалечен. Всеки отговор премахва слой. Започването от профила означава да пренапишете файл, който може никога да не е бил отварян.