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 त्रुटि बाँकी रहे त्यो जाँचका लागि बढी उपयोगी त्रुटि हुनेछ।