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 नंतरचे नियम आणि प्रमाणीकरण कॅश तपासा. पासवर्ड बदलल्याने चुकीच्या धोरणाखाली सुरू झालेली सेवा दुरुस्त होत नाही. त्याचप्रमाणे, डेमॉनचे ऑपरेटिंग-सिस्टम खाते बदलल्याने प्रॉक्सी वापरकर्ता तयार होत नाही.