OpenVPN не запускаецца без паведамлення пра памылку? Загляньце ў журнал

Каманда вяртаецца, служба паказвае збой, і ў тэрмінал не паступае нічога, што было б падобна на тлумачэнне. Гэтая цішыня — гэта сімптом, які людзі апісваюць як «OpenVPN не запускаецца», і амаль ніколі не азначае, што праграма памерла, не сказаўшы ні слова. Яна азначае, што паведамленне пайшло ў канал, які вы не чыталі, або што тое, што вы запусцілі, не было тым, што вы наладзілі. Абедзве сітуацыі можна дыягнаставаць менш чым за хвіліну, калі перастаць лічыць профіль падазроным.

Вывад паглынаюць чатыры месцы: журнал юніта, плагін, які валодае злучэннем, другі канец тунеля і іншы бінарны файл, чым той, які, на вашу думку, запушчаны. Кожнае месца мае ўласную праверку.

Цішыня азначае, што вы назіралі не той канал

Выклік у пярэднім плане друкуе ў ваш тэрмінал. Юніт друкуе ў журнал, і юніт са збоем можа выйсці раней, чым што-небудзь запіша, калі прычына ў тым, як яго запусцілі, а не ў тым, што яму паведамілі. Гэта розніца важная: адсутнасць запісу ў журнале азначае, што працэс наогул не запусціўся, а адзін запіс з наступным выхадам азначае, што ён запусціўся і нешта адхіліў.

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 або тайм-аўт паказваюць хутчэй на асяроддзе, і ніякае рэдагаванне профілю гэтага не зменіць. Запішыце абодва значэнні, перш чым нешта перазапускаць, бо перазапуск сцірае пераходны стан, які іх стварыў.

Імя экзэмпляра — частка шляху

Пакетаваны шаблонны юніт не прымае шлях да файла. Ён прымае імя экзэмпляра, і гэтае імя дадаецца да каталога, каб знайсці профіль: office вырашаецца ў /etc/openvpn/client/office.conf у пакетах Debian і Ubuntu. Файл з іменем office-v2.conf запушчаны як @office ніколі не чытаецца, і юніт выходзіць ціха, бо з яго пункту гледжання рабіць не было чаго. Каталог пошуку розны для рэжыму кліента і сервера, таму тая ж памылка паказвае зусім у іншае месца, калі вы мяняеце шаблон.

Гэтая няўзгодненасць — самая частая крыніца ціхага збою, і яна незаўважная ў профілі, бо профіль у парадку. Пералічыце тое, што рэальна існуе, і параўнайце два імёны па сімвалах, уключаючы любое пашырэнне, якога чакае пакет.

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

Калі юніт уключаны, але ні адзін экзэмпляр не паказаны, само ўключэнне можа спасылацца на імя, якое потым перайменавалі. Звычайна дастаткова зноў уключыць правільны экзэмпляр, а стары файл юніта, які застаўся, варта выдаліць, каб ён не блытаў наступнага чалавека. Пакінуты файл юніта — дробязь, якая каштуе камусьці гадзіну пазней.

Калі тунэлем валодае плагін, тэрмінал нічога не бачыць

Злучэннем, якое запушчана з аплета працоўнага стала, валодае 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. Юніт не выкарыстоўвае ваш PATH; ён запускае абсалютны шлях, запісаны ў ExecStart. Таму версія, якая працуе ў вашым тэрмінале, і версія, якая збаіць як служба, могуць быць сапраўды рознымі праграмамі.

Параўнайце абодва, перш чым нешта перабудоўваць. Трэцяя каманда — тая, што вырашае спрэчку.

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

Яшчэ адна розніца асяроддзя хаваецца ў тым жа месцы. Пакетаваны юніт разлічвае на каталог часу выканання пад /run, які стварае для яго systemd; напісаны ўручную заменны юніт, які апускае гэтую наладу, можа збаіць раней, чым адкрые хоць адзін файл, і збой выглядае як агульная адмова без паведамлення ад OpenVPN.

Збоі, пра якія кліент не можа паведаміць

Некаторыя вынікі вырашаюцца на далёкім канцы. Шлюз, які адказвае HTTP-статусам і зачыняе злучэнне, паведаміў вам пра свой стан, і карысны наступны крок — гэта яго журнал або ўліковы запіс за пасведчаннем, а не вашыя лакальныя файлы. У такім сцэнары нішто лакальнае не зламана, а рэдагаванне профілю дзеля кампенсацыі робіць наступную дыягностыку цяжэйшай. Прачытайце гэты журнал, перш чым кранаць канфігурацыю кліента.

Яшчэ адзін ціхі выпадак — кліент, які працуе правільна. Тунель у кліенцкім рэжыме ніколі не слухае порт, таму праверка, якая чакае адкрыты слухач, нічога не пакажа і будзе выглядаць як збой. Пацвердзіце, які рэжым вы запусцілі, перш чым рабіць выснову з пустога спісу партоў.

Праходзьце пласты па парадку: ці існуе юніт і ці правільнае імя экзэмпляра, ці дайшло нешта да журнала або да файла --log, які бінарны файл і профіль рэальна запусціліся, і ці збой лакальны або аддалены. Кожны адказ здымае слой. Пачынаць з профілю — значыць перапісваць файл, які, магчыма, ніколі не адкрываўся.