ปลายทางดั้งเดิมในการส่งต่อ TCP ไปยัง SOCKS แบบโปร่งใส

ไฟร์วอลล์เปลี่ยนตำแหน่งที่การเชื่อมต่อ TCP ไปถึงได้ แต่ด้วยการเปลี่ยนแปลงนั้นเพียงอย่างเดียว มันไม่สามารถสอนแอปพลิเคชันต้นทางให้พูด SOCKS ได้

เซิร์ฟเวอร์ SOCKS ทั่วไปคาดหวังการเจรจาที่อธิบายปลายทางที่ร้องขอ แอปพลิเคชันที่ไม่รู้จักพร็อกซีกลับส่งไบต์โพรโทคอลของตนเองทันที หากเปลี่ยนเส้นทางไบต์เหล่านั้นตรงไปยังตัวรับฟัง SOCKS ทั้งสองฝ่ายจะไม่เห็นด้วยกับข้อความแรก

องค์ประกอบที่ขาดหายไปคือตัวแปล

องค์ประกอบ TCP ไปยังพร็อกซีแบบโปร่งใสอยู่ระหว่างอินเทอร์เฟซเหล่านั้น มันค้นหาปลายทางที่แอปพลิเคชันร้องขอแต่แรก สร้างเซสชัน SOCKS หรือ HTTP CONNECT ที่เหมาะสม แล้วส่งต่อข้อมูลแอปพลิเคชันผ่านสตรีมที่เกิดขึ้น

บนเส้นทาง Linux iptables ซอร์สของ redsocks ดึงปลายทางที่เก็บรักษาไว้โดยใช้ SO_ORIGINAL_DST ระบบปฏิบัติการและวิธีการเปลี่ยนเส้นทางอื่นใช้กลไกที่แตกต่างกัน นี่เป็นคุณสมบัติของตัวเปลี่ยนเส้นทางและการตั้งค่าเครือข่าย ไม่ใช่คุณสมบัติของไคลเอนต์ SOCKS ทั่วไป

ข้อมูลปลายทางดั้งเดิมยังอธิบายด้วยว่าทำไมการย้ายกฎการเปลี่ยนเส้นทางจากโฮสต์พร็อกซีไปยังเกตเวย์ที่ไม่เกี่ยวข้องจึงไม่เทียบเท่ากันเสมอ กระบวนการที่รับต้องมีเมทาดาทาที่โหมดการดักจับของตนกำหนด ที่อยู่ที่เขียนใหม่ที่อื่นอาจไม่ให้ข้อมูลนั้นในรูปแบบที่คาดหวังอีกต่อไป

รักษาขอบเขตของตัวแปลให้ชัดเจน การเชื่อมต่อ TCP ที่เปลี่ยนเส้นทางแล้วและทำงานได้ไม่ได้พิสูจน์การรองรับ UDP ตามอำเภอใจ ICMP หรือทุกเส้นทางของตัวแปลงชื่อ โพรโทคอลพร็อกซีต้นน้ำและการนำตัวแปลไปใช้ยังคงกำหนดการดำเนินการที่รองรับ

เมื่อการตั้งค่าล้มเหลวทันทีหลังการเชื่อมต่อ ให้ตรวจสอบขอบเขตโพรโทคอลก่อนขยายกฎการเข้าถึง ตัวรับฟัง SOCKS ที่เข้าถึงได้สมบูรณ์ก็ยังอาจปฏิเสธไบต์ที่ไม่เคยเป็นคำขอ SOCKS