Само една кука за заспиване няма да върне VPN

Кука, която излиза с нула, доказва само, че скриптът е стартирал. Подредете я след мрежата, използвайте правилната идентичност и проверете дали профилът изобщо е подходящ.

Сложете команда за повторно свързване в куката за заспиване и проблемът изглежда решен. Той е решен само ако куката се изпълни след като мрежата съществува, с идентичност, която клиентът разпознава, по път, който клиентът наистина реализира. Повечето откази след събуждане са едно от тези три, и нито едно от тях не се появява като грешка в самата кука. Куката връща успех така или иначе.

Скрипт, който излиза с нула, не ви е казал нищо за това дали тунелът се е върнал.

Куката се изпълнява, и после какво?

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

Всяко събитие извиква куката два пъти — преди и след прехода — и ѝ подава фазата и името на събитието. Тя работи като root с минимална среда, затова са нужни абсолютни пътища и не бива да се очаква променлива от сесия на работния плот. Това, че и двете извиквания се връщат бързо, казва само, че скриптът е стартирал. Дали профилът е вдигнат след това е отделно наблюдение и се нуждае от собствени доказателства в журнала.

Третирайте аргумента за фазата като част от дизайна. Опит за повторно свързване във фаза pre се случва, докато машината е на път да загуби всичко, и не може да успее.

Root, минимална среда, грешен потребител

Ако клиентът пази токена за вход за всеки потребител, пускането на куката като root я оставя без нищо за представяне. Проверявайте състоянието под идентичността, която куката действително използва, а не онази, която сте тествали от терминал на работния плот. Някои сборки също оставят демон, който държи интерфейса след прекъсване, така че повторното свързване попада в остаряло състояние, а изчистването на процеса първо го възстановява с цената на нечисто спиране. Нито едно от двете поведения не се вижда, ако тествате само щастливия път.

Пишете куката с абсолютни пътища, дръжте я притежавана от root и изпълнима, и записвайте какво е направила. Без този журнал следващото разследване започва от нула.

Автоматичното свързване не е пътят на VPN

NetworkManager предлага два механизма за активиране: флаг за автоматично свързване в профила и вторични връзки, които стартират, когато се активира основен профил. Собствените типове устройства реализират първия; плъгините за VPN исторически са реализирали само втория, затова отмятането на автоматично свързване в профил OpenVPN може да няма никакъв ефект. Проверете и двете свойства, после прикачете VPN като вторична връзка към профила за Wi-Fi или Ethernet.

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

Интерфейс WireGuard, управляван от unit на systemd, се нуждае от този допълнителен файл, а не от кука, подреден след като мрежата е онлайн.

Изчакайте мрежата, но с таван

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

Пазете се и от бури от рестарти, като броите опитите и спирате. Пазач, който реагира на всяка неуспешна проверка, превръща един срив в цикъл.

Спрете системата веднъж, после прочетете журнала за собствения изход на куката. Това е единственият тест, който доказва подредбата.

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