Vien miego hook VPN negrąžins

Hook, kuris baigiasi nuliu, įrodo tik tai, kad scenarijus buvo paleistas. Įdėkite jį po tinklo, naudokite teisingą tapatybę ir patikrinkite, ar profilis apskritai tinkamas.

Įdėkite prisijungimo iš naujo komandą į miego hook ir problema atrodo išspręsta. Ji išspręsta tik tada, kai hook paleidžiamas po to, kai yra tinklas, kaip tapatybė, kurią klientas atpažįsta, keliu, kurį klientas tikrai įgyvendina. Dauguma gedimų po pabudimo yra vienas iš šių trijų, ir nė vienas jų nepasireiškia kaip klaida pačiame hook. Hook vis tiek grąžina sėkmę.

Scenarijus, kuris baigiasi nuliu, nieko nepasakė apie tai, ar tunelis grįžo.

Hook paleidžiamas, o paskui?

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

Kiekvienas įvykis iškviečia hook du kartus, prieš perėjimą ir po jo, perduodamas jam fazę ir įvykio pavadinimą. Jis veikia kaip root minimalioje aplinkoje, todėl būtini absoliutūs keliai ir nereikia tikėtis jokio darbalaukio sesijos kintamojo. Tai, kad abu iškvietimai grįžta greitai, sako tik, kad scenarijus buvo paleistas. Ar profilis po to pakilo, yra atskiras stebėjimas ir jam reikia savo įrodymų žurnale.

Fazės argumentą laikykite dizaino dalimi. Bandymas prisijungti iš naujo pre fazėje vyksta tada, kai mašina ruošiasi prarasti viską, ir jis negali pavykti.

Root, minimali aplinka, neteisingas naudotojas

Jei klientas saugo prisijungimo raktą kiekvienam naudotojui, hook paleidimas kaip root palieka jį be nieko pateikti. Tikrinkite būseną pagal tapatybę, kurią hook iš tikrųjų naudoja, o ne tą, kurią bandėte iš darbalaukio terminalo. Kai kurie rinkiniai po atjungimo taip pat palieka demoną, laikantį sąsają, todėl prisijungimas iš naujo patenka į pasenusią būseną, o proceso išvalymas pirmiausia ją atkuria nešvaraus išjungimo kaina. Nė vienas elgesys nematomas, jei bandote tik laimingą kelią.

Rašykite hook su absoliučiais keliais, laikykite jį root nuosavybėje ir vykdomą, ir registruokite, ką jis padarė. Be to žurnalo kitas tyrimas prasideda nuo nulio.

Automatinis prisijungimas nėra VPN kelias

NetworkManager siūlo du aktyvinimo mechanizmus: automatinio prisijungimo vėliavėlę profilyje ir antrinius ryšius, kurie prasideda, kai suaktyvinamas pirminis profilis. Vietiniai įrenginių tipai įgyvendina pirmąjį; VPN papildiniai istoriškai įgyvendino tik antrąjį, todėl automatinio prisijungimo pažymėjimas OpenVPN profilyje gali visiškai neturėti poveikio. Patikrinkite abi savybes, tada prijunkite VPN kaip antrinį prie Wi-Fi arba Ethernet profilio.

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

WireGuard sąsajai, valdomai systemd įrenginio, reikia to papildomo failo, o ne hook, išdėstyto po to, kai tinklas prisijungęs.

Palaukite tinklo, su viršutine riba

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"

Po pabudimo tunelio gali būti prašoma, kol Wi-Fi dar jungiasi iš naujo, todėl bet koks fiksuotas miegas tampa spėjimu. Palaukite pasiekiamo adreso, tada pakelkite profilį, ir apribokite laukimą, kad hook negalėtų neribotai laikyti pabudimo kelio atviro. Teikite pirmenybę profilio pavadinimui, o ne skaitiniam indeksui, ir jei teisingas profilis skiriasi pagal tinklą, leiskite sveikam tuneliui iš anksto įrašyti savo pasirinkimą į failą.

Saugokitės ir perkrovimo audrų, skaičiuodami bandymus ir sustodami. Stebėtojas, reaguojantis į kiekvieną nepavykusį patikrinimą, vieną gedimą paverčia ciklu.

Pristabdykite sistemą vieną kartą, tada perskaitykite žurnale paties hook išvestį. Tai vienintelis testas, įrodantis tvarką.

Susiję straipsniai