Miksi OpenVPN kuolee kannettavan herätessä?

Aseta kone unitilaan, herätä se ja tarkista sitten kolme asiaa tässä järjestyksessä ennen kuin kosket mihinkään asetukseen: onko tun0 yhä olemassa, valitseeko reitti sisäiseen osoitteeseen sen edelleen ja listaako palvelin tämän peerin yhä. Laite, joka selviää unitilasta reitin osoittaessa muualle, on jäänne, ei tunneli. Kun reitti on oikein ja liikenne silti kuolee, vika on tunnelin yläpuolella eikä asiakkaan uudelleenkäynnistys muuta sitä. Uudelleenkäynnistyksen automatisointi on järkevää vasta sen jälkeen, kun käsintesti on näyttänyt, mikä näistä kolmesta tapauksesta sinulla on.

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

Toista herätys ennen kuin automatisoit sen

Unitila päättää salatun istunnon useammin kuin poistaa laitteen. UDP-virta, joka piti tunnelin elossa, pysähtyy, palvelin voi pudottaa peerin, ja asiakas joko huomaa sen ja yhdistää uudelleen tai pitää rajapinnan, jonka takana ei ole mitään. Rajapinnan tarkistus yksinään todistaa vähän, koska vanhentunut laite näyttää täsmälleen toimivalta kunnes pakettien on kuljettava sen läpi. Aja reittihaku ja yksi todellinen pyyntö tunnelin läpi ja lue sitten lokia herätyksen hetken ympäriltä.

Jos asiakas palaa itsestään, koukku lisää säätöä luotettavuuden sijaan. Jos se ei koskaan toivu, automatisointi on rehellinen ratkaisu.

Missä systemd:n unitilakoukku oikeasti sijaitsee

Monet vanhemmat oppaat osoittavat hakemistoon /etc/pm/sleep.d, jonka omistaa pm-utils ja jota systemd-pohjainen unitila ei koskaan kysy. systemd lukee koukut hakemistoista /usr/lib/systemd/system-sleep/ ja /etc/systemd/system-sleep/, välittäen ensin vaiheen ja toiseksi toiminnon, joten pre ja post ovat ainoat arvot, joiden mukaan koukku haarautuu. Pidä paikallinen kopio hakemistossa /etc sen sijaan, että muokkaisit pakattua tiedostoa, ja muista, että skripti ajetaan root-oikeuksin siirtymän keskellä, joten sen on palattava nopeasti.

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

try-restart koskee yksikköä vain, kun se on jo aktiivinen, joten tarkoituksella suljettu tunneli pysyy suljettuna herätyksen yli. --no-block estää koukkua odottamasta asiakkaan neuvotellessa, millä on merkitystä, kun verkko ei ole vielä noussut. Yhdessä kaksi lippua tarkoittavat koukkua, joka epäonnistuu hiljaa sen sijaan, että pitäisi koko herätyssekvenssiä. Kun yksikkö on jo pysäytetty, ei tapahdu lainkaan mitään, ja se on täsmälleen se tulos, jonka siinä haluat.

Palauta palvelu, jätä tun0 rauhaan

tun0 käsin alas ottaminen jättää daemonin valvomaan rajapintaa, jota se ei enää omista, ja seuraava tilanmuutos tuottaa hämmentäviä virheitä. Kohdista palveluun tai sen yhteyden profiiliin rajapinnan sijaan; tarkista ensin yksikön tarkka nimi, koska jakelupaketit, OpenVPN 3 ja NetworkManager valitsevat kaikki erilaisen. NetworkManager-profiili palaa, kun tämä yhteys kierrätetään, joten systemd-yksikkö ei ole siellä kohde. Mekanismi mikä tahansa, sen pitäisi olla sama toiminto, jonka varmistit käsin.

Uudelleenkäynnistys asentaa uudelleen reitit, jotka asiakas työnsi yhdistyessään. Useimmat herätykset haluavat sen. Kone, johon lisäsit omia polkuja, ei halua, joten tarkista ne uudelleen sen sijaan, että olettaisit palautuksen palauttaneen ne, ja kirjoita ne muistiin sinne, mistä seuraava herätys ne löytää.

Käsittele ajoitus, jota et hallitse

Langaton liittyminen ja DHCP valmistuvat usein vasta koukun ajamisen jälkeen, joten uudelleenkäynnistys voi epäonnistua, kun polkua palvelimeen ei vielä ole. Odota hetki tuota osoitetta, yritä kerran uudelleen ja kirjaa tulos lokiin.

Nimien selvitys on erillinen kilpailu, koska työpöydän verkkopinon voi palauttaa DNS:n vasta, kun tunneli on jo ylhäällä. Testaa haut erikseen komennolla resolvectl query internal.example sen sijaan, että päättelet ne toimivasta reitistä. Tunneli, joka reitittää oikein eikä selvitä mitään, on DNS-ongelma, ei koukun ongelma.

Pidä koukun päätös näkyvänä kirjoittamalla vaihe, yksikön nimi ja tulos lokiin. Merkitse koneen muistiinpanoihin, minkä herätystestin ajoit, jotta toimiva palautus voidaan erottaa onnekkaasta. Valitse vähiten häiritsevä toiminto, joka palauttaa palvelun, ja anna itsestään toipuvan asiakkaan tehdä se. Täysi uudelleenkäynnistys pudottaa käynnissä olevat istunnot, mikä on todellinen kustannus kannettavalla, joka herää useita kertoja päivässä.