เชื่อมไคลเอนต์ SOCKS เข้ากับพาเรนต์ HTTP CONNECT ด้วย 3proxy

แอปพลิเคชันต้องใช้ SOCKS บริการต้นทางที่ได้รับอนุมัติของคุณรับ HTTP CONNECT การใส่ปลายทาง HTTP ลงในช่อง SOCKS ของแอปพลิเคชันไม่ได้แปลระหว่างโปรโตคอล

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

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

ทำให้แต่ละอินเทอร์เฟซชัดเจน

สำหรับเกตเวย์ที่รองรับการจัดวางนี้ ชนิดของพาเรนต์มีความสำคัญ เอกสารของ 3proxy แยกพาเรนต์ connect ออกจากพาเรนต์ที่ใช้เป็นพร็อกซีส่งต่อ HTTP ทั่วไป

เมื่อมีผู้ใช้ 3proxy และการพิสูจน์ตัวตนอยู่แล้ว ส่วนการกำหนดเส้นทางภายในเครื่องเท่านั้นอาจมีรูปแบบดังนี้

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

ส่วนนี้ถือว่าบัญชีถูกกำหนดไว้แล้ว ไม่ได้เพิ่มข้อมูลรับรองใด ๆ ที่พาเรนต์ HTTP เองต้องการ และไม่ได้แทนที่นโยบายการเข้าถึงที่มีอยู่ สำหรับปลายทางสาธารณะบนเส้นทางที่อนุญาตพาเรนต์ HTTP สาธารณะที่ไม่มีการพิสูจน์ตัวตน รายการพร็อกซี HTTP เสนอโฮสต์และพอร์ตที่เป็นไปได้ สำหรับสาขานั้นให้ละเว้นข้อมูลรับรองของพาเรนต์และยืนยันสิทธิ์สำหรับเป้าหมายจริง บัญชีของเกตเวย์เองยังคงเป็นภายในเครื่อง กฎ parent เชื่อมโยงกับกฎ allow ก่อนหน้าตามรูปแบบการกำหนดค่าที่บันทึกไว้ใน 3proxy

แอปพลิเคชันใช้ปลายทาง SOCKS ภายในเครื่อง เกตเวย์ใช้ HTTP CONNECT ไปยังพาเรนต์ พาเรนต์ยังคงตัดสินว่าโฮสต์และพอร์ตปลายทางที่ร้องขอได้รับอนุญาตหรือไม่

ขอบเขตที่เป็นประโยชน์ที่นี่คืออุโมงค์สตรีม TCP ทั่วไป การเชื่อมโยง UDP ของ SOCKS5 ไม่ได้รับการสนับสนุนเพียงเพราะตัวรับฟังด้านหน้ายอมรับ SOCKS5 พาเรนต์ HTTP CONNECT ไม่ได้ให้รีเลย์ UDP ที่จำเป็นโดยอัตโนมัติ

HTTPS สามารถคงอยู่แบบปลายถึงปลายภายในเส้นทางนี้ การแปลระหว่างอินเทอร์เฟซพร็อกซีไม่จำเป็นต้องแอบอ้างเป็นเว็บไซต์ปลายทาง การพิสูจน์ตัวตนกับเกตเวย์ กับพาเรนต์ และกับเว็บไซต์ยังคงเป็นข้อมูลรับรองและการแลกเปลี่ยนที่แตกต่างกัน