प्रोक्सी प्रमाणीकरण बिना एउटा Squid गन्तव्यलाई अनुमति दिनुहोस्

निगरानी पृष्ठले प्रोक्सी लगइन बिना काम गर्नुपर्छ। स्पष्ट नियम http_access allow status_site हो। प्रमाणीकरण अघि राख्दा, तपाईंले कहिल्यै सेवा दिन नचाहेका क्लाइन्टहरूलाई पनि यसले अपवाद दिन सक्छ।

Squid 6 वा 7 का लागि, अपवादका सर्तहरू सँगै राख्नुहोस्। अवस्थित व्यवस्थापन, असुरक्षित पोर्ट, CONNECT र स्थानीय-सेवा सुरक्षाहरूपछि, सम्बन्धित भाग यस्तो देखिन सक्छ:

acl office_clients src 192.0.2.0/24
acl status_site dstdomain status.example.net
acl signed_in proxy_auth REQUIRED

http_access allow office_clients status_site
http_access allow office_clients signed_in
http_access deny all

नेटवर्क र होस्टनाम प्लेसहोल्डर हुन्। प्रमाणीकरणलाई अझै यसको अवस्थित हेल्पर कन्फिगरेसन चाहिन्छ। यो पहुँच नीतिको अपवाद भाग हो, पूर्ण प्रोक्सी कन्फिगरेसन होइन।

पहिलो लाइनले छानिएका क्लाइन्टहरूलाई लगइन ACL मूल्याङ्कन नगरी त्यो गन्तव्यमा अनुमति दिन्छ। अर्को लाइनले ती क्लाइन्टहरूलाई अन्यत्र प्रमाणीकरणपछि मात्र अनुमति दिन्छ। अघिल्ला फराकिला अनुमतिहरू वा पछिका वैकल्पिक मार्गहरूले नतिजा बदल्न सक्छन्, त्यसैले समावेश गरिएका फाइलहरूसहित पूरै क्रमबद्ध नीति पढ्नुहोस्।

प्रम्प्टबाट बच्न मात्र अपवादलाई गन्तव्य-पोर्ट सुरक्षाहरूमाथि सार्नु हुँदैन। अनपेक्षित पोर्टमा अधिकृत साइट अझै फरक मार्ग हो। साथै अनावश्यक रूपमा फराकिलो प्रत्यय थप्नुको सट्टा ठ्याक्कै होस्ट वा यसका सबडोमेनहरू योग्य हुनुपर्छ कि भन्ने निर्णय गर्नुहोस्।

होस्टनाम अपवादले मिल्ने गन्तव्यलाई समेट्छ, यसको पृष्ठले लोड गर्ने हरेक निर्भरतालाई होइन। रिडिरेक्ट र तेस्रो-पक्ष सम्पत्तिहरूले वैध रूपमा सामान्य लगइन आवश्यकताको सामना गर्न सक्छन्।

सादा HTTP का लागि, प्रोक्सीले उपयुक्त हुँदा थप सूक्ष्म URL जानकारी प्रयोग गर्न सक्छ। सामान्य HTTPS CONNECT अनुरोधले पृष्ठको बाटो खुलाउँदैन, त्यसैले पूरै होस्टको टनेल अपवादबाट 'एउटा पृष्ठ मात्र' नियम अनुमान गर्न सकिँदैन।