DNAT للوكيل الشفاف: لماذا يهم مسار الإرجاع

قد يصل SYN المعاد توجيهه إلى Squid بينما يظل العميل في مهلة انتظار. في إعداد DNAT، يجب أن تصل حزمة الإرجاع أيضًا إلى البوابة التي تملك حالة الترجمة.

تخيل هذه الشبكة المحلية الافتراضية:

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. توجيه الإرجاع المتماثل يحل آلية المهلة هذه، لا إعداد الوكيل الشفاف بأكمله.