Macin VPN yhdistetty, mutta ip-up ei koskaan lauennut: käynnistä launchd-vahti

Laitat route-komennon tiedostoon /etc/ppp/ip-up, yhdistät toimistotunnelin uudelleen, eikä tiedosto koskaan suoritu. Skriptissä ei ole mitään vikaa: tuo yhteys ei kulje PPP:n kautta lainkaan. Sisäänrakennetut Cisco IPSec- ja IKEv2-asiakkaat eivät koskaan käynnistä pppd, joten hook-hakemistoa ei koskaan lueta, kun taas PPTP ja IPSecin yli kulkeva L2TP kulkevat edelleen sen kautta. Selvitä, kumpi tapaus sinulla on, ja laukaise sitten ei-PPP-tapaus launchd-vahtityöstä.

Tarkista liitäntä ennen kuin muokkaat yhtään hookia

Kaksi komentoa ratkaisevat, mikä mekanismi voi toimia. Listaa määritetyt palvelut ja listaa sitten liitännät, jotka ovat olemassa tunnelin ollessa päällä. Liitännän nimi on todiste; System Settingsin nimike ei ole.

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

Palvelu, joka tuottaa ppp0, suorittaa PPP-hookit ja suorittaa tiedostosi. Cisco IPSec- tai IKEv2-palvelu tuottaa sen sijaan utun-laitteen, tunneliliitännän ilman PPP-kerrosta, joten mikään /etc/ppp-hakemistossa ei voi tavoittaa sitä. Kun molempia tyyppejä esiintyy, tarkista, mihin palveluun yhdistit. Ihmiset tuhlaavat iltapäivän väärään hookiin lukemalla asiakkaan nimen.

PPP-polulla tiedoston täytyy olla rootin omistama ja suoritettava, koska pppd tarkistaa molemmat ennen kuin suorittaa mitään. install asettaa omistajan ja tilan yhdessä vaiheessa.

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

Finderilla tai graafisella editorilla luotu tiedosto päätyy usein oman tilisi omistukseen tai ilman suoritusbittiä, ja epäonnistuu sitten yhtä hiljaa kuin puuttuva hook. Laita ip-down sen viereen nyt. root ja wheel omistajasarakkeessa sekä rwxr-xr-x tilasarakkeessa on se, mitä haluat.

Anna launchdin laukaista skripti, kun tunneli ilmestyy

Asiakkaille, jotka eivät koskaan koske PPP:hen, liipaisimen on tultava muualta, ja järjestelmän asetustietovarasto on rehellinen lähde: macOS kirjoittaa sen uudelleen jokaisessa tunnelin siirtymässä. Kyseistä hakemistoa valvova launchd-työ kutsutaan, kun tunneli ilmestyy tai katoaa.

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

Asenna se launch-daemoniksi, ei käyttäjäkohtaiseksi agentiksi, koska reittien korjaus kuuluu koneelle. bootstrap korvaa vanhemman load -w-muodon nykyisissä julkaisuissa. RunAtLoad tekee ensimmäisestä suorituksesta havaittavan, ja ThrottleInterval estää Wi-Fi-liittymisten muutosryöpyn käynnistämästä skriptiä toistuvasti.

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

Ansana on, että valvottu hakemisto muuttuu myös tapahtumista, joilla ei ole mitään tekemistä VPN:si kanssa: Wi-Fi-liittyminen, DHCP-uudistus, kaapelin kytkeminen. Alla oleva vartija muuttaa meluisan liipaisimen käyttökelpoiseksi hookiksi, ja lokirivi selittää oudolla tunnilla syntyneen reitin.

Omistajuus kattaa plistin yhtä lailla kuin skriptin. Daemon, joka suorittaa tiedoston hakemistossa, johon oma tilisi voi kirjoittaa, antaa rootin sille tilille.

Suojaa skripti, ettei toinen ajo muuta mitään

Skripti päättää ensin, onko tunneli olemassa, ja poistuu hiljaa, jos ei ole. Kaiken sen jälkeen on oltava turvallista toistaa, koska liipaisin laukeaa paljon useammin kuin yksi yhteys. Ratkaise liitäntä ajonaikaisesti sen sijaan, että kovakoodaisit indeksin, joka muuttuu seuraavassa yhteydessä.

#!/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 poistuu nollasta poikkeavalla tilalla, kun reitti on jo olemassa, joten skripti, joka pitää jokaista nollasta poikkeavaa tilaa virheenä, raportoi rikkinäisestä hookista joka kerta tehdessään oikein. Yllä oleva netstat-testi muuttaa tapauksen eksplisiittiseksi no-opiksi.

Liitännän olemassaolo on heikompi todiste kuin miltä näyttää, koska muut VPN-asiakkaat ja jotkin konttiympäristöt luovat myös utun-laitteita. Kysy palvelulta itseltään scutil --nc status "Office VPN":lla ja vaadi yhdistetty tila ennen reititykseen koskemista. Pidä vastaus lokirivillä, koska viikkoa myöhemmin se merkintä on ainoa selitys, joka sinulla on.

Palauta yhdyskäytävä rikkomatta DNS:ää

Kun tunneli ottaa oletusreitin haltuunsa, tavallinen selailu lähtee toimiston kautta ja paikallinen internetpolku lakkautuu. Napaa ensin fyysisen liitännän reititin ja osoita sitten oletusreitti takaisin siihen. DHCP voittaa taulukon jäsentämisen, jossa on jo tunnelin oma oletus.

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

Nimipalvelimet ovat erillinen kerros erillisellä työkalulla, eikä reitin korjaaminen korjaa niitä. Katso scutil --dns:llä, mikä on voimassa, ja korjaa sitten se, mikä sen tuottaa: palvelujen järjestys ja fyysisen palvelun DNS-merkinnät. Välimuistin tyhjentäminen diagnosoi verkonvaihdon jälkeen juuttuneen haun; se ei ole mitään aikataulutettavaa.

Tunneli, joka selviää Wi-Fi-vaihdosta samalla kun DNS jumittuu, on kolmas vika: sudo killall -HUP mDNSResponder saa nimipalvelimen lukemaan asetuksensa uudelleen. Käytä sitä kerran, käsin.

Todista, että työ laukeaa itsestään

Pakota yksi ajo kickstart -k:llä ennen kuin luotat valvontapolkuun, ja lue sitten työn kirjaama poistumistila. Puhdas poistuminen todistaa, että skripti toimii; se ei todista, että liipaisin toimii. Kytke sitten irti ja yhdistä uudelleen työn ollessa ladattuna ja tarkkaile ajoa, jota et pyytänyt.

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

Tarkista scutil --nc status ennen jokaista yritystä ja sen jälkeen. Skripti, joka ajettiin tunnelin ollessa alhaalla, ei todista mitään yhteyspolusta.

Purkuhaara ansaitsee saman kohtelun kuin yhteyshaara: poista reitti käsin, anna työn ajaa ja varmista, että se palaa. Hook, joka lisää reitin eikä koskaan poista sitä, jättää koneen, joka käyttäytyy huonosti viikkoa myöhemmin, ilman että mikään yhdistää kaksi tapahtumaa. Kun molemmat käyttäytymiset pitävät, sudo launchctl bootout system/net.example.tunnel-watch poistaa työn siististi. Latautuneeksi jätetty valvontadaemon on tapa, jolla kertaluonteinen korjaus muuttuu kuukausia myöhemmin selittämättömäksi reitiksi.