Squid SO_ORIGINAL_DST त्रुटि पढ़ना

NF getsockopt(SO_ORIGINAL_DST) मूल गंतव्य की खोज की ओर संकेत करता है। इंटरसेप्शन सेटअप में Squid को यह पुनः प्राप्त करना होता है कि पुनर्निर्देशित कनेक्शन मूल रूप से कहाँ जा रहा था।

स्पष्ट रूप से कॉन्फ़िगर किया गया ब्राउज़र अपने अनुरोध जानबूझकर प्रॉक्सी को भेजता है। उस कनेक्शन को केवल इसलिए NAT इंटरसेप्शन का इतिहास नहीं मिल जाता कि Squid श्रोता के पोर्ट के पास intercept लिखा है।

इसलिए यह असंगति गंतव्य के प्रमाणपत्र के प्रासंगिक होने से पहले ही विफल हो सकती है।

कनेक्शन कैसे आया, इससे शुरू करें

• यदि अनुप्रयोग में प्रॉक्सी पता कॉन्फ़िगर है, तो वह सामान्य फ़ॉरवर्ड-प्रॉक्सी श्रोता पहचानें जिसका उसे उपयोग करना चाहिए।
• यदि गेटवे अन्यथा सीधे ट्रैफ़िक को पुनर्निर्देशित करता है, तो जाँचें कि वह इच्छित इंटरसेप्शन श्रोता तक पहुँचता है और समर्थित NAT डिज़ाइन आवश्यक गंतव्य जानकारी सुरक्षित रखता है।
• यदि दोनों मोड मौजूद हैं, तो जाँचें कि विफल होने वाले क्लाइंट ने वास्तव में किस पते और पोर्ट से संपर्क किया।

Squid का http_port दस्तावेज़ अंतर स्पष्ट करता है: मोड फ़्लैग छोड़ने पर फ़ॉरवर्ड-प्रॉक्सी मोड चुना जाता है; intercept IP परत पर NAT इंटरसेप्शन की अपेक्षा करता है।

इसके बाद परिवहन सुरक्षा को अलग से देखें। एक HTTP प्रॉक्सी CONNECT के माध्यम से HTTPS ले जा सकता है। प्रॉक्सी तक TLS कनेक्शन के लिए संगत श्रोता और क्लाइंट कॉन्फ़िगरेशन आवश्यक है। गंतव्य ट्रैफ़िक को डिक्रिप्ट करना एक और वैकल्पिक क्षमता है।

केवल इसलिए कि गंतव्य URL HTTPS से शुरू होता है, प्रमाणपत्र निर्माण चालू करने वाला पुराना “HTTPS समाधान” नकल न करें। पहले क्लाइंट और श्रोता के बीच तालमेल ठीक करें। इसके बाद यदि वास्तविक TLS त्रुटि बची रहती है, तो वह जाँच के लिए अधिक उपयोगी त्रुटि होगी।