Sam hook uśpienia nie przywróci VPN-u

Hook, który kończy się zerem, dowodzi tylko, że skrypt się uruchomił. Ustaw go po sieci, użyj właściwej tożsamości i sprawdź, czy profil jest w ogóle kwalifikowany.

Umieść polecenie ponownego połączenia w hooku uśpienia, a problem wydaje się rozwiązany. Jest rozwiązany tylko wtedy, gdy hook działa po tym, jak sieć istnieje, jako tożsamość, którą klient rozpoznaje, ścieżką, którą klient naprawdę implementuje. Większość awarii po wznowieniu to jedna z tych trzech, i żadna z nich nie pojawia się jako błąd w samym hooku. Hook i tak zwraca sukces.

Skrypt, który kończy się zerem, nie powiedział ci nic o tym, czy tunel wrócił.

Hook działa, i co dalej?

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

Każde zdarzenie wywołuje hook dwa razy, przed przejściem i po nim, przekazując mu fazę i nazwę zdarzenia. Działa jako root w minimalnym środowisku, więc potrzebne są ścieżki bezwzględne i nie należy oczekiwać żadnej zmiennej sesji pulpitu. Szybki powrót obu wywołań mówi tylko, że skrypt się uruchomił. Czy profil potem wstał, to osobna obserwacja i wymaga własnego dowodu w logu.

Traktuj argument fazy jako część projektu. Próba ponownego połączenia w fazie pre zdarza się, gdy maszyna zaraz wszystko straci, i nie może się udać.

Root, minimalne środowisko, zły użytkownik

Jeśli klient trzyma token logowania dla każdego użytkownika, uruchomienie hooka jako root pozostawia go bez niczego do przedstawienia. Sprawdzaj stan pod tożsamością, której hook naprawdę używa, a nie tą, którą testowałeś z terminala pulpitu. Niektóre kompilacje zostawiają po rozłączeniu demona trzymającego interfejs, więc ponowne połączenie trafia w nieaktualny stan, a wcześniejsze wyczyszczenie procesu przywraca go kosztem nieczystego zamknięcia. Żadne z tych zachowań nie jest widoczne, jeśli testujesz tylko szczęśliwą ścieżkę.

Pisz hook z bezwzględnymi ścieżkami, trzymaj go w posiadaniu roota i wykonywalny, i loguj, co zrobił. Bez tego logu następne dochodzenie zaczyna się od zera.

Automatyczne połączenie nie jest ścieżką VPN

NetworkManager oferuje dwa mechanizmy aktywacji: flagę automatycznego połączenia w profilu i połączenia wtórne, które startują, gdy aktywuje się profil główny. Rodzime typy urządzeń implementują pierwszy; wtyczki VPN historycznie implementowały tylko drugi, więc zaznaczenie automatycznego połączenia w profilu OpenVPN może w ogóle nie mieć efektu. Sprawdź obie właściwości, a potem podepnij VPN jako wtórne do profilu Wi-Fi lub Ethernet.

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

Interfejs WireGuard zarządzany przez jednostkę systemd potrzebuje tego pliku dodatkowego zamiast hooka, uporządkowany po tym, jak sieć jest online.

Poczekaj na sieć, z limitem

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"

Przy wznowieniu tunel może być wymagany, gdy Wi-Fi jeszcze łączy się ponownie, co czyni każde stałe uśpienie zgadywaniem. Poczekaj na osiągalny adres, potem podnieś profil, i ogranicz czekanie, żeby hook nie mógł trzymać ścieżki wznowienia otwartej bez końca. Preferuj nazwę profilu zamiast indeksu liczbowego, a jeśli właściwy profil różni się w zależności od sieci, niech zdrowy tunel zapisze swój wybór do pliku z góry.

Chroń się też przed burzami restartów, licząc próby i zatrzymując się. Watchdog, który reaguje na każdą nieudaną próbę, zamienia jedną awarię w pętlę.

Wstrzymaj system raz, potem przeczytaj w dzienniku własne wyjście hooka. To jedyny test, który dowodzi kolejności.

Powiązane artykuły