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

ದೃಢೀಕರಣವು ಈಗಾಗಲೇ ಸಂರಚಿಸಲಾಗಿದೆ ಎಂದು ಊಹಿಸಿ, ಉದಾಹರಣೆಗೆ Squid 6.13 NCSA ಸೆಟಪ್, ಮುಖ್ಯ ನೀತಿ ಇದು:

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

Squid ನಿಜವಾಗಿ ಸ್ವೀಕರಿಸುವ ಮೂಲವನ್ನು ಬಳಸಿ; ಮಾದರಿಯು ದಸ್ತಾವೇಜು ವಿಳಾಸವಾಗಿದೆ. ಅಸುರಕ್ಷಿತ ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್‌ಗಳು, ಸ್ಥಳೀಯ ಸೇವೆಗಳು ಮತ್ತು CONNECT ಸಂಚಾರಕ್ಕಾಗಿ ಹಿಂದಿನ ರಕ್ಷಣೆಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ. ಈ ತುಣುಕು ಸಂಯೋಜಿತ ಷರತ್ತನ್ನು ತೋರಿಸುತ್ತದೆ, ಪೂರ್ಣ ಶ್ರೋತೃ ಸಂರಚನೆಯಲ್ಲ.

ಅದರ ಮೇಲಿನ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಹಿಂದಿನ ವಿಶಾಲ ಅನುಮತಿಯು ಹೊಸ ಷರತ್ತಿಗೆ ತಲುಪುವ ಮೊದಲೇ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಬಹುದು. http_access ಉಲ್ಲೇಖವು ಕ್ರಮಬದ್ಧ ಹೊಂದಾಣಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸೇರಿಸಲಾದ ಫೈಲ್‌ಗಳೂ ಸೇರಿದಂತೆ ಸಂಪೂರ್ಣ ಅನುಕ್ರಮವನ್ನು ಓದಿ.

ಬಳಕೆದಾರರ ಹೆಸರಿಗೆ ಒಂದು ಅನುಮತಿ ಮತ್ತು ಮೂಲಕ್ಕೆ ಇನ್ನೊಂದು ಎರಡನ್ನೂ ಬೇಡುವುದಿಲ್ಲ. ಯಾವುದೇ ಸಾಲು ಸ್ವತಂತ್ರವಾಗಿ ಯಶಸ್ವಿಯಾಗಬಹುದು. ಅದು ಬೇರೆ ನೀತಿ.

proxy_auth ACL ದೃಢೀಕರಣ ಸಹಾಯಕವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಅದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು ಬಳಕೆದಾರರನ್ನು ರಚಿಸುವ ಅಥವಾ ಪಾಸ್‌ವರ್ಡ್ ಮಾನ್ಯಗೊಳಿಸುವ ವಿಧಾನವಲ್ಲ. ಈ ಉದಾಹರಣೆ ಸ್ಪಷ್ಟ ಪ್ರಾಕ್ಸಿಗೆ, ಅದರ ಕ್ಲೈಂಟ್‌ಗಳು ಪ್ರಾಕ್ಸಿ ದೃಢೀಕರಣ ಸವಾಲುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು.

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

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