Dante 1.4.4 में क्लाइंट नियम SOCKS वार्ता से पहले कनेक्शन स्वीकार करते हैं, जबकि SOCKS नियम तय करते हैं कि कौन-से प्रमाणित अनुरोध आगे जा सकते हैं। अनुमत स्रोत से आए कनेक्शन को भी दूसरे चरण में उपयोगकर्ता नाम देना पड़ सकता है।

ऑपरेटिंग सिस्टम के उपयोगकर्ता नाम से प्रमाणीकरण के लिए विधि के साथ सेवा की पहचान भी देखें। खाता डेटाबेस पढ़ने के लिए विशेषाधिकार वाली पहचान की ज़रूरत हो सकती है:

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Dante के लिए स्थापित वास्तविक कम अधिकार वाला सेवा खाता इस्तेमाल करें। उपयोगकर्ता नाम वाले बैकएंड के अनुकूल अधिकृत क्लाइंट खाता बनाएँ या चुनें; सेवा की पहचान और क्लाइंट का लॉगिन अलग भूमिकाएँ हैं।

अनुरोध की सीमाएँ बनाए रखें

मौजूदा सीमित क्लाइंट नियम के बाद अनुमत SOCKS मार्ग पर खाता अनिवार्य करें:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

पते और खाते का नाम उदाहरण हैं। इससे एक स्रोत, एक गंतव्य, एक कमांड और निर्दिष्ट प्रमाणित उपयोगकर्ता को अनुमति मिलती है। केवल पासवर्ड जोड़ देने के कारण यह सीमा हटाकर सभी स्रोतों को खुली पहुँच न दें।

वैश्विक और नियम-विशिष्ट विधि सेटिंग मेल खानी चाहिए। केवल स्रोत आधारित पुराने सेटअप से बचा कोई सिर्फ none वाला नियम देखें। निर्धारित लिसनर और फ़ायरवॉल की पाबंदियाँ भी बनाए रखें।

वार्ता और पहुँच अलग-अलग जाँचें

शुरू करने से पहले स्थापित सर्वर के कॉन्फ़िगरेशन जाँच मोड से फ़ाइल जाँचें। फिर ऐसा अधिकृत क्लाइंट इस्तेमाल करें जो वास्तव में SOCKS5 उपयोगकर्ता नाम/पासवर्ड वार्ता का समर्थन करता हो। पहचान विवरण न होना, गलत विवरण और अनुमत खाते से प्रतिबंधित लक्ष्य माँगना जाँचें।

RFC 1929 में परिभाषित उपयोगकर्ता नाम/पासवर्ड उपवार्ता पासवर्ड एन्क्रिप्ट नहीं करती। गंतव्य के साथ बाद का HTTPS सत्र पहले हुए उस प्रॉक्सी आदान-प्रदान की रक्षा नहीं करता। क्लाइंट से सर्वर तक उचित रूप से सुरक्षित मार्ग इस्तेमाल करें।

सफल कॉन्फ़िगरेशन जाँच सिंटैक्स और पहचान की पुष्टि करती है, खाता डेटाबेस या नेटवर्क मार्ग की नहीं। वास्तविक परीक्षण किस चरण में अस्वीकार हुआ, यह सर्वर लॉग में देखें।

संबंधित लेख