Systemd kontraŭ NetworkManager: kiu startigas la VPN ĉe la lanĉo?

Du Ubuntu-maŝinoj el la sama bildo, unu VPN-profilo, kontraŭaj rezultoj ĉe ensaluto: ĉe unu la tunelo estas supre antaŭ ol la labortablo aperas, ĉe la alia ĝi neniam leviĝas. La profilo ne estas la variablo ĉi tie. La diferenco estas, kiun el tri komponantoj oni ordonis startigi ĝin, kaj tiuj tri ne dividas unu ŝaltilon.

Komparo flank-al-flanke estas pli rapida ol divenado. Ĉiu el ili malsukcesas laŭ rekonebla maniero, kaj tio estas kio faras la komparon inda.

Tri lanĉiloj kun tri malsamaj ellasiloj

La pakaĵa openvpn-servo estas la plej malnova vojo. Ĝia init-skripto legas aŭtostartan liston el /etc/default/openvpn. Se tiu listo estas komentita aŭ lasita malplena, la skripto startigas ĉiun agordon, kiun ĝi trovas en tiu dosierujo, anstataŭ la ununuran, kiun vi aldonis. Unu dosiero aldonita por unu tunelo povas silente levi plurajn.

La dua vico estas tiu, kiun homoj agordas malĝuste. NetworkManager tenas la importitan profilon kaj startigos ĝin, sed nur kiel duaranga de alia konekto, kio signifas, ke la ellasilo apartenas al la reta ligo kaj ne al la VPN.

Komparu la agordan koston kaj la amplekson

La vojo tra la init-skripto kostas unu linion kaj kovras ĉiun agordon en la maŝino. Tio taŭgas por enkursigilo kaj malĝustas por tekkomputilo, kiu aliĝas al malsamaj retoj. La vojo de NetworkManager kostas UUID-serĉon kaj ligas la tunelon al unu baza konekto. Ĝi leviĝas en la laboreja SSID kaj restas malsupre en hotela reto.

Mane skribita unito kostas plej multe kaj aĉetas la plej grandan kontrolon, inkluzive ordigon rilate aliajn servojn. La amplekso estas la decida faktoro. Se la maŝino havas unu reton kaj unu tunelon, la pakaĵa servo estas honesta kaj antaŭvidebla. Se la tunelo devas sekvi specifan Wi-Fi-reton, la duaranga estas la sola el la tri, kiu esprimas tiun kondiĉon sen plia skriptado.

Elektu unu posedanton kaj forigu la aliajn

Profilo startigita de du posedantoj produktas tempiĝon, kiu ŝanĝiĝas inter lanĉoj, kio estas pli malbona ol iu ajn el la mekanismoj sola. Elektu la posedanton, poste malŝaltu la konkurantan vojon intence anstataŭ hazarde.

# 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"

Se la pakaĵa vojo estas tiu, kiu estas retiriĝanta, faru ĝin en la ĝusta ordo: agordu AUTOSTART al none, rulu systemctl daemon-reload por ke la generitaj unitoj prenu la novan liston, poste malŝaltu la ŝablonan instancon, kiun vi ne plu volas. Se vi preterlasas la reŝargon, la malnovaj unitoj restas aktivaj, kio aspektas kvazaŭ la ŝanĝo nenion efikis.

Halto, kiu pendas, estas aparta problemo kun limigita respondo. TimeoutStopSec limigas kiom longe systemd atendas antaŭ ol sendi SIGKILL. Drop-in dosiero estas la ĝusta loko por difini ĝin, ĉar redaktado de la pakaĵa unito perdas la ŝanĝon ĉe la sekva ĝisdatigo.

Kontrolu, kio efektive startis

Restartigu kaj legu la pruvojn anstataŭ fidi la agordan dosieron. La unito, kiu posedas la tunelon, montros aktivan staton kaj startan tempomarkon kongruan kun la lanĉo, kaj la VPN-interfaco ekzistos antaŭ ol vi ensalutos.

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

Unu plia kontrolo apartenas ĉi tien: konfirmu, ke la ExecStart de la unito montras al la binara dosiero, kiun vi pensas. Loke kompilita kliento aŭ snap-pakaĵo ofte bezonas eksplicitan vojon aŭ snap run-ĉirkaŭvolvaĵon, ĉar systemd ne heredas la serĉordon de via ŝelo. Kompari command -v openvpn kun la unita dosiero solvas tion en sekundoj.

Skribu la elektitan posedanton en la notojn de la maŝino, apud la profila nomo. La sekva persono, kiu sencimigos mankan tunelon, komencos de tiu linio anstataŭ ripeti la komparon.