Mac VPN जोडले आहे पण ip-up कधीच चालला नाही: launchd देखरेख सुरू करा

Cisco IPSec आणि IKEv2 बोगदे कधीच pppd सुरू करत नाहीत, त्यामुळे /etc/ppp/ip-up शांत राहतो। कॉन्फिगरेशन डिरेक्टरीवर लक्ष ठेवा आणि स्क्रिप्टला बोगदा सिद्ध करू द्या।

तुम्ही /etc/ppp/ip-up मध्ये route आदेश ठेवता, ऑफिसचा बोगदा पुन्हा जोडता, आणि फाइल कधीच चालत नाही। स्क्रिप्टमध्ये काहीही चूक नाही: ते कनेक्शन PPP मधून मुळीच जात नाही। अंगभूत Cisco IPSec आणि IKEv2 क्लायंट कधीच pppd सुरू करत नाहीत, त्यामुळे हूक डिरेक्टरी कधीच वाचली जात नाही, तर PPTP आणि IPSec वरील L2TP अजूनही त्यातून जातात। तुमची कोणती स्थिती आहे ते ठरवा, मग PPP नसलेली स्थिती launchd देखरेख कामातून सुरू करा।

कोणताही हूक संपादित करण्यापूर्वी इंटरफेस तपासा

दोन आदेश कोणती पद्धत काम करू शकते हे ठरवतात। कॉन्फिगर केलेल्या सेवा सूचीबद्ध करा, मग बोगदा सुरू असताना असलेले इंटरफेस सूचीबद्ध करा। इंटरफेसचे नाव हाच पुरावा; System Settings मधील लेबल नाही।

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

ppp0 तयार करणारी सेवा PPP हूक चालवते आणि तुमची फाइल चालवेल। Cisco IPSec किंवा IKEv2 सेवा त्याऐवजी utun उपकरण तयार करते, PPP स्तर नसलेला बोगदा इंटरफेस, त्यामुळे /etc/ppp मधील काहीही त्याला पोहोचू शकत नाही। दोन्ही प्रकार दिसल्यास, तुम्ही कोणत्या सेवेशी जोडले गेले आहात ते तपासा। लोक क्लायंटचे नाव वाचून चुकीच्या हूकवर दुपारचा वेळ वाया घालवतात।

PPP मार्गावर फाइल root च्या मालकीची आणि चालवण्यायोग्य असणे आवश्यक आहे, कारण pppd काहीही चालवण्यापूर्वी दोन्ही तपासते। install एकाच पायरीत मालक आणि मोड सेट करते।

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

Finder किंवा ग्राफिकल एडिटरद्वारे तयार केलेली फाइल बऱ्याचदा तुमच्या खात्याच्या मालकीची होते, किंवा तिला एक्झिक्युट बिट नसतो, आणि मग गहाळ हूकइतकीच शांतपणे अयशस्वी होते। आता तिच्या शेजारी ip-down ठेवा। मालक स्तंभात root आणि wheel तसेच मोड स्तंभात rwxr-xr-x हे तुम्हाला हवे आहे।

बोगदा दिसल्यावर launchd ला स्क्रिप्ट चालवू द्या

PPP ला कधीही स्पर्श न करणाऱ्या क्लायंटसाठी ट्रिगर इतरत्रून आला पाहिजे, आणि सिस्टम कॉन्फिगरेशन स्टोअर हा प्रामाणिक स्रोत आहे: macOS प्रत्येक बोगदा संक्रमणावर तो पुन्हा लिहितो। त्या डिरेक्टरीवर लक्ष ठेवणारे launchd काम बोगदा दिसल्यावर किंवा नाहीसा झाल्यावर बोलावले जाते।

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

ते launch daemon म्हणून स्थापित करा, प्रत्येक वापरकर्त्यासाठी एजंट म्हणून नाही, कारण मार्ग दुरुस्ती यंत्राची आहे। bootstrap सध्याच्या आवृत्त्यांमध्ये जुना load -w प्रकार बदलते। RunAtLoad पहिल्या अंमलबजावणीचे निरीक्षण करण्यायोग्य करते, आणि ThrottleInterval Wi-Fi जोडणीतील बदलांचा लोंढा स्क्रिप्ट वारंवार सुरू करण्यापासून थांबवते।

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

सापळा असा आहे की देखरेखीखालील डिरेक्टरी तुमच्या VPN शी संबंध नसलेल्या घटनांवरही बदलते: Wi-Fi जोडणी, DHCP नूतनीकरण, केबल लावणे। खालील रक्षक गोंगाट करणाऱ्या ट्रिगरचा उपयुक्त हूक बनवतो, आणि लॉगची एक ओळ विचित्र वेळेचा मार्ग स्पष्ट करते।

मालकी स्क्रिप्टबरोबरच plist लाही लागू होते। तुमचे स्वतःचे खाते जिथे लिहू शकते अशा डिरेक्टरीतील फाइल चालवणारा डीमन त्या खात्याला root देतो।

