วิธีตรวจ WebRTC Leak บน Chrome และ Firefox

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

บทความนี้พูดถึง ทดสอบ WebRTC Leak อย่างถูกวิธี อ่านผลบน Chrome และ Firefox อย่างไร แยก IP ภายในที่ไม่เป็นอันตรายออกจากการเปิดเผยจริงอย่างไร และต้องเปลี่ยนอะไรเมื่อเจอปัญหา ส่วนแนวคิดพื้นฐานอ่านได้ที่ WebRTC Leak คืออะไร ที่นี่เน้นตัวการทดสอบ

การทดสอบ WebRTC Leak มองหาอะไร

WebRTC เชื่อมสองฝั่งเข้าด้วยกันด้วยกระบวนการชื่อ ICE พูดง่ายๆ คือเบราว์เซอร์จะรวบรวมรายการ candidate แต่ละรายการคือเส้นทางหนึ่งที่อาจติดต่อมาถึงเครื่องคุณได้ และเพจอ่านรายการนั้นได้ด้วยสคริปต์ไม่กี่บรรทัด

candidate ที่คุณอาจเห็นมีสี่ชนิด

• Host candidate ที่อยู่บนอุปกรณ์หรือเครือข่ายภายในของคุณ เช่นที่อยู่ภายใน 192.168.1.20 ซึ่งตามกฎการจัดสรรที่อยู่อินเทอร์เน็ตเป็นช่วงส่วนตัว จึงแทบไม่มีความหมายนอกบ้านหรือสำนักงาน
• Server-reflexive candidate คือ IP สาธารณะที่เซิร์ฟเวอร์ผู้ช่วย (เรียกว่า STUN server) มองเห็นเมื่อเบราว์เซอร์ติดต่อไป ตัวนี้สำคัญที่สุด ถ้าเป็นที่อยู่ของผู้ให้บริการเน็ตคุณขณะเปิด VPN คือการรั่ว
• Relay candidate ที่อยู่ของเซิร์ฟเวอร์ตัวกลางที่ใช้เมื่อเชื่อมต่อตรงไม่ได้ พบเฉพาะบางการตั้งค่า
• ชื่อ mDNS เบราว์เซอร์สมัยใหม่มักแทนที่อยู่ภายในจริงด้วยชื่อสุ่มลงท้าย .local เพื่อไม่ให้เปิดเผยโครงสร้างเครือข่ายภายใน

เพจทดสอบก็แค่รวบรวม candidate เหล่านี้แล้วแสดงออกมา การทดสอบไม่ได้พิสูจน์ว่าเว็บใดแอบสอดแนม แต่แสดงว่าเว็บ ใดก็ได้ อ่านอะไรได้บ้าง มาตรฐานเบื้องหลังอธิบายไว้ใน ข้อกำหนด WebRTC ของ W3C และ คู่มือ WebRTC API ของ MDN อธิบายแนวคิดเดียวกันด้วยภาษาที่นักพัฒนาอ่านง่าย

เตรียมการทดสอบให้สะอาด จดค่าเริ่มต้นก่อน ส่วนเสริมทีหลัง

ผลลัพธ์มีประโยชน์ก็ต่อเมื่อมีอะไรให้เทียบ ทำขั้นตอนนี้ก่อนเปิด VPN

1. ปิด VPN แล้วรอ 10 วินาที
2. เปิดเพจทดสอบ WebRTC ในเบราว์เซอร์ที่ต้องการตรวจ ในหน้าต่างปกติ
3. คัดลอก candidate ทั้งหมด ทั้ง IP สาธารณะ IP ภายใน และชื่อ .local นี่คือค่าเริ่มต้นของคุณ IP สาธารณะตรงนี้ควรเป็นของผู้ให้บริการเน็ตคุณ
4. ดูว่าส่วนเสริมไหนเปิดอยู่ โปรแกรมบล็อกโฆษณา ส่วนเสริมด้านความเป็นส่วนตัว และส่วนเสริม VPN บางตัวเปลี่ยนพฤติกรรม WebRTC จดรายการไว้ ในการทดสอบครั้งแรกให้ใช้โปรไฟล์หรือหน้าต่างส่วนตัวที่ปิดส่วนเสริม เพื่อเห็นพฤติกรรมของเบราว์เซอร์เอง
5. จดเวอร์ชันเบราว์เซอร์ พฤติกรรมต่างกันตามเวอร์ชัน และคุณจะต้องใช้ข้อมูลนี้ตอนทดสอบซ้ำ

