VPN ya Mac imeunganishwa lakini ip-up haikuwahi kuwaka: endesha ufuatiliaji wa launchd

Unaweka amri ya route katika /etc/ppp/ip-up, unaunganisha tena tuneli ya ofisi, na faili haiendeshwi kamwe. Hakuna kosa kwenye skripti: muunganisho huo haupiti PPP kabisa. Wateja waliojengwa ndani wa Cisco IPSec na IKEv2 hawanzishi pppd kamwe, kwa hiyo folda ya ndoano haisomwi kamwe, wakati PPTP na L2TP juu ya IPSec bado zinapita humo. Tambua ni kisa kipi kilicho chako, kisha anzisha kisa kisicho cha PPP kutoka kazi ya ufuatiliaji ya launchd.

Angalia kiolesura kabla ya kuhariri ndoano yoyote

Amri mbili huamua ni utaratibu upi unaweza kufanya kazi. Orodhesha huduma zilizosanidiwa, kisha orodhesha violesura vilivyopo wakati tuneli iko juu. Jina la kiolesura ndilo ushahidi; lebo katika Mipangilio ya Mfumo siyo.

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

Huduma inayozalisha ppp0 huendesha ndoano za PPP na itatekeleza faili yako. Huduma ya Cisco IPSec au IKEv2 huzalisha kifaa utun badala yake, kiolesura cha tuneli kisicho na tabaka la PPP, kwa hiyo hakuna kitu ndani ya /etc/ppp kinachoweza kuifikia. Wakati aina zote mbili zinaonekana, angalia ni huduma ipi uliunganisha. Watu hupoteza mchana kwenye ndoano isiyo sahihi kwa kusoma jina la mteja.

Kwenye njia ya PPP faili lazima iwe inayomilikiwa na root na inayoweza kutekelezwa, kwa sababu pppd hukagua vyote viwili kabla ya kuendesha chochote. install huweka mmiliki na hali katika hatua moja.

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

Faili iliyoundwa kupitia Finder au kihariri cha picha mara nyingi huishia kuwa mali ya akaunti yako, au bila biti ya utekelezaji, kisha inashindwa kimya kimya kama ndoano iliyokosekana. Weka ip-down kando yake sasa. root na wheel kwenye safu ya mmiliki pamoja na rwxr-xr-x kwenye safu ya hali ndiyo unayotaka.

Acha launchd iwashe skripti wakati tuneli inaonekana

Kwa wateja wasiogusa PPP kamwe, kichocheo lazima kitoke mahali pengine, na hifadhi ya usanidi wa mfumo ndicho chanzo cha uaminifu: macOS huandika upya kila tuneli inapobadilika. Kazi ya launchd inayofuatilia folda hiyo huitwa wakati tuneli inaonekana au inatoweka.

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

Sakinisha kama launch daemon, si kama wakala wa kila mtumiaji, kwa sababu ukarabati wa njia ni wa mashine. bootstrap hubadilisha umbo la zamani load -w kwenye matoleo ya sasa. RunAtLoad hufanya utekelezaji wa kwanza uonekane, na ThrottleInterval huzuia wimbi la mabadiliko ya kuunganisha Wi-Fi kuanzisha skripti mara kwa mara.

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

Mtego ni kwamba folda inayofuatiliwa hubadilika pia kwa matukio yasiyo na uhusiano na VPN yako: kuunganisha Wi-Fi, kuhuisha DHCP, kebo iliyochomekwa. Mlinzi hapa chini hubadilisha kichocheo chenye kelele kuwa ndoano inayoweza kutumika, na mstari wa kumbukumbu hufafanua njia katika saa isiyo ya kawaida.

Umiliki unahusisha plist pamoja na skripti. Daemon inayotekeleza faili katika folda ambayo akaunti yako mwenyewe inaweza kuandika humpa akaunti hiyo root.

Linda skripti ili utekelezaji wa pili usibadilishe chochote

Skripti kwanza huamua kama tuneli ipo, na hutoka kimya kimya ikiwa haipo. Kila kitu baada ya hapo lazima kiwe salama kurudiwa, kwa sababu kichocheo huwaka mara nyingi zaidi kuliko muunganisho mmoja. Tatua kiolesura wakati wa utekelezaji badala ya kuweka kwa nguvu faharisi inayobadilika kwenye muunganisho ujao.

#!/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 hutoka na hali isiyo sifuri wakati njia ipo tayari, kwa hiyo skripti inayochukua kila hali isiyo sifuri kama kosa huripoti ndoano iliyovunjika kila inapofanya jambo sahihi. Jaribio la netstat hapo juu hubadilisha kisa hicho kuwa no-op iliyo wazi.

Uwepo wa kiolesura ni ushahidi hafifu kuliko unavyoonekana, kwa sababu wateja wengine wa VPN na baadhi ya mazingira ya kontena huunda pia vifaa vya utun. Uliza huduma yenyewe kwa scutil --nc status "Office VPN" na udai hali iliyounganishwa kabla ya kugusa uelekezaji. Weka jibu katika mstari wa kumbukumbu, kwa sababu wiki moja baadaye rekodi hiyo itakuwa maelezo pekee uliyo nayo.

Rudisha lango bila kuvunja DNS

Tuneli inapochukua njia ya chaguo-msingi, uvinjari wa kawaida hutoka kupitia ofisi na njia ya ndani ya intaneti huacha kufanya kazi. Nasa kwanza kipanga njia cha kiolesura halisi, kisha uelekeze chaguo-msingi kurudi kwake. DHCP inashinda kuchanganua jedwali ambalo tayari lina chaguo-msingi la tuneli yenyewe.

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

Vitatuzi ni tabaka tofauti lenye chombo tofauti, na kurekebisha njia hakuwarekebishi. Angalia kinachotumika kwa scutil --dns, kisha rekebisha kinachokizalisha: mpangilio wa huduma na maingizo ya DNS kwenye huduma halisi. Kufuta akiba huchunguza utafutaji uliokwama baada ya kubadilika kwa mtandao; si kitu cha kupanga.

Tuneli inayostahimili mabadiliko ya Wi-Fi wakati DNS inasimama ni hitilafu ya tatu: sudo killall -HUP mDNSResponder hufanya kitatuzi kisome usanidi wake tena. Itumie mara moja, kwa mkono.

Thibitisha kuwa kazi huwaka yenyewe

Lazimisha utekelezaji mmoja kwa kickstart -k kabla ya kuamini njia ya ufuatiliaji, kisha soma hali ya kutoka iliyorekodiwa na kazi. Kutoka safi huthibitisha kuwa skripti inafanya kazi; hakuthibitishi kuwa kichocheo kinafanya kazi. Kisha tenganisha na unganisha tena kazi ikiwa imepakiwa, na uangalie utekelezaji usiokuomba.

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

Angalia scutil --nc status kabla na baada ya kila jaribio. Skripti iliyoendeshwa wakati tuneli ilikuwa chini haithibitishi chochote kuhusu njia ya muunganisho.

Tawi la kuvunja linastahili utunzaji sawa na tawi la kuunganisha: ondoa njia kwa mkono, acha kazi iendelee, na thibitisha kuwa inarudi. Ndoano inayoongeza njia na haitoi kamwe huacha mashine inayofanya vibaya wiki moja baadaye, bila kitu kinachounganisha matukio mawili. Wakati tabia zote mbili zinashikilia, sudo launchctl bootout system/net.example.tunnel-watch hustaafisha kazi kwa usafi. Daemon ya ufuatiliaji iliyoachwa imepakiwa ndiyo njia ambayo ukarabati wa mara moja huwa njia isiyoelezewa miezi baadaye.