पारदर्शक प्रॉक्सी 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 ला आवश्यक गंतव्य माहिती द्यावी लागेल. सममितीय परतीचे राउटिंग ही टाइमआउट यंत्रणा सोडवते, संपूर्ण पारदर्शक-प्रॉक्सी कॉन्फिगरेशन नाही.

संबंधित लेख