Mac-VPN verbonnen, awer ip-up ass ni gelaf: eng launchd-Iwwerwaachung astellen

Cisco IPSec an IKEv2-Tunnelen starten ni pppd, dofir bleift /etc/ppp/ip-up stëll. Iwwerwaach de Konfiguratiouns-Dossier a loosst de Skript den Tunnel beweisen.

Du setz eng route-Uerdnung an /etc/ppp/ip-up, verbënns de Büro-Tunnel nei, an d’Datei leeft ni. Um Skript ass näischt falsch: déi Verbindung geet guer net duerch PPP. Déi agebaut Cisco IPSec- an IKEv2-Kliente starten ni pppd, dofir gëtt den Hook-Dossier ni gelies, während PPTP an L2TP iwwer IPSec nach ëmmer duerch en ginn. Fann eraus, wéi ee Fall du hues, an da léis den Net-PPP-Fall vun engem launchd-Iwwerwaachungsjob aus un.

Kontrolléier d’Interface, ier s du en Hook änderst

Zwou Uerdnunge entscheeden, wéi ee Mechanismus ka schaffen. Lëscht d’konfiguréiert Servicer op, dann lëscht d’Interfacen op, déi et gëtt, während den Tunnel uewen ass. Den Numm vun der Interface ass de Beweis; d’Etikett an de Systemastellungen net.

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

E Service, deen ppp0 produzéiert, leeft d’PPP-Hooken an huet deng Datei auszeféieren. E Cisco IPSec- oder IKEv2-Service produzéiert amplaz en utun-Apparat, eng Tunnel-Interface ouni PPP-Schicht, dofir kann näischt an /etc/ppp derbäi kommen. Wa béid Zorte erschéngen, kontrolléier, mat wéi engem Service s du verbonne bass. D’Leit verléieren en Nomëtteg um falschen Hook, well se den Numm vum Client liesen.

Um PPP-Wee muss d’Datei dem root gehéieren an ausféierbar sinn, well pppd béides kontrolléiert, ier eppes leeft. install setzt Proprietär a Modus an engem Schrëtt.

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

Eng Datei, déi iwwer den Finder oder en grafeschen Editeur entsteet, gehéiert dacks dengem Kont oder huet keen Ausféierungsbit a feelt dann sou stëll wéi den Hook, dee gefeelt huet. Setz elo ip-down dernieft. root an wheel an der Proprietärskolonn plus rwxr-xr-x an der Moduskolonn sinn dat, wat s du wëlls.

Looss launchd de Skript zünden, wann en Tunnel erschéngt

Fir Cliente, déi PPP ni beréieren, muss den Ausléiser vun aneschtwou kommen, an de Systemkonfiguratiounsspäicher ass déi éierlech Quell: macOS schreift en bei all Tunnel-Iwwergank nei. En launchd-Job, deen deen Dossier iwwerwaacht, gëtt geruff, wann en Tunnel erschéngt oder verschwënnt.

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

Installéier en als launch-Daemon, net als Agent pro Benotzer, well d’Réparatur vun de Weeër gehéiert zur Maschinn. bootstrap ersetzt déi eeler Form load -w op den aktuellen Versiounen. RunAtLoad mécht déi éischt Ausféierung observéierbar, an ThrottleInterval verhënnert, datt en Ulaf vu Wi-Fi-Verbindungsännerungen de Skript ëmmer erëm 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

D’Fal ass, datt den iwwerwaachten Dossier sech och bei Evenementer ännert, déi näischt mat dengem VPN ze dinn hunn: eng Wi-Fi-Verbindung, eng DHCP-Erneierung, e Kabel, deen agepluggt gëtt. De Wiechter hei drënner mécht aus engem lueren Ausléiser en notzlechen Hook, an eng Zeil am Log erkläert eng Route zu enger komescher Stonn.

D’Proprietéit deckt de plist grad wéi de Skript. En Daemon, deen eng Datei an engem Dossier ausféiert, an deen deng eege Kont schreiwen kann, gëtt deem Kont root.

