Чаму OpenVPN гіне пасля абуджэння ноўтбука?

Сон можа забіць сесію OpenVPN, пакінуўшы tun0. Праверце тунэль, затым перазапусціце юніт праз хук сну systemd, а не прыладу.

Прыпыніце машыну, аднавіце яе, затым праверце тры рэчы ў гэтым парадку, перш чым кранаць якую-небудзь канфігурацыю: ці tun0 яшчэ існуе, ці маршрут да ўнутранага адраса ўсё яшчэ выбірае яго і ці сервер усё яшчэ пералічвае гэтага партнёра. Прылада, якая перажывае сон, пакуль маршрут паказвае ў іншае месца, — гэта рэштка, а не тунэль. Калі маршрут правільны, а трафік усё роўна гіне, няспраўнасць знаходзіцца над тунэлем, і перазапуск кліента гэтага не зменіць. Аўтаматызаваць перазапуск мае сэнс толькі пасля таго, як ручная праверка пакажа, які з гэтых трох выпадкаў у вас.

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

Аднавіце сітуацыю перад тым, як аўтаматызаваць

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

Калі кліент вяртаецца сам, хук дадае мітусню замест надзейнасці. Калі ён ніколі не аднаўляецца, аўтаматызацыя — гэта сумленнае рашэнне.

Дзе насамрэч жыве хук сну systemd

Мноства старых кіраўніцтваў паказваюць на /etc/pm/sleep.d, каталог, якім валодае pm-utils і да якога прыпыненне на базе systemd ніколі не звяртаецца. systemd чытае хукі з /usr/lib/systemd/system-sleep/ і /etc/systemd/system-sleep/, перадаючы спачатку фазу, а потым аперацыю, таму pre і post — адзіныя значэнні, на якіх разгаліноўваецца хук. Трымайце лакальную копію ў /etc замест рэдагавання файла з пакета і памятайце, што скрыпт выконваецца ад імя root у сярэдзіне пераходу, таму ён павінен вяртацца хутка.

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

try-restart закранае юніт толькі тады, калі ён ужо актыўны, таму тунэль, які вы наўмысна адключылі, застаецца адключаным і пасля аднаўлення. --no-block не дае хуку чакаць, пакуль кліент дамаўляецца, што важна, калі сетка яшчэ не паднялася. Разам два сцягі азначаюць хук, які ціха памыляецца замест таго, каб затрымліваць усю паслядоўнасць аднаўлення. Калі юніт ужо спынены, не адбываецца наогул нічога, і гэта менавіта той вынік, які вам патрэбны.

Аднавіце службу, пакіньце tun0 у спакоі

Калі здымаць tun0 уручную, дэман застаецца наглядаць за інтэрфейсам, якім ён ужо не валодае, і наступнае змяненне стану спараджае заблытаныя памылкі. Нацэльвайцеся на службу ці яе профіль злучэння, а не на інтэрфейс; спачатку праверце дакладнае імя юніта, бо пакункі дыстрыбутываў, OpenVPN 3 і NetworkManager выбіраюць розныя. Профіль NetworkManager вяртаецца, калі гэта злучэнне перазапускаюць, таму юніт systemd там не мэта. Якім бы ні быў механізм, гэта павінна быць тое самае дзеянне, якое вы праверылі ўручную.

Перазапуск пераўсталёўвае маршруты, якія кліент праштурхнуў пры падключэнні. Большасць аднаўленняў гэтага хоча. Машына, дзе вы дадалі ўласныя шляхі, — не, таму пераправерце іх, замест таго каб меркаваць, што аднаўленне іх вярнула, і запішыце іх там, дзе наступнае аднаўленне зможа іх знайсці.

Разбярыцеся з тэрмінамі, якія вы не кантралюеце

Бесправадная асацыяцыя і DHCP часта завяршаюцца пасля таго, як хук адпрацаваў, таму перазапуск можа праваліцца, пакуль шляху да сервера яшчэ няма. Пачакайце крыху гэты адрас, паспрабуйце яшчэ раз і запішыце вынік у журнал.

Развязанне імён — асобная гонка, бо сеткавы стэк працоўнага стала можа аднавіць DNS пасля таго, як тунэль ужо падняты. Праверце запыты асобна з resolvectl query internal.example, а не выводзьце іх з працоўнага маршруту. Тунэль, які правільна маршрутызуе і нічога не развязвае, — гэта праблема DNS, а не праблема хука.

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

Падобныя артыкулы