Mac VPN ಮತ್ತು PAC ಪ್ರಾಕ್ಸಿ: ಎರಡು ನಿರ್ಧಾರಗಳು, ಒಂದೇ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ

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

PAC ವಿಳಾಸ ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಎಲ್ಲಿ ಭಿನ್ನವಾಗುತ್ತವೆ

https://config.corp.example/proxy.pac ನಂತಹ ವಿಳಾಸವು ಡೌನ್ಲೋಡ್ ಮಾಡಬೇಕಾದ ದಾಖಲೆಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ದಾಖಲೆಯು ಸಂಚಾರವನ್ನು ಕಳುಹಿಸಲು ಸರ್ವರ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. URL ಅನ್ನು ಪ್ರಾಕ್ಸಿ ಹೋಸ್ಟ್ ಕ್ಷೇತ್ರಕ್ಕೆ ಅಂಟಿಸುವುದು ಕ್ಲೈಂಟ್ಗೆ ಎಂದಿಗೂ ಅಂತಹ ಸಂಪರ್ಕವನ್ನು ಕೇಳದ ಫೈಲ್ ಸರ್ವರ್ಗೆ ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕ ತೆರೆಯಲು ಹೇಳುತ್ತದೆ. ಫೈಲ್ನ ಒಳಗೆ ಕ್ಲೈಂಟ್ ಪ್ರತಿ ವಿನಂತಿಗೆ ಕರೆಯುವ ಫಂಕ್ಷನ್ ಇದೆ, ಮತ್ತು ಅದರ ಮರಳಿಸುವ ಮೌಲ್ಯವು ಆ ಒಂದೇ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮುಂದಿನ ಹಾಪ್. ಈ ಪರೋಕ್ಷತೆಯು ಒಂದೇ ನೆಟ್ವರ್ಕ್ ಸೇವೆಯಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳು, ಎರಡರಲ್ಲೂ ಸರಿಯಾದ URL ಇದ್ದರೂ, ಏಕೆ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸಬಹುದು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿಯನ್ನು ಯಾರೂ ಮುಟ್ಟದೆಯೇ ನೀತಿ ಬದಲಾವಣೆ ಏಕೆ ಜಾರಿಗೆ ಬರುತ್ತದೆ ಎಂಬುದನ್ನೂ ಇದು ವಿವರಿಸುತ್ತದೆ.

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

ಸ್ಕ್ರಿಪ್ಟ್ ಏನನ್ನೂ ನಿರ್ಧರಿಸುವ ಮೊದಲು ಅದನ್ನು ತರಬೇಕು

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

ಕೆಳಗಿನ ಮೂರು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಚಲಾಯಿಸಿ ಮತ್ತು ಮೊದಲ ವೈಫಲ್ಯದಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಹಂತಗಳಿಗೆ ಒಂದೇ ಕಾರಣವಿಲ್ಲ. ಒಟ್ಟಾಗಿ ಅವು ನೀತಿ ಸಂರಚಿಸಲ್ಪಟ್ಟಿದೆಯೇ, ತಲುಪಬಹುದೇ ಮತ್ತು ಏನನ್ನು ಮರಳಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

ಮೊದಲ ಆಜ್ಞೆ ಸಕ್ರಿಯ ಸೇವೆಯ ಪ್ರಾಕ್ಸಿ ನಿಘಂಟನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಸಿಸ್ಟಮ್ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಯಾವುದೇ ಸ್ವಯಂ-ಸಂರಚನೆ URL ಸೇರಿದಂತೆ. ಎರಡನೆಯದು ಒಂದು ಹೆಸರಿಸಿದ ಸೇವೆಗೆ ಜೋಡಿಸಲಾದ URL ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಇದು Wi-Fi ಮತ್ತು Ethernet ನಡುವೆ ಚಲಿಸುವ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಮುಖ್ಯ. ಮೂರನೆಯದು ಫೈಲ್ ಅನ್ನು ರೆಂಡರ್ ಮಾಡದೆ ತರುತ್ತದೆ, ಆದ್ದರಿಂದ 404, ಟೈಮೌಟ್ ಮತ್ತು ರಿಜಾಲ್ವರ್ ವೈಫಲ್ಯ ಪ್ರತ್ಯೇಕವಾಗಿ ಉಳಿಯುತ್ತವೆ. ಆ ಕೊನೆಯ ಆಜ್ಞೆ ಸ್ಕ್ರಿಪ್ಟ್ ಮರಳಿಸಿದರೂ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತಿದ್ದರೆ, ಸಮಸ್ಯೆ ಈಗಾಗಲೇ ತರುವಿಕೆಯನ್ನು ದಾಟಿದೆ.

DIRECT ಉತ್ತರ ನಿಜವಾಗಿ ಏನನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ

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

