Mac VPN இணைக்கப்பட்டது ஆனால் ip-up ஒருபோதும் இயங்கவில்லை: ஒரு launchd கண்காணிப்பை இயக்குங்கள்

Cisco IPSec மற்றும் IKEv2 சுரங்கப்பாதைகள் pppd ஐ ஒருபோதும் தொடங்குவதில்லை, எனவே /etc/ppp/ip-up அமைதியாக உள்ளது. உள்ளமைவு கோப்பகத்தைக் கண்காணித்து ஸ்கிரிப்ட் சுரங்கப்பாதையை நிரூபிக்கச் செய்யுங்கள்.

நீங்கள் /etc/ppp/ip-up இல் route கட்டளையை வைத்து, அலுவலக சுரங்கப்பாதையை மீண்டும் இணைக்கிறீர்கள், ஆனால் கோப்பு ஒருபோதும் இயங்குவதில்லை. ஸ்கிரிப்டில் எந்த தவறும் இல்லை: அந்த இணைப்பு PPP வழியாகவே செல்லவில்லை. உள்ளமைந்த Cisco IPSec மற்றும் IKEv2 வாடிக்கையாளர்கள் pppd ஐ ஒருபோதும் தொடங்குவதில்லை, எனவே hook கோப்பகம் ஒருபோதும் படிக்கப்படுவதில்லை, அதே நேரத்தில் PPTP மற்றும் IPSec மேல் L2TP இன்னும் அதன் வழியாகச் செல்கின்றன. உங்களுக்கு எந்த நிலை என்று கண்டறிந்து, பின்னர் PPP அல்லாத நிலையை launchd கண்காணிப்பு பணியிலிருந்து இயக்குங்கள்.

எந்த hook ஐயும் திருத்தும் முன் இடைமுகத்தைச் சரிபார்க்கவும்

எந்த பொறிமுறை செயல்பட முடியும் என்பதை இரண்டு கட்டளைகள் தீர்மானிக்கின்றன. உள்ளமைக்கப்பட்ட சேவைகளைப் பட்டியலிட்டு, பின்னர் சுரங்கப்பாதை இயங்கும் போது உள்ள இடைமுகங்களைப் பட்டியலிடுங்கள். இடைமுகத்தின் பெயரே சான்று; System Settings இல் உள்ள லேபிள் அல்ல.

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

ppp0 ஐ உருவாக்கும் சேவை PPP hook களை இயக்கி உங்கள் கோப்பை இயக்கும். Cisco IPSec அல்லது IKEv2 சேவை அதற்குப் பதிலாக utun சாதனத்தை உருவாக்குகிறது, PPP அடுக்கு இல்லாத சுரங்கப்பாதை இடைமுகம், எனவே /etc/ppp இற்குள் எதுவும் அதை அடைய முடியாது. இரண்டு வகைகளும் தோன்றும்போது, எந்த சேவையுடன் இணைந்தீர்கள் என்று சரிபார்க்கவும். மக்கள் வாடிக்கையாளரின் பெயரைப் படித்து தவறான hook இல் மதியத்தை வீணாக்குகிறார்கள்.

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 அல்லது வரைகலை தொகுப்பான் மூலம் உருவாக்கப்பட்ட கோப்பு பெரும்பாலும் உங்கள் கணக்கின் உடைமையாக மாறுகிறது, அல்லது இயக்க பிட்டு இல்லாமல் போகிறது, பின்னர் காணாமல் போன hook போலவே அமைதியாக தோல்வியடைகிறது. இப்போது அதன் அருகில் 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 புதுப்பித்தல், கேபிள் செருகுதல். கீழே உள்ள காவலர் சத்தமான தூண்டியை பயனுள்ள hook ஆக மாற்றுகிறது, ஒரு பதிவு வரி விநோத நேரத்தின் பாதையை விளக்குகிறது.

உடைமை ஸ்கிரிப்டுடன் 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 பாதை ஏற்கனவே இருந்தால் பூஜ்ஜியமற்ற நிலையுடன் வெளியேறுகிறது, எனவே ஒவ்வொரு பூஜ்ஜியமற்ற நிலையையும் தோல்வியாகக் கருதும் ஸ்கிரிப்ட் சரியானதைச் செய்யும் ஒவ்வொரு முறையும் உடைந்த hook ஐப் புகாரளிக்கிறது. மேலே உள்ள 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 சரிபார்க்கவும். சுரங்கப்பாதை கீழே இருந்தபோது இயங்கிய ஸ்கிரிப்ட் இணைப்புப் பாதையைப் பற்றி எதையும் நிரூபிக்கவில்லை.

பிரிக்கும் கிளை இணைக்கும் கிளையின் அதே கவனிப்புக்குத் தகுதியானது: பாதையை கையால் நீக்கி, பணி இயங்கட்டும், அது திரும்பி வருவதை உறுதிப்படுத்துங்கள். பாதையைச் சேர்த்து ஒருபோதும் நீக்காத hook ஒரு வாரம் கழித்து மோசமாக நடந்துகொள்ளும் இயந்திரத்தை விட்டுச் செல்கிறது, இரண்டு நிகழ்வுகளையும் எதுவும் இணைக்கவில்லை. இரண்டு நடத்தைகளும் நிலைத்தால், sudo launchctl bootout system/net.example.tunnel-watch பணியை தூய்மையாக ஓய்வு பெறச் செய்கிறது. ஏற்றப்பட்ட நிலையில் விடப்பட்ட கண்காணிப்பு டேமன் ஒரு முறை பழுது பல மாதங்கள் கழித்து விளக்கமில்லாத பாதையாக மாறும் வழி.

தொடர்புடைய கட்டுரைகள்