Waarom sterf OpenVPN wanneer die skootrekenaar wakker word?

Stel die masjien in suspensie, hervat dit en kontroleer dan drie dinge in hierdie volgorde voordat jy enige konfigurasie aanraak: of tun0 nog bestaan, of die roete na 'n interne adres dit nog kies, en of die bediener hierdie eweknie nog lys. 'n Toestel wat slaap oorleef terwyl die roete elders heen wys, is 'n oorblyfsel, nie 'n tonnel nie. Wanneer die roete reg is en verkeer steeds doodgaan, sit die fout bo die tonnel en om die kliënt te herbegin sal dit nie verander nie. Om 'n herbegin te outomatiseer maak net sin nadat 'n handmatige toets gewys het watter van daardie drie gevalle jy het.

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

Reproduseer die hervatting voordat jy dit outomatiseer

Suspensie beëindig die versleutelde sessie dikwels eerder as wat dit die toestel verwyder. Die UDP-vloei wat die tonnel lewendig gehou het, stop, die bediener kan die eweknie laat val, en die kliënt merk dit óf en herverbind óf hou 'n koppelvlak met niks agter hom. 'n Koppelvlakkontrole op sigself bewys min, want lyk 'n verouderde toestel presies soos 'n werkende een totdat pakkies daaroorheen moet beweeg. Voer die roeteopsoek uit plus een werklike versoek deur die tonnel, en lees dan die joernaal rondom die oomblik van hervatting.

As die kliënt vanself terugkom, voeg 'n haak bykomende werk by eerder as betroubaarheid. As dit nooit herstel nie, is outomatisering die eerlike oplossing.

Waar 'n systemd-slaaphak werklik woon

Baie ouer gidse wys na /etc/pm/sleep.d, 'n gids wat deur pm-utils besit word en nooit deur 'n systemd-gebaseerde suspensie geraadpleeg word nie. systemd lees hake uit /usr/lib/systemd/system-sleep/ en /etc/systemd/system-sleep/, en gee die fase eerste en die bewerking tweede, so pre en post is die enigste waardes waarop 'n haak vertak. Hou die plaaslike kopie onder /etc in plaas daarvan om 'n verpakte lêer te redigeer, en onthou die skrip loop as root in die middel van die oorgang, so dit moet vinnig terugkeer.

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

try-restart raak 'n eenheid net wanneer dit reeds aktief is, so 'n tonnel wat jy doelbewus afgeskakel het, bly af deur die hervatting. --no-block verhoed dat die haak wag terwyl die kliënt onderhandel, wat saak maak wanneer die netwerk nog nie op is nie. Saam beteken die twee vlae 'n haak wat stil faal eerder as om die hele hervattingreeks op te hou. Niks gebeur hoegenaamd wanneer die eenheid reeds gestop is nie, wat presies die uitkoms is wat jy daar wil hê.

Herstel die diens, laat tun0 met rus

Om tun0 met die hand af te neem, laat die daemon toesig hou oor 'n koppelvlak wat dit nie meer besit nie, en die volgende toestandsverandering lewer verwarrende foute op. Teiken die diens of sy verbindingsprofiel eerder as die koppelvlak; kontroleer eers die presiese eenheidsnaam, want verspreidingspakkette, OpenVPN 3 en NetworkManager kies almal verskillende een. 'n NetworkManager-profiel kom terug wanneer daardie verbinding gesikliseer word, so die systemd-eenheid is nie daar die teiken nie. Wat die meganisme ook al is, dit moet dieselfde aksie wees wat jy met die hand geverifieer het.

'n Herbegin herinstalleer die roetes wat die kliënt gestoot het toe dit verbind het. Die meeste hervattings wil dit hê. 'n Masjien waar jy jou eie paaie bygevoeg het, nie, so herkontroleer dié eerder as om te aanvaar die herstel het hulle teruggesit, en skryf hulle neer waar die volgende hervatting hulle kan vind.

Hanteer die tydsberekening wat jy nie kan beheer nie

Draadlose assosiasie en DHCP voltooi dikwels nadat die haak geloop het, so 'n herbegin kan misluk terwyl daar nog geen pad na die bediener bestaan nie. Wag kortliks vir daardie adres, probeer een keer weer en teken die resultaat aan.

Naamresolusie is 'n aparte wedloop, want die werkskerm se netwerkstapel kan DNS herstel nadat die tonnel reeds op is. Toets opsoeke op hulle eie met resolvectl query internal.example eerder as om hulle uit 'n werkende roete af te lei. 'n Tonnel wat korrek roeteer en niks oplos nie, is 'n DNS-probleem, nie 'n haakprobleem nie.

Hou die haak se besluit sigbaar deur die fase, die eenheidsnaam en die resultaat in die joernaal te skryf. Teken in die masjiennotas aan watter hervattingstoets jy uitgevoer het, so 'n werkende herstel kan van 'n gelukkige een onderskei word. Kies die minste ontwrigtende aksie wat diens terugbring, en laat 'n kliënt wat vanself herstel dit doen. 'n Volle herbegin laat vlugtige sessies val, wat 'n werklike koste is op 'n skootrekenaar wat verskeie kere per dag hervat.