ทดสอบการรั่วไหลของ WebRTC: VPN กำลังเปิดเผย IP จริงของคุณหรือไม่?
เครื่องมือทดสอบการรั่วไหลของ WebRTC นี้ทำงานผ่านกลไกการเชื่อมต่อแบบเพียร์ทูเพียร์ (peer-to-peer) เช่นเดียวกับสคริปต์ติดตามออนไลน์ เพื่อตรวจดูว่ามีที่อยู่ IP ใดบ้างที่ถูกเปิดเผยซึ่ง VPN ของคุณควรจะปกปิดไว้ โดยระบบจะเปิดการเชื่อมต่อ RTCPeerConnection พร้อมช่องข้อมูลว่างเปล่า — ไม่ใช้กล้อง ไม่ใช้ไมโครโฟน ไม่ขอสิทธิ์ — ส่งคำขอไปยังเซิร์ฟเวอร์ STUN สาธารณะ 2 แห่งเพื่อดูมุมมองการเชื่อมต่อของคุณจากภายนอก แล้วนำมาเปรียบเทียบกับ IP ที่ส่งคำขอ HTTPS ตามปกติ
วิธีอ่านค่า ICE candidates ที่ระบบตรวจพบ
WebRTC จำเป็นต้องค้นหาเส้นทางเครือข่ายทั้งหมดที่คู่สนทนาสามารถเชื่อมต่อกับคุณได้ จึงสร้างรายการที่เรียกว่า ICE candidates หน้านี้จะแสดงรายการข้อมูลดิบพร้อมระบุประเภทและโปรโตคอลการส่งข้อมูล และจะหยุดการค้นหาหลังจากผ่านไป 5 วินาที
ส่วนด้านบนคือที่อยู่ IPv4 และ IPv6 ทั่วไปที่ตรวจพบผ่าน HTTP — ซึ่งตรงกับค่าในหน้า ที่อยู่ IP ของฉันคืออะไร ค่าเหล่านี้คือเกณฑ์เปรียบเทียบมาตรฐาน และผลการวินิจฉัยจะตัดสินจากการจับคู่ของทั้งสองส่วนนี้
host, srflx และ relay — ป้ายกำกับเหล่านี้หมายถึงอะไร
- ภายใน (host) — ที่อยู่ของการ์ดเครือข่ายในอุปกรณ์ของคุณ: เช่น IP วงแลน
192.168.1.14หรือชื่อ.localแบบสุ่ม - สาธารณะ (ผ่าน STUN) — ผู้สมัคร
srflxซึ่งเป็นที่อยู่ภายนอกที่เซิร์ฟเวอร์ STUN ตรวจพบเมื่อได้รับแพ็กเก็ต เป็นจุดสำคัญที่สุดเมื่อเชื่อมต่อผ่าน VPN - รีเลย์ (TURN) — การรับส่งข้อมูลผ่านเซิร์ฟเวอร์ตัวกลาง เนื่องจากเครื่องมือนี้ใช้เฉพาะ STUN เท่านั้น แถวรีเลย์จึงปรากฏขึ้นได้ยากมาก
ความหมายของผลการทดสอบแต่ละรูปแบบ
- ตรวจพบการรั่วไหล — IP สาธารณะจาก STUN ไม่ตรงกับ HTTP IP ของคุณ แสดงว่าแพ็กเก็ต WebRTC เลี่ยงออกนอกอุโมงค์ VPN
- ไม่พบการรั่วไหล — IP ทั้งสองส่วนตรงกันอย่างสมบูรณ์
- IP ภายในรั่วไหล — ที่อยู่วงแลนจริงปรากฏขึ้นแทนที่จะเป็นชื่อ mDNS ที่ปิดบังไว้
- ได้รับการป้องกัน — ที่อยู่ภายในได้รับการปกป้องภายใต้ชื่อโฮสต์
.localแบบสุ่ม - ไม่พบ IP สาธารณะ / WebRTC ถูกบล็อก — ไม่สามารถติดต่อเซิร์ฟเวอร์ STUN ได้ หรือ WebRTC ถูกปิดใช้งานในเบราว์เซอร์
ทำไม WebRTC ถึงทำ IP หลุดทั้งที่เชื่อมต่อ VPN อยู่
WebRTC ถูกออกแบบมาเพื่อการสื่อสารโดยตรงระหว่างเบราว์เซอร์ เช่น การสนทนาทางวิดีโอ การโทรด้วยเสียง และการโอนย้ายไฟล์ การเชื่อมต่อข้ามเราเตอร์จำเป็นต้องผ่าน NAT ซึ่งต้องการคำตอบจากภายนอกว่า: การเชื่อมต่อนี้ส่งมาจาก IP ใดกันแน่? เซิร์ฟเวอร์ STUN ทำหน้าที่ตอบคำถามนี้ และเว็บไซต์ทั่วไปสามารถสั่งการขั้นตอนนี้ผ่าน JavaScript ในเบื้องหลังได้อย่างเงียบเชียบ
สิ่งนี้กลายเป็นช่องโหว่ทันทีเมื่อคุณต้องการซ่อนที่อยู่จริง VPN ทั่วไปจะส่งข้อมูล HTTP ผ่านอุโมงค์ที่เข้ารหัส แต่ WebRTC จะส่งแพ็กเก็ต UDP ของตัวเองไปยัง STUN ซึ่งในระบบแบบ split-tunneling แพ็กเก็ต UDP เหล่านี้จะวิ่งออกทางเน็ตบ้านปกติ ส่วนขยาย VPN บนเบราว์เซอร์คือตัวอย่างที่ชัดเจนที่สุด: พวกมันทำหน้าที่เป็นพร็อกซีสำหรับเว็บเพจ แต่ไม่ได้ครอบคลุมโปรโตคอล UDP ของระบบ — ทำให้ผลตรวจนี้อาจขัดแย้งกับการ ตรวจสอบ VPN ผ่าน HTTP
ชื่อโฮสต์ .local แบบสุ่มไม่ใช่การรั่วไหลของข้อมูล
หากรายการ host แสดงข้อความเช่น 7b3f9c21-4d0a-48e7.local แทนที่จะเป็น 192.168.1.14 แสดงว่าระบบความปลอดภัยทำงานอย่างถูกต้อง นี่คือการอำพรางด้วย mDNS: เบราว์เซอร์จะสร้างชื่อมัลติคาสต์ DNS ชั่วคราวขึ้นมาแทนที่ IP แลนจริง ซึ่ง Chrome, Edge, Brave, Firefox และ Safari ล้วนเปิดใช้ฟังก์ชันนี้เป็นค่าเริ่มต้น — uBlock Origin ได้ยกเลิกตัวเลือก WebRTC ของตนเองไปในเวอร์ชัน 1.38 เนื่องจากเบราว์เซอร์จัดการเรื่องนี้ให้แล้ว ข้อควรระวังคือ: วิธีนี้ปกป้องเฉพาะ IP ภายในบ้านเท่านั้น ไม่ได้ป้องกัน IP สาธารณะรั่วผ่าน VPN และเว็บที่ได้รับสิทธิ์ไมโครโฟนหรือกล้องจะยังคงเห็น IP วงแลนจริงได้อยู่ดี
วิธีแก้ไขปัญหา WebRTC รั่วไหลบน Chrome และ Edge
เบราว์เซอร์ทั้งสองไม่มีปุ่มเปิดปิด WebRTC แบบตรงไปตรงมา และการตั้งค่าใน chrome://flags หรือ edge://flags ก็ไม่สามารถปิด WebRTC ได้อีกต่อไป วิธีการที่ใช้งานได้จริงในปัจจุบันมี 3 แนวทาง:
- ใช้โปรแกรม VPN เต็มรูปแบบระดับระบบปฏิบัติการ (Full-Tunnel) แทนการใช้ส่วนขยายในเบราว์เซอร์ หากแพ็กเก็ต UDP ทั้งหมดถูกบังคับเข้าอุโมงค์ STUN ก็จะเห็นได้เฉพาะ IP ของ VPN เท่านั้น
- ตั้งค่านโยบายการจัดการ IP ผ่านส่วนขยาย เครื่องมือเช่น WebRTC Leak Prevent จะช่วยเปลี่ยนค่า
chrome.privacy.network.webRTCIPHandlingPolicyเป็นdefault_public_interface_onlyหรือdisable_non_proxied_udpเพื่อหยุดการเปิดเผย IP ภายใน - ใช้นโยบายระดับระบบปฏิบัติการ (GPO/Registry) บน Windows ให้กำหนดนโยบาย
WebRtcIPHandlingใน Chrome หรือWebRtcLocalhostIpHandlingภายใต้SOFTWARE\Policies\Microsoft\Edgeเป็นAllowPublicInterfaceOnlyหรือDisableNonProxiedUdpจำเป็นต้องรีสตาร์ทเบราว์เซอร์และตรวจสอบที่edge://policy
วิธีปิดการทำงานของ WebRTC อย่างสมบูรณ์บน Firefox
Firefox เป็นเบราว์เซอร์บนคอมพิวเตอร์เพียงตัวเดียวที่มีสวิตช์ปิดการทำงานจริง เพียงพิมพ์ about:config ในแถบที่อยู่ กดยอมรับความเสี่ยง ค้นหา media.peerconnection.enabled แล้วดับเบิลคลิกเพื่อเปลี่ยนค่าเป็น false WebRTC จะถูกปิดการทำงานในทุกเว็บไซต์ทันทีโดยไม่ต้องรีสตาร์ท และหน้านี้จะรายงานว่าถูกบล็อก
นี่เป็นการตัดการทำงานโดยสิ้นเชิง: โปรแกรมประชุมงานผ่านเว็บอย่าง Google Meet, Teams, Discord และ Zoom จะไม่สามารถเชื่อมต่อสายได้ หากต้องการให้ใช้งานโทรได้ตามปกติ ให้ปล่อยค่านั้นเป็น true แล้วเปลี่ยน media.peerconnection.ice.default_address_only เป็น true แทน — Firefox จะรายงานเฉพาะที่อยู่ของเส้นทางหลัก (ซึ่งก็คือ VPN)
วิธีป้องกันการรั่วไหลของ WebRTC บนเบราว์เซอร์ Brave
Brave นำเสนอเมนูควบคุมที่ Chrome ซ่อนไว้ ให้ไปที่ brave://settings/privacy แล้วค้นหาหัวข้อ WebRTC IP handling policy เมื่อใช้งานร่วมกับ VPN หรือพร็อกซี มีตัวเลือกสำคัญดังนี้:
- Default — สแกนทุกการเชื่อมต่อและอาจเปิดเผย IP ภายในเครื่อง
- Default Public and Private Interfaces — ใช้เส้นทางหลักแต่ยังคงแสดง IP ส่วนตัวที่ตรงกัน
- Default Public Interface Only — ใช้เฉพาะเส้นทางหลัก ปิดบัง IP ภายใน สายสนทนายังใช้งานได้ เป็นตัวเลือกที่ดีที่สุดสำหรับการใช้งานทั่วไป
- Disable Non-Proxied UDP — บังคับใช้ TCP ผ่านพร็อกซีหากพร็อกซีไม่รองรับ UDP ปลอดภัยสูงสุด (ค่าเริ่มต้นในหน้าต่าง Tor) แต่อาจทำให้การโทร P2P ใช้งานไม่ได้
ข้อควรทราบสำหรับ Safari, iPhone และอุปกรณ์ Android
บนอุปกรณ์พกพาและเทคโนโลยี WebKit คำแนะนำทั่วไปสำหรับคอมพิวเตอร์อาจใช้งานไม่ได้เสมอไป
Safari บน macOS
Safari รุ่นปัจจุบันไม่มีสวิตช์ปิดการทำงานแบบถาวร เมนูในส่วน Develop จะถูกรีเซ็ตเมื่อปิดโปรแกรม เนื่องจาก Safari ซ่อน IP ภายในด้วย mDNS จนกว่าจะอนุญาตให้ใช้กล้องหรือไมค์ การรับมือที่ดีที่สุดคือการคัดกรองสิทธิ์เว็บไซต์ใน Safari > การตั้งค่า > เว็บไซต์ ควบคู่กับการใช้ VPN ของระบบ
iPhone และ iPad (iOS/iPadOS)
เบราว์เซอร์ทุกตัวบน iOS ถูกบังคับให้ใช้เอนจิน WebKit ทำให้ Chrome หรือ Firefox บน iPhone ไม่มีหน้า about:config หรือส่วนขยาย ตัวบล็อกเนื้อหาก็ไม่สามารถกรอง WebRTC ได้ การแก้ปัญหาบน iOS ต้องอาศัยโปรไฟล์ VPN ใน การตั้งค่า > VPN ที่ส่งข้อมูล UDP เต็มรูปแบบ แล้วทดสอบซ้ำบน Safari
อุปกรณ์ระบบ Android
Chrome บน Android ไม่มีตัวเลือกหรือส่วนขยายสำหรับ WebRTC ส่วน Brave บน Android มีเมนูนโยบายจัดการ IP แบบเดียวกันในส่วนความเป็นส่วนตัว สำหรับ Firefox ต้องใช้รุ่น Beta หรือ Nightly เท่านั้นจึงจะเข้าถึง about:config ได้ ทางออกที่ดีที่สุดคือเปิด VPN ที่เปิดตลอดเวลา และ บล็อกการเชื่อมต่อที่ไม่มี VPN ในการตั้งค่า Android
สิ่งที่การทดสอบนี้ไม่สามารถตรวจจับได้
หน้านี้ตรวจสอบได้เฉพาะสิ่งที่เบราว์เซอร์ส่งให้กับสคริปต์ในเว็บไซต์นี้เท่านั้น ไม่สามารถตรวจจับการรั่วไหลที่อยู่ลึกลงไปในระดับระบบปฏิบัติการ — เช่น ปัญหาการกำหนดเส้นทางผิดพลาดของระบบ หรือช่องทาง IPv6 ที่ VPN ของคุณไม่ได้ครอบคลุม — และไม่ได้ทดสอบการรั่วไหลของ DNS นอกจากนี้ หากไฟร์วอลล์บล็อก STUN ระบบจะแจ้งว่า „ไม่พบ IP สาธารณะ“ ซึ่งหมายถึงไม่ได้รับคำตอบเท่านั้น ยิ่งไปกว่านั้น IP เป็นเพียงข้อมูลระบุตัวตนหนึ่งในหลายส่วน: ความละเอียดหน้าจอ ฟอนต์ และข้อมูลเบราว์เซอร์ที่แสดงในหน้า เบราว์เซอร์ของฉันคืออะไร ยังคงสามารถระบุอุปกรณ์ของคุณได้แม้ว่าจะใช้ VPN ก็ตาม
คำถามที่พบบ่อย (FAQ)
WebRTC สามารถทำ IP จริงของฉันรั่วไหลได้หรือไม่แม้จะเชื่อมต่อ VPN อยู่?
เกิดขึ้นได้จริงและพบบ่อยมาก WebRTC จะส่งแพ็กเก็ต UDP ตรงไปยังเซิร์ฟเวอร์ STUN ในกรณีที่ใช้ส่วนขยาย VPN บนเบราว์เซอร์หรือการแยกอุโมงค์ แพ็กเก็ต UDP มักจะเลี่ยงออกทางเครือข่ายอินเทอร์เน็ตจริงของคุณ STUN จะรับรู้ IP จริงจากผู้ให้บริการและเว็บไซต์สามารถอ่านค่านี้ผ่าน JavaScript ได้ การใช้แอปพลิเคชัน VPN แบบเต็มระบบจะช่วยปิดช่องโหว่นี้ได้สนิท
มีวิธีปิด WebRTC บนเบราว์เซอร์ Edge แบบสมบูรณ์หรือไม่?
ไม่สามารถทำได้ผ่านเมนูการตั้งค่าทั่วไป: Edge ไม่มีปุ่มเปิดปิด และตัวเลือกใน about:flags ถูกนำออกไปแล้ว บน Windows สามารถตั้งค่านโยบาย WebRtcLocalhostIpHandling เป็น AllowPublicInterfaceOnly หรือ DisableNonProxiedUdp ใน Registry ที่ SOFTWARE\Policies\Microsoft\Edge ต้องรีสตาร์ทเบราว์เซอร์และตรวจสอบที่ edge://policy
จุดปิดการทำงานของ WebRTC และ PeerConnection ใน Firefox อยู่ตรงไหน?
พิมพ์ about:config ในแถบที่อยู่: ค้นหา media.peerconnection.enabled แล้วดับเบิลคลิกเพื่อเปลี่ยนเป็น false ซึ่งจะปิด WebRTC ทันทีโดยไม่ต้องรีสตาร์ท แต่การสนทนาทางวิดีโอบนเว็บจะใช้งานไม่ได้ หากต้องการโทรต่อ ให้คงค่านั้นไว้แล้วเปลี่ยน media.peerconnection.ice.default_address_only เป็น true แทน
จะปิดการทำงานของ WebRTC ถาวรใน Safari ได้อย่างไร?
บน Safari รุ่นปัจจุบันไม่สามารถปิดถาวรได้ เมนูฟังก์ชันทดลองในอดีตถูกตัดทิ้ง และเมนูสำหรับนักพัฒนาจะรีเซ็ตทุกครั้งที่ปิดโปรแกรม เนื่องจาก Safari อำพราง IP ภายในด้วย mDNS อยู่แล้ว ทางออกที่ดีที่สุดคือการจำกัดสิทธิ์ใน Safari > การตั้งค่า > เว็บไซต์ ร่วมกับการเปิดใช้งานโปรแกรม VPN ทั่วทั้งระบบ
การตั้งค่าใดใน Brave ที่ป้องกันการรั่วไหลของ WebRTC ได้ดีที่สุด?
ไปที่ brave://settings/privacy และตั้งค่า WebRTC IP handling policy เป็น „Disable Non-Proxied UDP“ เมื่อใช้งานร่วมกับ VPN หรือพร็อกซี เพื่อบังคับให้ WebRTC ใช้ TCP ผ่านพร็อกซี ทำให้ STUN ไม่เห็น IP จริงของคุณ ส่วนตัวเลือก „Default Public Interface Only“ เหมาะสำหรับผู้ที่ต้องการโทรด้วยเสียงได้ตามปกติ
ฉันควรเลือกใช้นโยบายการจัดการ IP ของ WebRTC แบบใดดี?
ตัวเลือก „Default Public Interface Only“ เหมาะสำหรับผู้ใช้ส่วนใหญ่: ช่วยซ่อน IP เครือข่ายภายใน รองรับ UDP และทำให้การโทรแบบวิดีโอยังคงทำงานได้ตามปกติ เลือกใช้ „Disable Non-Proxied UDP“ เฉพาะเมื่อต้องการความเป็นส่วนตัวสูงสุดผ่านพร็อกซี/VPN สำหรับตัวเลือกเริ่มต้นยังคงเปิดเผย IP เครือข่ายภายในอยู่
ทำไม IP ส่วนตัวในวงแลนของฉันถึงถูกเผยแพร่ออกสู่สาธารณะผ่าน WebRTC?
ในเบราว์เซอร์ยุคปัจจุบันปัญหานี้จะไม่เกิดขึ้นตรงๆ Chrome, Edge, Brave, Firefox และ Safari จะแทนที่ IP แลนจริงด้วยชื่อโฮสต์ mDNS สุ่มที่ลงท้ายด้วย .local เว็บไซต์จะเห็นเฉพาะชื่อจำลองนั้นแทนที่จะเป็น 192.168.1.14 หากผลการทดสอบแสดง IP แลนแบบเปิดเผย แสดงว่าระบบป้องกัน mDNS ไม่ทำงาน