3proxy ನ HTTP ಮತ್ತು SOCKS ಎರಡೂ ಸೇವೆಗಳಲ್ಲಿ ಲಾಗಿನ್ ಅಗತ್ಯಪಡಿಸಿ

ಬಳಕೆದಾರರನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು 3proxy ನ ಸಂಪೂರ್ಣ ಲಾಗಿನ್ ಸಂರಚನೆ ಅಲ್ಲ. ಸೇವೆಗೆ ದೃಢೀಕರಣ ವಿಧಾನ ಮತ್ತು ಅದನ್ನು ಬಳಸುವ ಪ್ರವೇಶ ನಿಯಮವೂ ಬೇಕು. ಕ್ರಮ ಮುಖ್ಯ ಏಕೆಂದರೆ ಸಂರಚನೆ ಸಂಸ್ಕರಿಸುವಾಗ ಸೇವಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಅನ್ವಯವಾಗುತ್ತವೆ.

ಎರಡು ಸೇವೆಗಳಿಗೆ ಸ್ಥಳೀಯ ಮಾತ್ರ ಉದಾಹರಣೆ:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

ಸಂರಚನಾ ಉಲ್ಲೇಖ users, auth strong ಮತ್ತು ಸೇವಾ ಆಜ್ಞೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. CL ಈ ಉದಾಹರಣೆಯ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಸ್ಪಷ್ಟ ಪಠ್ಯವಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಫೈಲ್ ಅನ್ನು ರಕ್ಷಿಸಿ ಮತ್ತು ನಿಯೋಜನೆಗೆ ಸೂಕ್ತವಾದ ಬೆಂಬಲಿತ ರುಜುವಾತು ಸಂಗ್ರಹಣಾ ರೂಪವನ್ನು ಆಯ್ಕೆಮಾಡಿ.

ಕ್ಲೈಂಟ್‌ಗೆ ಸರಿಯಾದ ಲಾಗಿನ್ ವಿನಿಮಯ ಬೇಕು

HTTP ಸೇವೆ HTTP ಪ್ರಾಕ್ಸಿ ದೃಢೀಕರಣವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. SOCKS ಸೇವೆಗೆ SOCKS5 ಬಳಕೆದಾರಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ದೃಢೀಕರಣವನ್ನು ಬೆಂಬಲಿಸುವ ಕ್ಲೈಂಟ್ ಬೇಕು. SOCKS4 ಕ್ಲೈಂಟ್ ಕೇವಲ ಅದೇ ಕೇಳಿಸುವ ಪೋರ್ಟ್ ತಲುಪುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಆ ವಿನಿಮಯವನ್ನು ಒದಗಿಸಲಾರದು.

strong ಪದವು ದೃಢೀಕರಣ ಮೋಡ್‌ನ ಹೆಸರು, ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಸಾಗಣೆಯ ಖಾತರಿ ಅಲ್ಲ. ಅಗತ್ಯವಿದ್ದಾಗ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಾಕ್ಸಿವರೆಗಿನ ಭಾಗವನ್ನು ರಕ್ಷಿಸಿ. ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ HTTPS ಮತ್ತು ಪ್ರಾಕ್ಸಿಗೆ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯಗಳಾಗಿಯೇ ಉಳಿಯುತ್ತವೆ.

ಲೂಪ್‌ಬ್ಯಾಕ್ ಬೈಂಡಿಂಗ್‌ಗಳು ಈ ಉದಾಹರಣೆಯನ್ನು ಸ್ಥಳೀಯ ಪ್ರವೇಶಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುತ್ತವೆ. ದೂರದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಉದ್ದೇಶಿತ ಕೇಳುಗ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ನೀತಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಆಯ್ಕೆಮಾಡಿ. ಸಾರ್ವಜನಿಕ ವೈಲ್ಡ್‌ಕಾರ್ಡ್ ಕೇಳುಗ ಲಾಗಿನ್ ನಡವಳಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸುವುದಕ್ಕೆ ಪರ್ಯಾಯವಲ್ಲ.

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