VPN në Mac i lidhur por ip-up nuk u aktivizua kurrë: nis një mbikëqyrje launchd

Vendos një komandë route në /etc/ppp/ip-up, rilidh tunelin e zyrës, dhe skedari nuk ekzekutohet kurrë. Skripti nuk ka asgjë të gabuar: ajo lidhje nuk kalon fare nëpër PPP. Klientët e integruar Cisco IPSec dhe IKEv2 nuk nisin kurrë pppd, prandaj dosja e grepave nuk lexohet kurrë, ndërsa PPTP dhe L2TP mbi IPSec vazhdojnë të kalojnë nëpër të. Përcakto cili rast është yti, pastaj aktivizo rastin jo-PPP nga një punë mbikëqyrjeje launchd.

Kontrollo ndërfaqen përpara se të redaktosh çdo grep

Dy komanda vendosin cili mekanizëm mund të funksionojë. Listo shërbimet e konfiguruara, pastaj listo ndërfaqet që ekzistojnë sa kohë tuneli është lart. Emri i ndërfaqes është prova; etiketa në Cilësimet e Sistemit nuk është.

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

Një shërbim që prodhon ppp0 ekzekuton grepat PPP dhe do të ekzekutojë skedarin tënd. Një shërbim Cisco IPSec ose IKEv2 prodhon në vend të tij një pajisje utun, një ndërfaqe tuneli pa shtresë PPP, prandaj asgjë brenda /etc/ppp nuk mund ta arrijë. Kur shfaqen të dy llojet, kontrollo me cilin shërbim u lidhët. Njerëzit humbin një pasdite në grepin e gabuar duke lexuar emrin e klientit.

Në rrugën PPP skedari duhet të jetë në pronësi të root dhe i ekzekutueshëm, sepse pppd kontrollon të dyja përpara se të ekzekutojë çdo gjë. install vendos pronarin dhe modin në një hap.

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

Një skedar i krijuar përmes Finder ose një redaktori grafik shpesh përfundon në pronësi të llogarisë tënde, ose pa bitin e ekzekutimit, dhe pastaj dështon po aq heshtur sa grepi që mungonte. Vendos tani ip-down pranë tij. root dhe wheel në kolonën e pronarit plus rwxr-xr-x në kolonën e modit është ajo që dëshiron.

Lëre launchd të nisë skriptin kur shfaqet një tunel

Për klientët që nuk prekin kurrë PPP, shkasja duhet të vijë nga diku tjetër, dhe depoja e konfigurimit të sistemit është burimi i ndershëm: macOS e rishkruan në çdo kalim tuneli. Një punë launchd që vëzhgon atë dosje thirret kur një tunel shfaqet ose zhduket.

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

Instaloje si launch daemon, jo si agjent për çdo përdorues, sepse riparimi i rrugëve i përket makinës. bootstrap zëvendëson formën më të vjetër load -w në versionet aktuale. RunAtLoad e bën ekzekutimin e parë të vëzhgueshëm, dhe ThrottleInterval ndalon një valë ndryshimesh lidhjeje Wi-Fi të nisë skriptin vazhdimisht.

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

Kurthi është se dosja e vëzhguar ndryshon edhe për ngjarje pa asnjë lidhje me VPN-në tënde: një lidhje Wi-Fi, një rinovim DHCP, një kabllo e futur. Roja më poshtë e kthen një shkas të zhurmshëm në një grep të përdorshëm, dhe një rresht log shpjegon një rrugë në një orë të çuditshme.

Pronësia mbulon plist-in njësoj si skriptin. Një daemon që ekzekuton një skedar në një dosje ku llogaria jote mund të shkruajë i jep asaj llogarie root.

Mbroje skriptin që një ekzekutim i dytë të mos ndryshojë asgjë

Skripti së pari vendos nëse tuneli ekziston, dhe del në heshtje kur nuk ekziston. Çdo gjë pas kësaj duhet të jetë e sigurt për t’u përsëritur, sepse shkasja aktivizohet shumë më shpesh sesa një lidhje e vetme. Zgjidhe ndërfaqen në kohë ekzekutimi në vend që të kodosh fort një indeks që ndryshon në lidhjen tjetër.

#!/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 del me status jo zero kur rruga ekziston tashmë, prandaj një skript që trajton çdo status jo zero si dështim raporton një grep të thyer sa herë që bën gjënë e duhur. Testi me netstat më sipër e kthen atë rast në një no-op të qartë.

Prania e ndërfaqes është provë më e dobët sesa duket, sepse klientë të tjerë VPN dhe disa mjedise kontejnerësh krijojnë gjithashtu pajisje utun. Pyet vetë shërbimin me scutil --nc status "Office VPN" dhe kërko gjendjen e lidhur përpara se të prekësh rrugëzimin. Mbaje përgjigjen në një rresht log, sepse një javë më vonë ai regjistrim do të jetë shpjegimi i vetëm që do të kesh.

Kthe portalin pa prishur DNS

Kur tuneli merr rrugën e parazgjedhur, shfletimi i zakonshëm del përmes zyrës dhe rruga lokale e internetit ndalon së funksionuari. Kapni së pari routerin e ndërfaqes fizike, pastaj kthejeni të parazgjedhurën drejt tij. DHCP e mund analizimin e një tabele që tashmë mban të parazgjedhurën e vetë tunelit.

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

Zgjidhësit janë një shtresë e veçantë me një mjet të veçantë, dhe riparimi i rrugës nuk i riparon ata. Shiko me scutil --dns çfarë është në fuqi, pastaj rregullo atë që e prodhon: renditja e shërbimeve dhe hyrjet DNS në shërbimin fizik. Zbrazja e cache-it diagnostikon një kërkim të bllokuar pas një ndryshimi rrjeti; nuk është diçka për t’u planifikuar.

Një tunel që i mbijeton një ndryshimi Wi-Fi ndërsa DNS ngec është defekti i tretë: sudo killall -HUP mDNSResponder e detyron zgjidhësin të rilexojë konfigurimin e tij. Përdore një herë, me dorë.

Provo se puna aktivizohet vetë

Detyro një ekzekutim me kickstart -k përpara se t’i besosh rrugës së mbikëqyrjes, pastaj lexo statusin e daljes që regjistroi puna. Një dalje e pastër provon se skripti funksionon; nuk provon se shkasja funksionon. Pastaj shkëput dhe rilidh me punën e ngarkuar, dhe vëzhgo një ekzekutim që nuk e kërkove.

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

Kontrollo scutil --nc status përpara dhe pas çdo përpjekjeje. Një skript që ekzekutohej sa kohë tuneli ishte poshtë nuk provon asgjë për rrugën e lidhjes.

Dega e çmontimit meriton të njëjtin trajtim si dega e lidhjes: hiq rrugën me dorë, lëre punën të ekzekutohet, dhe konfirmo se kthehet. Një grep që shton një rrugë dhe nuk e heq kurrë lë një makinë që sillet keq një javë më vonë, pa asgjë që lidh dy ngjarjet. Kur të dyja sjelljet qëndrojnë, sudo launchctl bootout system/net.example.tunnel-watch e tërheq punën pastër. Një daemon mbikëqyrjeje i lënë i ngarkuar është mënyra se si një riparim njëherësh bëhet një rrugë e pashpjeguar muaj më vonë.