Prečo OpenVPN umiera po prebudení notebooku?

Uveďte stroj do režimu spánku, prebuďte ho a potom v tomto poradí skontrolujte tri veci, skôr než sa dotknete akejkoľvek konfigurácie: či tun0 ešte existuje, či k nemu trasa k internej adrese stále vedie a či server tohto peera stále uvádza. Zariadenie, ktoré spánok prežije, zatiaľ čo trasa ukazuje inam, je zvyšok, nie tunel. Keď je trasa správna a prevádzka napriek tomu umiera, porucha je nad tunelom a reštart klienta to nezmení. Automatizovať reštart má zmysel až po tom, čo ručný test ukázal, ktorý z tých troch prípadov máte.

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

Reprodukujte prebudenie, skôr než ho zautomatizujete

Spánok ukončí šifrovanú reláciu častejšie, než odstráni zariadenie. UDP tok, ktorý držal tunel nažive, sa zastaví, server môže peera zhodiť a klient si to buď všimne a znovu sa pripojí, alebo si ponechá rozhranie, za ktorým nič nie je. Kontrola rozhrania sama o sebe dokazuje málo, pretože zastarané zariadenie vyzerá presne ako funkčné kým cez neho nemusia prejsť pakety. Spustite vyhľadanie trasy a jednu skutočnú požiadavku cez tunel, potom si prečítajte žurnál okolo okamihu prebudenia.

Ak sa klient vráti sám, hook pridáva ruch namiesto spoľahlivosti. Ak sa nikdy nezotaví, automatizácia je poctivé riešenie.

Kde hook spánku systemd skutočne žije

Mnoho starších návodov ukazuje na /etc/pm/sleep.d, adresár, ktorý vlastní pm-utils a ktorý spánok založený na systemd nikdy nekonzultuje. systemd číta hooky z /usr/lib/systemd/system-sleep/ a /etc/systemd/system-sleep/, odovzdáva najprv fázu a potom operáciu, takže pre a post sú jediné hodnoty, podľa ktorých sa hook vetví. Majte lokálnu kópiu pod /etc namiesto úpravy zabaleného súboru a pamätajte, že skript beží ako root uprostred prechodu, takže sa musí rýchlo vrátiť.

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

try-restart sa dotkne jednotky len vtedy, keď je už aktívna, takže tunel, ktorý ste zámerne vypli, ostane vypnutý aj počas prebudenia. --no-block bráni hooku čakať, kým klient vyjednáva, čo je dôležité, keď sieť ešte nie je hore. Spolu oba príznaky znamenajú hook, ktorý ticho zlyhá, namiesto toho, aby zdržal celú sekvenciu prebudenia. Keď je jednotka už zastavená, nestane sa vôbec nič, a to je presne ten výsledok, ktorý tam chcete.

Obnovte službu, nechajte tun0 na pokoji

Ručné zhodenie tun0 nechá démona dohliadať na rozhranie, ktoré už nevlastní, a ďalšia zmena stavu vytvorí mätúce chyby. Zacielte na službu alebo jej profil pripojenia, nie na rozhranie; najprv skontrolujte presný názov jednotky, pretože distribučné balíky, OpenVPN 3 a NetworkManager volia rôzne. Profil NetworkManager sa vráti, keď sa toto pripojenie zacyklí, takže jednotka systemd tam nie je cieľom. Nech je mechanizmus akýkoľvek, mala by to byť tá istá akcia, ktorú ste overili ručne.

Reštart znovu nainštaluje trasy, ktoré klient pretlačil pri pripojení. Väčšina prebudení to chce. Stroj, kde ste pridali vlastné cesty, nie, takže ich znova skontrolujte namiesto toho, aby ste predpokladali, že obnova ich vrátila, a zapíšte ich tam, kde ich najbližšie prebudenie nájde.

Zvládnite časovanie, ktoré nemôžete ovládať

Bezdrôtové pripojenie a DHCP sa často dokončia až po tom, čo hook prebehol, takže reštart môže zlyhať, kým cesta k serveru ešte neexistuje. Krátko počkajte na tú adresu, skúste to ešte raz a výsledok zapíšte do žurnálu.

Preklad mien je samostatný pretek, pretože sieťový stack pracovnej plochy môže obnoviť DNS až po tom, čo je tunel už hore. Testujte dopyty samostatne s resolvectl query internal.example namiesto odvodzovania z funkčnej trasy. Tunel, ktorý správne smeruje a nič neprekladá, je problém DNS, nie problém hooku.

Udržujte rozhodnutie hooku viditeľné tým, že zapíšete fázu, názov jednotky a výsledok do žurnálu. Poznamenajte si do poznámok stroja, ktorý test prebudenia ste spustili, aby sa funkčná obnova dala odlíšiť od šťastnej. Vyberte najmenej rušivú akciu, ktorá vráti službu, a nechajte klienta, ktorý sa obnoví sám, aby to urobil. Úplný reštart zahodí bežiace relácie, čo je skutočná cena na notebooku, ktorý sa prebúdza niekoľkokrát denne.