Mac VPN ಗಾಗಿ ಶಾಶ್ವತ ರೂಟ್ಗಳು: networksetup ಅಥವಾ ಸಂಪರ್ಕ ಹುಕ್?

ಪ್ರತಿ ಸಂಪರ್ಕದ ನಂತರ ಟೈಪ್ ಮಾಡುವ ರೂಟ್ ಕ್ಷಣವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ವಾರವನ್ನಲ್ಲ. macOS ನಲ್ಲಿ, ಶಾಶ್ವತ ಆಯ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ VPN ಸೇವೆಯೊಂದಿಗೆ ಸಂಗ್ರಹವಾದ ಪ್ರಿಫಿಕ್ಸ್, ಏಕೆಂದರೆ ಸೇವೆ ಅದನ್ನು ಪ್ರತಿ ಸಂಪರ್ಕದಲ್ಲಿ ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ ಮತ್ತು ಸೇವೆ ನಿಂತಿರುವಾಗ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಪರ್ಯಾಯಗಳೆಂದರೆ ಪರೀಕ್ಷೆಗಾಗಿ ತಾತ್ಕಾಲಿಕ route add ಮತ್ತು ಮಾತುಕತೆಯ ನಂತರ ಮಾತ್ರ ತಿಳಿಯುವ ವಿಳಾಸಗಳಿಗೆ ಸಂಪರ್ಕ ಹುಕ್.

ರೂಟ್ ಸೇವೆಯದ್ದೇ ಅಥವಾ ಅಧಿವೇಶನದ್ದೇ ಎಂದು ನಿರ್ಧರಿಸಿ

ಪ್ರಿಫಿಕ್ಸ್ ಯಾವುದನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂದು ಕೇಳಿ. ಅದು ಸ್ಥಳೀಯ VPN ಸೇವೆಯ ಹಿಂದಿನ ಸ್ಥಿರ ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ ಆಗಿದ್ದರೆ, ರೂಟ್ ಆ ಸೇವೆಯದ್ದು. ಅದು ಪ್ರತಿ ಸಂಪರ್ಕದಲ್ಲಿ ಬದಲಾಗುವ ಪೀರ್ ವಿಳಾಸವನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಹುಕ್ ಅಥವಾ ಸ್ಥಿತಿ-ಚಾಲಿತ ಕೆಲಸ ಉತ್ತಮ ಮಾಲೀಕರಾಗಬಹುದು. ನೀವು ಮುಂದಿನ ಐದು ನಿಮಿಷಗಳಿಗೆ ಮಾರ್ಗವನ್ನು ಮಾತ್ರ ಪರಿಶೀಲಿಸುತ್ತಿದ್ದರೆ, ತಾತ್ಕಾಲಿಕ ರೂಟ್ ಸಾಕು.

ಸೇವೆಗೆ ಬದ್ಧವಾದ ರೂಟ್ ಅತ್ಯಂತ ಸ್ವಚ್ಛ ಜೀವನಚಕ್ರವನ್ನು ಹೊಂದಿದೆ. ಅದು ಸೇವೆಯೊಂದಿಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಸೇವೆ ಸಂಪರ್ಕಗೊಂಡಿಲ್ಲದಿದ್ದಾಗ ಮಾಯವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಸೂಚಿಸುವ ಸುರಂಗಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕಲಾರದು. ಆ ಗುಣ ಒಂದು ಸಾಲಿನ ಆದೇಶದ ಅನುಕೂಲಕ್ಕಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯದ್ದು.

ಅಧಿವೇಶನಕ್ಕೆ ಬದ್ಧವಾದ ರೂಟ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಸೇರಿದ್ದು, ಮತ್ತು ಆ ಸಂಖ್ಯೆ ಸೂಚನೆ ಇಲ್ಲದೆ ಬದಲಾಗುತ್ತದೆ. ಮರುಸಂಪರ್ಕವು ಸುರಂಗಕ್ಕೆ ಹಿಂದಿನ ಅಧಿವೇಶನ ಬಳಸಿದ್ದಕ್ಕಿಂತ ಬೇರೆ utun ಹೆಸರನ್ನು ನೀಡಬಹುದು, ಇದು ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಿದ ಆದೇಶವನ್ನು ಏನನ್ನೂ ಸೂಚಿಸದ ಅಥವಾ, ಹೆಚ್ಚು ಕೆಟ್ಟದಾಗಿ, ಬೇರೆ ಸುರಂಗವನ್ನು ಸೂಚಿಸುವ ರೂಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ಪ್ರಸ್ತುತ ರೂಟ್ ಮತ್ತು ಸೇವಾ ಸ್ಥಿತಿಯನ್ನು ಓದಿ

