Mac VPN povezan, a ip-up se ni nikoli zagnal: nastavite launchd nadzor

V /etc/ppp/ip-up vstavite ukaz route, znova povežete pisarniški tunel, datoteka pa se nikoli ne izvede. S skriptom ni nič narobe: ta povezava sploh ne gre skozi PPP. Vgrajena odjemalca Cisco IPSec in IKEv2 nikoli ne zaženeta pppd, zato se mapa hookov nikoli ne prebere, medtem ko PPTP in L2TP prek IPSec še vedno gresta skozi njo. Ugotovite, kateri primer velja pri vas, nato pa ne-PPP primer sprožite iz opravila nadzora launchd.

Preverite vmesnik, preden uredite katerikoli hook

Dva ukaza odločita, kateri mehanizem lahko deluje. Naštejte konfigurirane storitve, nato naštejte vmesnike, ki obstajajo, medtem ko je tunel aktiven. Ime vmesnika je dokaz; oznaka v Sistemskih nastavitvah ni.

scutil --nc list
ifconfig -l | tr ' ' '\n' | grep -E '^(utun|ppp)[0-9]+$'

Storitev, ki ustvari ppp0, izvaja hooke PPP in bo izvedla vašo datoteko. Storitev Cisco IPSec ali IKEv2 namesto tega ustvari napravo utun, tunelski vmesnik brez plasti PPP, zato nič znotraj /etc/ppp ne more do njega. Ko se pojavita obe vrsti, preverite, s katero storitvijo ste se povezali. Ljudje izgubijo popoldne na napačnem hooku, ker berejo ime odjemalca.

Na poti PPP mora datoteka pripadati rootu in biti izvršljiva, ker pppd preveri oboje, preden kar koli zažene. install nastavi lastnika in način v enem koraku.

sudo install -o root -g wheel -m 0755 /dev/null /etc/ppp/ip-up
sudo ls -l /etc/ppp/ip-up

Datoteka, ustvarjena prek Finderja ali grafičnega urejevalnika, pogosto konča v lasti vašega računa ali brez izvršilnega bita in nato spodleti enako tiho kot manjkajoči hook. Zdaj polepite ip-down ob njo. root in wheel v stolpcu lastnika ter rwxr-xr-x v stolpcu načina je tisto, kar želite.

Pustite launchd, da zažene skript, ko se pojavi tunel

Za odjemalce, ki se PPP nikoli ne dotaknejo, mora sprožilec priti od drugod, shramba sistemske konfiguracije pa je pošten vir: macOS jo prepiše ob vsakem prehodu tunela. Opravilo launchd, ki nadzoruje to mapo, se prikliče, ko se tunel pojavi ali izgine.

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>WatchPaths</key>
  <array><string>/Library/Preferences/SystemConfiguration</string></array>
  <key>Label</key><string>net.example.tunnel-watch</string>
  <key>ProgramArguments</key>
  <array><string>/bin/sh</string><string>/usr/local/sbin/tunnel-hook</string></array>
  <key>RunAtLoad</key><true/>
  <key>ThrottleInterval</key><integer>20</integer>
</dict>
</plist>

Namestite ga kot launch daemon, ne kot agenta za posameznega uporabnika, ker popravilo poti pripada stroju. bootstrap v trenutnih izdajah nadomesti starejšo obliko load -w. RunAtLoad naredi prvo izvedbo opazljivo, ThrottleInterval pa prepreči, da bi plaz sprememb pri povezovanju z Wi-Fi večkrat zagnal skript.

sudo install -o root -g wheel -m 0644 tunnel-watch.plist \
  /Library/LaunchDaemons/net.example.tunnel-watch.plist
sudo launchctl bootstrap system \
  /Library/LaunchDaemons/net.example.tunnel-watch.plist

Past je v tem, da se nadzorovana mapa spremeni tudi ob dogodkih, ki nimajo zveze z vašim VPN: povezava z Wi-Fi, obnova DHCP, priklopljen kabel. Stražar spodaj spremeni hrupni sprožilec v uporaben hook, vrstica v dnevniku pa pojasni pot ob nenavadni uri.

