Systemd laban sa NetworkManager: sino ang nagbubukas ng VPN sa boot?

Dalawang makinang Ubuntu mula sa parehong imahe, isang VPN profile, magkasalungat ang resulta sa pag-log in: sa isa, nakataas na ang tunnel bago pa lumitaw ang desktop; sa isa pa, hindi ito bumabangon kailanman. Hindi ang profile ang baryabol dito. Ang pagkakaiba ay kung alin sa tatlong bahagi ang inutusang magsimula nito, at ang tatlong iyon ay hindi nagbabahagi ng isang switch.

Mas mabilis ang paghahambing nang magkatabi kaysa sa paghula. Bawat isa ay nabibigo sa makikilalang paraan, at iyon ang dahilan kung bakit sulit ang paghahambing.

Tatlong panimula na may tatlong magkaibang trigger

Ang naka-package na serbisyong openvpn ang pinakamatandang landas. Binabasa ng init script nito ang listahan ng autostart mula sa /etc/default/openvpn. Kung ang listahang iyon ay naka-comment o iniwang blangko, sinisimulan ng script ang bawat configuration na makita nito sa direktoryong iyon sa halip na ang nag-iisang idinagdag mo. Ang isang file na idinagdag para sa isang tunnel ay maaaring tahimik na magpaangat ng ilan.

Ang ikalawang hilera ang madalas na mali ang pagkakaayos. Hawak ng NetworkManager ang inangkat na profile at sisimulan ito, ngunit bilang sekundaryo lamang ng ibang koneksyon, ibig sabihin, pag-aari ng network link ang trigger at hindi ng VPN.

Ihambing ang gastos sa pag-set up at ang saklaw

Ang landas ng init script ay isang linya lamang ang gastos at sinasaklaw ang bawat configuration sa makina. Tama iyon para sa router at mali para sa laptop na sumasali sa magkaibang network. Ang landas ng NetworkManager ay nangangailangan ng isang paghahanap ng UUID at itinatali ang tunnel sa isang batayang koneksyon. Bumabangon ito sa SSID ng trabaho at nananatiling patay sa network ng hotel.

Ang unit na isinulat sa kamay ang pinakamahal at nagbibigay ng pinakamaraming kontrol, kasama ang pagkakasunod-sunod laban sa ibang serbisyo. Ang saklaw ang tagapagpasya. Kung isang network at isang tunnel lang ang makina, tapat at mahuhulaan ang naka-package na serbisyo. Kung dapat sundan ng tunnel ang isang partikular na Wi-Fi, ang sekundaryo lang sa tatlo ang nagpapahayag ng kondisyong iyon nang walang dagdag na script.

Pumili ng isang may-ari at alisin ang iba

Ang profile na sinisimulan ng dalawang may-ari ay nagdudulot ng timing na nagbabago sa bawat boot, na mas masama kaysa sa alinman sa mga mekanismo nang nag-iisa. Piliin ang may-ari, pagkatapos ay sadyang patayin ang karibal na landas, hindi aksidente lang.

# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'

# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"

Kung ang itinatabi ay ang naka-package na landas, gawin ito sa tamang pagkakasunod-sunod: itakda ang AUTOSTART sa none, patakbuhin ang systemctl daemon-reload upang makuha ng mga nalikhang unit ang bagong listahan, pagkatapos ay i-disable ang template instance na ayaw mo na. Kapag nilaktawan ang reload, nananatiling aktibo ang lumang unit, at mukhang walang naging epekto ang pagbabago.

Ang paghinto na bumabitin ay hiwalay na problema na may limitadong sagot. Nililimitahan ng TimeoutStopSec kung gaano katagal maghintay ang systemd bago magpadala ng SIGKILL. Ang drop-in ang tamang lugar para itakda iyon, dahil ang pag-edit sa naka-package na unit ay nawawala ang pagbabago sa susunod na upgrade.

Tiyakin kung ano talaga ang nagsimula

Mag-reboot at basahin ang ebidensya sa halip na magtiwala sa configuration file. Ipapakita ng unit na may-ari ng tunnel ang aktibong estado at timestamp ng pagsisimula na tugma sa boot, at naroon na ang VPN interface bago ka mag-log in.

systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0

May isa pang pagsusuri na nararapat dito: tiyakin na ang ExecStart ng unit ay tumuturo sa binary na iniisip mo. Ang kliyenteng kinompile nang lokal o ang snap package ay madalas mangailangan ng tahasang path o snap run wrapper, dahil hindi namamana ng systemd ang pagkakasunod-sunod ng paghahanap ng iyong shell. Ang paghahambing ng command -v openvpn sa unit file ay nagtatapos nito sa ilang segundo.

Isulat ang napiling may-ari sa mga tala ng makina, sa tabi ng pangalan ng profile. Ang susunod na taong magde-debug ng nawawalang tunnel ay magsisimula sa linyang iyon sa halip na ulitin ang paghahambing.