Bakit nananatiling patay ang iyong OpenVPN client pagkatapos ng isang timeout

Lunes ng umaga: wala na ang tunnel na umangat noong Biyernes, nakalista pa rin ang interface, at walang sinasabi sa journal na may nakapansin. Nasa online ang host, berde ang dashboard, at lahat ng ipinadala nito sa katapusan ng linggo ay lumabas sa pisikal na interface. Dalawang malayang desisyon ang kulang dito: isa kung nakakaligtas ba ang proseso ng client sa panandaliang pagkabigo at isa kung may magsimulang muli ng proseso sa itaas nito pagkatapos nitong lumabas. Ang pag-aayos ng isa lang ay iniiwan na bukas ang kabilang butas.

Magsimula sa aktwal na ginawa ng unit, hindi sa sinasabi ng monitoring. Ipinapakita ng systemctl status openvpn-client@office at journalctl -u openvpn-client@office -n 50 ang dahilan ng paglabas at ang huling linyang isinulat ng client bago ito umalis.

Lumabas ang proseso bago pa may nakapansin

Ang client na nawawala nang walang error ay kadalasang lumabas nang sinasadya. Ang profile ang nagpapasya sa ugali na iyon, hindi ang service manager: tinatapos ng ping-exit ang proseso sa sandaling tumigil ang kabilang panig sa pagsagot, samantalang pinapanatili ng ping-restart ang proseso at muling kumokonekta sa loob nito. Ang mga limitasyon ng session at mga timer ng kawalan ng aktibidad ay nagbibigay ng parehong larawan mula sa labas: walang tunnel at walang alarma.

Hindi maaaring magkasama sa isang profile ang dalawang ping directive, kaya pumili ng isa at itala ang pinili. Tingnan din ang server, dahil ang sarili nitong ping-exit ay nagsasara ng session anuman ang hilingin ng client, at tanging log ng server ang nagtatala kung sino ang gumawa ng desisyong iyon.

Pagpili sa pagitan ng ping-exit at ping-restart

Piliin ang ping-restart para sa laptop o malayong site na dapat gumaling sa sarili, at itabi ang ping-exit para sa mga kaso kung saan dapat ihinto ng patay na tunnel ang proseso upang may ibang makagawa ng hakbang. Mas mababa ang halaga ng mga numero kaysa sa ugnayan: ang ping 10 kasama ng ping-restart 60 ay nangangahulugang sampung segundong katahimikan bago ang pagsubok at animnapu bago ang muling pag-start, na agresibo sa mobile link na may pagkalugi at makatwiran sa may kable. Isulat ang dahilan sa tabi ng linya, kung hindi ay ipapalagay ng susunod na mambabasa na sinasadya ang mga default na halaga.

Pagkatapos, tiyakin na ang proseso nga ang lumabas. Ang unit na nag-uulat na aktibo habang patay ang tunnel ay ibang pagkabigo, na tinalakay sa ibaba.

Pangangasiwang talagang nag-restart ng unit

Sa host na systemd, ang pinakamaliit na pangmatagalang pagbabago ay isang drop-in file: Restart=on-failure at RestartSec=10 sa /etc/systemd/system/[email protected]/restart.conf. Binabasa lamang ang drop-in kapag muling nag-load ang systemd ng sarili nitong mga depinisyon, kaya patakbuhin ang systemctl daemon-reload pagkatapos. I-verify gamit ang systemctl show -p Restart -p ExecMainStatus openvpn-client@office sa halip na ipagpalagay na dumating ang halaga. Ang instance sa pangalan ng file ay dapat ang profile na aktwal na nilo-load ng unit, kaya ang file na isinulat para sa office ay walang ginagawa para sa openvpn-client@home.

on-failure ay hindi pinapansin ang isang kaso: malinis na paglabas na may status na sero. Ang ilang landas ng teardown ay nagtatapos nang ganoon, kaya basahin ang naitalang status sa halip na magtiwala sa pananalita ng isang man page. Kung sumusuko ang client mo nang may sero, kailangan mo ang Restart=always, at ang halaga ay patuloy na bumabalik ang talagang sirang profile hanggang sa umandar ang limitasyon sa rate ng pag-start at mapuno ang journal.

Restart=always ay umiiral din pagkatapos ng sinadyang paghinto. Gamitin ang systemctl stop para sa maintenance, at i-mask ang unit kung kailangan itong manatiling patay habang nagtatrabaho ka.

Hulihin ang pagtagas habang patay ang tunnel

Ibinabalik ng pangangasiwa ang tunnel; hindi nito pinipigilan ang trapikong lumabas habang wala ang tunnel. Pinapanatili ng persist-tun ang device at ang mga ruta nito sa pagitan ng mga muling pagkonekta, na maginhawa at nagbubukas ng bintana. Nabubuhay ang device, nakatuon pa rin dito ang mga ruta, at tumutulo ang mga packet nang walang proteksyon at walang ulat. Iyon ay pagpiling patakaran, hindi neutral na default.

Kapag hindi talaga pinapayagang maglabas ng mga packet na walang proteksyon ang isang host, tanging firewall lang ang makakagarantiya nito. Ang panuntunan sa labas na pumapayag sa interface ng tunnel at address ng VPN server habang itinatapon ang lahat ng iba ay nananatiling may bisa pagkatapos mamatay ang client, at wala sa sariling configuration ng client ang makakapagsala ng trapikong hindi dinadala ng client.

Subukan ito sa pamamagitan ng sinadyang paghinto ng client. Patakbuhin ang systemctl stop openvpn-client@office, pagkatapos ang curl -m 5 https://example.com, na dapat mabigo sa halip na magtagumpay sa pisikal na link. Ang tagumpay ay nangangahulugang kulang ang panuntunan ng firewall o masyadong mapagpayag.

Kumonekta muli, tiyakin na dinadala na ng tunnel ang trapiko, at saka lamang idagdag ang pagsusuri sa monitoring. Ang pag-poll ng ip addr mula sa cron para sa tun device ay ang pangangasiwang pinakamadalas mabigo, dahil sa persist-tun ay mas matagal pang nabubuhay ang device kaysa sa session at nag-uulat ang pagsusuri ng kalusugan habang walang dinadala.