Mac VPN ulangan, lekin ip-up hech qachon ishga tushmadi: launchd kuzatuvini o‘rnating

/etc/ppp/ip-up ichiga route buyrug’ini qo’yasiz, ofis tunneliga qayta ulanadi va fayl hech qachon ishlamaydi. Skriptda hech qanday xato yo’q: bu ulanish PPP orqali umuman o’tmaydi. O’rnatilgan Cisco IPSec va IKEv2 mijozlari hech qachon pppd ni ishga tushirmaydi, shuning uchun hook jildi hech qachon o’qilmaydi, holbuki PPTP va IPSec ustidagi L2TP hali ham undan o’tadi. Qaysi holat sizda ekanini aniqlang, so’ngra PPP bo’lmagan holatni launchd kuzatuv ishidan ishga tushiring.

Har qanday hookni tahrirlashdan oldin interfeysni tekshiring

Ikki buyruq qaysi mexanizm ishlashi mumkinligini hal qiladi. Sozlangan xizmatlarni sanab chiqing, so’ngra tunnel yoqilganda mavjud bo’lgan interfeyslarni sanang. Interfeys nomi dalil; System Settings dagi yorliq emas.

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

ppp0 hosil qiluvchi xizmat PPP hooklarini ishga tushiradi va faylingizni bajaradi. Cisco IPSec yoki IKEv2 xizmati buning o’rniga utun qurilmasini hosil qiladi, PPP qatlamisiz tunnel interfeysi, shuning uchun /etc/ppp ichidagi hech narsa unga yetib bora olmaydi. Ikkala tur ham ko’rinsa, qaysi xizmatga ulanganingizni tekshiring. Odamlar mijoz nomini o’qib noto’g’ri hookda tushlikdan keyingi vaqtni yo’qotadi.

PPP yo’lida fayl rootga tegishli va bajariladigan bo’lishi kerak, chunki pppd biror narsani ishga tushirishdan oldin ikkalasini ham tekshiradi. install egasi va rejimni bir qadamda belgilaydi.

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

Finder yoki grafik muharrir orqali yaratilgan fayl ko’pincha hisobingizga tegishli bo’lib qoladi yoki bajarish biti bo’lmaydi, so’ngra yo’qolgan hook kabi jim muvaffaqiyatsiz bo’ladi. Hozir uning yoniga ip-down qo’ying. Egasi ustunida root va wheel, rejim ustunida rwxr-xr-x — bu siz xohlagan narsa.

Tunnel paydo bo’lganda launchd skriptni ishga tushirsin

PPP ga hech qachon tegmaydigan mijozlar uchun trigger boshqa joydan kelishi kerak va tizim konfiguratsiyasi ombori halol manbadir: macOS uni har bir tunnel o’tishida qayta yozadi. O’sha jildni kuzatuvchi launchd ishi tunnel paydo bo’lganda yoki yo’qolganda chaqiriladi.

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

Uni launch daemon sifatida o’rnating, har bir foydalanuvchi uchun agent sifatida emas, chunki marshrutlarni tuzatish mashinaga tegishli. bootstrap joriy versiyalarda eski load -w shaklini almashtiradi. RunAtLoad birinchi bajarilishni kuzatiladigan qiladi, ThrottleInterval esa Wi-Fi ulanish o’zgarishlari oqimining skriptni qayta-qayta ishga tushirishini to’xtatadi.

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

Tuzoq shundaki, kuzatilayotgan jild VPN ingizga aloqasi bo’lmagan hodisalarda ham o’zgaradi: Wi-Fi ulanishi, DHCP yangilanishi, kabel ulanishi. Quyidagi qo’riqchi shovqinli triggerni foydali hookga aylantiradi va log satri g’alati soatdagi marshrutni tushuntiradi.

Egalik skript bilan birga plist ni ham qamrab oladi. O’z hisobingiz yozishi mumkin bo’lgan jilddagi faylni bajaradigan daemon o’sha hisobga root beradi.

