ಶಾಖಾ ಬ್ರೌಸರ್‌ನಿಂದ ಪ್ರಾಕ್ಸಿಗೆ: ಎರಡು ಸಂಪರ್ಕಗಳು, ಎರಡು ಮಾರ್ಗಗಳು

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

ಹಂತ 1: ಎರಡು ಹರಿವುಗಳನ್ನು ಬರೆಯಿರಿ

ಬ್ರೌಸರ್‌ನ ತಕ್ಷಣದ ಗಮ್ಯಸ್ಥಾನ ಪ್ರಾಕ್ಸಿ ಶ್ರೋತೃ, ಬಳಕೆದಾರರು ಅಂತಿಮವಾಗಿ ಭೇಟಿಯಾಗುವ ಪ್ರತಿ ಸೈಟ್ ಅಲ್ಲ. ಆ ಒಂದೇ ವಾಕ್ಯ ಈ ವಿನ್ಯಾಸದಲ್ಲಿನ ಹೆಚ್ಚಿನ ಗೊಂದಲವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

ಬೇರೆ ಮೂಲಗಳು, ಬೇರೆ ಮಾರ್ಗಗಳು, ಬೇರೆ ಅನುಮತಿಗಳು. ಕರಡು ಚಿತ್ರವನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ನಂತರದ ಪರಿಶೀಲನೆಯೂ ಅದರ ಎರಡು ಅರ್ಧಗಳಲ್ಲಿ ಒಂದನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ.

ಹಂತ 2: ಬ್ರೌಸರ್‌ಗೆ ಶ್ರೋತೃದವರೆಗೆ ಮಾರ್ಗ ನೀಡಿ

ಪ್ರಾಕ್ಸಿ ಹೋಸ್ಟ್‌ಹೆಸರು, ಶ್ರೋತೃ ಪೋರ್ಟ್, ದೃಢೀಕರಣ ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ಅನುಮತಿಸಿದ ಶಾಖಾ ಮೂಲಗಳನ್ನು ದಾಖಲಿಸಿ. ಆ ಪಟ್ಟಿಯೇ ಮೊದಲ ಹರಿವಿನ ಸ್ವೀಕೃತಿ ಮಾನದಂಡ, ಮತ್ತು ಅದು ಖಾಸಗಿ ಹೆಸರು ವಿಭಜನೆಯ ಜೊತೆಗೆ ಸುರಂಗ ಮಾರ್ಗವನ್ನೂ ಒಳಗೊಂಡಿರಬೇಕು.

ಇಂಟರ್ನೆಟ್‌ಗೆ ನಿರ್ಬಂಧವಿಲ್ಲದ ಪ್ರಾಕ್ಸಿ ಪ್ರಕಟಿಸುವ ಬದಲು ಉದ್ದೇಶಿತ ಸೇವೆಗೆ ಸಂಕುಚಿತ ಜಾಲ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸಿ. ಉದ್ದೇಶಿತ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಅದರವರೆಗೆ ಬೆಂಬಲಿತ ಮಾರ್ಗವಿದ್ದಾಗ ಪ್ರಾಕ್ಸಿ ಆಂತರಿಕ ಜಾಲದಲ್ಲೇ ಇರಬಹುದು.

ಹಂತ 3: ಕೇವಲ ಮಾರ್ಗ ಕೋಷ್ಟಕವಲ್ಲ, ಬ್ರೌಸರ್ ಸಂರಚಿಸಿ

ಬ್ರೌಸರ್‌ನ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್, PAC ಫೈಲ್ ಅಥವಾ ಸಂಸ್ಥೆಯ ನಿರ್ವಹಿತ ಪತ್ತೆ ಕ್ರಮವನ್ನು ಬಳಸಿ. ಸಾಮಾನ್ಯ ವೆಬ್‌ಸೈಟ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮಾರ್ಗದೊಂದಿಗೆ ಪ್ರಾಕ್ಸಿ ವಿಳಾಸದತ್ತ ಕಳುಹಿಸುವುದು ಬ್ರೌಸರ್ ಪ್ರಾಕ್ಸಿ ಪ್ರೋಟೋಕಾಲ್ ಮಾತನಾಡುವಂತೆ ಮಾಡುವುದಿಲ್ಲ; ಅದು ಪಾರದರ್ಶಕ ಪ್ರತಿಬಂಧ ಮತ್ತು ಬೇರೆ ಗೇಟ್‌ವೇ ವಿನ್ಯಾಸಕ್ಕೆ ಸೇರುತ್ತದೆ.

ಯಾವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಗೌರವಿಸುತ್ತವೆ ಎಂದು ಬರೆಯಿರಿ. ಮೇಲ್ ಕ್ಲೈಂಟ್, ಅಪ್‌ಡೇಟರ್ ಮತ್ತು ಆಟಗಳು ಹೆಚ್ಚಾಗಿ ಗೌರವಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅವು ಸಾಮಾನ್ಯ ಮಾರ್ಗವನ್ನೇ ಬಳಸುತ್ತವೆ.

ಹಂತ 4: ಪ್ರಾಕ್ಸಿಯ ಮುಂದಿನ ಸಂಪರ್ಕವನ್ನು ಸಾಬೀತುಪಡಿಸಿ

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

HTTPSಗಾಗಿ, CONNECT ವಿನಂತಿಸಿದ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸುರಂಗ ತೆರೆಯುತ್ತದೆ. ಸಾಮಾನ್ಯ ಫಾರ್ವರ್ಡಿಂಗ್ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಪುಟವನ್ನು ಪ್ರಾಕ್ಸಿಗೆ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಪರಿಶೀಲನೆಗಾಗಿ ಪ್ರಮಾಣಪತ್ರ ಮಾನ್ಯತೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಪರಿಹಾರವಲ್ಲ.

ಹಂತ 5: ನಾಲ್ಕು ವೈಫಲ್ಯಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ

ಪ್ರಾಕ್ಸಿ ದೃಢೀಕರಣ ಸವಾಲು ಶ್ರೋತೃದಿಂದ ಬರುವ 407. ನಿರಾಕರಿಸಿದ CONNECT ಪ್ರಾಕ್ಸಿಯಲ್ಲಿನ ನೀತಿ ನಿರ್ಣಯ, ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನದೇ ಸ್ಥಿತಿ ಮತ್ತು ಲಾಗ್ ಸಾಲಿನೊಂದಿಗೆ. ವಿಫಲವಾದ ಮುಂದಿನ ಸಂಪರ್ಕ ಪ್ರಾಕ್ಸಿ ಗಮ್ಯಸ್ಥಾನದ ವಿರುದ್ಧ ದಾಖಲಿಸುವ ಸಮಯ ಮೀರಿಕೆ ಅಥವಾ ಮರುಹೊಂದಿಕೆಯಂತೆ ಕಾಣುತ್ತದೆ. ವೆಬ್‌ಸೈಟ್ ಪ್ರತಿಕ್ರಿಯೆ ಎಂದರೆ ಎರಡೂ ಸಂಪರ್ಕಗಳು ಕೆಲಸ ಮಾಡಿದವು ಮತ್ತು ಸಮಸ್ಯೆ ಮೂಲದಲ್ಲಿದೆ.

ನೀವು ಗಮನಿಸಿದ ಗಡಿಯನ್ನು ವರದಿ ಮಾಡಿ, VPN ವಿಫಲವಾಯಿತು ಎಂಬ ಸಾರಾಂಶವನ್ನಲ್ಲ.

ಹಂತ 6: ವ್ಯಾಪ್ತಿ ನಿರ್ಧರಿಸಿ ಮತ್ತು ಪರ್ಯಾಯವನ್ನು ಯೋಜಿಸಿ

ಪ್ರಾಕ್ಸಿ ಅಥವಾ ಸುರಂಗ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ, ಮತ್ತು ಈ ವಿನ್ಯಾಸ ಯಾವ ಸಂಚಾರವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ. ಇದು ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಗೌರವಿಸುವ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ವೆಬ್ ಪ್ರವೇಶವನ್ನು ಸಾಗಿಸುತ್ತದೆ; ಮೇಲ್, ಅನಿಯಂತ್ರಿತ ಸಾಧನ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಅಥವಾ ಸಂರಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ತಂತ್ರಾಂಶವನ್ನು ಸಾಗಿಸುವುದಿಲ್ಲ.

ವಿನ್ಯಾಸವನ್ನು ಹೆಚ್ಚು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ವಿಸ್ತರಿಸುವ ಮೊದಲು ಅನುಮೋದಿತ ಯೋಜನೆಯ ಅಡಿಯಲ್ಲಿ ಅಗತ್ಯವಾದ ಬ್ರೌಸರ್ ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ಒಂದು ಅಗತ್ಯ ನಿರಾಕರಣೆಯನ್ನು ಮಾನ್ಯಗೊಳಿಸಿ.