รายการผู้สมัคร WebRTC เผยอะไรเกี่ยวกับ VPN ของคุณ
ผู้สมัครแบบโฮสต์ แบบสะท้อนจากเซิร์ฟเวอร์ หรือแบบรีเลย์ บอกว่าที่อยู่มาจากไหน มีเพียงคู่ ICE ที่ถูกเลือกเท่านั้นที่บอกว่าเส้นทางใดถูกใช้จริงโดยสื่อ
เมื่อหน้าทดสอบ WebRTC พิมพ์ 172.20.4.15 แสดงว่าเพจนั้นได้รู้ว่ามีอินเทอร์เฟซภายในเครื่องอยู่ในเครือข่ายนั้น นี่คือการเปิดเผยจริง และไม่ใช่ข้อสรุปเดียวกับ «สื่อออกไปทางทางออก VPN» การค้นหาผู้สมัครและการกำหนดเส้นทางแพ็กเก็ตเป็นกลไกแยกกัน และรายงานการรั่วไหลส่วนใหญ่มักรวมทั้งสองเป็นคำตัดสินเดียว สิ่งที่คุณกำลังดูอยู่คือตัวกำหนดวิธีแก้
การรวบรวมเกิดขึ้นก่อนที่จะส่งอะไรออกไป
เบราว์เซอร์จะแจกแจงอินเทอร์เฟซภายในเครื่อง ส่งคำขอผูกกับเซิร์ฟเวอร์ STUN และขอการจัดสรรจากเซิร์ฟเวอร์ TURN จากนั้นจึงเขียนผลลัพธ์ลงในคำอธิบายเซสชันเป็นบรรทัดผู้สมัคร ทั้งหมดนี้เสร็จสิ้นโดยไม่มีการเรียก ไม่มีสื่อ และไม่มีคู่สนทนา รายการผู้สมัครจึงเป็นบันทึกของการค้นพบ ไม่ใช่ของการส่งข้อมูล
เบราว์เซอร์สมัยใหม่อาจแทนที่ที่อยู่จริงของผู้สมัครแบบโฮสต์ด้วยชื่อ mDNS .local ทำให้เพจไม่สามารถอ่าน IP ส่วนตัวได้ เครือข่ายภายในยังคงเห็นคำถามแบบมัลติแคสต์ที่แปลงชื่อนั้น ดังนั้นที่อยู่จึงถูกซ่อนจากแอปพลิเคชันแทนที่จะถูกลบออกจากสาย
ลำดับก็สำคัญเช่นกัน: การโหลดหน้าใหม่จะรวบรวมชุดใหม่ ด้วยการจัดสรร TURN อีกแบบและอาจมีการแมปแบบสะท้อนที่ต่างออกไป การรันสองครั้งที่ให้ผลต่างกันไม่จำเป็นต้องเป็นการตั้งค่าสองแบบที่ต่างกัน
ผู้สมัครสามประเภท หลักฐานสามชนิด
แต่ละบรรทัดมาจากการสังเกตที่ต่างกัน แต่ละประเภทตอบคำถามที่ต่างกัน และตารางแยกประเภทตามสิ่งที่พิสูจน์ได้และพิสูจน์ไม่ได้
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
ผู้สมัครแบบรีเลย์มักถูกเข้าใจผิดว่าเป็นที่อยู่อินเทอร์เน็ตของผู้ใช้ มันเป็นของเซิร์ฟเวอร์ TURN และการมีอยู่ของมันแสดงว่ามีรีเลย์พร้อมใช้ ไม่ได้แสดงว่าเบราว์เซอร์เลือกรีเลย์นั้น ความสับสนแบบเดียวกันเกิดขึ้นในทิศตรงข้ามกับผู้สมัครแบบโฮสต์ ซึ่งชื่อ mDNS ซ่อนที่อยู่จากเพจในขณะที่เครือข่ายยังคงส่งคำถาม อ่านประเภทก่อนอ่านค่า
คู่ที่ถูกเลือกตอบคำถามเรื่องเส้นทาง
ICE จับคู่ผู้สมัครภายในเครื่องทุกตัวกับผู้สมัครระยะไกลทุกตัว รันการตรวจสอบการเชื่อมต่อในแต่ละคู่ แล้วเสนอชื่อผู้ชนะ คู่ที่ถูกเสนอชื่อนั้น ซึ่งมองเห็นได้ในการวินิจฉัยของเบราว์เซอร์เอง เป็นตัวส่งสื่อ ส่วนที่เหลือในรายการคือความเป็นไปได้ที่แพ้ไปแล้ว
ผู้ชนะบอกคุณถึงรูปร่างของเส้นทาง รีเลย์ถึงรีเลย์ผ่านเซิร์ฟเวอร์ TURN คู่แบบโฮสต์ยังอยู่ในเครือข่ายภายใน และคู่แบบสะท้อนจากเซิร์ฟเวอร์ไปตรงผ่าน NAT นั่นคือข้อเท็จจริงที่การตรวจสอบ VPN ต้องการ และเป็นข้อเท็จจริงที่ต่างจากรายการที่อยู่ การเรียกสองครั้งที่มีรายการผู้สมัครเหมือนกันอาจใช้คู่ที่ต่างกัน
ผู้สมัครที่ไม่ได้ถูกเลือกก็ยังถูกเก็บรวบรวม และการรวบรวมคือทราฟฟิกเครือข่ายที่ออกจากเครื่อง การเรียกที่ใช้รีเลย์ในที่สุดไม่ได้หมายความว่าไม่มีอะไรถูกเปิดเผยระหว่างการสร้างรายการ
การควบคุมสอดคล้องกับเป้าหมาย ไม่ใช่คะแนนการรั่วไหล
ข้อกำหนดการจัดการ IP ของ WebRTC อธิบายนโยบายหลายอย่าง: ใช้อินเทอร์เฟซที่แบกเส้นทางเริ่มต้นเท่านั้น ใช้อินเทอร์เฟซทั้งหมด และปิด UDP ที่ไม่ผ่านพร็อกซีเพื่อให้ทราฟฟิกต้องผ่านรีเลย์หรือพร็อกซี แต่ละอย่างแลกการเชื่อมต่อและความหน่วงกับรูปแบบการเปิดเผยที่ต่างกัน เบราว์เซอร์ใช้แบบใดและในชื่อใดนั้นแตกต่างตามแพลตฟอร์มและเวอร์ชัน
เลือกนโยบายจากเป้าหมาย การซ่อนที่อยู่ภายในจากเพจเป็นเป้าหมายหนึ่ง การป้องกันทราฟฟิกแบบเพียร์ทูเพียร์โดยตรงเป็นอีกเป้าหมาย และการเก็บทุกแพ็กเก็ตไว้ในอุโมงค์เป็นเป้าหมายที่สาม เป้าหมายแรกเกี่ยวกับสิ่งที่แอปพลิเคชันได้รู้ เป้าหมายที่สองเกี่ยวกับเส้นทางที่ได้รับอนุญาต และเป้าหมายที่สามต้องบังคับใช้ที่ขอบของแพลตฟอร์มหรือ VPN ด้วย
ไม่ว่าคุณจะเลือกการควบคุมใด ตรวจสอบทั้งสองส่วน: รันการทดสอบการรวบรวมและบันทึกประเภทผู้สมัคร แล้วตรวจดูคู่ที่ถูกเลือกระหว่างเซสชันจริง รายการที่อยู่ที่สะอาดพร้อมเส้นทางสื่อโดยตรงก็ยังเป็นเส้นทางที่คุณไม่ได้ตั้งใจ