VPN ก่อน Tor: ลำดับเปลี่ยนอะไรจริง ๆ

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

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

ลำดับเปลี่ยนอะไร

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

หลังผู้เฝ้าทางเข้าวงจรทำงานเหมือนเดิม รีเลย์ยังแยกบทบาททางเข้า กลาง และทางออก และ VPN ไม่เห็นเนื้อหาสุดท้ายมากกว่า ISP ของคุณ

ยืนยันเส้นทางที่ใช้จริง

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

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

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

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

ดูว่าเกิดอะไรขึ้นเมื่ออุโมงค์หลุด

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

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

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

ตัดสินใจว่าชั้นเพิ่มเติมสมควรได้รับความไว้วางใจหรือไม่

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

ลำดับย้อนกลับก็มีอยู่ และชื่อเหล่านี้ใช้แทนกันไม่ได้:Tor over VPN และ VPN over Tor อธิบายความสัมพันธ์ของความไว้วางใจที่ต่างกัน และพฤติกรรมเมื่อล้มเหลวที่ต่างกัน อ่านการเปรียบเทียบก่อนนำมาผสมกัน

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