ಸಿಸ್ಟಂ ನಿಜವಾಗಿ ಬಳಸುವ ಹೆಸರುಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ. ನೆಟ್ವರ್ಕ್ ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲಿನ ಸೇವಾ ಹೆಸರು ಕೆಳಗಿನ ಆದೇಶಗಳಿಗೆ ಗುರುತಿಸುವಿಕೆಯಾಗಿದೆ, ಮತ್ತು ಪ್ರಸ್ತುತ ರೂಟ್ ಕೋಷ್ಟಕವು ಸಂಪರ್ಕಗೊಂಡ ಕ್ಲೈಂಟ್ ಏನನ್ನು ಸ್ಥಾಪಿಸಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಸುರಂಗ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಎರಡನ್ನೂ ಓದಿ.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

ಆ ಹುಡುಕಾಟವು ಈ ಕ್ಷಣದಲ್ಲಿ ಈ ವಿಳಾಸಕ್ಕೆ ಕರ್ನಲ್ ಯಾವ ಗೇಟ್ವೇ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಅದು ಈಗಾಗಲೇ ಸುರಂಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದರೆ, ಪ್ರಿಫಿಕ್ಸ್ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಹೊಸ ರೂಟ್ ಅನಗತ್ಯವಾಗುತ್ತದೆ. ಅದು ಸ್ಥಳೀಯ ರೌಟರ್ ಆಯ್ಕೆ ಮಾಡಿದ್ದರೆ, ಸುರಂಗದಲ್ಲಿ ಆ ಪ್ರಿಫಿಕ್ಸ್ ಇಲ್ಲ.

ಸಂಪರ್ಕಗೊಂಡಿರುವಾಗ ಪೀರ್ ವಿಳಾಸವನ್ನು ಗಮನಿಸಿ. ಅದು ಸೇವೆಗೆ ಬದ್ಧವಾದ ರೂಟ್ನಲ್ಲಿ ಗೇಟ್ವೇ ಮೌಲ್ಯವಾಗುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ netstat -rn ನಲ್ಲಿ ಸುರಂಗದ ಡೀಫಾಲ್ಟ್ ರೂಟ್ಗೆ ತೋರಿಸುವ ಗಮ್ಯಸ್ಥಾನ ಅದೇ ಆಗಿದೆ.

networksetup ನೊಂದಿಗೆ ಪ್ರಿಫಿಕ್ಸ್ ಸಂಗ್ರಹಿಸಿ

networksetup ಪರಿಕರವು ನೆಟ್ವರ್ಕ್ ಸೇವೆಗೆ ಹೆಚ್ಚುವರಿ ರೂಟ್ಗಳನ್ನು ಜೋಡಿಸುತ್ತದೆ. OfficeVPN ಎಂಬ ಸೇವೆ ಮತ್ತು ಸುರಂಗದ ಪೀರ್ ಮೂಲಕ ತಲುಪುವ ಖಾಸಗಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ, ರೂಪ ಹೀಗಿದೆ:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

ಸೇವಾ ಹೆಸರಿನ ನಂತರದ ಪ್ರತಿ ತ್ರಿಕವು ಗಮ್ಯಸ್ಥಾನ, ಅದರ ನೆಟ್ಮಾಸ್ಕ್ ಮತ್ತು ಗೇಟ್ವೇ ಆಗಿ ಸುರಂಗದ ಪೀರ್ ನೀಡುತ್ತದೆ. ಒಂದು ಕರೆ ಹಲವು ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಹೊತ್ತೊಯ್ಯಬಹುದು, ಮತ್ತು ಖಾಲಿ ಕರೆ ಸಂಗ್ರಹಿತ ಪಟ್ಟಿಯನ್ನು ಅಳಿಸುತ್ತದೆ. ಓದುಗ ನಿಜೀಕರಣದ ಹಂತ; ಪಟ್ಟಿ ಖಾಲಿಯಿದ್ದರೆ, ಸೆಟ್ ನೀವು ಯೋಚಿಸುವ ಸೇವೆಗೆ ಅನ್ವಯವಾಗಿಲ್ಲ.

