सही पासवर्ड इस नीति का केवल आधा हिस्सा है: खाते को एक स्वीकृत क्लाइंट पते से भी काम करना चाहिए। 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 के पीछे लोग एक पता साझा कर सकते हैं, और घूमता लैपटॉप पता बदल सकता है। अतिरिक्त शर्त खाते के उपयोग योग्य नेटवर्क स्थान को संकीर्ण करती है; यह भौतिक कंप्यूटर की विश्वसनीय पहचान नहीं करती। सुनिश्चित करें कि यह सीमा उस कारण से मेल खाती है जिसके लिए आपने शुरू में शर्त जोड़ी थी।

संबंधित लेख