Wêrom stjert OpenVPN nei it wekker wurden fan de laptop?

Sette de masine yn sliep, meitsje him wekker en kontrolearje dan trije dingen yn dizze folchoarder foar't jo hokker konfiguraasje oanreitsje: oft tun0 noch bestiet, oft de rûte nei in ynterne adres dy noch kiest en oft de server dizze peer noch listet. In apparaat dat sliep oerlibbet wylst de rûte earne oars hinne wiist, is in oerbliuwsel, net in tunnel. As de rûte goed is en it ferkear dochs stjert, sit de flater boppe de tunnel en sil it opnij starten fan de klient dat net feroarje. It automatisearjen fan in nije start hat allinnich sin nei't in hânmjittige test sjen litten hat hokker fan dy trije gefallen jo hawwe.

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

Reprodusearje it wekker wurden foar't jo it automatisearje

Sliep beëiniget de fersifere sesje faker as dat er it apparaat fuorthellet. De UDP-stream dy't de tunnel libben hâlde, stoppet, de server kin de peer falle litte, en de klient merkt it of en ferbynt him opnij of hâldt in ynterface sûnder wat der efter sit. In kontrôle fan 'e ynterface allinnich bewiist net folle, om't in ferâldere apparaat sjocht der krekt itselde út as in wurkjend ien oant pakketten der trochhinne moatte. Rin de rûtesykjen plus ien echt fersyk troch de tunnel, en lês dan it sjoernaal om it momint fan it wekker wurden hinne.

As de klient fansels weromkomt, foeget in heak oerlêst ta ynstee fan betrouberens. As er nea weromkomt, is automatisearring de earlike oplossing.

Wêr't in systemd-sliephak echt wennet

In protte âldere gidsen wize nei /etc/pm/sleep.d, in map dy't fan pm-utils is en nea troch in systemd-basearre sliep rieplachte wurdt. systemd lêst heakken út /usr/lib/systemd/system-sleep/ en /etc/systemd/system-sleep/, en jout earst de faze en dêrnei de operaasje troch, dus pre en post binne de iennichste wearden dêr't in heak op fertakket. Hâld de pleatslike kopy ûnder /etc ynstee fan in ferpakt bestân te bewurkjen, en tink deroan dat it skript as root yn 'e midden fan 'e oergong rint, dus it moat fluch weromkomme.

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

try-restart rekket in ienheid allinnich oan as dy al aktyf is, dus in tunnel dy't jo mei opsetsin útskeakele hawwe, bliuwt útskeakele oer it wekker wurden hinne. --no-block hâldt de heak tsjin om te wachtsjen wylst de klient ûnderhannelt, wat fan belang is as it netwurk noch net oan is. Tegearre betsjutte de twa flaggen in heak dy't stil mislearret ynstee fan de hiele wekkersequinsje tsjin te hâlden. As de ienheid al stoppe is, bart der hielendal neat, en dat is krekt it resultaat dat jo dêr wolle.

Werstel de tsjinst, lit tun0 gewurde

It mei de hân delheljen fan tun0 lit de daemon tafersjoch hâlde oer in ynterface dy't er net mear besit, en de folgjende steatferoaring jout betiizjende flaters. Rjochtsje op de tsjinst of har ferbiningprofyl ynstee fan de ynterface; kontrolearje earst de krekte namme fan 'e ienheid, om't distribúsjepakketten, OpenVPN 3 en NetworkManager allegear oare kieze. In NetworkManager-profyl komt werom as dy ferbining opnij rûn wurdt, dus de systemd-ienheid is dêr net it doel. Hokker meganisme ek, it moat deselde aksje wêze dy't jo mei de hân ferifiearre hawwe.

In nije start ynstallearret de rûtes opnij dy't de klient tawiisde doe't er ferbûn. De measte wekkers wolle dat. In masine dêr't jo eigen paden tafoege hawwe, net, dus kontrolearje dy opnij ynstee fan oan te nimmen dat it werstel se werombrocht hat, en skriuw se del dêr't de folgjende wekker se fine kin.

Behannelje de timing dy't jo net kontrolearje kinne

Draadleaze assosjaasje en DHCP einigje faak nei't de heak rûn hat, dus in nije start kin mislearje wylst der noch gjin paad nei de server is. Wachtje even op dat adres, probearje it noch ien kear en log it resultaat.

Namme-oplossing is in aparte wedstriid, om't de netwurkstapel fan it buroblêd DNS werstelle kin nei't de tunnel al oan is. Test opfregingen apart mei resolvectl query internal.example ynstee fan se ôf te lieden fan in wurkjende rûte. In tunnel dy't korrekt rûtes jout en neat oplost, is in DNS-probleem, net in heakprobleem.

Hâld de beslissing fan 'e heak sichtber troch de faze, de namme fan 'e ienheid en it resultaat yn it sjoernaal te skriuwen. Notearje yn 'e masine-oantekeningen hokker wekkertest jo rûn hawwe, sadat in wurkjend werstel fan in lokkich ien te ûnderskieden is. Kies de minst fersteurende aksje dy't de tsjinst werombringt, en lit in klient dy't himsels werstelt dat dwaan. In folsleine nije start smyt aktive sesjes fuort, wat in echte kosten is op in laptop dy't ferskate kearen deis wekker wurdt.