De ce moare OpenVPN după ce laptopul se trezește?

Suspensia poate ucide sesiunea OpenVPN și lăsa tun0 în urmă. Testați tunelul, apoi reporniți unitatea dintr-un hook de suspensie systemd, nu dispozitivul.

Suspendați mașina, treziți-o, apoi verificați trei lucruri în această ordine înainte de a atinge orice configurație: dacă tun0 mai există, dacă ruta către o adresă internă îl mai alege și dacă serverul mai listează acest peer. Un dispozitiv care supraviețuiește suspensiei în timp ce ruta indică altundeva este o rămășiță, nu un tunel. Când ruta este corectă și traficul moare totuși, defecțiunea se află deasupra tunelului, iar repornirea clientului nu o va schimba. Automatizarea unei reporniri are sens doar după ce un test manual a arătat care dintre cele trei cazuri îl aveți.

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

Reproduceți trezirea înainte de a o automatiza

Suspensia încheie sesiunea criptată mai des decât elimină dispozitivul. Fluxul UDP care ținea tunelul în viață se oprește, serverul poate abandona peer-ul, iar clientul fie observă și se reconectează, fie păstrează o interfață fără nimic în spate. O verificare a interfeței singură dovedește puțin, pentru că un dispozitiv vechi arată exact ca unul funcțional până când pachetele trebuie să treacă prin el. Rulați căutarea rutei plus o cerere reală prin tunel, apoi citiți jurnalul în jurul momentului trezirii.

Dacă clientul revine de la sine, un hook adaugă agitație în loc de fiabilitate. Dacă nu se recuperează niciodată, automatizarea este soluția onestă.

Unde trăiește de fapt un hook de suspensie systemd

Multe ghiduri vechi indică /etc/pm/sleep.d, un director deținut de pm-utils la care o suspensie bazată pe systemd nu apelează niciodată. systemd citește hook-uri din /usr/lib/systemd/system-sleep/ și /etc/systemd/system-sleep/, transmitând mai întâi faza și apoi operația, așa că pre și post sunt singurele valori pe care un hook se ramifică. Păstrați copia locală sub /etc în loc să editați un fișier din pachet și rețineți că scriptul rulează ca root în mijlocul tranziției, deci trebuie să revină rapid.

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

try-restart atinge o unitate doar când este deja activă, așa că un tunel pe care l-ați oprit intenționat rămâne oprit pe durata trezirii. --no-block împiedică hook-ul să aștepte în timp ce clientul negociază, ceea ce contează când rețeaua nu a urcat încă. Împreună, cele două steaguri înseamnă un hook care eșuează în silențiu în loc să rețină întreaga secvență de trezire. Când unitatea este deja oprită, nu se întâmplă absolut nimic, iar acesta este exact rezultatul dorit acolo.

Recuperați serviciul, lăsați tun0 în pace

Coborârea manuală a tun0 lasă demonul să supravegheze o interfață pe care nu o mai deține, iar următoarea schimbare de stare produce erori confuze. Țintiți serviciul sau profilul lui de conexiune, nu interfața; verificați mai întâi numele exact al unității, pentru că pachetele distribuției, OpenVPN 3 și NetworkManager aleg toate unele diferite. Un profil NetworkManager revine când acea conexiune este reciclată, așa că unitatea systemd nu este ținta acolo. Orice mecanism ar fi, ar trebui să fie aceeași acțiune pe care ați verificat-o manual.

O repornire reinstalează rutele pe care clientul le-a împins la conectare. Majoritatea trezirilor vor asta. O mașină în care ați adăugat rute proprii nu, așa că reverificați-le în loc să presupuneți că recuperarea le-a readus, și notați-le acolo unde următoarea trezire le poate găsi.

Gestionați sincronizarea pe care nu o puteți controla

Asocierea wireless și DHCP se termină adesea după ce hook-ul a rulat, așa că o repornire poate eșua în timp ce încă nu există o cale către server. Așteptați puțin acea adresă, încercați încă o dată și înregistrați rezultatul.

Rezolvarea numelor este o cursă separată, pentru că stiva de rețea a desktopului poate restabili DNS după ce tunelul este deja sus. Testați interogările separat cu resolvectl query internal.example în loc să le deduceți dintr-o rută funcțională. Un tunel care rutează corect și nu rezolvă nimic este o problemă de DNS, nu o problemă a hook-ului.

Țineți decizia hook-ului vizibilă scriind faza, numele unității și rezultatul în jurnal. Notați în notele mașinii ce test de trezire ați rulat, ca o recuperare funcțională să poată fi distinsă de una norocoasă. Alegeți acțiunea cea mai puțin perturbatoare care aduce serviciul înapoi și lăsați un client care se recuperează singur să facă asta. O repornire completă aruncă sesiunile în curs, ceea ce este un cost real pe un laptop care se trezește de mai multe ori pe zi.

Articole similare