Mac VPN wedi cysylltu ond ip-up heb danio erioed: rhedwch oruchwyliaeth launchd

Rydych yn rhoi gorchymyn route yn /etc/ppp/ip-up, yn ailgysylltu twnnel y swyddfa, ac nid yw’r ffeil yn rhedeg byth. Nid oes dim o’i le gyda’r sgript: nid yw’r cysylltiad hwnnw yn mynd trwy PPP o gwbl. Nid yw cleientiaid cynhenid Cisco IPSec ac IKEv2 byth yn dechrau pppd, felly ni ddarllenir y cyfeiriadur bachau byth, tra bod PPTP a L2TP dros IPSec yn dal i fynd drwyddo. Darganfyddwch pa achos sydd gennych, yna tanio’r achos nad yw’n PPP o swydd oruchwylio launchd.

Gwiriwch y rhyngwyneb cyn i chi olygu unrhyw fach

Mae dau orchymyn yn penderfynu pa fecanwaith all weithio. Rhestrwch y gwasanaethau a ffurfweddwyd, yna rhestrwch y rhyngwynebau sy’n bodoli tra bo’r twnnel i fyny. Enw’r rhyngwyneb yw’r dystiolaeth; nid yw’r label yng Ngosodiadau’r System.

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

Mae gwasanaeth sy’n cynhyrchu ppp0 yn rhedeg bachau PPP ac yn gweithredu eich ffeil. Mae gwasanaeth Cisco IPSec neu IKEv2 yn cynhyrchu dyfais utun yn lle hynny, rhyngwyneb twnnel heb haen PPP, felly ni all dim y tu mewn i /etc/ppp gyrraedd ato. Pan fydd y ddau fath yn ymddangos, gwiriwch pa wasanaeth y gwnaethoch gysylltu ag ef. Mae pobl yn gwastraffu prynhawn ar y bach anghywir drwy ddarllen enw’r cleient.

Ar lwybr PPP rhaid i’r ffeil fod yn eiddo i root ac yn weithredadwy, oherwydd mae pppd yn gwirio’r ddau cyn rhedeg unrhyw beth. Mae install yn gosod perchennog a modd mewn un cam.

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

Mae ffeil a grëwyd drwy Finder neu olygydd graffig yn aml yn perthyn i’ch cyfrif, neu heb y did gweithredu, ac yna’n methu mor dawel â’r bach coll. Rhowch ip-down wrth ei hymyl nawr. root a wheel yng ngholofn y perchennog a rwxr-xr-x yng ngholofn y modd yw’r hyn rydych ei eisiau.

Gadewch i launchd danio’r sgript pan fydd twnnel yn ymddangos

Ar gyfer cleientiaid nad ydynt byth yn cyffwrdd PPP, rhaid i’r triger ddod o rywle arall, a’r storfa ffurfweddiad system yw’r ffynhonnell onest: mae macOS yn ei hailysgrifennu ar bob trawsnewidiad twnnel. Gelwir swydd launchd sy’n gwylio’r cyfeiriadur hwnnw pan fydd twnnel yn ymddangos neu’n diflannu.

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

Gosodwch ef fel launch daemon, nid fel asiant fesul defnyddiwr, oherwydd mae trwsio llwybrau yn perthyn i’r peiriant. Mae bootstrap yn disodli’r ffurf hŷn load -w ar ryddhadau cyfredol. Mae RunAtLoad yn gwneud y gweithrediad cyntaf yn arsylwadwy, ac mae ThrottleInterval yn rhwystro bwrlwm o newidiadau ymuno â Wi-Fi rhag lansio’r sgript dro ar ôl tro.

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

Y trap yw bod y cyfeiriadur a wyliwyd yn newid ar gyfer digwyddiadau heb ddim i’w wneud â’ch VPN: ymuno â Wi-Fi, adnewyddu DHCP, cebl yn cael ei blygio i mewn. Mae’r gwarchodwr isod yn troi triger swnllyd yn fach ddefnyddiadwy, ac mae llinell log yn esbonio llwybr ar awr od.

Mae perchnogaeth yn cwmpasu’r plist yn ogystal â’r sgript. Mae daemon sy’n gweithredu ffeil mewn cyfeiriadur y gall eich cyfrif ei ysgrifennu yn rhoi root i’r cyfrif hwnnw.

