Systemd срещу NetworkManager: кой стартира VPN при зареждане?
Три механизма могат да вдигнат един и същ профил в Ubuntu, всеки с различен задействащ фактор. Сравнете ги, оставете един собственик и премахнете дубликата.
Две машини с Ubuntu от един и същ образ, един VPN профил, противоположни резултати при вход: на едната тунелът е вдигнат преди появата на работния плот, а на другата не се вдига никога. Профилът не е променливата тук. Разликата е кой от три компонента е получил задача да го стартира и тези три не споделят един превключвател.
Сравняването им една до друга е по-бързо от гадаене. Всяко от тях се проваля по разпознаваем начин и точно затова сравнението си заслужава.
Три стартиращи механизма с три различни задействания
Пакетираната услуга openvpn е най-старият път. Нейният init скрипт чете списък за автоматично стартиране от /etc/default/openvpn. Ако този списък е закоментиран или оставен празен, скриптът стартира всяка конфигурация, която намери в тази директория, вместо единствената, която сте добавили. Един файл, добавен за един тунел, може тихо да вдигне няколко.
| Starter | What triggers it | Typical failure |
|---|---|---|
| Init script and templated units | Boot, plus anything in the autostart list | Starts every config, not the one you meant |
| NetworkManager secondary | Activation of the base Wi-Fi or Ethernet profile | Nothing happens until that base link comes up |
| Hand-written unit or wrapper | Whatever its WantedBy and ExecStart say | Runs a different binary or environment than your shell |
Вторият ред е този, който хората конфигурират грешно. 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-а решава това за секунди.
Запишете избрания собственик в бележките на машината, до името на профила. Следващият човек, който отстранява липсващ тунел, ще започне от този ред, вместо да повтаря сравнението.