ಗೇಟ್ವೇ ಸುರಂಗದ ಪೀರ್ ಆಗಿರಬೇಕು, ಭೌತಿಕ ರೌಟರ್ ಅಲ್ಲ. ಸ್ಥಳೀಯ ಗೇಟ್ವೇಯನ್ನು ಹೆಸರಿಸುವ ರೂಟ್ ಖಾಸಗಿ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಇದು ಹೆಚ್ಚುವರಿ ಹಂತಗಳೊಂದಿಗಿನ ಮೂಲ ವೈಫಲ್ಯ. ಹಳೆಯ ಪೀರ್ ಸರಿಯಾಗಿ ಕಾಣುವ ರೂಟ್ ಎಂದಿಗೂ ಸಂಚಾರವನ್ನು ಸಾಗಿಸದಿರುವುದಕ್ಕೆ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಕಾರಣ. ಹಳೆಯ ಟಿಪ್ಪಣಿಯಿಂದ ವಿಳಾಸವನ್ನು ನಕಲಿಸುವ ಬದಲು ಸಂಪರ್ಕಿತ ಸ್ಥಿತಿಯಿಂದ ಪೀರ್ ಅನ್ನು ಮತ್ತೆ ಓದಿ.

route add ಅನ್ನು ಪರೀಕ್ಷೆಗೆ ಮಾತ್ರ ಬಳಸಿ

ನೇರ ರೂಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಶಾಶ್ವತ ಮಾಡುವ ಮೊದಲು ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಉಪಯುಕ್ತ. ಇಂಟರ್ಫೇಸ್ ರೂಪ ಗೇಟ್ವೇ ಹುಡುಕಾಟವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ:

sudo route -n add -net 10.20.0.0/16 -interface utun4

ರೂಟ್ ಮುಂದಿನ ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ ಮತ್ತು ಇಂದು ಇರುವ ಇಂಟರ್ಫೇಸ್ ಸಂಖ್ಯೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ. ಅದು ಅದನ್ನು ರೋಗನಿರ್ಣಯ ಮಾಡುತ್ತದೆ, ನಿಯೋಜನೆ ಅಲ್ಲ. ಪರೀಕ್ಷೆ ಕೆಲಸ ಮಾಡಿ ಸೇವೆಗೆ ಬದ್ಧವಾದ ರೂಟ್ ಮಾಡದಿದ್ದರೆ, ಮೊದಲು ಗೇಟ್ವೇ ಮೌಲ್ಯವನ್ನು ಹೋಲಿಸಿ; ಅದೇ ಹೆಚ್ಚಾಗಿ ತಪ್ಪಾಗಿರುವ ಕ್ಷೇತ್ರ.

ಸ್ಪ್ಲಿಟ್ ವರ್ತನೆಯನ್ನು ಒತ್ತಾಯಿಸಲು VPN ನ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ಬದಲಿಸುವ ಸಲಹೆಗಳಿಂದ ಜಾಗ್ರತೆ ವಹಿಸಿ. ಪೂರ್ಣ ಸುರಂಗವನ್ನು ಜಾರಿಗೊಳಿಸುವ ಕ್ಲೈಂಟ್ ಮರುಸಂಪರ್ಕ ಅಥವಾ ನೀತಿ ರಿಫ್ರೆಶ್ ನಂತರ ತನ್ನ ರೂಟ್ಗಳನ್ನು ಮತ್ತೆ ಸ್ಥಾಪಿಸಬಹುದು, ಆದ್ದರಿಂದ ಕೈಯಿಂದ ಮಾಡಿದ ಬದಲಾವಣೆ ಸದ್ದಿಲ್ಲದೆ ರದ್ದಾಗುತ್ತದೆ. ಕೆಲವು ಖಾಸಗಿ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ರೂಟಿಂಗ್ ಸಮಸ್ಯೆ; ಪೂರ್ಣ-ಸುರಂಗ ನೀತಿಯ ವಿರುದ್ಧ ಎಲ್ಲಾ ಇಂಟರ್ನೆಟ್ ಸಂಚಾರವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಇಡುವುದು ಸರ್ವರ್-ಬದಿಯ ನಿರ್ಧಾರ.

