Kiểm tra rò rỉ WebRTC: ngăn chặn rò rỉ IP
Một proxy hoạt động tốt không tự động bảo vệ mọi kết nối của trình duyệt. Hãy dùng bài kiểm tra rò rỉ WebRTC để xác minh định tuyến, ngăn việc lộ IP ngoài ý muốn và giữ cho hoạt động trực tuyến của bạn an toàn, nhất quán. Dưới đây là hướng dẫn đầy đủ cách thực hiện.
WebRTC là gì
WebRTC (Web Real-Time Communication) là một tiêu chuẩn mở cho phép trình duyệt và ứng dụng trao đổi âm thanh, video và dữ liệu trực tiếp mà không cần plugin. WebRTC thường dùng UDP để truyền với độ trễ thấp, nhưng cũng hỗ trợ TCP và các kết nối qua relay.
Để thiết lập kết nối, WebRTC thu thập các ứng viên ICE (Interactive Connectivity Establishment): các điểm cuối mạng khả dụng, gồm địa chỉ, cổng và giao thức truyền tải. Các ứng viên này là nguồn gốc của mọi rò rỉ tiềm ẩn.
Nếu quá trình dò tìm đi qua tuyến không được bảo vệ, các ứng viên này có thể làm lộ một IP nằm ngoài kết nối proxy hoặc VPN mà bạn định dùng.
Vì sao proxy bị rò rỉ qua WebRTC
Rò rỉ WebRTC xảy ra khi quá trình dò tìm kết nối của trình duyệt làm lộ một địa chỉ mà cấu hình định tuyến của bạn lẽ ra phải che giấu. Bài kiểm tra rò rỉ WebRTC giúp bạn phát hiện điều đó.
Một trang web bắt đầu thu thập ứng viên WebRTC.
Trình duyệt liên hệ với máy chủ STUN để tìm địa chỉ công khai của mình.
Nếu kết nối đó đi vòng qua proxy, STUN sẽ thấy địa chỉ ISP của bạn.
Trình duyệt có thể cung cấp địa chỉ đó cho JavaScript của trang web thông qua một ứng viên ICE.
Cần nhớ:
Cài đặt proxy của trình duyệt không nhất thiết áp dụng cho lưu lượng WebRTC.
VPN full-tunnel được cưỡng chế đúng cách sẽ chuyển cả lưu lượng này; bản thân WebRTC không vô hiệu hóa mã hóa của VPN.
Vì sao rò rỉ WebRTC có thể làm lộ bạn
IP công khai bị lộ có thể tiết lộ nhà cung cấp mạng và vị trí gần đúng của bạn, nhưng không lộ tên hay địa chỉ chính xác. Nó cũng có thể dẫn đến:
Việc đối chiếu, liên kết các phiên trình duyệt vốn tách biệt.
Các hạn chế dựa trên vị trí.
Yêu cầu xác minh bổ sung hoặc xem xét tài khoản.
Đây là những hậu quả có thể xảy ra, không phải kết quả chắc chắn. Dù vậy, bạn nên thận trọng và kiểm tra rò rỉ WebRTC thường xuyên.
Hãy thận trọng và luôn kiểm tra cả rò rỉ DNS lẫn rò rỉ WebRTC. Đọc về bảo mật proxy và dữ liệu để biết thêm.
Sự khác biệt giữa rò rỉ DNS và rò rỉ WebRTC
Rò rỉ DNS liên quan đến việc các truy vấn tên miền đi qua đâu; rò rỉ WebRTC liên quan đến việc quá trình dò tìm kết nối làm lộ những địa chỉ nào. Bài kiểm tra này không thay thế được bài kia.
Tiêu chí | Rò rỉ DNS | Rò rỉ WebRTC |
Tầng & giao thức | Phân giải tên của hệ thống/ứng dụng; UDP/TCP 53, DoH, DoT | Kết nối của trình duyệt/ứng dụng; ICE, STUN, TURN, thường là UDP |
Thông tin bị rò rỉ | Tên miền đã truy vấn; bộ phân giải thấy nguồn truy vấn | Địa chỉ IPv4/IPv6 cục bộ hoặc công khai |
Ai biết được | Bộ phân giải; bên quan sát mạng nếu DNS không được mã hóa | Script của trang, các peer hoặc máy chủ dò tìm |
Rủi ro chính | Lộ hoạt động truy vấn tên miền | Bị nhận diện mạng ngoài ý muốn và bị đối chiếu các phiên |
Phạm vi | Toàn hệ thống, theo từng ứng dụng hoặc theo từng trình duyệt | Trình duyệt và ứng dụng hỗ trợ WebRTC |
Cơ chế kích hoạt | Phân giải DNS bên ngoài tuyến được bảo vệ như dự định | WebRTC thu thập ứng viên hoặc kiểm tra kết nối |
Bài kiểm tra DNS thường chỉ xác định các bộ phân giải đệ quy, chứ không phải IP công khai của thiết bị bạn. Một bộ phân giải bất thường cần được điều tra; chỉ riêng quốc gia của nó chưa chứng minh có rò rỉ.
Cách kiểm tra rò rỉ WebRTC
Về cơ bản, bài kiểm tra rò rỉ WebRTC là để xem IP thật của bạn có xuất hiện trong các ứng viên ICE mà trình duyệt hiển thị hay không. Một số dịch vụ có thể hỗ trợ, chẳng hạn BrowserLeaks, IPLeak hoặc công cụ WebRTC chính thức Trickle ICE trên GitHub.
1. Kiểm tra IPv4 và IPv6 thực của bạn khi không dùng proxy/VPN
Đóng các phiên làm việc nhạy cảm trước khi ngắt bảo vệ.
Mở IPLeak.
Ghi lại IPv4 công khai trực tiếp và IPv6 (nếu có).
Giữ kín các địa chỉ gốc này.
“No IPv6 detected” nghĩa là bài kiểm tra không thiết lập được kết nối IPv6, chứ không có nghĩa IPv6 sẽ không bao giờ khả dụng.
2. Bật mạng proxy/VPN và kiểm tra lại IP
Kết nối VPN hoặc cấu hình proxy CyberYozh App trong hồ sơ trình duyệt hoặc ứng dụng khách mà bạn định dùng.
Mở một tab kiểm tra mới.
Xác nhận IP công khai đã đổi thành IP đầu ra mong muốn.
Kiểm tra IPv4 và IPv6 riêng biệt.
IP duyệt web thay đổi chứng tỏ tuyến kết nối đã đổi, nhưng rò rỉ WebRTC vẫn có thể tồn tại.
3. Mở BrowserLeaks, IPLeak hoặc Trickle ICE của WebRTC
Chọn một công cụ kiểm tra rò rỉ WebRTC trực tuyến:
BrowserLeaks: xem mục “Your WebRTC IP” và nhật ký SDP.
IPLeak: dùng bài kiểm tra rò rỉ DNS và WebRTC kết hợp của công cụ này.
Trickle ICE: một mẫu thuộc dự án WebRTC; nhấp “Gather candidates” và xem các cột địa chỉ/loại. Đây là mẫu chẩn đoán, không phải chứng nhận quyền riêng tư toàn diện.
4. Kiểm tra IP thực của bạn có xuất hiện trong kết quả hay không
So sánh kết quả kiểm tra rò rỉ WebRTC với địa chỉ gốc của bạn:
IP công khai trực tiếp của ISP xuất hiện: hãy điều tra rò rỉ IP.
IP đầu ra proxy/VPN như mong đợi xuất hiện: phù hợp với định tuyến được bảo vệ.
192.168.x.x hoặc 10.x.x.x: thông tin mạng riêng, không phải danh tính công khai của bạn.
Tên máy chủ .local: là cách làm mờ địa chỉ cục bộ, không chứng minh IP công khai được bảo vệ.
Không có ứng viên nào hoặc xảy ra lỗi thì chưa thể kết luận. Hãy kiểm tra lại bằng công cụ khác sau khi kết nối lại. Nếu không công cụ nào cho thấy rò rỉ, bạn đã an toàn. Để biết cách ngăn rò rỉ, hãy đọc tiếp.
Cách ngăn rò rỉ WebRTC
Hãy tắt WebRTC khi không cần thiết, hoặc cưỡng chế định tuyến được bảo vệ khi cuộc gọi và các ứng dụng thời gian thực vẫn phải hoạt động. Chặn UDP không đi qua proxy có ích, nhưng không thay thế được bài kiểm tra rò rỉ WebRTC để hiểu chuyện gì đang diễn ra.
Tìm hiểu cách đảm bảo IP proxy của bạn không bị chặn, bao gồm ngăn rò rỉ IP và các phương pháp khác.
Trong các trình duyệt thông thường
Hãy dùng hướng dẫn cài đặt trình duyệt phù hợp, sau đó áp dụng biện pháp kiểm soát tương ứng:
Firefox trên máy tính: about:config → media.peerconnection.enabled → false. Cách này tắt WebRTC.
Chrome: dùng một tiện ích quyền riêng tư còn được duy trì và hỗ trợ disable_non_proxied_udp.
Brave: tìm “WebRTC IP Handling Policy” trong Settings; chọn “Disable Non-Proxied UDP.”
Microsoft Edge: dùng tiện ích quyền riêng tư WebRTC tương thích hoặc chính sách được quản lý; sau đó kiểm tra lại.
Safari: dùng định tuyến VPN cưỡng chế ở cấp thiết bị; đừng dựa vào các hướng dẫn cũ về menu thử nghiệm.
Opera: chọn chặn UDP không qua proxy nếu có, hoặc dùng một tiện ích tương thích còn được duy trì.
Trong trình duyệt antidetect
Làm theo hướng dẫn cho trình duyệt antidetect.
Gán proxy cho hồ sơ, rồi kiểm tra cài đặt WebRTC của hồ sơ đó. Chọn chế độ tắt nếu không cần thiết; nếu không, hãy dùng tùy chọn định tuyến được bảo vệ của nhà phát triển.
Các nhãn như “Altered” khác nhau giữa các sản phẩm: chỉ thay đổi các ứng viên hiển thị chưa chứng minh lưu lượng mạng đã được bảo vệ.
Sau đó hãy kiểm tra từng hồ sơ.
Trong ứng dụng khách proxy
Làm theo hướng dẫn cho ứng dụng khách proxy. Sau đó:
Nhập thông tin xác thực CyberYozh của bạn.
Bật chế độ TUN/định tuyến toàn bộ nếu được hỗ trợ.
Xác minh upstream hỗ trợ UDP.
Định tuyến DNS qua tuyến đã định
Tắt cơ chế tự chuyển sang kết nối trực tiếp không mong muốn.
Chỉ dùng chế độ proxy hệ thống thì không tương đương với đường hầm trên toàn thiết bị. Sau đó hãy kiểm tra lại cấu hình trình duyệt thực tế để phát hiện rò rỉ WebRTC.
Cài đặt tường lửa hệ thống
Tham khảo hướng dẫn cài đặt hệ điều hành phù hợp.
Dùng kill switch của VPN trong cài đặt Wi-Fi, hoặc thêm các quy tắc chiều đi ra để giới hạn các ứng dụng cần bảo vệ chỉ dùng đường hầm hoặc ứng dụng khách proxy. Hãy áp dụng cho cả IPv4 và IPv6. Cách này sẽ chặn mọi lưu lượng không qua proxy (trực tiếp), giảm thiểu nguy cơ rò rỉ WebRTC.
Thực hành tốt khi làm việc với rò rỉ WebRTC
Hãy kiểm tra đúng hồ sơ làm việc của bạn, không chỉ trình duyệt mặc định; quyền của trình duyệt, tiện ích, việc gán proxy và quy tắc định tuyến có thể khác nhau giữa các môi trường.
Lặp lại kiểm tra sau khi cập nhật trình duyệt, thay đổi ứng dụng khách, chuyển mạng và kết nối lại; kết quả kiểm tra thành công chỉ xác nhận một cấu hình cụ thể, không phải mọi trạng thái có thể xảy ra trong tương lai.
Xác minh DNS và IPv6 một cách độc lập; tắt WebRTC không sửa được định tuyến bộ phân giải không liên quan, cũng không ngăn các kết nối thông thường đi vòng qua tuyến mạng được bảo vệ của bạn.
Kiểm tra hành vi khi lỗi trước khi làm việc thực tế: ngắt đường hầm và xác nhận các ứng dụng được bảo vệ ngừng kết nối thay vì lặng lẽ chuyển sang truy cập trực tiếp.
Giữ nguyên các chức năng cần thiết: kiểm tra cuộc gọi và chia sẻ màn hình sau khi áp dụng các hạn chế, rồi ghi lại cấu hình hoạt động mà không lưu mật khẩu proxy hay công khai chia sẻ các địa chỉ gốc.
