พร็อกซี่ SOCKS5 สำหรับ OpenVPN: อุโมงค์ TCP หรือพร็อกซี่แอป?

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

ข้อจำกัดเดียวกำหนดการออกแบบ

SOCKS5 ระบุโหมดการเชื่อมโยง UDP จริง แต่การรองรับพร็อกซี่ของไคลเอนต์ OpenVPN กลับสร้างขึ้นรอบสตรีม: socks-proxy มีเอกสารระบุสำหรับโปรไฟล์ TCP และพร็อกซี่ HTTP CONNECT ไม่มีเส้นทางสำหรับดาต้าแกรมเลย เอกสารบรรทัดเดียวตัดสินสถาปัตยกรรมก่อนที่คุณจะแตะไฟล์กำหนดค่า

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

ตัวเลือก A: เปลี่ยนอุโมงค์ให้เป็นสตรีม

ต้องมีเซิร์ฟเวอร์ที่มีตัวรับฟัง TCP และโปรไฟล์ไคลเอนต์ที่ระบุพร็อกซี่ ทั้งสองส่วนจำเป็น และฝั่งเซิร์ฟเวอร์คือส่วนที่คนลืม:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

แทนที่บรรทัดสุดท้ายด้วย http-proxy proxy.internal 8080 เมื่อพร็อกซี่พูด HTTP และเพิ่มไฟล์ข้อมูลรับรองหากต้องการ พร็อกซี่ต้องยินดีทำ CONNECT ไปยังพอร์ต VPN ของคุณ และเซิร์ฟเวอร์ต้องตอบบน TCP ตัวรับฟังเฉพาะ UDP จะไม่สนใจความพยายามนั้น การเลือก 443 เป็นการตัดสินที่ใช้ได้จริง เพราะเครือข่ายจำกัดหลายแห่งอนุญาตเฉพาะพอร์ตนั้นและแทบไม่มีอย่างอื่น

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

ตัวเลือก B: ปล่อยอุโมงค์ไว้ตามเดิม

เมื่ออุโมงค์ต้องอยู่บน UDP การกำหนดค่าไม่ได้อยู่ที่อุโมงค์ แต่ TCP ขาออกจากแอปจะถูกเปลี่ยนเส้นทางไปยังตัวรับฟัง SOCKS ภายในเครื่อง และแอปไม่เคยรู้ว่ามีพร็อกซี่อยู่ บน Linux โดยทั่วไปคือ redsocks บวกกฎ NAT REDIRECT ในตาราง nat

อีกครั้งคือ TCP เท่านั้น พร็อกซี่แบบ HTTP เท่านั้นอย่าง privoxy ไม่สามารถส่งโปรโตคอลใดก็ได้ และการออกแบบนี้ไม่ได้เพิ่มการรองรับดาต้าแกรมให้แอปด้วย

การบอกแอปแต่ละตัวเกี่ยวกับพร็อกซี่โดยตรงมักดีกว่าเมื่อซอฟต์แวร์รองรับ ตรวจสอบได้ง่ายกว่า และล้มเหลวในจุดที่คุณมองเห็นได้จริง

แต่ละตัวเลือกพังตรงไหน

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

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

ทั้งสองตัวเลือกไม่เปลี่ยนข้อกำหนดของอุปกรณ์ แพ็กเก็ตยังต้องมีโหนด TUN หรือ TAP ก่อนที่เคอร์เนลจะกำหนดเส้นทาง ดังนั้นโปรเซสยังต้องมีสิทธิ์บน /dev/net/tun ตัวห่อเปลี่ยนสิ่งที่เกิดขึ้นหลังจากโหนดนั้นเปิดขึ้น ไม่ใช่ว่าคุณต้องมีมันหรือไม่

พิสูจน์ว่าคุณสร้างเส้นทางไหน

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

ss -tnp | grep openvpn

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

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