OpenVPN не запускаецца: чытайце першы радок, а не канфігурацыю

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

Тры каманды толькі для чытання давядуць вас туды: спачатку journalctl -u openvpn@server -b --no-pager, потым systemctl status openvpn@server і ss -lunp для UDP-слухачоў і іх уладальнікаў.

Першы радок выбірае галіну

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

Сачыце за цыклам паўтораў, які хавае зыходны радок. Юніт з палітыкай перазапуску можа пахаваць першы збой пад дзесяткам ідэнтычных, таму journalctl -b, адфільтраваны па юніце і прачытаны зверху, лепшы за хвост.

Хто яшчэ трымае порт 1194

Вінаваты звычайна не другі сервер, які хтосьці наўмысна наладзіў. Чакайце кліента, запушчанага ўручную і яшчэ жывога ў іншым тэрмінале, другі профіль, які выпадкова ўзяў той жа порт, або пакет пастаўшчыка, чый уласны тунель трымае 1194. Уладальнік сокета паказваецца ў ss -lunp; перадайце гэты PID у systemctl status, каб даведацца, ці адказны юніт. Здыміце яго праз уласны шлях кіравання, а не сігналам.

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

Пакінутыя юніты пасля выдалення

Выдаленне знішчае бінарныя файлы; файлы юнітаў, напісаныя ўручную, звычайна ў /etc/systemd/system, яго перажываюць. Тады Systemd зноў спрабуе юніт, які паказвае на шлях, якога больш няма, і паведамленне датычыцца гэтага адсутнага файла, а не ўчорашняга выдалення. systemctl status паказвае шлях фрагмента юніта бліжэй да верху, таму праверце яго праз dpkg -S, перш чым нешта выдаляць. Калі сірата знікне, systemctl daemon-reload і systemctl reset-failed ачышчаюць стан; інакш кожная наступная праверка статусу яго атрымлівае ў спадчыну.

Калі which openvpn адказвае чымсьці ў /usr/local, задзейнічаны бінарны файл прыйшоў ад усталёўшчыка пастаўшчыка, а не з apt. Такі ўсталёўшчык звычайна прыносіць свой слухач, свой запіс загрузкі і свой каталог канфігурацыі, таму выдаленне бачнай каманды пакідае сокет занятым.

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

Прывядзіце стан у парадак перад паўторам

Ачысціце стан збою, перш чым рабіць з яго высновы: systemctl reset-failed выдаляе лічыльнікі, і systemctl status тады паведамляе бягучы стан юніта, а не яго гісторыю. Запусціце яго адзін раз і чытайце ўласны журнал гэтага запуску, а не сукупны стан машыны. Юніт, які паведамляе пра актыўнасць, пакуль тунель нічога не нясе, — гэта асобная праблема, і значна больш распаўсюджаная. Абедзве зліваюцца ў баг-рэпартах, бо абедзве заканчваюцца словамі карыстальніка, што VPN не працуе.

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