Squid ಪೇರಂಟ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಲಾಗಿನ್ ವಿವರಗಳನ್ನು ಹೊಂದಿಸಿ

ನಿಮ್ಮ Squid ಸೇವೆಗೆ ಬಳಕೆದಾರನ ಲಾಗಿನ್ ಮತ್ತು ಅದರ ಪೇರಂಟ್‌ಗೆ Squidನ ಲಾಗಿನ್ ಬೇರೆ ವಿವರಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಪೇರಂಟ್ ಮತ್ತೊಬ್ಬ ನಿರ್ವಾಹಕನದ್ದಾಗಿರಬಹುದು ಅಥವಾ ಬೇರೆ ಖಾತೆ ಡೇಟಾಬೇಸ್ ಬಳಸಬಹುದು. ಕ್ಲೈಂಟ್ ಪಾಸ್‌ವರ್ಡ್ ಸ್ವೀಕರಿಸುವುದು ಅದನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ಕಳುಹಿಸಬೇಕು ಎಂದಲ್ಲ.

Squid 6.13 ಪೇರಂಟ್ ವ್ಯಾಖ್ಯಾನಕ್ಕೆ ಸ್ಥಿರ ಲಾಗಿನ್ ಸೇರಿಸಬಹುದು:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly

ಮೇಲಿನ ವಿಳಾಸ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ದಾಖಲೆಯ ಉದಾಹರಣೆಗಳು. ತಪ್ಪಾಗಿ ಎರಡನೇ peer ರಚಿಸದೆ, ಈಗಿರುವ ಪೇರಂಟ್ ವ್ಯಾಖ್ಯಾನಕ್ಕೆ ಲಾಗಿನ್ ಸೇರಿಸಿ. ಯಾವ ವಿನಂತಿಗಳು ಈ ಪೇರಂಟ್ ಬಳಸಲೇಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವ ಪ್ರತ್ಯೇಕ ರೂಟಿಂಗ್ ನೀತಿಯನ್ನು ಉಳಿಸಿ.

ಖಾತೆಗಳ ವ್ಯಾಪ್ತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ

ಡೌನ್‌ಸ್ಟ್ರೀಮ್ auth_param ಸಂಯೋಜನೆಗಳು ನಿಮ್ಮ Squid ಇನ್‌ಸ್ಟನ್ಸ್‌ನ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ. Peerನ login ಆಯ್ಕೆ ಬೇರೆ ಹಾಪ್‌ಗೆ ವಿವರಗಳನ್ನು ನೀಡುತ್ತದೆ. ಒಂದನ್ನು ಬದಲಿಸಿದರೆ ಮತ್ತೊಂದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸುವುದಿಲ್ಲ.

ಪೇರಂಟ್ ದಾಖಲಿಸಿರುವ ದೃಢೀಕರಣ ಅವಶ್ಯಕತೆ ಅನುಸರಿಸಿ. ಈ ಸಾಲು ಪ್ರತಿ ಸಂಪರ್ಕ ಆಧಾರಿತ ದೃಢೀಕರಣ ವಿಧಾನಕ್ಕೂ ಪೂರ್ಣ ಸಂರಚನೆಯಲ್ಲ. ಪೇರಂಟ್ NTLM ಅಥವಾ Negotiate ನಿರೀಕ್ಷಿಸಿದರೆ ಈ ಕ್ಷೇತ್ರದ ಪಾಸ್‌ವರ್ಡ್ ಮತ್ತೆ ಮತ್ತೆ ಬದಲಿಸದೆ ಬೆಂಬಲಿತ peer ವ್ಯವಸ್ಥೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.

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

ಸಂರಚನೆಯನ್ನು ರಕ್ಷಿಸಿ ಸರಿಯಾದ ಹಾಪ್ ಪರೀಕ್ಷಿಸಿ

ಸ್ಥಿರ ರಹಸ್ಯವನ್ನು ಸಂರಚನೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಫೈಲ್ ಮತ್ತು ಬ್ಯಾಕಪ್ ಪ್ರವೇಶ ಸೀಮಿತಗೊಳಿಸಿ; parser ಅಥವಾ debug ಔಟ್‌ಪುಟ್ ಹಂಚುವ ಮುನ್ನ ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಹಾಕಿ. ಆಯ್ಕೆಗೆ ಸ್ವಂತ escaping ನಿಯಮಗಳಿವೆ: ದಾಖಲೆ URL escape ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ನೇರ ಶೇಕಡಾ ಚಿಹ್ನೆಯನ್ನು ಎರಡು ಬಾರಿ ಬರೆಯಲು ಹೇಳುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣ ಯಶಸ್ವಿಯಾದರೂ ಫಾರ್ವರ್ಡ್ ವಿನಂತಿಗಳು ಪೇರಂಟ್‌ನಲ್ಲಿ ವಿಫಲವಾದರೆ ಆ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ವಿನಿಮಯ ಮತ್ತು ಖಾತೆ ಪರಿಶೀಲಿಸಿ. ಕ್ಲೈಂಟ್–Squid ಮತ್ತು Squid–ಪೇರಂಟ್ ಸಾರಿಗೆ ರಕ್ಷಣೆಯನ್ನೂ ಪ್ರತ್ಯೇಕವಾಗಿಡಿ; ಮೊದಲ ಸಂಪರ್ಕ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದರೆ ಎರಡನೆಯದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸುರಕ್ಷಿತವಾಗುವುದಿಲ್ಲ.