Samotný hook na spaní VPN nevrátí

Hook, který skončí s nulou, dokazuje jen to, že se skript spustil. Zařaďte ho až za síť, použijte správnou identitu a ověřte, zda je profil vůbec způsobilý.

Dejte do hooku na spaní příkaz pro opětovné připojení a problém vypadá vyřešený. Vyřešený je jen tehdy, když hook běží poté, co síť existuje, pod identitou, kterou klient rozpozná, cestou, kterou klient skutečně implementuje. Většina selhání po probuzení je jedna z těch tří a žádné se neprojeví jako chyba v samotném hooku. Hook vrátí úspěch tak jako tak.

Skript, který skončí s nulou, vám neřekl nic o tom, zda se tunel vrátil.

Hook běží, a co pak?

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

Každá událost vyvolá hook dvakrát, před přechodem a po něm, a předá mu fázi a název události. Běží jako root s minimálním prostředím, takže jsou nutné absolutní cesty a nemá se očekávat žádná proměnná z desktopové relace. To, že se obě volání rychle vrátí, říká jen, že se skript spustil. Zda se profil potom zvedl, je samostatné pozorování a potřebuje vlastní důkaz v logu.

Berte argument fáze jako součást návrhu. Pokus o opětovné připojení ve fázi pre nastává, když stroj právě ztrácí všechno, a nemůže uspět.

Root, minimální prostředí, špatný uživatel

Pokud klient drží přihlašovací token pro každého uživatele, běh hooku jako root mu nenechá nic k předložení. Kontrolujte stav pod identitou, kterou hook skutečně používá, ne pod tou, kterou jste testovali z desktopového terminálu. Některé buildy také po odpojení nechávají démona držet rozhraní, takže opětovné připojení skončí v zastaralém stavu, a vyčištění procesu ho nejdřív obnoví za cenu nečistého vypnutí. Ani jedno chování není vidět, pokud testujete jen šťastnou cestu.

Pište hook s absolutními cestami, držte ho vlastněný rootem a spustitelný a logujte, co udělal. Bez toho logu začíná další vyšetřování od nuly.

Automatické připojení není cesta VPN

NetworkManager nabízí dva aktivační mechanismy: příznak automatického připojení v profilu a sekundární připojení, která se spustí, když se aktivuje primární profil. Nativní typy zařízení implementují první; pluginy VPN historicky implementovaly jen druhý, takže zaškrtnutí automatického připojení u profilu OpenVPN nemusí mít vůbec žádný účinek. Prohlédněte obě vlastnosti a pak připojte VPN jako sekundární k profilu Wi-Fi nebo Ethernet.

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

Rozhraní WireGuard spravované jednotkou systemd potřebuje ten drop-in místo hooku, seřazený poté, co je síť online.

Počkejte na síť, ale s 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"

Při probuzení může být tunel vyžádán, zatímco se Wi-Fi ještě znovu přidružuje, což dělá z každého pevného spánku hádání. Počkejte na dostupnou adresu, pak profil zvedněte a čekání ohraňte, aby hook nemohl držet cestu probuzení otevřenou neomezeně. Dejte přednost názvu profilu před číselným indexem, a pokud se správný profil liší podle sítě, ať si zdravý tunel svou volbu předem zapíše do souboru.

Braňte se i bouřím restartů tím, že počítáte pokusy a zastavíte. Hlídač, který reaguje na každou neúspěšnou kontrolu, promění jeden výpadek ve smyčku.

Pozastavte systém jednou a pak si v žurnálu přečtěte vlastní výstup hooku. To je jediný test, který dokazuje pořadí.

Související články