Зашто OpenVPN умире после буђења лаптопа?

Спавање може да убије сесију OpenVPN-а и остави tun0. Тестирајте тунел, затим рестартујте јединицу из systemd hook-а спавања, а не уређај.

Ставите машину у спавање, пробудите је, па пре него што дотакнете било коју конфигурацију проверите три ствари у овом редоследу: да ли tun0 још постоји, да ли рута до унутрашње адресе још увек бира њега и да ли сервер још увек наводи овај peer. Уређај који преживи спавање док рута показује негде другде је остатак, а не тунел. Када је рута исправна, а саобраћај ипак умире, квар је изнад тунела и рестарт клијента то неће променити. Аутоматизација рестарта има смисла само пошто ручни тест покаже који од та три случаја имате.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Репродукујте буђење пре него што га аутоматизујете

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

Ако се клијент врати сам, hook додаје метеж уместо поузданости. Ако се никада не опорави, аутоматизација је искрено решење.

Где заправо живи systemd hook спавања

Многи стари водичи упућују на /etc/pm/sleep.d, директоријум који поседује pm-utils и који спавање засновано на systemd никада не консултује. systemd чита hook-ове из /usr/lib/systemd/system-sleep/ и /etc/systemd/system-sleep/, преносећи прво фазу, а затим операцију, па су pre и post једине вредности на којима се hook грана. Држите локалну копију под /etc уместо да уређујете спаковану датотеку и запамтите да скрипта ради као root у средини транзиције, зато мора брзо да се врати.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart дотиче јединицу само када је она већ активна, па тунел који сте намерно искључили остаје искључен током буђења. --no-block спречава hook да чека док клијент преговара, што је важно када мрежа још није подигнута. Заједно два знака значе hook који тихо не успева уместо да задржи цео низ буђења. Када је јединица већ заустављена, не дешава се баш ништа, и то је тачно резултат који тамо желите.

Вратите услугу, оставите tun0 на миру

Ручно спуштање tun0 оставља демона да надгледа интерфејс који више не поседује, а следећа промена стања ствара збуњујуће грешке. Циљајте услугу или њен профил везе, а не интерфејс; прво проверите тачно име јединице, јер дистрибуцијски пакети, OpenVPN 3 и NetworkManager бирају различита. NetworkManager профил се враћа када се та веза рециклира, па systemd јединица тамо није циљ. Који год механизам био, то би требало да буде исто дејство које сте проверили ручно.

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

Позабавите се тајмингом који не можете да контролишете

Бежично повезивање и DHCP често завршавају након што се hook изврши, па рестарт може да не успе док још нема пута до сервера. Сачекајте кратко ту адресу, покушајте још једном и забележите резултат.

Разрешавање имена је посебна трка, јер мрежни стек радне површине може да врати DNS након што је тунел већ подигнут. Тестирајте претраге одвојено са resolvectl query internal.example уместо да их изводите из радне руте. Тунел који исправно рутира и ништа не разрешава је DNS проблем, а не проблем hook-а.

Држите одлуку hook-а видљивом тако што ћете фазу, име јединице и резултат уписати у дневник. Забележите у белешкама машине који тест буђења сте извршили, да би се радно опорављање разликовало од срећног. Изаберите најмање ометајуће дејство које враћа услугу и допустите клијенту који се сам опоравља да то уради. Потпуни рестарт одбацује сесије у току, што је стварни трошак на лаптопу који се буди неколико пута дневно.

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