OpenVPN sa pag-boot sa Ubuntu: NetworkManager o systemd?

Ipinapakita ng karamihan ng gabay ang pagpiling ito na parang kosmetiko: hayaang iangat ng NetworkManager ang tunnel, o paganahin ang isang instance ng systemd at tapos na. Nagkakaiba ang dalawang landas sa isang bagay na nagtatakda ng resulta sa makina na walang screen, at wala itong kinalaman sa kung aling tool ang mas bago. Binubuksan ng NetworkManager ang mga sikreto sa pamamagitan ng isang session; walang session na bubuksan ang isang instance ng systemd. Piliin ang landas na ang paghawak ng mga sikreto ay umaangkop sa makinang nasa harap mo.

Lahat ng iba, mula sa pag-install ng ruta hanggang sa ugali sa muling pagkonekta, ay nagmumula sa unang desisyong iyon.

Ang keyring ang pagkakaibang walang binabanggit

Kapag pagmamay-ari ng NetworkManager ang isang profile ng VPN, maaaring nasa login keyring ang password, na binubuksan kapag nag-sign in ang isang user. Mahusay itong gumagana sa laptop: naroon ang tao, bumubukas ang keyring, umaangat ang tunnel. Sa server na nagbo-boot nang walang nagmamatyag, walang sinumang magbubukas ng kahit ano, kaya naghihintay ang profile sa sikretong hindi dumarating. Mukhang naka-configure ang koneksyon at hindi ito kailanman nagiging aktibo.

Iniiwasan ng instance ng systemd ang problemang iyon sa pagbasa ng file ng mga kredensyal mula sa disk, na ginagawang ang file mismo ang bagay na pinoprotektahan mo. Ang chmod 400 kasama ang pagmamay-ari ng root ang pinakamababa, at dapat manatili ang file sa labas ng mga backup at template ng image na hindi mo kontrolado.

Ang paglakip ng VPN sa isang koneksyon ay hindi garantiya ng boot

Sa nm-connection-editor, piliin ang wired o wireless na koneksyon sa halip na ang VPN, buksan ang tab na General, tsekan ang opsyon na awtomatikong kumonekta sa isang VPN at pangalanan ang profile. Pagkatapos ay i-activate ng NetworkManager ang VPN bilang pangalawang koneksyon kapag naabot ng pangunahin ang konektadong estado. Ito ay dependency, hindi patakaran ng firewall. Maaari pa ring lumabas ang mga packet sa mga segundong bago umangat ang tunnel, at ang naka-save na sikretong hindi nabubuksan ay nag-iiwan sa makina na online nang wala ito.

Kung ang pangangailangan ay walang lumalabas nang walang tunnel, sabihin iyon at gumawa ng kill switch, dahil hindi ito ibibigay ng setting na ito. Subukan din ang suspend at resume, dahil muling sinusuri ang pangalawang koneksyon sa pagbabalik.

Kailangan ng instance ng systemd ang tugmang pangalan ng file

Ilagay ang profile sa direktoryo ng client na inaasahan ng package, halimbawa /etc/openvpn/client/office.conf, at tukuyin mula sa loob ang file ng mga kredensyal gamit ang auth-user-pass office.cred. Ang pangalan ng instance ay ang pangalan ng file na walang suffix, kaya binabasa ng openvpn-client@office ang office.conf. I-enable ito gamit ang sudo systemctl enable --now openvpn-client@office at kumpirmahin ang pagmamapa gamit ang systemctl cat openvpn-client@office sa halip na magtiwala sa halimbawa mula sa blog.

Ang mga landas sa loob ng profile ay nireresolba kaugnay ng working directory ng unit, hindi ng profile mismo, kaya ang isang relatibong linyang ca o auth-user-pass ay maaaring mabigo sa boot kahit gumagana kapag manu-mano mong sinusubukan. Gumamit ng absolute na landas para sa lahat ng dapat hanapin ng unit. Pagkatapos ay basahin ang journalctl -u openvpn-client@office -b pagkatapos ng tunay na boot; ang unit na nag-uulat na aktibo nang walang tunnel ay karaniwang nagbabanggit ng nawawalang file sa log na iyon.

Ang mas lumang mga package ay may ibang pangalan ng template, kaya tinutukoy ng systemctl list-unit-files 'openvpn*' kung alin ang umiiral sa host na ito.

Ang ugali sa muling pagkonekta ay hiwalay na desisyon

Ang profile na may ping-restart ay muling binubuo ang tunnel pagkatapos nitong bumagsak, at ang unit na may direktiba ng restart ay gumagawa ng katulad sa antas ng serbisyo. Iyon ay mga patakarang pinipili mo, hindi mga default na namamana mo. Kung ang koneksyon ay dapat umangat lamang kapag hiniling, sadyang alisin ang ugali ng restart at isulat kung bakit. Kung ang unit ay nagsisimula bago maging magamit ang network, kailangan nito ng patakaran sa muling pagsubok, dahil ang isang bigong pagtatangka sa boot ay hindi kusang umuulit.

Ang paghinto ay kasing-literal: sudo systemctl disable --now openvpn-client@office ay hinihinto ang tumatakbong instance at tinatanggal ang boot link. Ang pag-disable lamang ay nag-iiwan sa tunnel na tumatakbo hanggang sa susunod na reboot, na ikinagulat ng sinumang sumusubok sa pamamagitan ng pag-disable at panonood na nananatiling nakaangat ang interface.

I-reboot, pagkatapos ay suriin ang apat na bagay sa pagkakasunod-sunod

Ang pag-restart ng serbisyo ay sumusubok sa serbisyo; ang pag-reboot ng makina ay sumusubok sa landas ng boot. Pagkatapos ng reboot, kumpirmahin na umangat ang unit, pagkatapos na may ruta para sa malayong subnet, pagkatapos kung aling address ang ipinapakita ng makina sa internet, at sa huli na nireresolba ang mga pangalan sa pamamagitan ng tunnel. Ang apat na pagsusuring iyon ay bumabagsak sa ganoong pagkakasunod-sunod kapag may mali, na ginagawang kapaki-pakinabang ang unang pagkabigo.

Ang unit na aktibo nang walang ruta ay karaniwang nangangahulugang kumonekta ang profile ngunit walang itinulak na ruta ang server, o na-install ang ruta sa isang interface na nawala kalaunan. Ang rutang walang gumaganang paghahanap ng pangalan ay tumuturo sa configuration ng DNS at hindi sa tunnel mismo.

Magpasya nang maaga kung ano ang dapat mangyari kapag hindi umaangat ang tunnel. Ang pagbabalik sa ordinaryong konektibidad ay isang patakaran, at dapat itong isulat sa halip na ipaubaya sa sinumang tagapamahala na naunang nagsimula.