ค่าเริ่มต้นทำให้กติกาของการทดสอบหลักชัดเจน คือขณะ VPN เชื่อมต่ออยู่ รายการต้องไม่มี IP สาธารณะเดิมของคุณ

ถ้าอยากเทียบกับการตรวจรั่วทั่วไป ให้ทำตามขั้นตอนใน วิธีทดสอบ IP Address Leak หลังเปิด VPN ในเซสชันเดียวกัน WebRTC Leak แยกจากการรั่วของคำขอเว็บทั่วไป ผลที่สะอาดอย่างหนึ่งไม่ได้บอกอะไรเกี่ยวกับอีกอย่าง

ทดสอบบน Chrome

Chrome และเบราว์เซอร์ตระกูล Chromium ใช้พฤติกรรม WebRTC ส่วนใหญ่ร่วมกัน ทำตามลำดับนี้

1. เชื่อมต่อ VPN แล้วรอจนแอปบอกว่าเชื่อมต่อแล้ว
2. เปิดหน้าต่างไม่ระบุตัวตน (Incognito) ใหม่ ส่วนเสริมจะปิดอยู่เป็นค่าเริ่มต้น เว้นแต่คุณอนุญาตไว้
3. เปิดเพจทดสอบ WebRTC และรอให้รวบรวมเสร็จ อาจใช้เวลาไม่กี่วินาที
4. อ่านรายการทีละบรรทัดและถามว่า บรรทัดนี้เป็น IP ภายใน ชื่อ .local หรือ IP สาธารณะ
5. เทียบ IP สาธารณะทุกตัวกับค่าเริ่มต้นที่จดไว้
6. รีเฟรชอีกสองครั้ง การรวบรวม candidate อาจต่างกันเล็กน้อยในแต่ละรอบ
7. ทำซ้ำโดยเปิดส่วนเสริมทีละตัว ถ้าคุณใช้อยู่ ส่วนเสริมความเป็นส่วนตัวที่ปรับ WebRTC อาจตัดที่อยู่ที่เบราว์เซอร์จะแสดงออกไป

สิ่งที่มักเห็นใน Chrome เวอร์ชันปัจจุบันคือชื่อ .local แทนที่อยู่ภายในจริง บวก IP สาธารณะหนึ่งตัว เมื่อ VPN ทำงานถูกต้อง IP สาธารณะนั้นเป็นของ VPN ถ้าเห็น IP สาธารณะสองตัว ทั้ง IPv4 และ IPv6 ให้เทียบทั้งสองกับค่าเริ่มต้น เพราะตัวที่สองคือจุดที่การรั่วมักซ่อนอยู่ รูปแบบสั้นแบบเก่ากำหนดไว้ใน RFC 791 ส่วนพฤติกรรม IPv6 อธิบายไว้ใน บทความเรื่อง IP Leak

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

ทดสอบบน Firefox

Firefox เปิดเผยการตั้งค่าของตัวเองมากกว่า ซึ่งช่วยให้เข้าใจพฤติกรรมได้ดี

1. เชื่อมต่อ VPN และยืนยันว่าทำงานอยู่
2. เปิดหน้าต่างส่วนตัว (Private Window)
3. เปิดเพจทดสอบแล้วรอให้รวบรวม candidate
4. อ่านรายการและเทียบกับค่าเริ่มต้นเหมือนบน Chrome
5. ถ้าอยากทดลอง ให้พิมพ์ about:config ในช่องที่อยู่ แล้วกดยอมรับคำเตือน ค้นหา media.peerconnection.enabled
6. ตั้งค่านี้เป็น false เพื่อปิด WebRTC ของเบราว์เซอร์ แล้วโหลดเพจทดสอบใหม่ ควรไม่เห็น candidate เลย
7. ตั้งกลับเป็น true เมื่อทดลองเสร็จ เว้นแต่คุณแน่ใจว่าไม่ต้องใช้การโทรผ่านเบราว์เซอร์ เว็บประชุมวิดีโอ แชตเสียง และเครื่องมือแชร์ไฟล์บางตัวจะใช้ไม่ได้เมื่อปิด WebRTC

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

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

อ่านรายการ candidate ด้วยตารางตัดสินใจ

นี่คือวิธีจัดประเภทสิ่งที่เห็นขณะ VPN เชื่อมต่ออยู่

