Защо OpenVPN умира след събуждане на лаптопа?

Заспиването може да убие сесията на OpenVPN, а tun0 да остане. Тествайте тунела, после рестартирайте юнита от sleep hook на systemd, а не устройството.

Спрете машината, възобновете я, после проверете три неща в този ред, преди да пипате каквато и да е конфигурация: дали 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-ът добавя суетене вместо надеждност. Ако никога не се възстанови, автоматизацията е честното решение.

Къде всъщност живее sleep hook на systemd

Много стари ръководства сочат /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-а видимо, като записвате фазата, името на юнита и резултата в журнала. Отбележете в бележките на машината кой тест на възобновяване сте пуснали, за да може работещо възстановяване да се различи от щастливо. Изберете най-малко разрушителното действие, което връща услугата, и оставете клиент, който се възстановява сам, да го направи. Пълният рестарт изхвърля активните сесии, което е реален разход на лаптоп, който се възобновява няколко пъти на ден.

Подобни статии