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 ಕೆಲಸವನ್ನು ಸ್ವಚ್ಛವಾಗಿ ನಿವೃತ್ತಿಗೊಳಿಸುತ್ತದೆ. ಲೋಡ್ ಮಾಡಿ ಬಿಟ್ಟ ಕಣ್ಗಾವಲು ಡೀಮನ್ ಒಂದೇ ಬಾರಿಯ ದುರಸ್ತಿ ತಿಂಗಳುಗಳ ನಂತರ ವಿವರಿಸಲಾಗದ ಮಾರ್ಗವಾಗುವ ದಾರಿ.