Varför dör OpenVPN när laptopen vaknar?

Vila kan döda OpenVPN-sessionen och lämna tun0 kvar. Testa tunneln och starta sedan om enheten från en systemd-vilohook, inte själva enheten.

Försätt maskinen i vila, väck den och kontrollera sedan tre saker i den här ordningen innan du rör någon konfiguration: om tun0 fortfarande finns, om rutten till en intern adress fortfarande väljer den och om servern fortfarande listar den här peeren. En enhet som överlever vilan medan rutten pekar någon annanstans är en kvarleva, inte en tunnel. När rutten är rätt och trafiken ändå dör sitter felet ovanför tunneln och en omstart av klienten ändrar inte det. Att automatisera en omstart är bara meningsfullt efter att ett manuellt test visat vilket av de tre fallen du har.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Reproducera uppvaknandet innan du automatiserar det

Vila avslutar den krypterade sessionen oftare än den tar bort enheten. UDP-flödet som höll tunneln vid liv stannar, servern kan släppa peeren och klienten antingen märker det och återansluter eller behåller ett gränssnitt utan något bakom sig. En gränssnittskontroll i sig bevisar lite, eftersom en föråldrad enhet ser exakt ut som en som fungerar tills paketen måste passera genom den. Kör ruteuppslaget plus en verklig förfrågan genom tunneln och läs sedan journalen kring uppvaknandet.

Om klienten kommer tillbaka av sig själv tillför en hook extra krångel i stället för tillförlitlighet. Om den aldrig återhämtar sig är automatisering den ärliga lösningen.

Var en systemd-vilohook faktiskt bor

Många äldre guider pekar på /etc/pm/sleep.d, en katalog som ägs av pm-utils och som en systemd-baserad vila aldrig rådfrågar. systemd läser hooks från /usr/lib/systemd/system-sleep/ och /etc/systemd/system-sleep/, skickar fasen först och operationen sedan, så pre och post är de enda värden en hook förgrenar sig på. Behåll den lokala kopian under /etc i stället för att redigera en paketerad fil, och kom ihåg att skriptet körs som root mitt i övergången, så det måste återvända snabbt.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart rör bara en enhet när den redan är aktiv, så en tunnel du medvetet stängt av förblir avstängd genom uppvaknandet. --no-block hindrar hooken från att vänta medan klienten förhandlar, vilket spelar roll när nätverket ännu inte är uppe. Tillsammans betyder de två flaggorna en hook som misslyckas tyst i stället för att hålla hela uppvaknandesekvensen tillbaka. När enheten redan är stoppad händer ingenting alls, och det är precis det resultat du vill ha där.

Återställ tjänsten, låt tun0 vara

Tar du ner tun0 för hand lämnas daemonen att övervaka ett gränssnitt den inte längre äger, och nästa tillståndsändring ger förvirrande fel. Rikta dig mot tjänsten eller dess anslutningsprofil i stället för gränssnittet; kontrollera först det exakta enhetsnamnet, eftersom distributionspaket, OpenVPN 3 och NetworkManager alla väljer olika. En NetworkManager-profil kommer tillbaka när den anslutningen cyklas, så systemd-enheten är inte målet där. Vilken mekanism det än är bör det vara samma åtgärd som du verifierade för hand.

En omstart installerar om rutterna som klienten sköt in när den anslöt. De flesta uppvaknanden vill det. En maskin där du lagt till egna vägar vill inte, så kontrollera dem igen i stället för att anta att återställningen lade tillbaka dem, och skriv ner dem där nästa uppvaknande kan hitta dem.

Hantera tajmingen du inte kan styra

Trådlös anslutning och DHCP blir ofta klara efter att hooken kört, så en omstart kan misslyckas medan det ännu inte finns någon väg till servern. Vänta en stund på den adressen, försök en gång till och logga resultatet.

Namnuppslagning är ett eget race, eftersom skrivbordets nätverksstack kan återställa DNS efter att tunneln redan är uppe. Testa uppslagningarna separat med resolvectl query internal.example i stället för att sluta dig till dem från en fungerande rutt. En tunnel som routar korrekt och inte löser något är ett DNS-problem, inte ett hook-problem.

Håll hookens beslut synligt genom att skriva fasen, enhetsnamnet och resultatet i journalen. Anteckna i maskinens noteringar vilket uppvaknandetest du körde, så att en fungerande återställning går att skilja från en lycklig. Välj den minst störande åtgärden som får tjänsten tillbaka, och låt en klient som återhämtar sig själv göra det. En full omstart släpper sessioner som pågår, vilket är en verklig kostnad på en laptop som vaknar flera gånger om dagen.

Relaterade artiklar