Miks sureb OpenVPN pärast sülearvuti ärkamist?

Uinumine võib OpenVPN-i sessiooni tappa, jättes tun0 alles. Testige tunnelit ja taaskäivitage seejärel üksus systemd uinumiskonksust, mitte seade.

Pange masin uinuma, äratage see ja kontrollige seejärel kolme asja selles järjekorras, enne kui puudutate ükskõik millist seadistust: kas tun0 on endiselt olemas, kas tee sisemise aadressini valib selle ikka ja kas server loetleb seda peer'i endiselt. Seade, mis uinumise üle elab, samal ajal kui tee osutab mujale, on jääk, mitte tunnel. Kui tee on õige ja liiklus sureb ikkagi, on viga tunneli kohal ja kliendi taaskäivitamine ei muuda seda. Taaskäivitamise automatiseerimine on mõttekas alles pärast seda, kui käsitsi tehtud test on näidanud, milline neist kolmest juhtumist teil on.

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

Taastage ärkamine enne, kui selle automatiseerite

Uinumine lõpetab krüpteeritud sessiooni sagedamini, kui see seadme eemaldab. UDP voog, mis hoidis tunneli elus, peatub, server võib peer'i maha jätta ja klient kas märkab seda ja ühendub uuesti või hoiab liidest, mille taga pole midagi. Liidese kontroll üksi tõestab vähe, sest aegunud seade näeb väljast täpselt töötava moodi kuni paketid peavad sellest läbi minema. Käivitage marsruudi otsing ja üks tõeline päring läbi tunneli, seejärel lugege päevikut ärkamise hetke ümbruses.

Kui klient tuleb ise tagasi, lisab konks ebamugavust, mitte töökindlust. Kui see ei taastu kunagi, on automatiseerimine aus lahendus.

Kus systemd uinumiskonks tegelikult asub

Paljud vanemad juhendid osutavad kataloogile /etc/pm/sleep.d, mis kuulub pm-utils-ile ja mida systemd-põhine uinumine kunagi ei konsulteeri. systemd loeb konkse kaustadest /usr/lib/systemd/system-sleep/ ja /etc/systemd/system-sleep/, edastades esimesena faasi ja teisena toimingu, seega on pre ja post ainsad väärtused, mille järgi konks hargneb. Hoidke kohalikku koopiat /etc all, selle asemel et pakendatud faili muuta, ja pidage meeles, et skript töötab ülemineku keskel root'ina, seega peab see kiiresti naasma.

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

try-restart puudutab üksust ainult siis, kui see on juba aktiivne, seega teadlikult suletud tunnel jääb ärkamise ajal suletuks. --no-block hoiab konksu ootamast, kuni klient läbirääkimisi peab, mis loeb siis, kui võrk pole veel püsti. Koos tähendavad kaks lippu konksu, mis ebaõnnestub vaikselt, selle asemel et kogu ärkamise jada kinni hoida. Kui üksus on juba peatatud, ei juhtu üldse midagi, mis on täpselt see tulemus, mida seal soovite.

Taastage teenus, jätke tun0 rahule

tun0 käsitsi maha võtmine jätab deemonile järelevalve liidese üle, mida ta enam ei oma, ja järgmine olekumuutus tekitab segaseid vigu. Sihtige teenust või selle ühendusprofiili, mitte liidest; kontrollige esmalt täpset üksuse nime, sest distributsioonipaketid, OpenVPN 3 ja NetworkManager valivad kõik erineva. NetworkManageri profiil naaseb, kui see ühendus ringi käib, seega systemd üksus ei ole seal sihtmärk. Ükskõik milline mehhanism, see peaks olema sama toiming, mille te käsitsi kontrollisite.

Taaskäivitamine paigaldab uuesti marsruudid, mille klient ühendudes lükkas. Enamik ärkamisi soovib seda. Masin, kuhu te lisasite oma teed, ei soovi, seega kontrollige need uuesti, selle asemel et eeldada, et taastamine need tagasi pani, ja kirjutage need üles sinna, kust järgmine ärkamine need leiab.

Käsitlege ajastust, mida te ei kontrolli

Traadita ühenduse loomine ja DHCP lõppevad sageli pärast seda, kui konks on töötanud, seega võib taaskäivitamine ebaõnnestuda, kuni serverini pole veel teed. Oodake veidi seda aadressi, proovige veel kord ja logige tulemus.

Nimede lahendamine on eraldi võidujooks, sest töölaua võrgupinu võib DNS-i taastada pärast seda, kui tunnel on juba püsti. Testige päringuid eraldi käsuga resolvectl query internal.example, selle asemel et neid töötava marsruudi põhjal oletada. Tunnel, mis marsruudib õigesti ja ei lahenda midagi, on DNS-i probleem, mitte konksu probleem.

Hoidke konksu otsus nähtav, kirjutades faasi, üksuse nime ja tulemuse päevikusse. Märkige masina märkmetesse, millise ärkamise testi te läbi viisite, et töötavat taastamist saaks eristada õnnelikust. Valige kõige vähem häiriv toiming, mis teenuse tagasi toob, ja laske kliendil, mis taastub ise, seda teha. Täielik taaskäivitamine viskab käimasolevad sessioonid välja, mis on tõeline kulu sülearvutil, mis ärkab mitu korda päevas.

Seotud artiklid