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

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

ชั้นไม่ได้บวกกัน แต่มีปฏิสัมพันธ์ต่อกัน

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

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

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

ลำดับเป็นตัวกำหนดว่าอะไรถูกขนส่งได้

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

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

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

OrderWhat must resolve the endpointWhat usually breaks
VPN, then TorThe tunnel's resolverEntry guards blocked by the VPN provider's filters
Tor, then VPNThe SOCKS proxy, remotelyUDP transports, which Tor does not carry
App proxy on topThe application itselfProxy bypass rules and cached connections

การหาจุดแรกที่แตก

ทดสอบแต่ละขั้นตามลำดับที่แพ็กเก็ตเดินทาง ด้วยคำขอที่ไม่เป็นอันตราย และหยุดที่จุดแรกที่ล้มเหลว จดว่าคำสั่งใดรันก่อน เพราะลำดับเป็นส่วนหนึ่งของหลักฐาน สองคำสั่งแยกวงจรที่ตายออกจากทางออกที่ตาย:

curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip
curl -4 -s https://api.ipify.org; echo

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

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

เมื่อไรควรหยุดเพิ่มชั้น

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

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

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

บทความที่เกี่ยวข้อง