OpenVPN се не покреће без грешке? Погледајте journal

Команда се враћа, услуга се приказује као неуспешна и у терминал не стиже ништа што личи на објашњење. Та тишина је симптом који људи описују као «OpenVPN се не покреће», и готово никада не значи да је програм умро а да није рекао ништа. Значи да је порука отишла у канал који нисте читали или да оно што сте покренули није било оно што сте конфигурисали. Оба случаја се могу дијагностиковати за мање од минута када престанете да сматрате профил осумњиченим.

Излаз упијају четири места: journal јединице, додатак који поседује везу, други крај тунела и друга бинарна датотека од оне за коју мислите да се извршава. Свако има своју проверу.

Тишина значи да нисте гледали прави канал

Позив у првом плану исписује у ваш терминал. Јединица исписује у journal, а неуспешна јединица може изаћи пре него што ишта напише ако је квар у начину на који је покренута, а не у ономе што јој је речено. Та разлика је важна: нема уноса у journal значи да процес никада заправо није радио, док један унос праћен излазом значи да је радио и нешто одбио.

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 у Debian и Ubuntu пакетима се разрешава у /etc/openvpn/client/office.conf. Датотека под називом office-v2.conf, покренута као @office никада се не чита и јединица тихо излази јер са њене тачке гледишта није било шта да ради. Директоријум за претрагу разликује се између клијентског и серверског режима, па иста грешка указује на сасвим друго место када промените шаблон.

То неслагање је најчешћи извор тихе грешке и невидљиво је у профилу јер је профил исправан. Пописати шта заиста постоји и упоредите два назива знак по знак, укључујући свако проширење које пакет очекује.

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

Ако је јединица омогућена али ниједна инстанца није наведена, само омогућавање може упућивати на назив који је касније преименован. Поновно омогућавање исправне инстанце обично је довољно, а стару заосталу датотеку јединице вреди избрисати да не збуњује следећу особу. Заостала датотека јединице је ситница која некога касније кошта сат времена.

Када додатак поседује тунел, терминал не види ништа

Везу покренуту из десктоп аплета поседује NetworkManager, а њен OpenVPN излаз иде у journal те услуге, а не у било који shell који имате отворен. Ручно покретање клијента без икаквог излаза очекивано је у том распореду, јер ручно покренути процес није онај који носи везу.

Претражите journal за услугом која га поседује, затим поновите парсирање са опширношћу коју можете да читате. Две наредбе испод гледају различите власнике исте грешке.

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 на подразумеваном Ubuntu PATH-у. Јединица не користи ваш PATH; она извршава апсолутну путању уписану у ExecStart. Зато верзија која ради у вашем терминалу и верзија која пада као услуга могу бити стварно различити програми.

Упоредите њих две пре него што било шта поново изградите. Трећа наредба је та која одлучује аргумент.

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

Још једна разлика у окружењу крије се на истом месту. Спакована јединица се ослања на директоријум за време извршавања под /run који systemd ствара за њу; ручно написана заменска јединица која изоставља то подешавање може пасти пре него што отвори иједну датотеку, а квар изгледа као опште одбијање без икакве OpenVPN поруке.

Кварови које клијент не може да пријави

Неки исходи се одлучују на далеком крају. Гејтвеј који одговори HTTP статусом и затвори везу рекао вам је о свом стању, а користан следећи корак је његов лог или налог иза података за пријаву, а не ваше локалне датотеке. Ништа локално није покварено у том сценарију, а уређивање профила ради компензације чини следећу дијагнозу тежом. Прочитајте тај лог пре него што дирнете конфигурацију клијента.

Други тихи случај је клијент који ради исправно. Тунел у клијентском режиму никада не слуша на порту, па провера која очекује отвореног слушаоца неће пријавити ништа и изгледаће као квар. Потврдите који сте режим покренули пре него што изведете закључак из празне листе портова.

Радите слојеве по реду: постоји ли јединица и је ли назив инстанце исправан, је ли ишта стигло у journal или у датотеку --log, која бинарна датотека и профил су заиста радили, и је ли квар локалан или удаљен. Сваки одговор уклања слој. Почињати од профила значи преписивати датотеку која можда никада није отворена.