ಹೋಸ್ಟ್ನ URL ನೊಂದಿಗೆ ಅತಿಥಿ VM ನಲ್ಲಿ PAC ಪ್ರಾಕ್ಸಿ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ

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

PAC URL ಒಂದು ಸ್ಕ್ರಿಪ್ಟ್, ಪ್ರಾಕ್ಸಿ ಅಲ್ಲ

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

ಆ ವ್ಯತ್ಯಾಸವೇ URL ನಕಲಿಸುವುದು ಕೆಲಸ ಮಾಡಿದಂತೆ ಕಾಣಲು ಕಾರಣ. ಕ್ಷೇತ್ರ ತುಂಬುತ್ತದೆ, ಸೆಟ್ಟಿಂಗ್ ಉಳಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯ ನಂತರವೇ ಕಾಣಿಸುತ್ತದೆ, ಸ್ಕ್ರಿಪ್ಟ್ ಪಡೆಯಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಅಥವಾ ಅತಿಥಿ ತಲುಪಲಾಗದ ಪ್ರಾಕ್ಸಿಯನ್ನು ಹಿಂತಿರುಗಿಸಿದಾಗ.

ನಾಲ್ಕು ಹಂತಗಳು ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ

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

ಪಡೆಯುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಅದಿಲ್ಲದೆ ಮುಂದಿನ ಎಲ್ಲವೂ ಅರ್ಥಹೀನ. ಖಾಸಗಿ ಸರ್ವರ್‌ನಲ್ಲಿನ PAC ಫೈಲ್ ಯಾವುದೇ ನಿಯಮ ಸಹಾಯ ಮಾಡುವ ಮೊದಲು ಆ ಸರ್ವರ್‌ಗೆ ಅನುಮತಿಸಿದ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ತಲುಪಲಾಗದ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಒಳಗಿನ ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆ ಅದನ್ನು ಪಡೆಯುವ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸಲಾಗದು:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

ಆ ವಿನಂತಿ ಅತಿಥಿಯಿಂದ ವಿಫಲವಾಗಿ ಹೋಸ್ಟ್‌ನಿಂದ ಕೆಲಸ ಮಾಡಿದರೆ, ಸಮಸ್ಯೆ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ವಿಷಯದಲ್ಲಲ್ಲ, ಅತಿಥಿಯ PAC ಸರ್ವರ್‌ಗೆ ಇರುವ ಮಾರ್ಗದಲ್ಲಿದೆ. ಅದು JavaScript ಫೈಲ್ ಹಿಂತಿರುಗಿಸಿದರೆ, ಎರಡನೇ ಹಂತಕ್ಕೆ ಹೋಗಿ ಸ್ಕ್ರಿಪ್ಟ್ ಅತಿಥಿಯ ಸಂದರ್ಭಕ್ಕೆ ಏನು ನಿರ್ಧರಿಸುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ.

ಅದೇ ಸ್ಕ್ರಿಪ್ಟ್ VM ನ ಒಳಗೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನಿರ್ಧರಿಸುತ್ತದೆ

PAC ಫಂಕ್ಷನ್‌ಗಳು ವಿನಂತಿಸಿದ ಹೋಸ್ಟ್ ಮತ್ತು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತಿರುವ ಯಂತ್ರದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ವಿಳಾಸದ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ನಿಯಮ, ಉದಾಹರಣೆಗೆ ಇಂಟರ್‌ಫೇಸ್ ವಿಳಾಸ ಅಥವಾ ಸಬ್‌ನೆಟ್ ಸದಸ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ನಿಯಮ, ಭೌತಿಕ ಹೋಸ್ಟ್‌ನದಲ್ಲ, ಅತಿಥಿಯ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಹೋಸ್ಟ್-ಬದಿಯ NAT ಹಿಂದೆ ಇವು ಬೇರೆ ವಿಳಾಸಗಳು, ಆದ್ದರಿಂದ ಅದೇ ಸ್ಕ್ರಿಪ್ಟ್ ಬೇರೆ ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆ ಮಾಡಬಹುದು ಅಥವಾ VM ನ ಒಳಗೆ DIRECT ಗೆ ಮರಳಬಹುದು.

ಇದು ಸ್ಕ್ರಿಪ್ಟ್‌ನ ದೋಷವಲ್ಲ. ಸ್ಕ್ರಿಪ್ಟ್ ತಾನು ಬರೆಯಲ್ಪಟ್ಟದ್ದನ್ನು ಬೇರೆ ಇನ್‌ಪುಟ್‌ನೊಂದಿಗೆ ನಿಖರವಾಗಿ ಮಾಡುತ್ತಿದೆ, ಮತ್ತು ಅದೇ ಹೋಸ್ಟ್ ಪ್ರಾಕ್ಸಿ ಬಳಸಿ ಅತಿಥಿ ನೇರವಾಗಿ ಸಂಪರ್ಕಿಸುವ ಗೊಂದಲಮಯ ವರದಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ನಿರ್ಣಯದ ಬಗ್ಗೆ ಯೋಚಿಸುವ ಬದಲು ಅದನ್ನು ಮರುಸೃಷ್ಟಿಸಿ: ವಿಳಾಸ ಮತ್ತು URL ತೆಗೆದುಕೊಳ್ಳುವ PAC ಮೌಲ್ಯಮಾಪಕ, ನಿಮ್ಮ ವಿತರಣೆಯಲ್ಲಿ ಇದ್ದರೆ, ಒಂದೇ ಆದೇಶದಲ್ಲಿ ಪ್ರಶ್ನೆಯನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ ನಿಜವಾಗಿ ಬಳಸಲಾಗುವ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಊಹಿಸುವ ಬದಲು ಅದರ ಪ್ರಾಕ್ಸಿ ಲಾಗ್ ಓದಿ.

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

