Mac VPN konektatuta, baina ip-up ez da inoiz abiarazi: jarri launchd zaintza bat

route komando bat jartzen duzu /etc/ppp/ip-up fitxategian, bulegoko tunela berriro konektatzen duzu, eta fitxategia ez da inoiz exekutatzen. Script-arekin ez dago ezer gaizki: konexio hori ez da PPP bidez igarotzen. Cisco IPSec eta IKEv2 bezero integratuek ez dute inoiz pppd abiarazten, beraz hook direktorioa ez da inoiz irakurtzen; PPTP eta IPSec gaineko L2TP oraindik hortik pasatzen dira. Zein kasu duzun zehaztu eta gero PPP ez den kasua abiarazi launchd zaintza lan batetik.

Egiaztatu interfazea edozein hook editatu aurretik

Bi komandok erabakitzen dute zein mekanismok funtziona dezakeen. Zerrendatu konfiguratutako zerbitzuak, eta gero zerrendatu tunela aktibo dagoen bitartean dauden interfazeak. Interfazearen izena da froga; Sistemaren Ezarpenetako etiketa ez da.

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

ppp0 sortzen duen zerbitzu batek PPP hook-ak exekutatzen ditu eta zure fitxategia exekutatuko du. Cisco IPSec edo IKEv2 zerbitzu batek utun gailu bat sortzen du horren ordez, PPP geruzarik gabeko tunel interfazea, beraz /etc/ppp barruko ezerk ezin du hara iritsi. Bi motak agertzen direnean, egiaztatu zein zerbitzutara konektatu zaren. Jendeak arratsalde bat galtzen du hook okerrean bezeroaren izena irakurtzeagatik.

PPP bidean fitxategia root-ena izan behar da eta exekutagarria, pppd-ek biak egiaztatzen baititu ezer exekutatu aurretik. install-ek jabea eta modua urrats bakarrean ezartzen ditu.

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

Finder edo editore grafiko baten bidez sortutako fitxategia sarritan zure kontuaren jabetzakoa izaten da, edo exekuzio bitik gabe, eta gero falta den hook-ak bezain isilik huts egiten du. Jarri ip-down haren ondoan orain. Jabearen zutabean root eta wheel eta moduaren zutabean rwxr-xr-x da nahi duzuna.

Utzi launchd-ri script-a abiarazten tunela agertzen denean

PPP inoiz ukitzen ez duten bezeroentzat, abiarazleak beste leku batetik etorri behar du, eta sistema konfigurazio biltegia iturri zintzoa da: macOS-ek tunelaren trantsizio bakoitzean berridazten du. Direktorio hori zaintzen duen launchd lan bat deitzen da tunela agertu edo desagertzen denean.

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

Instalatu launch daemon gisa, ez erabiltzaile bakoitzeko agente gisa, ibilbideen konponketa makinari dagokiolako. bootstrap-ek load -w forma zaharra ordezkatzen du uneko bertsioetan. RunAtLoad-ek lehen exekuzioa behatzeko modukoa egiten du, eta ThrottleInterval-ek Wi-Fi konexio aldaketen uholdeak script-a behin eta berriro abiaraztea eragozten du.

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

Tranpa da zaindua den direktorioa zure VPN-arekin zerikusirik ez duten gertaerengatik aldatzen dela: Wi-Fi konexioa, DHCP berritzea, kable bat konektatzea. Beheko zaintzaileak abiarazle zaratatsua hook erabilgarri bihurtzen du, eta log lerro batek ordu bitxiko ibilbidea azaltzen du.

Jabetzak plist-a ere hartzen du, script-az gain. Zure kontuak idatz dezakeen direktorio batean fitxategi bat exekutatzen duen daemon batek root ematen dio kontu horri.

Babestu script-a bigarren exekuzio batek ezer alda ez dezan

Script-ak lehenik tunela badagoen erabakitzen du, eta isilik irteten da ez badago. Horren ondorengo guztia errepikatzeko segurua izan behar da, abiarazlea konexio bakar bat baino askoz sarriago aktibatzen baita. Ebatz ezazu interfazea exekuzio garaian, hurrengo konexioan aldatzen den indize bat gogor kodetu beharrean.

#!/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 zerotikoa ez den egoerarekin irteten da ibilbidea jada badago, beraz zeroz besteko edozein egoera hutsegite gisa hartzen duen script-ak hook hautsia salatzen du gauza zuzena egiten duen bakoitzean. Goiko netstat probak kasu hori no-op esplizitu bihurtzen du.

Interfazearen presentzia dirudiena baino froga ahulagoa da, beste VPN bezero batzuek eta edukiontzi ingurune batzuek ere utun gailuak sortzen baitituzte. Galdetu zerbitzuari berari scutil --nc status "Office VPN" erabiliz eta eskatu konektatutako egoera bideratzea ukitu aurretik. Gorde erantzuna log lerro batean, astebete geroago erregistro hori izango baita izango duzun azalpen bakarra.

Ekarri atebidea DNS hautsi gabe

Tunelak lehenetsitako ibilbidea hartzen duenean, nabigatze arrunta bulegotik irteten da eta tokiko internet bidea funtzionatzeari uzten dio. Harrapatu lehenik interfaze fisikoaren router-a, eta gero zuzendu lehenetsitakoa berriro harengana. DHCP hobea da tunelaren berezko lehenetsia jada duen taula bat analizatzea baino.

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

Resolusioak geruza bereizia dira tresna bereiziarekin, eta ibilbidea konpontzeak ez ditu haiek konpontzen. Ikusi scutil --dns-ekin indarrean dagoena, eta gero konpondu hori sortzen duena: zerbitzuen ordena eta zerbitzu fisikoaren DNS sarrerak. Cachea hustutzeak sare aldaketa baten ondoren trabatutako bilaketa bat diagnostikatzen du; ez da programatzeko zerbait.

Wi-Fi aldaketa gainditzen duen tunel bat, DNS gelditzen den bitartean, hirugarren hutsegitea da: sudo killall -HUP mDNSResponder-ek resolusioa konfigurazioa berriro irakurtzera behartzen du. Erabili behin, eskuz.

Froga ezazu lanak bere kabuz abiarazten duela

Behartu exekuzio bat kickstart -k-ekin zaintza bidea fidatu aurretik, eta gero irakurri lanak erregistratutako irteera egoera. Irteera garbiak script-ak funtzionatzen duela frogatzen du; ez du frogatzen abiarazleak funtzionatzen duenik. Gero deskonektatu eta berriro konektatu lana kargatuta, eta begiratu eskatu ez duzun exekuzio baten bila.

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

Egiaztatu scutil --nc status saiakera bakoitzaren aurretik eta ondoren. Tunela behera zegoela exekutatu zen script-ak ez du ezer frogatzen konexio bideari buruz.

Desmuntatze adarrak konexio adarraren tratamendu bera merezi du: kendu ibilbidea eskuz, utzi lanari exekutatzen, eta egiaztatu itzultzen dela. Ibilbide bat gehitzen duen eta inoiz kentzen ez duen hook-ak astebete geroago gaizki portatzen den makina bat uzten du, bi gertaerak ezerk lotu gabe. Bi portaerek eusten dutenean, sudo launchctl bootout system/net.example.tunnel-watch-ek lana garbi erretiratzen du. Kargatuta uzten den zaintza daemon bat da behin-behineko konponketa hilabete batzuk geroago azaldu gabeko ibilbide bihurtzeko bidea.