UDP ผ่านพอร์ต SOCKS ของ Tor: อะไรที่ไม่ผ่าน

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

ตรวจสอบว่าแอปส่งอะไรจริง ๆ

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

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

อินเทอร์เฟซ SOCKS ของ Tor จะรับอะไร

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

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

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

รันการตรวจตามลำดับ

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

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

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

ย้อนกลับและเลือกเครื่องมือที่ถูกต้อง

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

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