Mac VPN കണക്ട് ചെയ്തു പക്ഷേ ip-up ഒരിക്കലും പ്രവർത്തിച്ചില്ല: launchd നിരീക്ഷണം നടത്തുക

നിങ്ങൾ /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 ജോലിയെ വൃത്തിയായി വിരമിക്കുന്നു. ലോഡ് ചെയ്ത് വിട്ട ഒരു നിരീക്ഷണ ഡീമോണാണ് ഒരു തവണത്തെ അറ്റകുറ്റപ്പണി മാസങ്ങൾക്കുശേഷം വിശദീകരിക്കാനാവാത്ത റൂട്ട് ആകുന്ന വഴി.