พร็อกซีอาจครอบคลุมทราฟฟิก HTTP แต่ WebRTC แลกเปลี่ยน candidate address ผ่าน STUN/ICE บน UDP ได้ บทความนี้อธิบายว่า local และ private-network address อาจถูกเปิดเผยเมื่อใด และควรทำให้ network exit กับสภาพแวดล้อมของเบราว์เซอร์สอดคล้องกันอย่างไร
ตั้งค่าพร็อกซีเรียบร้อยแล้ว และหน้าเช็ก IP ก็แสดงภูมิภาคกับผู้ให้บริการอินเทอร์เน็ตตามที่คาดไว้ ดูเหมือนว่า network identity จะเรียบร้อยดี แต่เมื่อเปิดหน้าทดสอบการรั่วไหล ช่อง WebRTC กลับเป็นสีแดงและแสดงที่อยู่ของการเชื่อมต่ออินเทอร์เน็ตจริงของคุณ
ยังไม่จำเป็นต้องรีบเปลี่ยนพร็อกซี ในกรณีส่วนใหญ่ ปัญหาไม่ได้อยู่ที่คุณภาพของพร็อกซี แต่อยู่ที่ทราฟฟิกบางส่วนซึ่งพร็อกซีควบคุมไม่ได้
พร็อกซีจัดการ HTTP แต่ WebRTC ใช้อีกเส้นทางหนึ่ง
พร็อกซีทำงานที่ชั้นเครือข่าย ไม่ว่าจะเป็นส่วนขยายเบราว์เซอร์หรือ tunnel ระดับระบบ หน้าที่หลักคือจัดการคำขอ HTTP/HTTPS และส่งทราฟฟิกส่วนนั้นออกทาง proxy exit
WebRTC ทำงานต่างออกไป เป็นความสามารถด้านการสื่อสารแบบเรียลไทม์ที่มีอยู่ในเบราว์เซอร์ เพื่อให้การโทรเสียง/วิดีโอและการรับส่งแบบ P2P หาเส้นทางที่เหมาะสม เบราว์เซอร์อาจส่ง STUN query ไปยังเซิร์ฟเวอร์ภายนอกโดยตรง — โดยใจความคือถามว่า “ฝั่งคุณเห็นที่อยู่ของฉันเป็นอะไร?” — จากนั้นจึงจัดคำตอบเป็น ICE candidate แล้วส่งให้หน้าเว็บ Query เหล่านี้ใช้ UDP ซึ่งเป็นช่องทางที่แยกจาก HTTP tunnel
จึงเกิดความไม่สอดคล้องขึ้น: คำขอของหน้าเว็บออกผ่านพร็อกซี แต่เบราว์เซอร์อาจรายงาน local address ไปพร้อมกัน การคิดว่าตั้งค่าพร็อกซีแล้วเท่ากับ network identity ทั้งหมดสะอาดโดยอัตโนมัติ คือจุดเริ่มต้นที่พบบ่อยที่สุดของปัญหานี้
สิ่งที่อาจรั่วไม่ได้มีแค่ public IP
ICE candidate โดยทั่วไปมีที่อยู่สองประเภท ประเภทแรกคือ public address หรือทางออกของผู้ให้บริการอินเทอร์เน็ตจริง อีกประเภทคือ local address เช่น private address ที่ขึ้นต้นด้วย 192.168 และบางครั้งอาจมีที่อยู่ของ virtual network adapter ด้วย
Private-network address เพียงอย่างเดียวไม่ได้บอกอะไรมาก เพราะคอมพิวเตอร์แทบทุกเครื่องมีอยู่แล้ว แต่ที่อยู่นี้อาจมีความคงที่เพียงพอ เมื่อ candidate address ของหลายบัญชีซ้ำหรือทับกันหลายครั้ง แพลตฟอร์มก็อาจใช้เป็นสัญญาณเพิ่มเติมเพื่อเชื่อมโยงบัญชีเหล่านั้นเข้ากับอุปกรณ์เดียวกัน ส่วน public address ตรงกว่า เพราะชี้ไปยังผู้ให้บริการจริงและพื้นที่ทางภูมิศาสตร์โดยประมาณ ความละเอียดขึ้นอยู่กับการทำงานของแต่ละแพลตฟอร์ม แต่หลักการชัดเจนว่า ยิ่งที่อยู่ใกล้ความจริงมากเท่าไร ก็ยิ่งเชื่อมโยงได้ง่ายขึ้น
เว็บไซต์จะอ่านที่อยู่นี้ได้จริงเมื่อใด
ไม่ใช่ทุกเว็บไซต์ที่จะพยายามอ่าน การแลกเปลี่ยนที่อยู่ต้องให้หน้าเว็บสร้าง RTCPeerConnection object ขึ้นมาเอง ซึ่งหน้าเนื้อหาทั่วไปมักไม่จำเป็นต้องทำ
เว็บไซต์ที่อาจทำมักอยู่ในไม่กี่กลุ่ม ได้แก่ บริการที่ต้องใช้การสื่อสารแบบเรียลไทม์ เช่น การประชุมวิดีโอ ฝ่ายบริการลูกค้าออนไลน์ และหน้าสตรีมสดบางประเภท; เว็บไซต์ที่พึ่งพาโฆษณาหรือการป้องกันการทุจริตอย่างมาก; และแพลตฟอร์มที่มีระบบควบคุมความเสี่ยงค่อนข้างครบ การอ่านข้อมูลเหล่านี้เกิดขึ้นในส่วนที่ผู้ใช้มองไม่เห็น และหลังจากเก็บข้อมูลแล้ว คุณก็มักไม่ได้รับแจ้งว่าข้อมูลถูกนำไปใช้อย่างไร
ยังมีอีกกรณีที่ไม่เกี่ยวกับตัวเว็บไซต์โดยตรง ในช่วงสั้น ๆ ที่พร็อกซีกำลังเชื่อมต่อใหม่หรือเปลี่ยน node คำขอ STUN จากเบราว์เซอร์อาจออกผ่านเครือข่ายภายใน ช่วงเวลาสั้นมาก แต่เพียงพอให้ถูกบันทึกได้หนึ่งครั้ง
สามสถานการณ์ที่ล้มเหลวบ่อย
พร็อกซีแบบส่วนขยายเบราว์เซอร์มักควบคุมเฉพาะคำขอ HTTP/HTTPS ส่วน UDP อยู่นอกขอบเขต และการเลือกตัวเลือก “global” ในหน้าจอก็ไม่ได้เปลี่ยนข้อเท็จจริงนี้
พร็อกซีแบบ global ระดับระบบดูครอบคลุมกว่า เพราะรองรับทราฟฟิกของทั้งอุปกรณ์ แต่การเก็บ candidate address อาจ bind เข้ากับ local network interface โดยตรงและข้าม system routing table ได้ ทำให้ tunnel ยังมีช่องว่างในขั้นตอนนี้
ปัญหาที่สามไม่ใช่เรื่องเทคนิคเพียงอย่างเดียว แต่เกี่ยวกับการเปลี่ยนแปลงของระบบควบคุมความเสี่ยงด้วย ระบบเหล่านี้กำลังใช้ WebRTC address มากขึ้นในฐานะหนึ่งในหลายสัญญาณสำหรับเชื่อมโยงบัญชี ข้อมูลที่เมื่อก่อนวัดไม่ได้หรือถูกมองข้าม ตอนนี้อาจถูกนำมารวมในการตัดสิน
เป้าหมายคือให้ทางออกสอดคล้องกัน ไม่ใช่แค่ปิดสวิตช์เดียว
มีแนวทางหลักอยู่หลายแบบ หาก workflow ไม่จำเป็นต้องใช้การสื่อสารแบบเรียลไทม์เลย การปิด WebRTC เป็นวิธีที่ง่ายที่สุด แต่ต้องแลกกับการที่ฟังก์ชันอย่างวิดีโอคอลและฝ่ายบริการลูกค้าออนไลน์ใช้งานไม่ได้เช่นกัน
หากต้องเก็บฟังก์ชันเหล่านี้ไว้ วิธีที่ใช้บ่อยคือทำให้ address ที่ WebRTC layer ส่งกลับมาสอดคล้องกับ proxy exit วิธีที่มั่นคงกว่าคือส่ง STUN request ผ่าน proxy channel ด้วย เพื่อไม่ให้ interface เปิดเผย local address หากต้องใช้ P2P หรือวิดีโอคอล ควรให้ UDP traffic ทั้งหมดผ่านพร็อกซี ไม่ใช่จัดการเฉพาะ HTTP layer
ความเข้าใจผิดที่พบบ่อยคือคิดว่าปิด WebRTC อย่างเดียวแล้ว environment ทั้งหมดจะสะอาด สิ่งสำคัญคือ network exit, DNS resolution, ความเป็นเจ้าของ IP และ ASN, time zone และภาษา รวมถึงคุณลักษณะของอุปกรณ์ ต้องสอดคล้องกันทั้งหมด หากมีส่วนใดไม่ตรงกัน ก็อาจเกิดสัญญาณผิดปกติได้ WebRTC เป็นเพียงหนึ่งในองค์ประกอบที่ถูกมองข้ามได้ง่ายที่สุด
วิธีตรวจสอบทำได้ง่าย หลังเปลี่ยน node ให้ทดสอบหนึ่งครั้ง และทดสอบอีกครั้งก่อนใช้งาน environment จริง: เปิด leak test แล้วดูว่า WebRTC section แสดง proxy exit, local address หรือ public address จริง การเช็ก IP แบบทั่วไปจะไม่แสดงข้อมูลส่วนนี้
โซลูชันแยก environment ในระดับ browser engine สามารถกำหนด WebRTC address policy แยกสำหรับแต่ละ environment และจับคู่กับ network exit ของ environment นั้นได้ PurpleMark ให้ความสามารถในลักษณะนี้ หากหลาย environment ใช้ exit เดียวกัน หรือ address policy ของแต่ละ environment ไม่สอดคล้องกัน ประโยชน์ของการแยก environment จะลดลงมาก
เนื้อหาข้างต้นเป็นเพียงคำอธิบายหลักการทางเทคนิค โปรดใช้เครื่องมือที่เกี่ยวข้องโดยปฏิบัติตามกฎของแพลตฟอร์มและกฎหมายท้องถิ่น
