योग्य पासवर्ड ही या धोरणाची फक्त अर्धी गोष्ट आहे: खाते एका मंजूर क्लायंट पत्त्यावरूनही चालले पाहिजे. 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 मागील लोक एक पत्ता सामायिक करू शकतात आणि फिरणारा लॅपटॉप पत्ता बदलू शकतो. अतिरिक्त अट खात्याचे वापरण्यायोग्य नेटवर्क स्थान अरुंद करते; ती भौतिक संगणक विश्वासार्हपणे ओळखत नाही. ही मर्यादा तुम्ही सुरुवातीला अट जोडण्याच्या कारणाशी जुळते याची खात्री करा.

संबंधित लेख