Mac VPN qoşulub, amma ip-up heç vaxt işləmədi: launchd nəzarəti qurun
Cisco IPSec və IKEv2 tunelləri heç vaxt pppd başlatmır, ona görə /etc/ppp/ip-up səssiz qalır. Konfiqurasiya qovluğunu izləyin və skriptin tuneli sübut etməsinə şərait yaradın.
/etc/ppp/ip-up faylına route əmri yazırsınız, ofis tunelinə yenidən qoşulursunuz, amma fayl heç vaxt işləmir. Skriptdə heç bir qüsur yoxdur: həmin bağlantı ümumiyyətlə PPP-dən keçmir. Daxili Cisco IPSec və IKEv2 müştəriləri heç vaxt pppd başlatmır, ona görə qarmaq qovluğu heç vaxt oxunmur, halbuki PPTP və IPSec üzərindən L2TP hələ də ondan keçir. Hansı halın sizdə olduğunu müəyyənləşdirin, sonra PPP olmayan halı launchd nəzarət işindən tetikləyin.
Hər hansı qarmağı redaktə etməzdən əvvəl interfeysi yoxlayın
İki əmr hansı mexanizmin işləyə biləcəyini həll edir. Konfiqurasiya edilmiş xidmətləri sadalayın, sonra tunel aktivkən mövcud olan interfeysləri sadalayın. Interfeys adı sübutdur; Sistem Parametrlərindəki etiket deyil.
scutil --nc list
ifconfig -l | tr ' ' '\n' | grep -E '^(utun|ppp)[0-9]+$'
ppp0 yaradan xidmət PPP qarmaqlarını işlədir və faylınızı icra edəcək. Cisco IPSec və ya IKEv2 xidməti isə utun cihazı yaradır, PPP qatı olmayan tunel interfeysi, ona görə /etc/ppp daxilində heç nə ona çata bilməz. Hər iki növ görünəndə hansı xidmətə qoşulduğunuzu yoxlayın. İnsanlar müştəri adını oxuyaraq səhv qarmaqda bir günortadan sonra vaxt itirir.
PPP yolunda fayl root-a aid olmalı və icra oluna bilməlidir, çünki pppd nəyisə işə salmazdan əvvəl hər ikisini yoxlayır. install sahibi və rejimi bir addımda qurur.
sudo install -o root -g wheel -m 0755 /dev/null /etc/ppp/ip-up
sudo ls -l /etc/ppp/ip-up
Finder və ya qrafik redaktorla yaradılan fayl çox vaxt hesabınıza aid olur, ya da icra biti olmur, sonra itkin qarmaq kimi səssizcə uğursuz olur. İndi ip-down faylını yanına qoyun. Sahib sütununda root və wheel, rejim sütununda isə rwxr-xr-x istədiyiniz nəticədir.
Tunel görünəndə skripti launchd işə salsın
PPP-yə heç toxunmayan müştərilər üçün tetik başqa yerdən gəlməlidir və sistem konfiqurasiya anbarı dürüst mənbədir: macOS onu hər tunel keçidində yenidən yazır. Həmin qovluğu izləyən launchd işi tunel görünəndə və ya yox olanda çağırılır.
<?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>
Onu hər istifadəçi üçün agent kimi deyil, launch daemon kimi quraşdırın, çünki marşrut bərpası maşına aiddir. bootstrap cari buraxılışlarda köhnə load -w formasını əvəz edir. RunAtLoad ilk icranı müşahidə olunan edir, ThrottleInterval isə Wi-Fi qoşulmaları selinin skripti təkrar-təkrar başlatmasının qarşısını alır.
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
Tələ buradadır ki, izlənən qovluq VPN-inizlə heç əlaqəsi olmayan hadisələrdə də dəyişir: Wi-Fi qoşulması, DHCP yenilənməsi, kabelin qoşulması. Aşağıdakı keşikçi səs-küylü tetiki işlək qarmağa çevirir və bir log sətri qəribə saatda yaranan marşrutu izah edir.
Sahiblik skriptlə yanaşı plist faylını da əhatə edir. Öz hesabınızın yaza bildiyi qovluqdakı faylı icra edən daemon həmin hesaba root verir.
Skripti elə qoruyun ki, ikinci işə salma heç nəyi dəyişməsin
Skript əvvəlcə tunelin mövcud olub-olmadığını qərarlaşdırır və olmadıqda səssizcə çıxır. Bundan sonra hər şey təkrarlana bilən olmalıdır, çünki tetik bir bağlantıdan qat-qat tez-tez işə düşür. İnterfeysi növbəti qoşulmada dəyişən indeksi sərt kodlaşdırmaq əvəzinə işləmə vaxtında təyin edin.
#!/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 marşrut artıq mövcud olduqda sıfırdan fərqli statusla çıxır, ona görə hər sıfırdan fərqli statusu uğursuzluq sayan skript düzgün iş gördüyü hər dəfə pozulmuş qarmaq bildirir. Yuxarıdakı netstat testi bu halı açıq no-op-a çevirir.
Interfeysin mövcudluğu göründüyündən zəif sübutdur, çünki başqa VPN müştəriləri və bəzi konteyner mühitləri də utun cihazları yaradır. Xidmətin özünə scutil --nc status "Office VPN" ilə sorğu verin və marşrutlaşdırmaya toxunmazdan əvvəl qoşulmuş vəziyyət tələb edin. Cavabı log sətrində saxlayın, çünki bir həftə sonra bu qeyd sizin yeganə izahınız olacaq.
DNS-i pozmadan şlüzü geri qaytarın
Tunel standart marşrutu ələ keçirdikdə adi gəzinti ofisdən çıxır və yerli internet yolu işləməyi dayandırır. Əvvəlcə fiziki interfeysin marşrutlaşdırıcısını tutun, sonra standart marşrutu yenidən ona yönəldin. DHCP, artıq tunelin öz standartını saxlayan cədvəli təhlil etməkdən üstündür.
PHYS=en0
GW=$(ipconfig getoption "$PHYS" router)
[ -n "$GW" ] && sudo route -n change default "$GW"
Həlledicilər ayrı alətə malik ayrı qatdır və marşrutu təmir etmək onları təmir etmir. scutil --dns ilə nəyin qüvvədə olduğuna baxın, sonra onu doğuran şeyi düzəldin: xidmət sırası və fiziki xidmətdəki DNS qeydləri. Keşi təmizləmək şəbəkə dəyişikliyindən sonra ilişib qalmış axtarışı diaqnoz edir; plana salınacaq bir şey deyil.
Wi-Fi dəyişikliyindən sağ çıxan, lakin DNS-in donduğu tunel üçüncü qüsurdur: sudo killall -HUP mDNSResponder həlledicinin konfiqurasiyasını yenidən oxumasına səbəb olur. Onu bir dəfə, əl ilə istifadə edin.
İşin öz-özünə işə düşdüyünü sübut edin
Nəzarət yoluna güvənməzdən əvvəl kickstart -k ilə bir işə salma məcbur edin, sonra işin qeyd etdiyi çıxış statusunu oxuyun. Təmiz çıxış skriptin işlədiyini sübut edir; tetikin işlədiyini sübut etmir. Sonra iş yüklü halda əlaqəni kəsin və yenidən qoşulun, istəmədiyiniz bir işə salmanı gözləyin.
sudo launchctl kickstart -k system/net.example.tunnel-watch
sudo launchctl print system/net.example.tunnel-watch | grep -E 'last exit code|state ='
Hər cəhddən əvvəl və sonra scutil --nc status yoxlayın. Tunel söndüyü halda işləyən skript qoşulma yolu haqqında heç nə sübut etmir.
Sökmə budağı da qoşulma budağı kimi eyni rəftara layiqdir: marşrutu əl ilə silin, işin işləməsinə imkan verin və geri qayıtdığını təsdiqləyin. Marşrut əlavə edib onu heç vaxt silməyən qarmaq bir həftə sonra səhv davranan, iki hadisəni heç nəyin bağlamadığı bir maşın qoyub gedir. Hər iki davranış saxlananda sudo launchctl bootout system/net.example.tunnel-watch işi təmiz şəkildə təqaüdə çıxarır. Yüklü saxlanan nəzarət daemonu bir dəfəlik təmirin aylar sonra izahsız marşruta çevrilmə yoludur.