पारदर्शी प्रॉक्सी DNAT: वापसी मार्ग क्यों मायने रखता है

समझें कि DNAT किसी अनुरोध को अलग प्रॉक्सी तक क्यों पहुँचा सकता है जबकि उत्तर गेटवे को छोड़ देता है और कनेक्शन टूट जाता है।

रीडायरेक्ट किया गया SYN Squid तक पहुँच सकता है जबकि क्लाइंट अभी भी टाइमआउट में हो। DNAT सेटअप में वापसी पैकेट को भी उस गेटवे तक पहुँचना चाहिए जिसके पास अनुवाद की स्थिति है।

इस काल्पनिक LAN पर विचार करें:

client 192.168.40.25 → gateway 192.168.40.1
                         DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directly

क्लाइंट मूल रूप से किसी वेबसाइट पते से जुड़ा था। DNAT के बाद प्रॉक्सी क्लाइंट का स्रोत देखता है और सीधे उत्तर देने के लिए स्थानीय सबनेट मार्ग का उपयोग कर सकता है। वह उत्तर गेटवे के उल्टे अनुवाद को चूक जाता है और अपेक्षित वेबसाइट पते के बजाय प्रॉक्सी पते से क्लाइंट तक पहुँच सकता है। गेटवे उन पैकेटों को ठीक नहीं कर सकता जो उसे कभी मिले ही नहीं।

दृष्टिकोणपरिणाम
प्रॉक्सी के उत्तरों को अनुवाद करने वाले गेटवे से होकर भेजनाआने वाला प्रॉक्सी कनेक्शन क्लाइंट का स्रोत पता बनाए रख सकता है
उपयुक्त स्रोत अनुवाद भी लागू करनाप्रॉक्सी गेटवे को उसका साथी मानकर उत्तर देता है, परंतु अब मूल क्लाइंट के बजाय वही अनूदित स्रोत देखता है

सुंदर लॉग के लिए SNAT को वापसी मार्ग जाँचे बिना न हटाएँ। इसे व्यापक रूप से लागू करने से स्रोत ACL और एट्रिब्यूशन भी बदलते हैं; उस परिणाम को डिज़ाइन का हिस्सा मानें।

एक विश्वसनीय HTTP हॉप फ़ॉरवर्डिंग हेडर में क्लाइंट मेटाडेटा भेज सकता है, लेकिन NAT वह हेडर नहीं बनाता और न ही उसे TCP साथी पहचान में बदलता है। Squid तक के कनेक्शन पर स्रोत सुरक्षित रखना उसे Squid के अलग वेबसाइट कनेक्शन पर भी नहीं रखता।

अंत में, इंटरसेप्शन डिज़ाइन को अभी भी Squid को आवश्यक गंतव्य जानकारी देनी होगी। सममित वापसी राउटिंग इस टाइमआउट तंत्र को हल करती है, पूरे पारदर्शी-प्रॉक्सी कॉन्फ़िगरेशन को नहीं।

संबंधित लेख