Mac VPN připojeno, ale ip-up se nikdy nespustil: nastavte launchd sledování

Dáte příkaz route do /etc/ppp/ip-up, znovu připojíte kancelářský tunel a soubor se nikdy nespustí. Se skriptem není nic špatně: toto připojení vůbec nejde přes PPP. Vestavění klienti Cisco IPSec a IKEv2 nikdy nespustí pppd, takže se adresář hooků nikdy nečte, zatímco PPTP a L2TP přes IPSec jím stále procházejí. Zjistěte, který případ máte, a pak ten ne-PPP spusťte z úlohy launchd sledování.

Než upravíte jakýkoli hook, zkontrolujte rozhraní

Dva příkazy rozhodnou, který mechanismus může fungovat. Vypište nakonfigurované služby, pak vypište rozhraní, která existují, dokud je tunel aktivní. Název rozhraní je důkaz; popisek v Nastavení systému není.

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

Služba, která vytváří ppp0, spouští PPP hooky a spustí váš soubor. Služba Cisco IPSec nebo IKEv2 vytváří místo toho zařízení utun, tunelové rozhraní bez PPP vrstvy, takže nic uvnitř /etc/ppp se k němu nedostane. Když se objeví oba druhy, ověřte, ke které službě jste se připojili. Lidé ztratí odpoledne na špatném hooku, protože čtou název klienta.

Na cestě PPP musí soubor patřit rootu a být spustitelný, protože pppd kontroluje obojí, než cokoli spustí. install nastaví vlastníka i režim v jednom kroku.

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

Soubor vytvořený přes Finder nebo grafický editor často skončí ve vlastnictví vašeho účtu nebo bez práva spuštění, a pak selže stejně tiše jako chybějící hook. Umístěte vedle něj hned ip-down. root a wheel ve sloupci vlastníka plus rwxr-xr-x ve sloupci režimu je to, co chcete.

Nechte launchd spustit skript, když se objeví tunel

U klientů, kteří se PPP nikdy nedotknou, musí spouštěč přijít odjinud, a úložiště systémové konfigurace je poctivý zdroj: macOS ho přepisuje při každém přechodu tunelu. Úloha launchd, která tento adresář sleduje, se zavolá, když se tunel objeví nebo zmizí.

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

Nainstalujte ho jako launch daemon, ne jako agenta pro jednotlivého uživatele, protože oprava tras patří stroji. bootstrap nahrazuje v aktuálních verzích starší formu load -w. RunAtLoad činí první spuštění pozorovatelným a ThrottleInterval brání tomu, aby série změn při připojení k Wi-Fi spouštěla skript opakovaně.

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 tom, že sledovaný adresář se mění i při událostech, které s vaší VPN nemají nic společného: připojení k Wi-Fi, obnova DHCP, zapojený kabel. Strážce níže mění hlučný spouštěč v použitelný hook a řádek v logu vysvětlí trasu v neobvyklou hodinu.

Vlastnictví zahrnuje plist stejně jako skript. Démon, který spouští soubor v adresáři, kam váš účet může zapisovat, dává tomu účtu root.

Chraňte skript, aby druhé spuštění nic nezměnilo

Skript nejprve rozhodne, zda tunel existuje, a když ne, tiše skončí. Vše po tom musí být bezpečné opakovat, protože spouštěč se aktivuje mnohem častěji než jediné připojení. Rozhraní zjišťujte za běhu, místo abyste natvrdo kódovali index, který se při dalším připojení změní.

#!/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 skončí s nenulovým stavem, když trasa už existuje, takže skript, který každý nenulový stav bere jako chybu, hlásí rozbitý hook pokaždé, když dělá správnou věc. Test s netstat výše mění tento případ na výslovný no-op.

Přítomnost rozhraní je slabší důkaz, než to vypadá, protože jiní klienti VPN a některá kontejnerová prostředí také vytvářejí zařízení utun. Zeptejte se samotné služby pomocí scutil --nc status "Office VPN" a před zásahem do směrování vyžadujte připojený stav. Odpověď držte v řádku logu, protože za týden bude ten záznam jediné vysvětlení, které budete mít.

Vraťte bránu zpět, aniž byste rozbili DNS

Když tunel převezme výchozí trasu, běžné prohlížení vychází přes kancelář a místní internetová cesta přestane fungovat. Nejprve zachyťte router fyzického rozhraní, pak výchozí trasu namiřte zpět na něj. DHCP je lepší než parsování tabulky, která už obsahuje vlastní výchozí trasu tunelu.

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

Resolver je samostatná vrstva se samostatným nástrojem a oprava trasy ho neopraví. Podívejte se pomocí scutil --dns, co platí, a pak opravte to, co to vytváří: pořadí služeb a DNS záznamy na fyzické službě. Vyprázdnění cache diagnostikuje dotaz zaseknutý po změně sítě; není to něco, co se má plánovat.

Tunel, který přežije změnu Wi-Fi, zatímco DNS zamrzne, je třetí závada: sudo killall -HUP mDNSResponder přiměje resolver znovu načíst konfiguraci. Použijte to jednou, ručně.

Dokažte, že se úloha spouští sama

Vynuťte jedno spuštění pomocí kickstart -k, než uvěříte cestě sledování, a pak přečtěte návratový stav, který úloha zaznamenala. Čistý návrat dokazuje, že skript funguje; nedokazuje, že funguje spouštěč. Potom se odpojte a znovu připojte s načtenou úlohou a sledujte spuštění, o které jste nežádali.

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

Před každým pokusem a po něm zkontrolujte scutil --nc status. Skript, který běžel, když byl tunel dole, o cestě připojení nic nedokazuje.

Větev demontáže si zaslouží stejné zacházení jako větev připojení: odstraňte trasu ručně, nechte úlohu běžet a potvrďte, že se vrátí. Hook, který trasu přidá a nikdy ji neodebere, zanechá stroj, který se za týden chová špatně, a nic ty dvě události nespojuje. Když obě chování obstojí, sudo launchctl bootout system/net.example.tunnel-watch úlohu čistě vyřadí. Ponechaný načtený sledovací démon je způsob, jak se jednorázová oprava po měsících stane nevysvětlenou trasou.