Сам hook за спавање неће вратити VPN

Hook који изађе са нулом доказује само да се скрипта извршила. Поставите га после мреже, користите исправан идентитет и проверите да ли је профил уопште подобан.

Ставите команду за поновно повезивање у hook за спавање и проблем изгледа решен. Решен је само ако се hook изврши након што мрежа постоји, као идентитет који клијент препознаје, путем који клијент заиста имплементира. Већина неуспеха после буђења је један од та три, и ниједан се не појављује као грешка у самом hook-у. Hook у сваком случају враћа успех.

Скрипта која изађе са нулом није вам рекла ништа о томе да ли се тунел вратио.

Hook се извршава, и шта онда?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

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

Третирајте аргумент фазе као део дизајна. Покушај поновног повезивања у фази pre дешава се док је машина на прагу губитка свега и не може успети.

Root, минимално окружење, погрешан корисник

Ако клијент чува токен за пријаву по кориснику, покретање hook-а као root оставља га без ичега да представи. Проверите стање под идентитетом који hook заиста користи, а не под оним који сте тестирали из десктоп терминала. Неке градње после прекида оставе и демон који држи интерфејс, па поновно повезивање заврши у застарелом стању, а чишћење процеса прво га врати по цену нечистог искључивања. Ниједно од два понашања није видљиво ако тестирате само срећан пут.

Пишите hook са апсолутним путањама, држите га у власништву root-а и извршним, и забележите шта је урадио. Без тог дневника следећа истрага почиње од нуле.

Аутоматско повезивање није пут VPN-а

NetworkManager нуди два механизма активирања: заставицу аутоматског повезивања на профилу и секундарне везе које почињу када се активира примарни профил. Изворни типови уређаја имплементирају први; VPN додаци су историјски имплементирали само други, па означавање аутоматског повезивања на OpenVPN профилу можда уопште неће имати ефекта. Прегледајте оба својства, а затим прикачите VPN као секундаран уз Wi-Fi или Ethernet профил.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

WireGuard интерфејсу којим управља systemd јединица потребна је та допунска датотека уместо hook-а, поређана након што мрежа буде онлајн.

Сачекајте мрежу, са горњом границом

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

При буђењу тунел може бити затражен док се Wi-Fi још поново повезује, што свако фиксно спавање чини нагађањем. Сачекајте доступну адресу, затим подигните профил, и ограничите чекање да hook не би могао неограничено да држи пут буђења отворен. Дајте предност имену профила над нумеричким индексом, и ако се исправан профил разликује по мрежи, нека здрави тунел унапред забележи свој избор у датотеку.

Чувајте се и олуја рестартовања, бројањем покушаја и заустављањем. Надзорник који реагује на сваку неуспелу проверу претвара један прекид у петљу.

Суспендујте систем једном, затим прочитајте у дневнику сопствени излаз hook-а. То је једини тест који доказује редослед.

Повезани чланци