การเชื่อมต่อแบบ IPv6 เท่านั้น บริการ IPv4: ให้ SOCKS พร็อกซีเป็นสะพาน

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

สองซ็อกเก็ต สองตระกูลที่อยู่

คำขอ SOCKS5 ระบุปลายทางในหนึ่งในสามรูปแบบ: ที่อยู่ v4 แบบตรงตัว ที่อยู่ v6 แบบตรงตัว หรือชื่อที่ให้พร็อกซีแก้ไข คำขออธิบายว่าพร็อกซีควรเชื่อมต่อที่ใด ไม่ใช่ว่าการเชื่อมต่อจากลูกค้าไปยังพร็อกซีมีลักษณะอย่างไร

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

ตัวอย่าง SSH ที่ควบคุมได้

เลือกโฮสต์ SSH ที่คุณได้รับอนุญาตให้ใช้ ซึ่งตอบสนองบน IPv6 และสามารถเข้าถึงบริการ HTTPS ที่มีอยู่เฉพาะบน v4 ได้ด้วยตัวเอง การส่งต่อแบบไดนามิกของ OpenSSH วางตัวรับฟัง SOCKS ภายในเครื่องของคุณขณะที่เซสชันเข้าสู่ระบบทำงานผ่าน v6

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

โฮสต์และบัญชีข้างต้นเป็นเพียงตัวอย่าง และการผูกกับ loopback ทำให้ตัวรับฟังอยู่ในคอมพิวเตอร์เครื่องนี้ อย่าแทนที่ด้วยการผูกแบบไวลด์การ์ดเพื่อให้สำนักงานแบ่งปันพร็อกซีที่ไม่มีการพิสูจน์ตัวตน ExitOnForwardFailure=yes มีอยู่เพื่อให้การส่งต่อที่ล้มเหลวจบเซสชัน แทนที่จะปล่อยคำสั่งเงียบๆ ทำงานอยู่เบื้องหลัง

เมื่อเซสชันทำงานอยู่ คำขอมีลักษณะดังนี้:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

การเชื่อมต่อ loopback ไม่ใช่เส้นทางอินเทอร์เน็ต IPv4 สิ่งที่ออกจากเครื่องของคุณคือเซสชันเข้าสู่ระบบผ่าน v6 และฝั่งไกลเป็นผู้เปิดซ็อกเก็ตปลายทาง รูปแบบ socks5h ยังมอบการแก้ไขชื่อให้ฝั่งนั้นด้วย ซึ่งสำคัญเมื่อลูกค้าไม่มีเส้นทางการแก้ไข IPv4 ของตนเอง

สิ่งที่ปลายทางเห็นจริง

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

ตัวส่งต่อยังเป็นจุดที่ทั้งสองครึ่งของการสนทนามองเห็นได้ ซึ่งเป็นคุณสมบัติที่มีประโยชน์ระหว่างการวินิจฉัย และเป็นภาระหากตัวส่งต่อถูกแบ่งปันโดยไม่มีนโยบาย

นี่ไม่ใช่ DNS64 หรือ NAT64

DNS64 ตอบด้วยระเบียนสังเคราะห์ที่ทำหน้าที่แทนปลายทาง v4 และ NAT64 เขียนแพ็กเก็ตใหม่ตามเส้นทางที่กำหนด ไม่มีทั้งสองอธิบายสิ่งที่เกิดขึ้นที่นี่ ซึ่งการสนทนาขนส่งหนึ่งสิ้นสุดและอีกอันเริ่มต้น และไม่มีที่อยู่สังเคราะห์ใดอธิบายผลลัพธ์ได้ คำขอที่สำเร็จจึงไม่ได้บอกอะไรเกี่ยวกับบริการแปลที่ผู้ให้บริการของคุณดำเนินการ และพร็อกซีอาจใช้ NAT ธรรมดาบนทางออกของตนเอง

กลไกทั้งสองสามารถมีอยู่ได้ในเครือข่ายเดียวกัน ดังนั้นจงอธิบายสิ่งที่คุณตรวจสอบจริง ไม่ใช่สิ่งที่ฟังดูใกล้เคียงที่สุด

รู้ขอบเขตก่อนจะสัญญา

การส่งต่อแบบไดนามิกของ OpenSSH ขนส่งการเชื่อมต่อ TCP ไม่ใช่ทราฟฟิก IP ตามอำเภอใจ ดังนั้น UDP, ICMP และโปรโตคอลใดๆ ที่เพิกเฉยต่อพร็อกซีจึงต้องมีรูปแบบที่รองรับต่างออกไป รักษาการตรวจสอบคีย์โฮสต์ SSH ข้อจำกัดการส่งต่อของเซิร์ฟเวอร์ และการตรวจสอบใบรับรอง HTTPS ไว้ เพราะพร็อกซีเป็นผู้มีส่วนร่วมที่เชื่อถือได้เพิ่มเติม ไม่ใช่เหตุผลที่จะทำให้การตรวจสอบตัวตนอ่อนแอลง หากเป้าหมายคือการขนส่งภายนอกของ VPN ผ่านพร็อกซี ให้ตรวจสอบว่าทั้งสองฝั่งรองรับการขนส่งนั้น แทนที่จะสันนิษฐานว่าตัวรับฟัง SOCKS ใดก็ได้สามารถส่งต่อได้

ไม่มีสิ่งใดในนี้ทำให้ลูกค้าเป็น dual-stack และไม่จำเป็นต้องเป็น การทำเช่นนี้ทำให้แอปพลิเคชันหนึ่งเข้าถึงบริการหนึ่งผ่านตัวส่งต่อหนึ่ง ซึ่งเป็นการกล่าวอ้างที่เล็กกว่าและตรวจสอบได้ง่ายกว่ามาก