Один лише хук сну не поверне 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, яким керує юніт 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 ще перепідключається, що робить будь-який фіксований сон здогадкою. Дочекайтеся доступної адреси, потім підніміть профіль, і обмежте очікування, щоб хук не міг тримати шлях пробудження відкритим нескінченно. Надавайте перевагу назві профілю над числовим індексом, і якщо правильний профіль залежить від мережі, нехай здоровий тунель заздалегідь запише свій вибір у файл.

Стережіться і бур перезапуску: рахуйте спроби й зупиняйтеся. Сторож, який реагує на кожну невдалу перевірку, перетворює один збій на цикл.

Призупиніть систему один раз, потім прочитайте в журналі власний вивід хука. Це єдиний тест, що доводить порядок.

Схожі статті