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-от тоа го решава за секунди.
Запишете го избраниот сопственик во белешките на машината, покрај името на профилот. Следниот човек што ќе отстранува дефект на тунел што недостасува ќе почне од тој ред наместо да ја повторува споредбата.