पठाइएको 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 लाई आवश्यक गन्तव्य जानकारी दिनुपर्छ। सममित फर्किने राउटिङले यो समय-समाप्ति संयन्त्र समाधान गर्छ, सम्पूर्ण पारदर्शी-प्रोक्सी कन्फिगरेसन होइन।

सम्बन्धित लेखहरू