DIRECT ಅನ್ನು VPN ನ ಹೊರಗೆ ಎಂದು ಓದುವುದು ಜನರನ್ನು ತಪ್ಪು ಸೆಟ್ಟಿಂಗ್ಗಳ ಪ್ಯಾನೆಲ್ಗೆ ಕಳುಹಿಸುವ ತಪ್ಪು. ಕನ್ನಡಿ ಚಿತ್ರವೂ ಅಷ್ಟೇ ಸಾಮಾನ್ಯ, ಏಕೆಂದರೆ ಖಾಸಗಿ ಪ್ರಾಕ್ಸಿಯನ್ನು ವಿಭಜಿತ ಮಾರ್ಗದ ಮೂಲಕ ತಲುಪಬಹುದು, ಆದರೆ ಉಳಿದ ಯಂತ್ರ ಸುರಂಗದ ಹೊರಗೆ ಉಳಿಯುತ್ತದೆ. ಆಗ ಗಮ್ಯಸ್ಥಾನವು ವರದಿ ಮಾಡುವುದು ಪ್ರಾಕ್ಸಿಯ ಸ್ವಂತ ನಿರ್ಗಮನಕ್ಕೆ ಸೇರಿದ್ದು, ಅದು ಬೇರೆ ದೇಶದಲ್ಲಿರಬಹುದು. ಒಂದು ಆಂತರಿಕ ಹೋಸ್ಟ್ ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೋಸ್ಟ್ಗೆ ನಿರೀಕ್ಷೆಯನ್ನು ಬರೆಯುವುದು ಇದನ್ನು ಬೇಗನೇ ಬಯಲು ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಾಗ್ಗೆ ಎರಡಕ್ಕೂ ವಿಭಿನ್ನವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಯಾವ ಹಾಪ್ ವಿಳಾಸವನ್ನು ಉತ್ಪಾದಿಸಿತು ಎಂದು ತಿಳಿದ ನಂತರ, ವರದಿ ನಿಗೂಢವಾಗಿರುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.

ಒಂದೇ ದೋಷ ಪುಟವಾಗಿ ಕಾಣುವ ಮೂರು ವೈಫಲ್ಯಗಳು

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

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

ಪ್ರಾಕ್ಸಿಗೆ ಪೂರ್ಣಗೊಂಡ ಸಂಪರ್ಕವು ಪ್ರಶ್ನೆಯನ್ನು ದೃಢೀಕರಣಕ್ಕೆ ಅಥವಾ ಪ್ರಾಕ್ಸಿಯ ಸ್ವಂತ ನೀತಿಗೆ ಸರಿಸುತ್ತದೆ, ಅದಕ್ಕೆ ಬೇರೆ ಮಾಲೀಕನಿದ್ದಾನೆ. ಮಾರ್ಗದಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಇಲ್ಲದೆ ಆಂತರಿಕ ಹೋಸ್ಟ್ಗೆ ಪೂರ್ಣಗೊಂಡ ಸಂಪರ್ಕವು ಮಾರ್ಗವನ್ನು ಹೊರಗಿಡುತ್ತದೆ ಮತ್ತು ನೀತಿಯತ್ತ ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಆಜ್ಞೆಗಳು macOS ಪ್ರಾಕ್ಸಿ ನಿಘಂಟನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ, ಶೆಲ್ ಪ್ರಾಕ್ಸಿ ಚರಗಳನ್ನು ರಫ್ತು ಮಾಡದಿದ್ದರೆ, ಆದ್ದರಿಂದ ಮೊದಲು ಅವನ್ನು ತೆರವುಗೊಳಿಸಿ. ಎರಡೂ ಪ್ರೋಬ್ಗಳಲ್ಲಿ ಒಂದು ಇನ್ನೊಂದನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಒಂದೇ ದೋಷ ಪುಟ ಇಷ್ಟು ಕಾಲ ದಾರಿ ತಪ್ಪಿಸುತ್ತದೆ.

ಟಿಕೆಟ್ನೊಂದಿಗೆ ಏನನ್ನು ಹಸ್ತಾಂತರಿಸಬೇಕು

ಸಕ್ರಿಯ ನೆಟ್ವರ್ಕ್ ಸೇವೆ, PAC URL, ವಿಫಲವಾಗುತ್ತಿರುವ ಹೋಸ್ಟ್ಗೆ ಮೌಲ್ಯಮಾಪನ ಫಲಿತಾಂಶ ಮತ್ತು ದೋಷ ಕಾಣಿಸಿಕೊಂಡ ಹಂತವನ್ನು ಕಳುಹಿಸಿ. ಆ ನಾಲ್ಕು ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಯಾವ ಪದರ ಸೇರಿತ್ತು ಎಂದು ಊಹಿಸುವ ಬದಲು ನಿರ್ಧಾರವನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ. ಪರೀಕ್ಷೆಯ ಕ್ಷಣದಲ್ಲಿ ಸುರಂಗದ ಸ್ಥಿತಿಯನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಮರುಸಂಪರ್ಕಕ್ಕೆ ಮೊದಲು ಸೆರೆಹಿಡಿದ ಫಲಿತಾಂಶ ಹಳೆಯದು. ಸ್ಕ್ರಿಪ್ಟ್ನ ಪರಿಷ್ಕರಣೆಯನ್ನೂ ಇಟ್ಟುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ನೀತಿ ಫೈಲ್ ಸೂಚನೆ ಇಲ್ಲದೆ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು ನಿನ್ನೆಯ ಉತ್ತರ ಇನ್ನು ಮಾನ್ಯವಾಗಿರದೇ ಇರಬಹುದು.

ಸ್ಕ್ರಿಪ್ಟ್ ತರಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಕ್ಲೈಂಟ್ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಅನುಷ್ಠಾನಗಳು ಭಿನ್ನವಾಗಿವೆ ಮತ್ತು ಪ್ರಾಕ್ಸಿ ನಿರ್ಧಾರವು ಇಡೀ ಸಾಧನದ ಕಿಲ್ ಸ್ವಿಚ್ ಅಲ್ಲ. ಕೆಲವು ನೇರ ಸಂಪರ್ಕಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತವೆ ಮತ್ತು ಇತರರು ಮುಚ್ಚಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವು ಅಡಚಣೆ ಮುರಿದ ಪ್ರಾಕ್ಸಿಯಂತೆ ಕಾಣುತ್ತದೆಯೇ ಅಥವಾ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ನೀತಿಯಂತೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು ನಿಖರವಾದ ಕ್ಲೈಂಟ್ ಮತ್ತು ಆವೃತ್ತಿಗೆ ನಡವಳಿಕೆಯನ್ನು ದೃಢೀಕರಿಸಿ.