Systemd наспрам NetworkManager-а: ко подиже VPN при подизању система?

Два Ubuntu рачунара из исте слике, један VPN профил, супротни исходи при пријави: на једном је тунел већ горе пре него што се појави радна површина, а на другом се никада не диже. Профил овде није променљива. Разлика је у томе којој је од три компоненте наложено да га покрене, а те три не деле исти прекидач.

Упоређивање једног уз друго брже је од нагађања. Сваки од њих пада на препознатљив начин, и управо то чини поређење вредним.

Три покретача са три различита окидача

Пакетна openvpn услуга је најстарији пут. Њена init скрипта чита листу за аутоматско покретање из /etc/default/openvpn. Ако је та листа закоментарисана или остављена празна, скрипта покреће сваку конфигурацију коју нађе у том директоријуму, а не ону једину коју сте додали. Један фајл додат за један тунел може тихо подићи њих неколико.

Други ред је онај који људи погрешно постављају. NetworkManager држи увезени профил и покренуће га, али само као секундарно на другој вези, што значи да окидач припада мрежном споју, а не VPN-у.

Упоредите цену постављања и обим

Пут преко init скрипте кошта један ред и покрива сваку конфигурацију на машини. То је у реду за рутер, а погрешно за лаптоп који се спаја на различите мреже. Пут преко NetworkManager-а кошта претрагу UUID-а и везује тунел за једну основну везу. Диже се на мрежи на послу, а остаје спуштен на хотелској.

Ручно написан unit кошта највише и даје највише контроле, укључујући редослед према другим услугама. Обим је одлучујући чинилац. Ако машина има једну мрежу и један тунел, пакетна услуга је поштена и предвидива. Ако тунел треба да прати одређену Wi-Fi мрежу, секундарно је једино од три које тај услов изражава без додатног скриптовања.

Изаберите једног власника и уклоните остале

Профил који покрећу два власника даје тајминг који се мења између подизања система, што је горе од било ког механизма самог. Изаберите власника, па потом намерно, а не случајно, онемогућите конкурентски пут.

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

Ако се повлачи пакетни пут, урадите то правим редоследом: поставите AUTOSTART на none, покрените systemctl daemon-reload да генерисани unit-и преузму нову листу, па онемогућите инстанцу шаблона коју више не желите. Прескакање поновног учитавања оставља старе unit-е активним, па изгледа као да промена није имала никакав ефекат.

Заустављање које виси јесте засебан проблем са ограниченим одговором. TimeoutStopSec ограничава колико systemd чека пре слања SIGKILL-а. Drop-in је право место да се то постави, јер уређивање пакетног unit-а губи промену при следећем ажурирању.

Проверите шта је заиста покренуто

Поново подигните систем и читајте доказе уместо да верујете конфигурационој датотеци. Unit који поседује тунел показаће активно стање и време покретања које се поклапа са подизањем система, а VPN интерфејс ће постојати пре него што се пријавите.

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

Овде спада још једна провера: потврдите да ExecStart unit-а показује на бинар који мислите. Локално компајлирани клијент или snap пакет често тражи изричиту путању или омотач snap run, јер systemd не наслеђује редослед претраге ваше љуске. Поређење command -v openvpn са датотеком unit-а решава то у секундама.

Запишите изабраног власника у белешке машине, уз назив профила. Следећа особа која буде тражила тунел који недостаје почеће од тог реда уместо да понови поређење.