ವಿಳಾಸ ಮಾತುಕತೆಯಾದಾಗ ಮಾತ್ರ ಹುಕ್ ಆಯ್ಕೆ ಮಾಡಿ

PPP-ಆಧಾರಿತ ಲಿಂಕ್ಗಳಿಗೆ, ಉದಾಹರಣೆಗೆ L2TP, macOS ಲಿಂಕ್ ಸ್ಥಾಪಿತವಾದ ನಂತರ /etc/ppp/ip-up ಚಲಾಯಿಸುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್ ಇಂಟರ್ಫೇಸ್ ಹೆಸರು ಮತ್ತು ಮಾತುಕತೆಯಾದ ಸ್ಥಳೀಯ ಹಾಗೂ ದೂರದ ವಿಳಾಸಗಳನ್ನು ಪಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ ನಿಗದಿಪಡಿಸಿದ ಪೀರ್ ಅನ್ನು ಅವಲಂಬಿಸಿದ ರೂಟ್ ಸೇರಿಸಬಹುದು. ಸ್ಥಿರ ಸೇವಾ ರೂಟ್ ವ್ಯಕ್ತಪಡಿಸಲಾಗದ ಸಂದರ್ಭ ಅದೇ ಆಗಿದೆ.

IKEv2 ಮತ್ತು ತಯಾರಕರ ಕ್ಲೈಂಟ್ಗಳು ಆ PPP ಮಾರ್ಗವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸದೇ ಇರಬಹುದು, ಅಂದರೆ ಸ್ಕ್ರಿಪ್ಟ್ ಇಡೀ ಅಧಿವೇಶನದಲ್ಲಿ ಮೌನವಾಗಿರಬಹುದು. ಹಾಗಾದಾಗ, scutil --nc status ಅನ್ನು ವಿಚಾರಿಸಿ ಸ್ಥಿತಿ ಬದಲಾವಣೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ launchd ಕೆಲಸವು ಸಮಾನವಾದ ಕಾರ್ಯವಿಧಾನ, ಸ್ವಲ್ಪ ವಿಳಂಬದೊಂದಿಗೆ.

ನೀವು ಯಾವ ಹುಕ್ ಬಳಸಿದರೂ, ಅದನ್ನು ಐಡೆಂಪೊಟೆಂಟ್ ಮಾಡಿ ಮತ್ತು ಅದು ತಾನೇ ರಚಿಸಿದ ರೂಟ್ಗಳನ್ನು ಮಾತ್ರ ತೆಗೆದುಹಾಕುವಂತೆ ಮಾಡಿ. ಸುರಂಗವನ್ನು ಉಲ್ಲೇಖಿಸುವ ಪ್ರತಿ ರೂಟ್ ಅನ್ನು ಅಳಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಕೊನೆಗೆ VPN ಸರ್ವರ್ ಅನ್ನು ತಲುಪಬಹುದಾಗಿಸುವ ರೂಟ್ ಅನ್ನೂ ಅಳಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕ ಯಶಸ್ವಿಯಾದ ಕ್ಷಣವೇ ಕುಸಿಯುತ್ತದೆ.

ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನ, ಸಾಮಾನ್ಯ ಬ್ರೌಸಿಂಗ್ ಮತ್ತು ಮರುಸಂಪರ್ಕ ಅಥವಾ ನಿದ್ರೆ ಚಕ್ರವನ್ನು ಪರಿಶೀಲಿಸಿ ಮುಗಿಸಿ. ನಂತರ scutil --dns ಅನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಹೆಸರು ಪರಿಹಾರವು ಪ್ರತ್ಯೇಕ ನೀತಿ ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ರೂಟ್ ಖಾಸಗಿ ಹೆಸರುಗಳು ಪರಿಹರಿಸುತ್ತವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.