Pelkkä unitilakoukku ei palauta VPN:ää

Laita uudelleenyhdistämiskomento unitilakoukkuun, ja ongelma näyttää ratkenneen. Se on ratkennut vain, jos koukku ajetaan sen jälkeen kun verkko on olemassa, identiteettinä jonka asiakas tunnistaa, polkua pitkin jonka asiakas todella toteuttaa. Useimmat jatkamisen jälkeiset viat ovat yksi näistä kolmesta, eikä mikään niistä näy virheenä itse koukussa. Koukku palauttaa silti onnistumisen.

Nollalla poistuva skripti ei ole kertonut sinulle mitään siitä, tuliko tunneli takaisin.

Koukku ajetaan, ja sitten?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

Jokainen tapahtuma kutsuu koukkua kahdesti, ennen siirtymää ja sen jälkeen, antaen sille vaiheen ja tapahtuman nimen. Se ajetaan rootina minimaalisessa ympäristössä, joten absoluuttiset polut ovat välttämättömiä eikä mitään työpöytäistunnon muuttujaa pidä odottaa. Se, että molemmat kutsut palaavat nopeasti, kertoo vain että skripti ajettiin. Nousiko profiili sen jälkeen, on erillinen havainto ja tarvitsee oman todisteensa lokiin.

Käsittele vaiheargumenttia osana suunnittelua. Uudelleenyhdistämisyritys pre-vaiheessa tapahtuu, kun kone on juuri menettämässä kaiken, eikä se voi onnistua.

Root, minimaalinen ympäristö, väärä käyttäjä

Jos asiakas pitää kirjautumistunnistetta käyttäjäkohtaisesti, koukun ajaminen rootina jättää sen ilman mitään esitettävää. Tarkista tila identiteetin alla, jota koukku todella käyttää, älä sen alla jota testasit työpöytäpäätteestä. Jotkin versiot jättävät myös taustapalvelun pitämään rajapintaa katkaisun jälkeen, joten uudelleenyhdistäminen päätyy vanhentuneeseen tilaan, ja prosessin siivoaminen ensin palauttaa sen epäsiistin sammutuksen hinnalla. Kumpikaan käytös ei näy, jos testaat vain onnellista polkua.

Kirjoita koukku absoluuttisilla poluilla, pidä se rootin omistamana ja suoritettavana, ja kirjaa mitä se teki. Ilman sitä lokia seuraava tutkinta alkaa nollasta.

Automaattinen yhdistäminen ei ole VPN:n polku

NetworkManager tarjoaa kaksi aktivointimekanismia: automaattisen yhdistämisen lipun profiilissa ja toissijaiset yhteydet, jotka käynnistyvät kun ensisijainen profiili aktivoituu. Natiivit laitetyypit toteuttavat ensimmäisen; VPN-liitännäiset ovat historiallisesti toteuttaneet vain toisen, joten automaattisen yhdistämisen rastittaminen OpenVPN-profiilissa ei välttämättä vaikuta lainkaan. Tarkista molemmat ominaisuudet ja liitä VPN sitten sen sijaan Wi-Fi- tai Ethernet-profiilin toissijaiseksi.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

systemd-yksikön hallitsema WireGuard-rajapinta tarvitsee tuon lisätiedoston koukun sijaan, järjestettynä sen jälkeen kun verkko on verkossa.

Odota verkkoa, ylärajalla

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

Jatkettaessa tunnelia voidaan pyytää, kun Wi-Fi vielä yhdistyy uudelleen, mikä tekee jokaisesta kiinteästä unesta arvauksen. Odota tavoitettavissa olevaa osoitetta, nosta sitten profiili, ja rajaa odotus, jotta koukku ei voi pitää jatkamispolkua avoinna loputtomasti. Suosi profiilin nimeä numeerisen indeksin sijaan, ja jos oikea profiili vaihtelee verkon mukaan, antakoon terveen tunnelin kirjata valintansa tiedostoon etukäteen.

Varaudu myös uudelleenkäynnistysmyrskyihin laskemalla yrityksiä ja pysähtymällä. Vahtikoira, joka reagoi jokaiseen epäonnistuneeseen kokeeseen, muuttaa yhden katkoksen silmukaksi.

Keskeytä kerran ja lue sitten lokista koukun oma tuloste. Se on ainoa testi, joka todistaa järjestyksen.