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 вырашае гэта за секунды.

Запішыце выбранага гаспадара ў нататкі машыны, побач з назвай профілю. Наступны чалавек, які будзе шукаць адсутны тунель, пачне з гэтага радка замест таго, каб паўтараць параўнанне.