Bài kiểm tra hoạt động thế nào
WebRTC là tính năng trình duyệt đứng sau gọi video và chia sẻ màn hình không cần plugin. Trước khi hai trình duyệt nói chuyện trực tiếp, mỗi bên phải biết mình có thể được tiếp cận ở địa chỉ nào, bước gọi là thu thập ứng viên ICE. Trình duyệt liệt kê giao diện mạng của mình, rồi hỏi máy chủ STUN công cộng xem nó xuất hiện từ địa chỉ nào trên Internet, và gom câu trả lời thành ứng viên. Bất kỳ trang web nào cũng được phép bắt đầu quá trình đó bằng một script ngắn, không cần quyền camera hay micro, và đọc lại các ứng viên.
Trang này làm đúng như vậy trong trình duyệt của bạn. Vai trò duy nhất của máy chủ là cho script biết IP công khai mà kết nối của bạn đến từ đó để so sánh:
- Script tạo đối tượng peer connection với một máy chủ STUN công cộng.
- Nó mở một data channel, kích hoạt thu thập ứng viên mà không chạm vào thiết bị media nào.
- Mỗi ứng viên trình duyệt tạo ra được ghi vào bảng: loại, địa chỉ, giao thức và cổng.
- Khi thu thập xong, mỗi ứng viên công khai được so với IP kết nối. Trạng thái là đạt khi mọi địa chỉ công khai khớp, không đạt khi có địa chỉ công khai khác.
- Không gì được gửi cho ai ngoài chính yêu cầu STUN; phép so sánh diễn ra trong trang. Trên trang điểm ẩn danh, cùng kết quả cũng được gửi về máy chủ để cập nhật dòng WebRTC.
Bốn loại ứng viên bạn có thể thấy:
| Loại | Là gì | Từ đâu |
|---|---|---|
| host | Địa chỉ của một giao diện trên chính thiết bị | Hệ điều hành; hiện dưới dạng tên .local trong trình duyệt hiện tại |
| srflx | Server reflexive: địa chỉ công khai mà máy chủ STUN thấy bạn đến từ đó | Câu trả lời của STUN, đi qua UDP |
| prflx | Peer reflexive: địa chỉ phát hiện trong lúc thử kết nối | Hiếm trong bài này vì không có peer |
| relay | Địa chỉ trên máy chủ chuyển tiếp dùng khi không kết nối trực tiếp được | Chỉ khi có TURN; bài này không dùng |
Dòng srflx là dòng rò rỉ. Đó là địa chỉ gói UDP của bạn mang theo khi rời mạng, và nếu proxy chỉ mang TCP, địa chỉ đó là địa chỉ thật của bạn.
Cách đọc kết quả
| Bảng hiển thị | Ý nghĩa |
|---|---|
| Tên .local ở ứng viên host, một srflx bằng IP kết nối | Bình thường và an toàn. Đường hầm mang UDP và địa chỉ LAN được che. |
| Srflx khác IP kết nối | Rò rỉ. Địa chỉ đó tới được ngoài đường hầm, và trang đọc được. Mất 15 điểm ẩn danh. |
| Srflx là IPv6 trong khi IP kết nối là IPv4 | Trình duyệt tìm thấy tuyến IPv6 công khai ngoài đường hầm chỉ IPv4. Coi là rò rỉ; kiểm tra IPv6 sẽ hiện cùng địa chỉ. |
| Ứng viên host với địa chỉ riêng thô như 192.168.x.x | Trình duyệt cũ hoặc thiết lập nới lỏng; lộ cấu trúc LAN nhưng không lộ IP công khai. |
| Chỉ có host, không srflx | UDP tới STUN bị chặn hoặc WebRTC bị giới hạn ở địa chỉ nội bộ. Không lộ địa chỉ công khai; một số trang để ý sự vắng mặt này. |
| Không có ứng viên nào | WebRTC bị tắt trong trình duyệt hoặc bởi tiện ích mở rộng. Không rò rỉ; trình duyệt nhận diện được là đã tắt WebRTC. |
| Ứng viên relay | Máy chủ TURN được cấu hình bởi tiện ích hoặc chính sách; địa chỉ của nó là thứ trang thấy. |
So ứng viên công khai với địa chỉ ở đầu trang. Khớp thì thiết lập của bạn đạt. Khác thì địa chỉ khác đó là địa chỉ thật của bạn, và không kiểm tra nào khác quan trọng cho tới khi sửa xong.
Cách khắc phục
Chọn mục đúng với thứ bạn dùng, rồi nhấn nút chạy để thu thập lại ứng viên.
Ứng dụng và tiện ích mở rộng VPN
- Trong tiện ích mở rộng VPN, bật tùy chọn bảo vệ WebRTC.
- Trong ứng dụng máy tính, đảm bảo đường hầm là VPN toàn hệ thống chứ không phải chế độ proxy chỉ cho trình duyệt; đường hầm đầy đủ mang UDP, nên câu trả lời STUN đến qua điểm thoát.
Chrome, Edge, Brave và trình duyệt Chromium khác
- Brave có sẵn: Settings → Privacy and security → WebRTC IP handling policy. Chọn "Disable non-proxied UDP".
- Chrome và Edge không có công tắc. Cài tiện ích WebRTC Network Limiter hoặc tương đương và đặt chỉ dùng giao diện công cộng mặc định, hoặc tắt UDP không qua proxy.
Firefox
- Mở about:config.
- Đặt media.peerconnection.ice.default_address_only thành true và media.peerconnection.ice.no_host thành true. Để tắt hẳn WebRTC, đặt media.peerconnection.enabled thành false.
- Với SOCKS5, đặt thêm media.peerconnection.ice.proxy_only thành true để ứng viên được thu thập qua proxy hoặc không thu thập.
Safari
- Safari đưa WebRTC qua ngăn xếp mạng hệ thống, nên VPN toàn hệ thống bảo vệ được nó. Không có công tắc người dùng cho việc thu thập ứng viên.
- Nếu vẫn rò rỉ trên macOS, cách sửa nằm ở ứng dụng VPN: bật chế độ full-tunnel và kill switch.
Trình duyệt anti-detect
- Mở thiết lập WebRTC của hồ sơ. Chọn chế độ thay hoặc sửa địa chỉ công khai bằng địa chỉ proxy, thường gọi là replace hoặc altered.
- Tránh chế độ disabled khi đăng nhập trang khắt khe; trình duyệt không có WebRTC là hiếm và một số script lấy dấu vân tay ghi nhận điều đó.
- Nếu proxy là SOCKS5 không hỗ trợ UDP, replace là chế độ duy nhất tạo ứng viên công khai khớp; chế độ real sẽ rò rỉ.
Android và iOS
- Trình duyệt di động hiếm khi có thiết lập WebRTC. Dùng ứng dụng VPN tạo đường hầm toàn bộ lưu lượng.
- Firefox cho Android hỗ trợ cùng khóa about:config trên một số kênh phát hành.
- Với proxy trên di động, ưu tiên ứng dụng cung cấp đường hầm kiểu VPN hơn thiết lập proxy chỉ cho trình duyệt, vốn không mang UDP.
Router và tường lửa
- Chặn UDP đi ra tới cổng 3478 và các cổng STUN phổ biến tại tường lửa loại bỏ ứng viên srflx cho mọi thiết bị phía sau. Đây là công cụ thô; nó cũng làm hỏng các cuộc gọi dựa vào STUN.
Giới hạn của bài kiểm tra này
- Một máy chủ STUN, một thời điểm. Trang dùng máy chủ TURN riêng có thể thấy địa chỉ relay khác, dù srflx công khai vẫn giống nhau.
- So sánh dựa trên IP kết nối như máy chủ của chúng tôi thấy. Nếu bạn tới trang này qua đường khác với đường trang mục tiêu dùng, phép so sánh có thể không phản ánh góc nhìn của trang đó.
- Ứng viên IPv6 chỉ so theo địa chỉ.
- Hành vi của tiện ích mở rộng không hiện trong bài kiểm tra. Tiện ích viết lại ứng viên làm rò rỉ biến mất khỏi bảng, đúng mục đích, nhưng bài kiểm tra không phân biệt được ứng viên bị viết lại với ứng viên thật.
- Không chạm vào thiết bị media. Bài kiểm tra không liệt kê camera hay micro.
- Tên .local không phân giải được bởi trang và hiển thị như trình duyệt báo cáo.
Vì sao WebRTC rò rỉ sau proxy nhưng ít hơn sau VPN
Proxy đặt trong trình duyệt mang yêu cầu web của trình duyệt, đi qua TCP. Khám phá địa chỉ của WebRTC là trao đổi UDP với máy chủ STUN, và trình duyệt không gửi UDP qua proxy HTTP; SOCKS5 về nguyên tắc mang được UDP nhưng hỗ trợ trong trình duyệt hạn chế và tắt mặc định. Nên yêu cầu STUN rời đi trên kết nối thật và câu trả lời nêu địa chỉ công khai thật. VPN hoạt động bên dưới trình duyệt, ở giao diện mạng, mang mọi gói kể cả UDP, nên câu trả lời STUN về qua điểm thoát và ứng viên công khai là địa chỉ VPN. Đó là lý do duy nhất VPN qua bài này mặc định còn proxy thì không, và là lý do trình duyệt anti-detect thêm chế độ replace: nó giả lập những gì đường hầm đầy đủ sẽ tạo ra.
Địa chỉ nội bộ và mDNS
Trình duyệt cũ báo địa chỉ riêng của thiết bị, như 192.168.1.20, làm ứng viên host, cho phép trang lấy dấu vân tay mạng gia đình và đếm thiết bị. Trình duyệt hiện tại thay nó bằng tên ngẫu nhiên dưới .local, kỹ thuật mượn từ mDNS, và chỉ phân giải tên đó cho peer thật trên cùng mạng. Nếu bạn thấy địa chỉ riêng thô ở dòng host, trình duyệt đã cũ hoặc một thiết lập đã tắt việc che. Đó không phải rò rỉ IP công khai mà trang này nói tới, nhưng là thông tin thêm mà khách cẩn thận không muốn tiết lộ.
Qua được kiểm tra WebRTC nghĩa là VPN an toàn?
Nghĩa là WebRTC không phải kênh rò rỉ địa chỉ của bạn. Hai kênh khác được kiểm tra riêng: tra cứu tên, bởi kiểm tra rò rỉ DNS, và định tuyến IPv6, bởi kiểm tra IPv6. Kiểm tra rò rỉ IP chạy cả ba cùng kiểm tra IPv4, và điểm ẩn danh kết hợp chúng với kiểm tra mạng và tính nhất quán trình duyệt. Rò rỉ WebRTC là phổ biến nhất trong ba kênh trên thiết lập proxy và dễ xác nhận nhất, nên đó là bài cần chạy đầu tiên, không phải bài duy nhất.