การตรวจจับการรั่วไหล · หมายเหตุทางเทคนิค

WebRTC Leak คืออะไร

WebRTC คือความสามารถในการสื่อสารแบบเรียลไทม์ที่มีมาในเบราว์เซอร์ ใช้กับการประชุมทางวิดีโอ การโทรด้วยเสียง การส่งไฟล์แบบ P2P และสถานการณ์อื่น ๆ ในการสร้างการเชื่อมต่อแบบ peer-to-peer เบราว์เซอร์จะค้นหาที่อยู่ฝั่งสาธารณะของตัวเองผ่านเซิร์ฟเวอร์ STUN การตรวจนี้มักใช้ UDP และ proxy แบบ HTTP / SOCKS ทั่วไปไม่จำเป็นต้องดักรับ UDP เสมอไป

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

วิธีอ่านผลลัพธ์

ทำอย่างไรเมื่อพบการรั่วไหล

• เปลี่ยนไคลเอนต์ proxy เป็นโหมด TUN เพื่อให้ UDP ของ WebRTC ออกผ่านขาออกของ proxy ด้วย
• Chrome / Edge: ตั้งนโยบายองค์กร <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code> ส่วน Firefox: เปิด <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> ใน <code>about:config</code> อย่าลบ WebRTC ทิ้งไปเลย เพราะเบราว์เซอร์ที่ไม่มี WebRTC ก็ถูกระบุตัวได้ในตัวเอง
• Brave: ตั้งนโยบายการจัดการ IP ของ WebRTC เป็น “Disable non-proxied UDP”
• เมื่อต้องใช้การประชุมหรือโทรด้วยเสียง ให้แก้ไขกฎการแยกเส้นทาง UDP / STUN ในไคลเอนต์ proxy ก่อน

IP ขาออกหลายตัวไม่จำเป็นต้องเป็นการรั่วไหล

หากคุณตั้งค่าการแยกเส้นทางไว้ เซิร์ฟเวอร์ STUN แต่ละตัวอาจวิ่งผ่านโหนดต่างกัน เช่น STUN ของ Google ผ่านขาออกในสหรัฐอเมริกา และ STUN ของ Cloudflare ผ่านขาออกในฮ่องกง กรณีนี้ไม่จำเป็นต้องอันตราย สิ่งสำคัญคือตรงกับกฎที่คุณออกแบบไว้หรือไม่ สิ่งที่ต้องระวังจริง ๆ คือเมื่อที่อยู่ WebRTC ทั้งหมดชี้ไปยังตำแหน่งจริงของคุณหรือ ISP ในพื้นที่

DNS Leak ก็สำคัญไม่แพ้กัน

WebRTC Leak เปิดเผย “IP จริงของคุณ” ส่วน DNS Leak เปิดเผย “โดเมนที่คุณค้นหา” หากคำขอ DNS ไม่ผ่าน proxy ผู้ให้บริการเครือข่ายในพื้นที่หรือ resolver upstream ก็ยังเห็นได้ว่าคุณเข้าเว็บไซต์ใดบ้าง

การตรวจ DNS Leak ในหน้านี้ใช้ probe จริง: CleanIP.io ให้บริการ NS ที่มีสิทธิ์ (authoritative) ที่รัฐยูทาห์ สหรัฐอเมริกา (ns1) และที่ลอสแอนเจลิส สหรัฐอเมริกา (ns2) แห่งละ 1 ตัว สำหรับโซน dp.cleanip.io การตรวจแต่ละครั้งจะ resolve ซับโดเมน <uuid>.dp.cleanip.io ที่แยกกัน 8 รายการ คำขอเหล่านี้จะผ่าน stub resolver ของระบบคุณ -> ISP / VPN / recursive resolver สาธารณะ และไปสิ้นสุดที่ NS ที่มีสิทธิ์ของเรา ซึ่งจะบันทึก IP ของ resolver ที่ส่งคำขอและ EDNS Client Subnet (ถ้ามี) แล้วส่งกลับมาให้คุณเปรียบเทียบ

ดูสัญญาณ 2 อย่างเป็นหลัก: ① ซับเน็ต ECS — หาก recursive resolver ส่งต่อซับเน็ตของไคลเอนต์คุณ (พบบ่อยกับ Google 8.8.8.8) ซับเน็ตนั้นคือหลักฐานชัดเจนที่ระบุตัวไคลเอนต์ของคุณ ② ประเทศของ resolver — การใช้ anycast ข้ามประเทศของ recursive resolver สาธารณะ (1.1.1.1 / 8.8.8.8) เป็นเรื่องปกติ สิ่งสำคัญคือเมื่อคุณคิดว่าเปิด VPN อยู่ ตำแหน่งของ resolver ตรงกับประเทศของขาออก HTTP หรือไม่

ทำไมโหมด proxy กับโหมด TUN จึงให้ผลต่างกัน

Proxy แบบ HTTP / SOCKS มักจัดการเฉพาะ TCP ดังนั้น UDP ที่ STUN ต้องใช้อาจส่งไม่ออก และหน้าเว็บอาจแสดงว่า “ไม่รั่วไหล” แต่นั่นไม่ได้หมายความว่า UDP ถูกส่งผ่าน proxy อย่างปลอดภัย เพียงแค่ UDP ไม่เคยไปถึงเซิร์ฟเวอร์ STUN เท่านั้น โหมด TUN ดักรับทั้ง TCP และ UDP บนอะแดปเตอร์เครือข่ายเสมือน จึงสะท้อนเส้นทางขาออก UDP จริงได้ดีกว่า