VPN ผ่าน Tor: ตรวจสอบการขนส่งก่อน

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

ทำการตรวจสอบตามลำดับ แต่ละข้อตัดสินว่าข้อถัดไปคุ้มค่าที่จะเริ่มหรือไม่

คุณกำลังสร้างลำดับแบบไหนกันแน่

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

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

ตรวจสอบการขนส่งก่อนสิ่งอื่นใด

อินเทอร์เฟซ SOCKS ของ Tor ขนส่งสตรีม TCP และไม่ได้ให้การเชื่อมโยง UDP ทั่วไป VPN ที่การขนส่งเป็น UDP ไม่สามารถถือพร็อกซีนั้นเป็นอินเทอร์เฟซเครือข่ายปกติได้ และไม่มีการตั้งค่าไคลเอนต์ใดเปลี่ยนสิ่งที่พร็อกซีพร้อมจะส่งต่อ WireGuard ในรูปแบบปกติคือเหยื่อที่ชัดเจน โปรไฟล์ OpenVPN ในโหมด TCP เป็นวิธีแก้ปัญหาทั่วไป และยังต้องบอกอย่างชัดเจนให้ใช้พร็อกซี

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

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

เขียนแผนที่ผู้สังเกตใหม่

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

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

นับชั้นของความล้มเหลวเมื่อมันพัง

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

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

หยุดหากแบบจำลองภัยคุกคามต้องการการป้องกันของ Tor Browser

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

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