ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿರುವ ಪ್ರಾಕ್ಸಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ನಂತರ ಆ ಸಹಾಯಕವು ಕಂಪನಿ ಪ್ರಾಕ್ಸಿಗೆ ದೃಢೀಕರಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ಕಂಪನಿಯ ದೃಢೀಕರಣ ವಿನಿಮಯ ಮಾಡಲೇಬೇಕೆಂದಿಲ್ಲ.

application → local helper → company proxy → destination

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

ವಿಫಲವಾದ ಹಂತವನ್ನು ಗುರುತಿಸಿ

ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ಸಹಾಯಕದ ನಿಜವಾದ ಆಲಿಸುವಿಕೆ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಆಯ್ಕೆ ಮಾಡಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಆ ಆಲಿಸುವಿಕೆ ತಲುಪುವ ಮೊದಲಿನ ದೋಷ NTLM ವೈಫಲ್ಯವಲ್ಲ. ನಂತರ ಸಹಾಯಕವು ಸಂರಚಿತ ಪೋಷಕವನ್ನು ತಲುಪಿದೆಯೇ ಮತ್ತು ಪೋಷಕ ಅದರ ಗುರುತನ್ನು ಸ್ವೀಕರಿಸಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

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

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

ಆಲಿಸುವಿಕೆ ನಿಜವಾದ ಸೇವೆ

Loopback ಆಲಿಸುವಿಕೆಯನ್ನು ಸುತ್ತಮುತ್ತಲಿನ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ದೂರ ಇಡುತ್ತದೆ; ಅದು ಆ ಕಂಪ್ಯೂಟರ್‌ನ ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಅಥವಾ ಬಳಕೆದಾರರನ್ನು ಬೇರ್ಪಡಿಸುವುದಿಲ್ಲ. ಗೇಟ್‌ವೇ ಅಥವಾ ವಿಶಾಲ ಬೈಂಡಿಂಗ್ ಸಹಾಯಕದ ಮೇಲ್ಮುಖ ಗುರುತನ್ನು ಬಳಸಬಹುದಾದ ಕರೆಗಾರರ ಗುಂಪನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಆ ಬದಲಾವಣೆಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮಾಡಿ.

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು