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

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

Privoxy จัดทำเอกสารการจัดวางนี้ผ่านกฎการส่งต่อ สำหรับอุโมงค์ SOCKS5 ภายในเครื่องที่มีอยู่แล้ว ส่วนหนึ่งของการกำหนดค่าคือ:

forward-socks5 / 127.0.0.1:1080 .

แอปพลิเคชันเชื่อมต่อกับตัวรับฟัง HTTP ของ Privoxy ไม่ใช่พอร์ต 1080 เก็บตัวรับฟังนั้นไว้ภายในเครื่องตามนโยบายการเข้าถึงที่ตั้งใจไว้ จุดท้ายในกฎมีความหมายที่จัดทำเอกสารไว้ มันไม่ใช่ตัวแทนสำหรับชื่อโฮสต์อินเทอร์เน็ตที่หายไป

นี่คือการแปลโปรโตคอล

เอกสารการส่งต่อของ Privoxy อธิบายไวยากรณ์การส่งต่อ SOCKS และการจัดการชื่อโฮสต์ การส่งต่อพอร์ต TCP ธรรมดาไม่ได้ทำการแปลแบบเดียวกัน มันขนส่งไบต์ HTTP ของไคลเอนต์โดยไม่เปลี่ยนแปลงไปยังตัวรับฟัง SOCKS ซึ่งยังคงคาดหวังการเจรจา SOCKS

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

สำหรับเว็บไซต์ HTTPS แอปพลิเคชันมักขอ CONNECT จากสะพาน HTTP และสะพานได้รับการเชื่อมต่อปลายทางผ่าน SOCKS TLS ปกติของเว็บไซต์ยังคงเป็นความสัมพันธ์ระหว่างแอปพลิเคชันกับเว็บไซต์ สะพานไม่จำเป็นต้องแอบอ้างเป็นเว็บไซต์เพื่อให้เส้นทางนี้

หากแอปพลิเคชันใช้ SOCKS ได้โดยตรง ส่วนประกอบเพิ่มเติมอาจไม่จำเป็น ใช้สะพานเพื่อแก้ไขความไม่ตรงกันของโปรโตคอลจริง โดยแยกตัวรับฟังและต้นน้ำอย่างชัดเจน

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