Mac VPN ir savienots, bet ip-up nekad neiedarbojās: iestatiet launchd uzraudzību

Jūs ievietojat route komandu /etc/ppp/ip-up, atkārtoti pievienojaties biroja tunelim, un fails nekad netiek izpildīts. Ar skriptu viss ir kārtībā: šis savienojums nemaz neiet caur PPP. Iebūvētie Cisco IPSec un IKEv2 klienti nekad nepalaida pppd, tāpēc hook mape nekad netiek lasīta, bet PPTP un L2TP virs IPSec joprojām iet caur to. Noskaidrojiet, kurš gadījums ir jūsu, un pēc tam palaidiet ne-PPP gadījumu no launchd uzraudzības uzdevuma.

Pirms rediģējat jebkuru hook, pārbaudiet saskarni

Divi komandas izšķir, kurš mehānisms var darboties. Uzskaitiet konfigurētos pakalpojumus, pēc tam uzskaitiet saskarnes, kas pastāv, kamēr tunelis ir ieslēgts. Saskarnes nosaukums ir pierādījums; etiķete sistēmas iestatījumos nav.

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

Pakalpojums, kas rada ppp0, izpilda PPP hook un izpildīs jūsu failu. Cisco IPSec vai IKEv2 pakalpojums tā vietā rada utun ierīci, tuneļa saskarni bez PPP slāņa, tāpēc nekas /etc/ppp iekšienē nevar to sasniegt. Kad parādās abi veidi, pārbaudiet, kuram pakalpojumam pievienojāties. Cilvēki izšķērdē pēcpusdienu pie nepareizā hook, lasot klienta nosaukumu.

PPP ceļā failam jāpieder root un jābūt izpildāmam, jo pppd pārbauda abus pirms kaut ko palaiž. install vienā solī iestata īpašnieku un režīmu.

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

Fails, kas izveidots ar Finder vai grafisko redaktoru, bieži nonāk jūsu konta īpašumā vai bez izpildes bita, un pēc tam neizdodas tik klusi kā trūkstošais hook. Tagad novietojiet tam blakus ip-down. root un wheel īpašnieka kolonnā plus rwxr-xr-x režīma kolonnā ir tas, ko vēlaties.

Ļaujiet launchd palaist skriptu, kad parādās tunelis

Klientiem, kas nekad neaizskar PPP, izraisītājam jānāk no citurienes, un sistēmas konfigurācijas krātuve ir godīgais avots: macOS to pārraksta katrā tuneļa pārejā. launchd uzdevums, kas uzrauga šo mapi, tiek izsaukts, kad tunelis parādās vai pazūd.

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

Instalējiet to kā launch daemon, nevis kā katra lietotāja aģentu, jo maršrutu labošana pieder mašīnai. bootstrap pašreizējos laidienos aizstāj vecāko load -w formu. RunAtLoad padara pirmo izpildi novērojamu, un ThrottleInterval neļauj Wi-Fi pievienošanās izmaiņu plūsmam atkārtoti palaist skriptu.

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

Slazds ir tāds, ka uzraudzītā mape mainās arī notikumos, kuriem nav nekāda sakara ar jūsu VPN: Wi-Fi pievienošanās, DHCP atjaunošana, iesprausts kabelis. Zemāk esošais sargs pārvērš trokšņainu izraisītāju lietojamā hook, un žurnāla rinda izskaidro neparastas stundas maršrutu.

Īpašumtiesības aptver plist tāpat kā skriptu. Dēmons, kas izpilda failu mapē, kurā jūsu paša konts var rakstīt, nodod šim kontam root.

Aizsargājiet skriptu, lai otrs palaišana neko nemainītu

Skripts vispirms izlemj, vai tunelis pastāv, un klusi iziet, ja nepastāv. Visam pēc tam jābūt droši atkārtojamam, jo izraisītājs nostrādā daudz biežāk nekā viens savienojums. Atrisiniet saskarni izpildes laikā, nevis cieti kodējiet indeksu, kas mainīsies nākamajā savienojumā.

#!/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 iziet ar statusu, kas nav nulle, kad maršruts jau pastāv, tāpēc skripts, kas katru statusu, kas nav nulle, uzskata par kļūdu, katru reizi, kad rīkojas pareizi, ziņo par salauztu hook. Augstāk esošais netstat tests pārvērš šo gadījumu skaidrā no-op.

Saskarnes klātbūtne ir vājāks pierādījums, nekā izskatās, jo arī citi VPN klienti un dažas konteineru vides veido utun ierīces. Jautājiet pašam pakalpojumam ar scutil --nc status "Office VPN" un pieprasiet pievienotu stāvokli pirms maršrutēšanas aizskaršanas. Glabājiet atbildi žurnāla rindā, jo pēc nedēļas šis ieraksts būs vienīgais izskaidrojums, kas jums būs.

Atgrieziet vārteju, nesalaužot DNS

Kad tunelis pārņem noklusējuma maršrutu, parastā pārlūkošana iziet caur biroju un vietējais interneta ceļš pārstāj darboties. Vispirms tveriet fiziskās saskarnes maršrutētāju, pēc tam vērsiet noklusējuma maršrutu atpakaļ uz to. DHCP ir labāks par tabulas analīzi, kurā jau ir paša tuneļa noklusējums.

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

Atrisinātāji ir atsevišķs slānis ar atsevišķu rīku, un maršruta labošana tos nelabo. Apskatiet ar scutil --dns, kas ir spēkā, un pēc tam izlabojiet to, kas to rada: pakalpojumu secību un DNS ierakstus fiziskajā pakalpojumā. Kešatmiņas iztīrīšana diagnosticē pēc tīkla maiņas iestrēgušu meklēšanu; tas nav kaut kas, ko plānot.

Tunelis, kas pārdzīvo Wi-Fi maiņu, bet DNS iestrēgst, ir trešā kļūda: sudo killall -HUP mDNSResponder liek atrisinātājam nolasīt konfigurāciju no jauna. Izmantojiet to vienu reizi, ar roku.

Pierādiet, ka uzdevums nostrādā pats

Piespiediet vienu palaišanu ar kickstart -k, pirms uzticaties uzraudzības ceļam, pēc tam nolasiet uzdevuma reģistrēto izejas statusu. Tīra izeja pierāda, ka skripts darbojas; tā nepierāda, ka darbojas izraisītājs. Pēc tam atvienojieties un pievienojieties vēlreiz ar ielādētu uzdevumu un vērojiet palaišanu, kuru neprasījāt.

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

Pārbaudiet scutil --nc status pirms un pēc katra mēģinājuma. Skripts, kas darbojās, kamēr tunelis bija izslēgts, neko nepierāda par savienojuma ceļu.

Demontāžas zars ir pelnījis tādu pašu attieksmi kā savienojuma zars: noņemiet maršrutu ar roku, ļaujiet uzdevumam darboties un apstipriniet, ka tas atgriežas. Hook, kas pievieno maršrutu un nekad to nenoņem, atstāj mašīnu, kas pēc nedēļas uzvedas slikti, un nekas nesaista abus notikumus. Kad abas uzvedības pastāv, sudo launchctl bootout system/net.example.tunnel-watch kārtīgi atbrīvo uzdevumu. Ielādēts atstāts uzraudzības dēmons ir ceļš, kā vienreizējs labojums pēc mēnešiem kļūst par neizskaidrotu maršrutu.