PAC ಅನ್ನು ಸುತರಾಂ ಓದದ ಉಪಕರಣಗಳು

ಆದೇಶ ಸಾಲಿನ ಉಪಕರಣಗಳು ಪ್ರತ್ಯೇಕ ಗಡಿ, ಮತ್ತು ಇಲ್ಲಿಯೇ ಸಾಕಷ್ಟು ಸಮಯ ವ್ಯರ್ಥವಾಗುತ್ತದೆ. curl PAC ಫೈಲ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದಿಲ್ಲ, ಅದರ ಪ್ರಾಕ್ಸಿ ದಾಖಲೆ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುವಂತೆ. ಪ್ರಾಕ್ಸಿ ಚರವನ್ನು PAC ಡೌನ್‌ಲೋಡ್ URL ಗೆ ತೋರಿಸುವುದರಿಂದ ಸ್ಕ್ರಿಪ್ಟ್ ಪ್ರಾಕ್ಸಿ ಅಂತ್ಯಬಿಂದುವಾಗುವುದಿಲ್ಲ; ಉಪಕರಣವು JavaScript ಫೈಲ್‌ನೊಂದಿಗೆ HTTP ಮಾತನಾಡಲು ಪ್ರಯತ್ನಿಸಿ ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಅದೇ ವಿಷಯ ಅನೇಕ ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕರು, ಭಾಷಾ ರನ್‌ಟೈಮ್‌ಗಳು ಮತ್ತು ಬಿಲ್ಡ್ ಉಪಕರಣಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ, ಅವು ಸ್ಪಷ್ಟ ಪ್ರಾಕ್ಸಿ ಚರಗಳನ್ನು ಅಥವಾ ತಮ್ಮದೇ ಸಂರಚನೆಯನ್ನು ಮಾತ್ರ ಗೌರವಿಸುತ್ತವೆ. ನಿಮಗೆ ಮುಖ್ಯವಾದ ಪರೀಕ್ಷೆ CLI ಉಪಕರಣವಾದರೆ, PAC ಸ್ಕ್ರಿಪ್ಟ್ ಆಯ್ಕೆ ಮಾಡುತ್ತಿದ್ದ ನಿರ್ದಿಷ್ಟ ಪ್ರಾಕ್ಸಿಯೊಂದಿಗೆ ಅದನ್ನು ಸಂರಚಿಸಿ, ಮತ್ತು ಆ ಆಯ್ಕೆಗೆ ಹೇಗೆ ಬಂದಿರಿ ಎಂದು ದಾಖಲಿಸಿ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು.

Linux ನಲ್ಲಿ ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ಸಿಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತ ಮೋಡ್‌ಗೆ ಹಾಕಬೇಕು ಮತ್ತು URL ಕೂಡ ನೀಡಬೇಕು; ಮೋಡ್ ಇನ್ನೂ ಕೈಯಿಂದ ಇರುವಾಗ ಉಳಿಸಿದ URL ಏನೂ ಮಾಡುವುದಿಲ್ಲ. ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಅತಿಥಿಯ ಒಳಗೆ ಪರಿಶೀಲಿಸಿ:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT ಕೂಡ ಒಂದು ನಿರ್ಣಯ

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

ಆದ್ದರಿಂದ ಅಗತ್ಯವನ್ನು ಬರೆದ ದಿಶೆಯಲ್ಲಿ ಪರಿಶೀಲಿಸಿ. ಅಗತ್ಯ «ಈ ಅಪ್ಲಿಕೇಶನ್ ಒಳಾಂಗಣ ಸೈಟ್ ತಲುಪುತ್ತದೆ» ಆಗಿದ್ದರೆ, ಆ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ, ಮತ್ತು ಯಾವ ಪ್ರಾಕ್ಸಿ ಅಥವಾ ಮಾರ್ಗ ಅದನ್ನು ಒಯ್ದಿತು ಎಂದು ದಾಖಲಿಸಿ. ಅಗತ್ಯ «VM ಕಾರ್ಪೊರೇಟ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿದೆ» ಆಗಿದ್ದರೆ, ಆಯ್ಕೆ ಮಾಡಿದ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಕೆಲಸ ಮಾಡುವ ಬ್ರೌಸರ್ ಆ ಬ್ರೌಸರ್‌ಗೆ ಸಾಕ್ಷಿ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಲ್ಲ.

ಪರೀಕ್ಷೆ ಉತ್ತೀರ್ಣವಾಗಲು ಹೋಸ್ಟ್‌ನ ಟನೆಲ್ ಆಫ್ ಮಾಡುವ ಅಥವಾ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ ಸಡಿಲಿಸುವ ಬದಲು ಅತಿಥಿಯ ಒಳಗೆ ಸರಪಳಿಯನ್ನು ಸರಿಪಡಿಸಿ. ಸರಪಳಿಗೆ ನಾಲ್ಕು ಕೊಂಡಿಗಳಿವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಬಿಟ್ಟುಬಿಡುವ ಬದಲಾವಣೆ ಮುಂದಿನ ಬಾರಿ ಸ್ಕ್ರಿಪ್ಟ್ ನವೀಕರಿಸುವವರೆಗೆ ಅಥವಾ ಅತಿಥಿಯ ವಿಳಾಸ ಬದಲಾಗುವವರೆಗೆ ಉಳಿಯುತ್ತದೆ.