Waarom sterft OpenVPN wanneer de laptop wakker wordt?

Zet de machine in slaapstand, wek hem, en controleer daarna drie dingen in deze volgorde voordat je welke configuratie dan ook aanraakt: of tun0 nog bestaat, of de route naar een intern adres hem nog kiest, en of de server deze peer nog vermeldt. Een apparaat dat de slaap overleeft terwijl de route ergens anders heen wijst, is een restant, geen tunnel. Als de route klopt en het verkeer sterft alsnog, zit de fout boven de tunnel en een herstart van de client verandert daar niets aan. Een herstart automatiseren is pas zinvol nadat een handmatige test heeft laten zien welk van die drie gevallen je hebt.

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

Reproduceer het ontwaken voordat je het automatiseert

Slaap beëindigt de versleutelde sessie vaker dan dat hij het apparaat verwijdert. De UDP-stroom die de tunnel in leven hield, stopt, de server kan de peer laten vallen, en de client merkt het ofwel en verbindt opnieuw, of houdt een interface zonder iets erachter. Een interfacecontrole op zichzelf bewijst weinig, omdat een verouderd apparaat er precies zo uitziet als een werkend totdat pakketten erdoorheen moeten. Voer de routeopzoeking plus één echt verzoek door de tunnel uit en lees daarna het journaal rond het moment van ontwaken.

Als de client vanzelf terugkomt, voegt een hook ruis toe in plaats van betrouwbaarheid. Als hij nooit herstelt, is automatisering de eerlijke oplossing.

Waar een systemd-slaaphook echt woont

Veel oudere handleidingen wijzen naar /etc/pm/sleep.d, een map die eigendom is van pm-utils en waarnaar een op systemd gebaseerde slaapstand nooit kijkt. systemd leest hooks uit /usr/lib/systemd/system-sleep/ en /etc/systemd/system-sleep/, geeft eerst de fase en daarna de bewerking door, dus pre en post zijn de enige waarden waarop een hook vertakt. Houd de lokale kopie onder /etc in plaats van een verpakt bestand te bewerken, en onthoud dat het script als root midden in de overgang draait, dus het moet snel terugkeren.

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

try-restart raakt een unit alleen aan als die al actief is, dus een tunnel die je bewust hebt gestopt blijft gestopt tijdens het ontwaken. --no-block weerhoudt de hook ervan te wachten terwijl de client onderhandelt, wat uitmaakt wanneer het netwerk nog niet up is. Samen betekenen de twee vlaggen een hook die stil faalt in plaats van de hele ontwaakreeks tegen te houden. Als de unit al gestopt is, gebeurt er helemaal niets, en dat is precies het resultaat dat je daar wilt.

Herstel de service, laat tun0 met rust

Als je tun0 met de hand neerhaalt, houdt de daemon toezicht op een interface die hij niet meer bezit, en de volgende toestandswijziging levert verwarrende fouten op. Richt je op de service of het verbindingsprofiel in plaats van de interface; controleer eerst de exacte unitnaam, want distributiepakketten, OpenVPN 3 en NetworkManager kiezen allemaal andere. Een NetworkManager-profiel komt terug wanneer die verbinding wordt gerecycled, dus de systemd-unit is daar niet het doel. Wat het mechanisme ook is, het zou dezelfde actie moeten zijn die je met de hand hebt geverifieerd.

Een herstart installeert de routes opnieuw die de client bij het verbinden heeft geduwd. De meeste ontwaakmomenten willen dat. Een machine waar je eigen paden hebt toegevoegd niet, dus controleer die opnieuw in plaats van aan te nemen dat het herstel ze heeft teruggezet, en schrijf ze op waar de volgende ontwaking ze kan vinden.

Ga om met de timing die je niet kunt beheersen

Draadloze associatie en DHCP zijn vaak pas klaar nadat de hook is uitgevoerd, dus een herstart kan mislukken terwijl er nog geen pad naar de server is. Wacht even op dat adres, probeer het nog één keer en log het resultaat.

Naamresolutie is een aparte race, omdat de netwerkstack van de desktop DNS kan herstellen nadat de tunnel al up is. Test opzoekingen apart met resolvectl query internal.example in plaats van ze af te leiden uit een werkende route. Een tunnel die correct routeert en niets oplost, is een DNS-probleem, geen hookprobleem.

Houd de beslissing van de hook zichtbaar door de fase, de unitnaam en het resultaat in het journaal te schrijven. Noteer in de notities van de machine welke ontwaaktest je hebt uitgevoerd, zodat een werkend herstel te onderscheiden is van een gelukkig herstel. Kies de minst verstorende actie die de service terugbrengt, en laat een client die zichzelf herstelt dat doen. Een volledige herstart gooit lopende sessies weg, wat een echte kostenpost is op een laptop die meerdere keren per dag ontwaakt.