Mac-VPN ferbûn, mar ip-up gie nea ôf: set in launchd-wacht op

Jo sette in route-opdracht yn /etc/ppp/ip-up, ferbine de kantoartunnel opnij, en it bestân wurdt nea útfierd. Der is neat mis mei it skript: dy ferbining giet hielendal net troch PPP. De ynboude Cisco IPSec- en IKEv2-klanten starte nea pppd, dus de hook-map wurdt nea lêzen, wylst PPTP en L2TP oer IPSec der noch al troch geane. Fêststelle hokker gefal jo hawwe, en trigger dan it net-PPP-gefal fanút in launchd-wachtbaan.

Kontrolearje de ynterface foardat jo in hook bewurkje

Twa opdrachten beslisse hokker meganisme wurkje kin. Lis de konfigurearre tsjinsten op, lis dan de ynterfaces op dy’t besteane wylst de tunnel oan is. De namme fan de ynterface is it bewiis; it label yn Systeemynstellings is dat net.

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

In tsjinst dy’t ppp0 produsearret, rint de PPP-hooks en sil jo bestân útfierer. In Cisco IPSec- of IKEv2-tsjinst produsearret ynstee in utun-apparaat, in tunnel-ynterface sûnder PPP-laach, dus neat yn /etc/ppp kin it berikke. As beide soarten opkomme, kontrolearje by hokker tsjinst jo ferbûn binne. Minsken ferlieze in middei oan de ferkearde hook troch de klantnamme te lêzen.

Op it PPP-paad moat it bestân eigendom wêze fan root en útfierber, om’t pppd beide kontrolearret foardat er wat dan ek rint. install set eigener en modus yn ien stap.

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

In bestân dat troch Finder of in grafyske bewurker makke is, heart faak ta jo account of hat gjin útfierbit, en falt dan like stil as de ûntbrekkende hook. Set no ip-down dernjonken. root en wheel yn ’e eigener-kolom plus rwxr-xr-x yn ’e modus-kolom is wat jo wolle.

Lit launchd it skript ôfsjitte as der in tunnel ferskynt

Foar klanten dy’t PPP nea oanreitsje, moat de trigger earne oars wei komme, en de systeemkonfiguraasje-opslach is de earlike boarne: macOS skriuwt dy by elke tunnel-oergong opnij. In launchd-baan dy’t dy map yn ’e gaten hâldt, wurdt oproppen as in tunnel ferskynt of ferdwynt.

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

Ynstallearje it as launch-daemon, net as agent per brûker, om’t rûtemekaar hinget by de masine. bootstrap ferfangt de âldere foarm load -w op aktuele ferzjes. RunAtLoad makket de earste útfiering waarnimber, en ThrottleInterval keart dat in weach Wi-Fi-oanslutings it skript hieltiten opnij start.

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

De fal is dat de bewaakte map feroaret by barren sûnder ferbân mei jo VPN: in Wi-Fi-oansluting, in DHCP-ferfanging, in kabel dy’t der yn giet. De wachter hjirûnder makket fan in lawrierige trigger in brûkbere hook, en in logrigel ferklearret in rûte op in frjemd oere.

Eigendom beslacht de plist likegoed as it skript. In daemon dy’t in bestân útfierer yn in map dêr’t jo eigen account yn skriuwe kin, jout dat account root.

Beskoattelje it skript sadat in twadde rin neat feroaret

It skript beslút earst oft de tunnel bestiet, en giet stil fuort as dat net sa is. Alles dêrnei moat feilich te werheljen wêze, om’t de trigger folle faker ôfgiet as ien ferbining. Lis de ynterface by it rinnen fêst ynstee fan in yndeks hurdt te kodearjen dy’t by de folgjende ferbining feroaret.

#!/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 giet mei in net-nul status fuort as de rûte al bestiet, dus in skript dat elke net-nul status as mislearring behannelet, meldt elke kear in brutsen hook as it it goede docht. De netstat-test hjirboppe makket dat gefal ta in eksplisite no-op.

De oanwêzigens fan de ynterface is swakker bewiis as it liket, om’t oare VPN-klanten en guon container-omjouwings ek utun-apparaten meitsje. Freegje de tsjinst sels mei scutil --nc status "Office VPN" en easkje de ferbûne steat foardat jo de rûtering oanreitsje. Hâld it antwurd yn in logrigel, om’t jo in wike letter dy registraasje as iennichste ferklearring hawwe.

Bring de gateway werom sûnder DNS te brekken

As de tunnel de standertrûte oernimt, giet gewoan browsen fia it kantoar nei bûten en hâldt it lokale internetpaad op te wurkjen. Fange earst de router fan de fysike ynterface, en rjochtsje dan de standert wer op him. DHCP is better as it parsen fan in tabel dy’t al de eigen standert fan de tunnel befettet.

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

Resolvers binne in aparte laach mei in apart ark, en it reparearjen fan de rûte reparearret har net. Sjoch mei scutil --dns wat jildt, en reparearje dan wat dat produsearret: de tsjinstfolchoarder en de DNS-ynfieringen op de fysike tsjinst. It cache leegje diagnostisearret in syktocht dy’t fêstsit nei in netwurkwiksel; it is net wat om te plannen.

In tunnel dy’t in Wi-Fi-wiksel oerlibbet wylst DNS stilfalt, is in tredde flater: sudo killall -HUP mDNSResponder lit de resolver syn konfiguraasje opnij lêze. Brûk it ien kear, mei de hân.

Bewiis dat de baan út himsels ôfgiet

Twang ien rin ôf mei kickstart -k foardat jo it wachtpaad fertrouwe, en lês dan de útgongstatus dy’t de baan fêstlein hat. In skjinne útgong bewiist dat it skript wurket; it bewiist net dat de trigger wurket. Ferbine dan los en wer oan mei de baan laden, en sjoch út nei in rin dy’t jo net frege hawwe.

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

Kontrolearje scutil --nc status foar en nei elk besykjen. In skript dat rûn wylst de tunnel del wie, bewiist neat oer it ferbiningspaad.

De ôfbrekkaam fertsjinnet deselde behanneling as de ferbiningskaam: helje de rûte mei de hân fuort, lit de baan rinne, en befêstigje dat er weromkomt. In hook dy’t in rûte tafoeget en him nea fuorthellet, lit in masine efter dy’t in wike letter ferkeard docht, sûnder dat wat de beide barrens ferbynt. As beide gedrach hâldt, nimt sudo launchctl bootout system/net.example.tunnel-watch de baan skjin út tsjinst. In laden litten wachtdemon is de manier dêr’t in ienmalige reparaasje moannen letter in ûnferklearre rûte fan wurdt.