Bakit nagsisimula ang isang unit ng VPN bago ang network at pagkatapos ay namamatay

I-boot ang makina, mag-log in, at malaman na umangat ang tunnel at namatay makalipas ang ilang segundo. Maayos ang profile, maayos ang sertipiko, at ang tanging bakas na natira ay ang journal mula sa boot na iyon. Ang karaniwang nangyari ay isang karera: nagsimula ang unit bago magkaroon ng address ang makina, at ang order na idineklara nito ay hindi nangangahulugan ng hitsura nito. Ang lahat ng nasa ibaba ay tungkol sa pagpapatunay ng karerang iyon mula sa ebidensya at pagsasara nito nang maayos.

Ang target ay isang tagpuan, hindi isang tagapamahala

Walang alam ang network-online.target kung ano ang network. Ito ay isang punto ng koordinasyon na nangongolekta ng serbisyong dapat magpabagal ng pagsisimula hanggang maging magagamit ang link, at ipinagkakatiwala ang depinisyon sa network manager na nagmamay-ari ng makina. Sa karamihan ng desktop at server, nangangahulugan iyon ng serbisyo ng paghihintay na ibinibigay ng NetworkManager o ng systemd-networkd. Kung wala kang papaganahin sa dalawa, wala nang hihintayin ang target, kaya natatapos ito sa sandaling hilahin ito ng isang bagay, na maaaring bago pa tumugon ang DHCP. Ang linya ng order sa iyong unit ay tapat at gayunman walang silbi.

Kaya ang unang tanong ay hindi kung ano ang idinedeklara ng iyong unit. Ito ay kung may isang bagay sa makinang ito na talagang gumagawa ng paghihintay.

Basahin ang huling boot sa halip na ang file ng unit

Inilalarawan ng mga file ng unit ang intensyon, at inilalarawan ng journal ang nangyari. Humingi lamang ng boot na iyon, na may monotonikong timestamp para ang bawat mensahe ay maupo sa isang orasan. Pagkatapos ay hanapin ang dalawang linya: ang sandaling nagsimulang magsimula ang unit ng tunnel, at ang sandaling lumitaw ang address o natapos ang serbisyo ng paghihintay. Ayusin ang dalawang numerong iyon at ang karera ay kumpirmado o hindi kasama.

Pinatutunayan ito ng view ng dependencies. Kung ang isang kritikal na chain para sa unit ng tunnel ay walang serbisyo ng paghihintay, walang nagpabagal ng pagsisimula sa landas na iyon, at hindi ginawa ng target ang trabahong inakala mo. Dalawang view, isang konklusyon.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Idagdag ang paghihintay, pagkatapos ang bagong pagtatangka

Gumamit ng drop-in sa halip na i-edit ang isang nakabalot na unit, upang hindi itapon ng update ng package ang pagbabago nang tahimik. Dalawang direktiba ang mahalaga: dapat maayos ang pagkakasunod-sunod ng unit pagkatapos ng target, at dapat nitong hilahin ang target sa parehong transaksyon. Ang order lamang ay hindi tumatawag sa target; ang pagnanasa ang gumagawa nito.

Ang nakabalot na unit ng client ng OpenVPN ay may dalawa na. Ang mga unit na isinulat sa pamamagitan ng kamay ay karaniwang may isa o wala, na sulit suriin bago magdagdag ng anuman.

[Service]
Restart=on-failure
RestartSec=15

Bakit ang fixed na pagtulog ay isang bitag

Ang pagtulog sa ExecStartPre ay parang pagwawasto ng order at kumikilos na parang pagkaantala na may dagdag na hakbang. Pinapabagal nito ang bawat boot, kabilang ang mga malusog, at natatalo pa rin kapag ang link ay tumagal nang mas mahaba kaysa sa numerong pinili mo.

Mas masahol pa, itinatago nito kung gumagana ang serbisyo ng paghihintay, kaya ang susunod na pagkabigo ay lumalabas na ganap na bagong problema sa halip na pareho na may ibang timing. Ang maikling pagkaantala ng restart ang mas mabuting instrumento: wala itong gastos sa malusog na boot at ginagawang isa pang pagtatangka ang natalong karera. Panatilihing katamtaman ang pagitan at hayaang magtagumpay ang unit. Kung nagre-restart ito nang walang hanggan, sira ang profile at walang dami ng mga pagtatangka ang makakabago niyon, kaya basahin ang log sa halip na taasan ang pagitan.

Kapag tama ang order at nabibigo pa rin ang mga pangalan

Ang aktibong unit na may ruta ng tunnel ay nangangahulugan na nagawa ng order ang trabaho nito at ang natitirang depekto ay isang layer sa itaas. Ang karaniwang anyo ay isang setting ng resolver na inilalapat ng up script ng tunnel bago handa ang link o ang resolver na panatilihin ito. Ihambing ang estado ng resolver habang may pagkabigo sa estado pagkatapos ng restart ng unit ng tunnel.

Kung inaayos ng restart ang mga paghahanap, may depekto ka sa order ng pagsisimula at hindi maling DNS server, at ang dalawang iyon ay nangangailangan ng magkaibang pagwawasto. Pagkatapos ay patunayan ang lahat sa pamamagitan ng malamig na boot sa halip na restart ng serbisyo, dahil ang restart ay tumatakbo laban sa network na nakataas na at itatago ang eksaktong depektong hinahabol mo. Ulitin ito nang sadyang mabagal ang link, at ituring na sira pa rin ang isang unit na gumagana lamang kapag mabilis ang network.