Gwarchodwch y sgript fel na fydd ail rediad yn newid dim

Mae’r sgript yn penderfynu gyntaf a yw’r twnnel yn bodoli, ac yn gadael yn dawel pan nad yw. Rhaid i bopeth ar ôl hynny fod yn ddiogel i’w ailadrodd, oherwydd mae’r triger yn tanio yn llawer amlach nag un cysylltiad. Datryswch y rhyngwyneb ar amser rhedeg yn hytrach na chodio mynegai’n galed sy’n newid ar y cysylltiad nesaf.

#!/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"

Mae route add yn gadael â statws nad yw’n sero pan fo’r llwybr eisoes yn bresennol, felly mae sgript sy’n trin pob statws nad yw’n sero fel methiant yn adrodd bach wedi torri bob tro y mae’n gwneud y peth iawn. Mae prawf netstat uchod yn troi’r achos hwnnw’n no-op pendant.

Mae presenoldeb rhyngwyneb yn dystiolaeth wannach nag y mae’n edrych, gan fod cleientiaid VPN eraill a rhai amgylcheddau cynhwysydd hefyd yn creu dyfeisiau utun. Gofynnwch i’r gwasanaeth ei hun gyda scutil --nc status "Office VPN" a mynnwch y cyflwr cysylltiedig cyn cyffwrdd â llwybro. Cadwch yr ateb mewn llinell log, oherwydd wythnos yn ddiweddarach y cofnod hwnnw fydd yr unig esboniad fydd gennych.

Dewch â’r giât yn ôl heb dorri DNS

Pan fydd y twnnel yn cymryd y llwybr diofyn, mae pori cyffredin yn gadael drwy’r swyddfa ac mae llwybr rhyngrwyd lleol yn stopio gweithio. Cipiwch lwybrydd y rhyngwyneb ffisegol yn gyntaf, yna pwyntiwch y diofyn yn ôl ato. Mae DHCP yn well na dadansoddi tabl sy’n dal llwybr diofyn y twnnel ei hun yn barod.

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

Mae datryswyr yn haen ar wahân gydag offeryn ar wahân, ac nid yw trwsio’r llwybr yn eu trwsio. Edrychwch ar yr hyn sydd mewn grym gyda scutil --dns, yna trwsiwch yr hyn sy’n ei gynhyrchu: trefn y gwasanaethau a’r cofnodion DNS ar y gwasanaeth ffisegol. Mae fflysio’r storfa yn diagnosio chwiliad sy’n sownd ar ôl newid rhwydwaith; nid yw’n rhywbeth i’w drefnu.

Mae twnnel sy’n goroesi newid Wi-Fi tra bo DNS yn oedi yn drydydd nam: mae sudo killall -HUP mDNSResponder yn gwneud i’r datryswr ailddarllen ei ffurfweddiad. Defnyddiwch ef unwaith, â llaw.

Profwch fod y swydd yn tanio ar ei phen ei hun

Gorfodwch un rhediad gyda kickstart -k cyn ymddiried yn y llwybr gwylio, yna darllenwch y statws allanfa a gofnodwyd gan y swydd. Mae allanfa lân yn profi bod y sgript yn gweithio; nid yw’n profi bod y triger yn gweithio. Yna datgysylltwch ac ailgysylltu gyda’r swydd wedi’i llwytho, a gwyliwch am rediad na wnaethoch chi ofyn amdano.

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

Gwiriwch scutil --nc status cyn ac ar ôl pob ymgais. Nid yw sgript a redodd tra bo’r twnnel i lawr yn profi dim am y llwybr cysylltu.

Mae’r gangen datgymalu yn haeddu’r un driniaeth â’r gangen gysylltu: tynnwch y llwybr â llaw, gadewch i’r swydd redeg, a chadarnhewch ei fod yn dod yn ôl. Mae bach sy’n ychwanegu llwybr ac nad yw byth yn ei dynnu yn gadael peiriant sy’n camymddwyn wythnos yn ddiweddarach, heb ddim yn cysylltu’r ddau ddigwyddiad. Pan fydd y ddau ymddygiad yn dal, mae sudo launchctl bootout system/net.example.tunnel-watch yn ymddeol y swydd yn lân. Daemon gwylio a adawyd wedi’i lwytho yw sut mae trwsio untro yn dod yn llwybr heb esboniad fisoedd yn ddiweddarach.