Skriptni himoyalang, ikkinchi ishga tushirish hech narsani o’zgartirmasin

Skript avval tunnel bor-yo’qligini hal qiladi va yo’q bo’lsa jim chiqadi. Undan keyingi hamma narsa takrorlash uchun xavfsiz bo’lishi kerak, chunki trigger bitta ulanishdan ancha tez-tez ishga tushadi. Keyingi ulanishda o’zgaradigan indeksni qattiq kodlash o’rniga interfeysni ishlash vaqtida aniqlang.

#!/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 marshrut allaqachon bo’lsa, noldan farqli status bilan chiqadi, shuning uchun har bir noldan farqli statusni xato deb hisoblaydigan skript to’g’ri ish qilganda ham har safar buzilgan hook haqida xabar beradi. Yuqoridagi netstat sinovi bu holatni aniq no-op ga aylantiradi.

Interfeysning mavjudligi ko’rinadiganidan zaifroq dalil, chunki boshqa VPN mijozlari va ayrim konteyner muhitlari ham utun qurilmalarini yaratadi. scutil --nc status "Office VPN" bilan xizmatning o’zidan so’rang va marshrutlashga tegishdan oldin ulangan holatni talab qiling. Javobni log satrida saqlang, chunki bir haftadan keyin o’sha yozuv sizdagi yagona tushuntirish bo’ladi.

DNS ni buzmasdan shlyuzni qaytaring

Tunnel standart marshrutni egallaganda oddiy ko’rish ofis orqali chiqadi va mahalliy internet yo’li ishlamay qoladi. Avval jismoniy interfeys routerini ushlang, so’ngra standartni yana unga yo’naltiring. DHCP tunnelning o’z standartini allaqachon saqlagan jadvalni tahlil qilishdan yaxshiroq.

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

Resolverlar alohida asbobli alohida qatlam va marshrutni tuzatish ularni tuzatmaydi. scutil --dns bilan nima kuchda ekanini ko’ring, so’ngra uni hosil qiladigan narsani tuzating: xizmatlar tartibi va jismoniy xizmatdagi DNS yozuvlari. Keshni tozalash tarmoq almashgandan keyin tiqilib qolgan qidiruvni diagnostika qiladi; bu rejalashtiriladigan narsa emas.

Wi-Fi o’zgarishidan omon o’tib, lekin DNS da to’xtab qolgan tunnel uchinchi nuqson: sudo killall -HUP mDNSResponder resolverni konfiguratsiyasini qayta o’qishga majbur qiladi. Uni bir marta, qo’lda ishlating.

Ish o’zi ishga tushishini isbotlang

Kuzatuv yo’liga ishonishdan oldin kickstart -k bilan bitta ishga tushirishni majburan bajaring, so’ngra ish yozib olgan chiqish statusini o’qing. Toza chiqish skript ishlashini isbotlaydi; trigger ishlashini isbotlamaydi. So’ngra ish yuklangan holda uzib qayta ulaning va siz so’ramagan ishga tushishni kuzating.

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

Har bir urinishdan oldin va keyin scutil --nc status ni tekshiring. Tunnel o’chib turganda ishlagan skript ulanish yo’li haqida hech narsani isbotlamaydi.

Yechish tarmog’i ulash tarmog’i kabi e’tiborga loyiq: marshrutni qo’lda olib tashlang, ish ishlashiga yo’l qo’ying va u qaytishini tasdiqlang. Marshrut qo’shib, uni hech qachon olib tashlamaydigan hook bir haftadan keyin noto’g’ri ishlaydigan mashinani qoldiradi va ikki hodisani hech narsa bog’lamaydi. Ikkala xatti-harakat ham saqlansa, sudo launchctl bootout system/net.example.tunnel-watch ishni toza tarzda nafaqaga chiqaradi. Yuklangan holda qoldirilgan kuzatuv daemoni bir martalik tuzatishning oylar o’tib tushuntirilmagan marshrutga aylanish yo’lidir.