Lastništvo pokriva plist enako kot skript. Demon, ki izvaja datoteko v mapi, v katero lahko piše vaš lastni račun, temu računu podeli root.

Zaščitite skript, da druga izvedba ničesar ne spremeni

Skript najprej odloči, ali tunel obstaja, in tiho izstopi, ko ne. Vse po tem mora biti varno ponoviti, ker se sprožilec sproži veliko pogosteje kot ena sama povezava. Razrešite vmesnik med izvajanjem, namesto da trdo kodirate indeks, ki se ob naslednji povezavi spremeni.

#!/bin/sh
set -u
TUN=$(ifconfig -l | tr ' ' '\n' | grep -m1 '^utun[0-9]' || true)
[ -n "$TUN" ] || exit 0
netstat -rn -f inet | grep -q '^10\.42' && exit 0
route -n add -net 10.42.0.0/16 -interface "$TUN"

route add izstopi z neničelnim stanjem, ko pot že obstaja, zato skript, ki vsako neničelno stanje obravnava kot napako, vsakič, ko naredi pravo stvar, sporoči zlomljen hook. Test z netstat zgoraj ta primer spremeni v izrecen no-op.

Prisotnost vmesnika je šibkejši dokaz, kot se zdi, ker tudi drugi odjemalci VPN in nekatera okolja zabojnikov ustvarjajo naprave utun. Vprašajte samo storitev z scutil --nc status "Office VPN" in zahtevajte povezano stanje, preden se dotaknete usmerjanja. Odgovor shranite v vrstico dnevnika, ker bo teden dni pozneje ta zapis edino pojasnilo, ki ga boste imeli.

Vrnite prehod brez zloma DNS

Ko tunel prevzame privzeto pot, običajno brskanje odide skozi pisarno in lokalna internetna pot preneha delovati. Najprej zajemite usmerjevalnik fizičnega vmesnika, nato privzeto pot usmerite nazaj nanj. DHCP premaga razčlenjevanje tabele, ki že vsebuje tunelovo lastno privzeto pot.

PHYS=en0
GW=$(ipconfig getoption "$PHYS" router)
[ -n "$GW" ] && sudo route -n change default "$GW"

Razreševalniki so ločena plast z ločenim orodjem in popravilo poti jih ne popravi. Poglejte z scutil --dns, kaj velja, nato popravite, kar to ustvarja: vrstni red storitev in vnose DNS na fizični storitvi. Praznjenje predpomnilnika diagnosticira iskanje, zataknjeno po menjavi omrežja; to ni nekaj za načrtovanje.

Tunel, ki preživi menjavo Wi-Fi, medtem ko DNS obstane, je tretja napaka: sudo killall -HUP mDNSResponder prisili razreševalnik, da znova prebere konfiguracijo. Uporabite ga enkrat, ročno.

Dokažite, da se opravilo sproži samo

Vsilite eno izvedbo z kickstart -k, preden zaupate nadzorni poti, nato preberite izhodno stanje, ki ga je opravilo zabeležilo. Čist izhod dokaže, da skript deluje; ne dokaže, da deluje sprožilec. Nato se odklopite in znova povežite z naloženim opravilom ter opazujte izvedbo, ki je niste zahtevali.

sudo launchctl kickstart -k system/net.example.tunnel-watch
sudo launchctl print system/net.example.tunnel-watch | grep -E 'last exit code|state ='

Pred vsakim poskusom in po njem preverite scutil --nc status. Skript, ki je tekel, ko je bil tunel spuščen, ne dokaže ničesar o poti povezave.

Veja razgradnje si zasluži enako obravnavo kot veja povezave: odstranite pot ročno, pustite opravilu, da teče, in potrdite, da se vrne. Hook, ki doda pot in je nikoli ne odstrani, pusti stroj, ki se teden dni pozneje obnaša slabo, in nič ne poveže obeh dogodkov. Ko obe vedenji zdržita, sudo launchctl bootout system/net.example.tunnel-watch opravilo čisto upokoji. Naložen demon nadzora, ki ostane, je način, kako enkratno popravilo mesece pozneje postane nerazložena pot.