Squid SO_ORIGINAL_DST त्रुटी वाचणे

NF getsockopt(SO_ORIGINAL_DST) मूळ गंतव्याच्या शोधाकडे निर्देश करतो. इंटरसेप्शन सेटअपमध्ये, पुनर्निर्देशित कनेक्शन सुरुवातीला कुठे जात होते हे Squid ला पुन्हा शोधावे लागते.

स्पष्टपणे कॉन्फिगर केलेला ब्राउझर आपल्या विनंत्या जाणीवपूर्वक प्रॉक्सीकडे पाठवतो. Squid श्रोत्याच्या पोर्टजवळ intercept लिहिलेले आहे या एकाच कारणाने त्या कनेक्शनला NAT इंटरसेप्शनचा इतिहास मिळत नाही.

त्यामुळे ही विसंगती गंतव्याचे प्रमाणपत्र संबंधित होण्यापूर्वीच अपयशी ठरू शकते.

कनेक्शन कसे आले यापासून सुरुवात करा

• अ‍ॅप्लिकेशनमध्ये प्रॉक्सी पत्ता कॉन्फिगर केलेला असल्यास, त्याने वापरावा असे नेहमीचे फॉरवर्ड-प्रॉक्सी श्रोता निश्चित करा.
• गेटवे अन्यथा थेट असलेला रहदारी पुनर्निर्देशित करत असल्यास, तो इच्छित इंटरसेप्शन श्रोत्यापर्यंत पोहोचतो का आणि समर्थित NAT रचना आवश्यक गंतव्य माहिती जपते का ते तपासा.
• दोन्ही मोड असल्यास, अपयशी ठरणार्‍या क्लायंटने प्रत्यक्षात कोणत्या पत्त्याशी आणि पोर्टशी संपर्क साधला ते तपासा.

Squid चे http_port दस्तऐवज फरक स्पष्ट करतात: मोड फ्लॅग वगळल्यास फॉरवर्ड-प्रॉक्सी मोड निवडला जातो; intercept IP स्तरावर NAT इंटरसेप्शनची अपेक्षा करतो.

नंतर वाहतूक सुरक्षा वेगळी हाताळा. HTTP प्रॉक्सी CONNECT द्वारे HTTPS वाहून नेऊ शकते. प्रॉक्सीकडे TLS कनेक्शनासाठी सुसंगत श्रोता आणि क्लायंट कॉन्फिगरेशन आवश्यक आहे. गंतव्य रहदारी डिक्रिप्ट करणे ही आणखी एक ऐच्छिक क्षमता आहे.

गंतव्य URL HTTPS ने सुरू होते या कारणाने प्रमाणपत्र निर्मिती सुरू करणारे जुने “HTTPS उपाय” कॉपी करू नका. आधी क्लायंट आणि श्रोता यांच्यातील सुसंगती दुरुस्त करा. त्यानंतर खरी TLS त्रुटी राहिल्यास, ती तपासण्यासाठी अधिक उपयुक्त त्रुटी ठरेल.