स्क्रिप्टचे रक्षण करा जेणेकरून दुसऱ्या वेळी काहीही बदलणार नाही

स्क्रिप्ट प्रथम बोगदा आहे का हे ठरवते, नसेल तर शांतपणे बाहेर पडते। त्यानंतरचे सर्व पुनरावृत्तीसाठी सुरक्षित असले पाहिजे, कारण ट्रिगर एका कनेक्शनपेक्षा खूप जास्त वेळा चालतो। पुढील कनेक्शनला बदलणारा निर्देशांक हार्डकोड करण्याऐवजी रनटाइमला इंटरफेस शोधा।

#!/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 मार्ग आधीच असल्यास शून्येतर स्थितीसह बाहेर पडते, त्यामुळे प्रत्येक शून्येतर स्थिती अपयश मानणारी स्क्रिप्ट योग्य गोष्ट करतानाही प्रत्येक वेळी तुटलेल्या हूकची तक्रार करते। वरील netstat चाचणी ती स्थिती स्पष्ट no-op मध्ये बदलते।

इंटरफेसची उपस्थिती दिसते त्यापेक्षा कमकुवत पुरावा आहे, कारण इतर VPN क्लायंट आणि काही कंटेनर वातावरणेही utun उपकरणे तयार करतात। scutil --nc status "Office VPN" ने सेवेलाच विचारा आणि राउटिंगला स्पर्श करण्यापूर्वी जोडलेली स्थिती आवश्यक धरा। उत्तर लॉगच्या एका ओळीत ठेवा, कारण आठवड्यानंतर तीच नोंद तुमच्याकडे एकमेव स्पष्टीकरण असेल।

DNS न तोडता गेटवे परत आणा

बोगदा डीफॉल्ट मार्ग ताब्यात घेतल्यावर सामान्य ब्राउझिंग ऑफिसमधून बाहेर जाते आणि स्थानिक इंटरनेट मार्ग काम करणे थांबवतो। प्रथम भौतिक इंटरफेसचा राउटर पकडा, मग डीफॉल्ट पुन्हा त्याच्याकडे वळवा। DHCP हा बोगद्याचा स्वतःचा डीफॉल्ट आधीच असलेल्या तक्त्याच्या विश्लेषणापेक्षा चांगला आहे।

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

रिझॉल्व्हर स्वतंत्र साधन असलेला स्वतंत्र स्तर आहे, आणि मार्ग दुरुस्त करणे त्यांना दुरुस्त करत नाही। scutil --dns ने काय लागू आहे ते पहा, मग ते तयार करणारे सुधारा: सेवांचा क्रम आणि भौतिक सेवेवरील DNS नोंदी। कॅशे रिकामी करणे नेटवर्क बदलानंतर अडकलेली शोध प्रक्रिया निदान करते; ते नियोजित करण्यासारखे नाही।

Wi-Fi बदल सहन करणारा पण DNS अडकणारा बोगदा हा तिसरा दोष आहे: sudo killall -HUP mDNSResponder रिझॉल्व्हरला त्याचे कॉन्फिगरेशन पुन्हा वाचण्यास भाग पाडते। ते एकदा, हाताने वापरा।

काम स्वतः चालते हे सिद्ध करा

देखरेख मार्गावर विश्वास ठेवण्यापूर्वी kickstart -k ने एक अंमलबजावणी सक्तीने करा, मग कामाने नोंदवलेली निर्गमन स्थिती वाचा। स्वच्छ निर्गमन स्क्रिप्ट चालते हे सिद्ध करते; ट्रिगर चालतो हे सिद्ध करत नाही। मग काम लोड असताना डिस्कनेक्ट करा आणि पुन्हा जोडा, आणि तुम्ही न मागितलेली अंमलबजावणी पहा।

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

प्रत्येक प्रयत्नापूर्वी आणि नंतर scutil --nc status तपासा। बोगदा बंद असताना चाललेली स्क्रिप्ट कनेक्शन मार्गाबद्दल काहीही सिद्ध करत नाही।

तोडण्याची शाखा जोडण्याच्या शाखेइतकीच काळजी हक्काची आहे: मार्ग हाताने काढा, काम चालू द्या, आणि तो परत येतो याची खात्री करा। मार्ग जोडणारा आणि कधीही न काढणारा हूक आठवड्यानंतर वाईट वागणारे यंत्र सोडतो, आणि दोन घटना जोडणारे काहीही नसते। दोन्ही वर्तन टिकल्यावर sudo launchctl bootout system/net.example.tunnel-watch काम स्वच्छपणे निवृत्त करते। लोड केलेले सोडलेला देखरेख डीमन हा एकदाची दुरुस्ती महिन्यांनंतर अस्पष्ट मार्ग होण्याचा मार्ग आहे।

संबंधित लेख