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 पछिका नियम र प्रमाणीकरण क्यास जाँच्नुहोस्। पासवर्ड बदल्दा गलत नीतिमुनि सुरु भएको सेवा सुधारिँदैन। त्यसैगरी, डेमनको अपरेटिङ सिस्टम खाता बदल्दा प्रोक्सी प्रयोगकर्ता बन्दैन।