Mac-VPN tilkopla, men ip-up køyrde aldri: set opp ei launchd-overvaking

Du legg ein route-kommando i /etc/ppp/ip-up, koplar til kontortunnelen på nytt, og fila køyrer aldri. Det er ingenting gale med skriptet: den tilkoplinga går ikkje gjennom PPP i det heile. Dei innebygde Cisco IPSec- og IKEv2-klientane startar aldri pppd, så hook-mappa blir aldri lesen, medan PPTP og L2TP over IPSec framleis går gjennom ho. Finn ut kva tilfelle du har, og utløys deretter ikkje-PPP-tilfellet frå ein launchd-overvakingsjobb.

Kontroller grensesnittet før du redigerer nokon hook

To kommandoar avgjer kva mekanisme som kan verke. List dei konfigurerte tenestene, og list deretter grensesnitta som finst medan tunnelen er oppe. Grensesnittnamnet er provet; etiketten i Systeminnstillingar er det ikkje.

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

Ei teneste som produserer ppp0 køyrer PPP-hookane og vil køyre fila di. Ei Cisco IPSec- eller IKEv2-teneste produserer i staden ein utun-eining, eit tunellgrensesnitt utan PPP-lag, så ingenting inne i /etc/ppp kan nå ho. Når begge slaga dukkar opp, sjekk kva teneste du kopla til. Folk kastar bort ein ettermiddag på feil hook ved å lese klientnamnet.

På PPP-vegen må fila eigast av root og vere køyrbar, fordi pppd sjekkar begge før han køyrer noko. install set eigar og modus i eitt steg.

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

Ei fil som blir laga via Finder eller ein grafisk editor hamnar ofte eigd av kontoen din, eller utan køyrebiten, og feilar då like stille som hooken som mangla. Legg ip-down ved sida av ho no. root og wheel i eigarkolonnen pluss rwxr-xr-x i moduskolonnen er det du vil ha.

La launchd utløyse skriptet når ein tunnel dukkar opp

For klientar som aldri rører PPP, må utløysaren kome frå ein annan stad, og systemkonfigurasjonslageret er den ærlege kjelda: macOS skriv det på nytt ved kvar tunellovergang. Ein launchd-jobb som overvakar den mappa, blir kalla når ein tunnel dukkar opp eller forsvinn.

<?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>

Installer det som ein launch-daemon, ikkje som ein agent per brukar, fordi ruteutbetring høyrer til maskina. bootstrap erstattar den eldre load -w-forma på gjeldande utgåver. RunAtLoad gjer den første køyringa observerbar, og ThrottleInterval hindrar at ein bylgje av Wi-Fi-tilkoplingar startar skriptet om og om att.

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

Fella er at den overvaka mappa òg endrar seg for hendingar utan noko med VPN-en din å gjere: ei Wi-Fi-tilkopling, ei DHCP-fornying, ein kabel som blir sett i. Vakta nedanfor gjer ein støyande utløysar om til ein brukbar hook, og ei logglinje forklarar ei rute på eit merkeleg tidspunkt.

Eigarskap dekkjer plist så vel som skriptet. Ein daemon som køyrer ei fil i ei mappe din eigen konto kan skrive i, gjev den kontoen root.

Vern skriptet slik at ei ny køyring ikkje endrar noko

Skriptet avgjer først om tunnelen finst, og avsluttar stille når han ikkje gjer det. Alt etterpå må vere trygt å gjenta, fordi utløysaren fyrer mykje oftare enn éi enkel tilkopling. Løys opp grensesnittet ved køyring i staden for å hardkode ein indeks som endrar seg ved neste tilkopling.

#!/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 avsluttar med ikkje-null status når ruta alt finst, så eit skript som handsamar kvar ikkje-null status som feil, rapporterer ein øydelagd hook kvar gong det gjer det rette. netstat-testen ovanfor gjer det tilfellet om til ein eksplisitt no-op.

Tilstadeværet av grensesnittet er svakare prov enn det ser ut, fordi andre VPN-klientar og enkelte containarmiljø lagar òg utun-einingar. Spør tenesta sjølv med scutil --nc status "Office VPN" og krev den tilkopla tilstanden før du rører rutinga. Ta vare på svaret i ei logglinje, for ei veke seinare er den registreringa den einaste forklaringa du har.

Hent gatewayen tilbake utan å øydeleggje DNS

Når tunnelen tek over standardruta, går vanleg surfing ut gjennom kontoret, og den lokale internettvegen sluttar å verke. Fang rutaren til det fysiske grensesnittet først, og peik deretter standardruta tilbake på han. DHCP slår det å parse ein tabell som alt inneheld tunnelen si eiga standardrute.

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

Resolvarane er eit eige lag med eit eige verktøy, og å reparere ruta reparerer dei ikkje. Sjå med scutil --dns kva som gjeld, og rett deretter det som lagar det: tenesterekkefølgja og DNS-oppføringane på den fysiske tenesta. Å tømme hurtigbufferen diagnostiserer eit oppslag som heng etter eit nettverksbyte; det er ikkje noko å planleggje.

Ein tunnel som overlever eit Wi-Fi-byte medan DNS står stille, er ein tredje feil: sudo killall -HUP mDNSResponder får resolvaren til å lese konfigurasjonen sin på nytt. Bruk han éin gong, for hand.

Prov at jobben fyrer av seg sjølv

Tving fram éi køyring med kickstart -k før du stolar på overvakingsvegen, og les deretter utgangsstatusen jobben registrerte. Ein rein utgang provar at skriptet verkar; det provar ikkje at utløysaren verkar. Kople deretter frå og til att med jobben lasta, og sjå etter ei køyring du ikkje bad om.

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

Sjekk scutil --nc status før og etter kvart forsøk. Eit skript som køyrde medan tunnelen var nede, provar ingenting om tilkoplingsvegen.

Nedrivingsgreina fortener same handsaming som tilkoplingsgreina: fjern ruta for hand, la jobben køyre, og stadfest at ho kjem tilbake. Ein hook som legg til ei rute og aldri fjernar ho, etterlèt ei maskin som oppfører seg dårleg ei veke seinare, utan at noko knyter dei to hendingane saman. Når begge åtferdene held, pensjonerer sudo launchctl bootout system/net.example.tunnel-watch jobben reint. Ein overvakingsdaemon som blir ståande lasta, er måten ei eingongsreparasjon blir ei uforklart rute månader seinare.