Schütz de Skript, sou datt en zweete Laf näischt ännert

De Skript entscheet fir d’éischt, ob den Tunnel existéiert, a geet stëll eraus, wann net. Alles duerno muss sécher ze widderhuelen sinn, well den Ausléiser vill méi dacks geschott gëtt wéi eng eenzeg Verbindung. Léis d’Interface zur Lafzäit op, amplaz en Index fest ze kodéieren, dee bei der nächster Verbindung ännert.

#!/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 geet mat engem net-null Status eraus, wann d’Route scho existéiert, dofir mellt e Skript, deen all net-null Status als Feeler behandelt, all Kéier e gebrochenen Hook, wann et dat Richtegt mécht. Den netstat-Test hei uewen mécht aus deem Fall en expliziten No-op.

D’Präsenz vun der Interface ass e méi schwaache Beweis, wéi et ausgesäit, well aner VPN-Cliente an e puer Container-Ëmgebungen och utun-Apparater maachen. Frot de Service selwer mam scutil --nc status "Office VPN" a fuerder den verbonnene Staat, ier s du d’Routing beréiers. Halt d’Äntwert an enger Logzeil, well eng Woch méi spéit ass dee Rekord déi eenzeg Erklärung, déi s du hues.

Brëng d’Gateway zréck, ouni DNS ze briechen

Wann den Tunnel déi Standardroute iwwerhëlt, geet normal Browsen iwwer de Büro eraus an de lokalen Internetwee hält op ze schaffen. Fänk fir d’éischt de Router vun der physescher Interface, dann richt d’Standardroute zréck op en. DHCP ass besser wéi eng Tabell ze parsen, déi schonn den eegene Standard vum Tunnel huet.

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

Resolvere si séiergetrennte Schicht mat engem séiergetrennten Instrument, an d’Route ze reparéieren reparéiert se net. Kuck mam scutil --dns wat a Kraaft ass, dann reparéier, wat et produzéiert: d’Uerdnung vun de Servicer an d’DNS-Andräg um physesche Service. De Cache eidel ze maachen diagnostizéiert eng Sich, déi no engem Netzwierkwiessel hänkt; et ass näischt, wat een astellen soll.

En Tunnel, deen en Wi-Fi-Wiessel iwwerlieft, während DNS stockt, ass en drëtte Feeler: sudo killall -HUP mDNSResponder mécht, datt de Resolver seng Konfiguratioun nei liest. Benotz en eemol, mat der Hand.

Beweis, datt den Job vu sech selwer schott

Forcéier ee Laf mam kickstart -k, ier s du dem Iwwerwaachungswee vertraus, dann lies de Ausgangsstatus, deen den Job opgezeechent huet. En propperen Ausgang beweist, datt de Skript schafft; en beweist net, datt den Ausléiser schafft. Da trenn an verbinn erëm, mam geluedene Job, a kuck no engem Laf, deen s du net gefrot hues.

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

Kontrolléier scutil --nc status virun an no all Versuch. E Skript, deen gelaf ass, wéi den Tunnel ënnen war, beweist näischt iwwer de Verbindungswee.

De Lääschenausleefer verdéngt déi selwecht Behandlung wéi de Verbindungsausleefer: huel d’Route mat der Hand ewech, loos den Job lafen a bestäteg, datt se zréckkënnt. En Hook, deen eng Route bäisetzt an se ni ewechhëlt, hannerléisst eng Maschinn, déi eng Woch méi spéit falsch verhält, ouni datt eppes déi zwou Evenementer verbënnt. Wa béid Verhalen halen, pensionéiert sudo launchctl bootout system/net.example.tunnel-watch den Job propper. En geluedene geloossenen Iwwerwaachungsdaemon ass de Wee, wéi eng eenzeg Réparatur Méint méi spéit eng onerkläert Route gëtt.

Ähnlech Artikelen