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 ไม่ได้สร้างส่วนหัวนั้นหรือเปลี่ยนให้เป็นตัวตนของ peer TCP การรักษาต้นทางบนการเชื่อมต่อไปยัง Squid ก็ไม่ได้รักษาไว้บนการเชื่อมต่อเว็บไซต์แยกของ Squid เช่นกัน

สุดท้าย การออกแบบการดักจับยังต้องให้ ข้อมูลปลายทางที่ Squid ต้องการ การกำหนดเส้นทางขากลับแบบสมมาตรแก้กลไกการหมดเวลานี้ ไม่ใช่การกำหนดค่าพร็อกซีโปร่งใสทั้งหมด

บทความที่เกี่ยวข้อง