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

Командата се враќа, услугата изгледа како неуспешна и ништо што личи на објаснување не стигнува до терминалот. Таа тишина е симптомот што луѓето го опишуваат како «OpenVPN не стартува», и речиси никогаш не значи дека програмата умрела без да каже ништо. Тоа значи дека пораката отишла во канал што не сте го читале, или дека тоа што сте го стартувале не било тоа што сте го конфигурирале. И двата случаи може да се дијагностицираат за помалку од една минута штом престанете да го сметате профилот за осомничен.

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

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

Повикот во преден план печати на вашиот терминал. Unit-от печати во journal-от, а неуспешен unit може да излезе пред воопшто да напише нешто ако дефектот е во начинот на кој е стартуван, а не во она што му е кажано. Оваа разлика е важна: нема запис во 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 или таймаут укажуваат на околината, и никакво уредување на профилот тоа нема да го промени. Запишете ги двете вредности пред да рестартирате нешто, бидејќи рестартот ја брише преодната состојба што ги создала.

Името на инстанцата е дел од патеката

Спакуваниот шаблонски unit не прима патека до датотека. Прима име на инстанца, и тоа име се додава на директориум за да се најде профилот: office во Debian и Ubuntu пакувањето се решава во /etc/openvpn/client/office.conf. Датотека со име office-v2.conf стартувана како @office никогаш не се чита, и unit-от тивко излегува бидејќи од негова гледна точка немало што да прави. Директориумот за пребарување се разликува меѓу клиентски и серверски режим, па истата грешка при менување шаблон покажува сосема друго место.

Тоа несовпаѓање е најчест извор на тивкиот дефект и е невидливо во профилот бидејќи профилот е во ред. Наведете што навистина постои и споредете ги двете имиња знак по знак, вклучително секое проширување што го очекува пакувањето.

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

Ако unit-от е овозможен но не е наведена ниту една инстанца, самото овозможување може да укажува на име што подоцна било преименувано. Повторното овозможување на вистинската инстанца обично е доволно, а старата оставена unit датотека вреди да се избрише за да не го збуни следниот човек. Оставената unit датотека е ситница што некого подоцна го чини еден час.

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

Поврзување започнато од десктоп applet-от го поседува 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 интеграцијата, рутите и животниот век му припаѓаат на приклучокот. Поправањето на грешка во парсирањето во самостојното извршување не го поправа автоматски решавањето на имиња кога applet-от презема, затоа држете ги двете набљудувања одделно.

Два бинарни файла, еден 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-от постои и дали името на инстанцата е точно, дали нешто стигнало во journal-от или во датотеката --log , која бинарна датотека и профил навистина работеле, и дали дефектот е локален или далечен. Секој одговор отстранува еден слој. Да се почне од профилот значи да се препише датотека што можеби никогаш не била отворена.