candidate ในรายการ	ตัวอย่าง	รั่วไหม	เหตุผล
ชื่อสุ่มลงท้าย .local	a1b2c3.local	ไม่	เบราว์เซอร์ซ่อนที่อยู่ภายในของคุณ
IPv4 ภายใน	192.168.1.20 หรือ 10.0.0.5	มักไม่	มีความหมายเฉพาะในเครือข่ายของคุณ
IP สาธารณะ ตรงกับทางออก VPN	ตรงกับผลตรวจ IP ปกติ	ไม่	ทราฟฟิกแสดงว่ามาจาก VPN
IP สาธารณะ ตรงกับค่าเริ่มต้น	ที่อยู่ของผู้ให้บริการเน็ตคุณ	รั่ว	ที่อยู่จริงถูกเปิดเผยให้เพจ
IPv6 สาธารณะ ตรงกับค่าเริ่มต้น	ที่อยู่เลขฐานสิบหกยาว	รั่ว	เส้นทาง IPv6 เลี่ยงอุโมงค์
ไม่มี candidate เลย	ว่าง	ไม่	WebRTC ถูกปิดหรือบล็อก การโทรอาจใช้ไม่ได้
ที่อยู่ Relay	ไม่ใช่ของผู้ให้บริการเน็ตคุณ	ไม่	เป็นของบริการตัวกลาง

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

ทดสอบการโทรจริง ไม่ใช่แค่เพจทดสอบ

เพจทดสอบแสดงสิ่งที่ถูกอ่านได้ การทดสอบการโทรแสดงสิ่งที่เกิดขึ้นจริง ขั้นตอนเพิ่มนี้ใช้เวลา 5 นาทีและจับปัญหาคนละชุด

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

สำหรับคนทำงานระยะไกล นิสัยที่ปลอดภัยที่สุดคือทดสอบสั้นๆ ก่อนประชุมลูกค้าสำคัญ แทนที่จะมาพบปัญหากลางการประชุม

เมื่อ IP สาธารณะรั่ว ควรเปลี่ยนอะไร

ไล่จากตัวเลือกที่กระทบน้อยที่สุดไปมากที่สุด

1. เชื่อมต่อ VPN ใหม่แล้วทดสอบซ้ำ บางครั้งการรวบรวมเกิดก่อนอุโมงค์พร้อมเต็มที่
2. อัปเดตเบราว์เซอร์ รุ่นใหม่มักจำกัดการเปิดเผยที่อยู่ได้ดีขึ้น
3. ทดสอบซ้ำในโปรไฟล์ที่สะอาด ไม่มีส่วนเสริม ถ้าการรั่วหายไป แปลว่าส่วนเสริมตัวใดตัวหนึ่งเป็นสาเหตุ
4. ใช้การตั้งค่าความเป็นส่วนตัวของเบราว์เซอร์เอง ถ้ามี เช่นค่าของ Firefox ที่กล่าวไป ในรูปแบบแคบที่สุดที่หยุดการเปิดเผยได้
5. ใช้ส่วนเสริมด้านความเป็นส่วนตัว ที่จำกัดการจัดการที่อยู่ของ WebRTC หากใช้เบราว์เซอร์ตระกูล Chromium ตรวจสิทธิ์และชื่อเสียงก่อน แล้วทดสอบซ้ำ
6. ปิด WebRTC ทั้งหมด เฉพาะเมื่อไม่ต้องใช้การโทรในเบราว์เซอร์นั้นเลย ลองใช้เบราว์เซอร์ตัวที่สองสำหรับประชุม
7. ใช้แอป VPN ทั้งระบบแทนส่วนเสริมเบราว์เซอร์ เพื่อให้อุโมงค์ครอบคลุมทั้งอุปกรณ์ ไม่ใช่เบราว์เซอร์ตัวเดียว การเทียบส่วนเสริมกับแอป อธิบายเหตุผล สำหรับ XPASS คือแอป VPNclient ที่ใช้ฟรี ล็อกอินด้วยข้อมูลในหน้า My Pass ดูที่ หน้าดาวน์โหลด

หลังแก้แต่ละอย่าง ให้ทดสอบอีกครั้ง อย่าเพิ่งสรุปว่าได้ผลจนกว่ารายการจะพิสูจน์

ข้อผิดพลาดที่พบบ่อยในการทดสอบ WebRTC

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

สรุป

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

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