Proxy có thể xử lý lưu lượng HTTP trong khi WebRTC trao đổi địa chỉ ứng viên qua STUN/ICE bằng UDP. Bài viết giải thích khi nào địa chỉ cục bộ và địa chỉ mạng riêng có thể bị lộ, đồng thời nêu cách giữ nhất quán giữa đầu ra mạng và môi trường trình duyệt.
Bạn đã cấu hình proxy và trang kiểm tra IP hiển thị đúng khu vực cùng nhà mạng mong muốn. Danh tính mạng có vẻ đã được xử lý ổn thỏa. Nhưng khi mở trang kiểm tra rò rỉ, mục WebRTC lại chuyển sang màu đỏ và hiển thị địa chỉ của kết nối Internet thật.
Không cần vội đổi proxy. Trong phần lớn trường hợp, vấn đề không nằm ở chất lượng proxy mà ở loại lưu lượng proxy không kiểm soát được.
Proxy xử lý HTTP, còn WebRTC đi theo một đường khác
Proxy hoạt động ở tầng mạng. Dù được triển khai dưới dạng tiện ích mở rộng của trình duyệt hay đường hầm cấp hệ thống, nó xử lý các yêu cầu HTTP/HTTPS và đưa lưu lượng đó ra ngoài qua điểm thoát của proxy.
WebRTC lại khác. Đây là khả năng giao tiếp thời gian thực tích hợp sẵn trong trình duyệt. Để cuộc gọi âm thanh/video và truyền P2P tìm được đường phù hợp, trình duyệt có thể chủ động gửi truy vấn STUN đến máy chủ bên ngoài — về bản chất là hỏi “phía bạn nhìn thấy địa chỉ của tôi là gì?” — rồi sắp xếp kết quả thành các ứng viên ICE và chuyển cho trang web. Các truy vấn này dùng UDP, một kênh độc lập với đường hầm HTTP.
Vì vậy xuất hiện sự lệch nhau: yêu cầu web đi ra qua proxy, nhưng trình duyệt đồng thời vẫn có thể báo địa chỉ cục bộ. Cho rằng chỉ cần cấu hình proxy là toàn bộ danh tính mạng tự động sạch là điểm xuất phát phổ biến nhất của vấn đề này.
Không chỉ IP công khai có thể bị lộ
Các ứng viên ICE thường chứa hai loại địa chỉ. Một loại là địa chỉ công khai, tức điểm thoát của nhà cung cấp Internet thật. Loại còn lại là địa chỉ cục bộ, chẳng hạn địa chỉ mạng riêng bắt đầu bằng 192.168, và đôi khi còn có địa chỉ của bộ điều hợp mạng ảo.
Một địa chỉ mạng riêng tự nó không nói lên nhiều điều vì gần như máy tính nào cũng có. Tuy nhiên, địa chỉ này có thể đủ ổn định để việc các ứng viên lặp lại và chồng khớp giữa nhiều tài khoản trở thành một tín hiệu bổ sung giúp nền tảng liên kết chúng với cùng một thiết bị. Địa chỉ công khai trực tiếp hơn: nó chỉ tới nhà mạng thật và khu vực địa lý xấp xỉ. Mức độ chi tiết phụ thuộc vào cách nền tảng triển khai, nhưng nguyên tắc rất rõ: địa chỉ càng thật thì việc liên kết càng dễ.
Khi nào website thực sự có thể đọc được địa chỉ này?
Không phải website nào cũng cố đọc. Việc trao đổi địa chỉ đòi hỏi trang phải chủ động tạo đối tượng RTCPeerConnection, điều mà các trang nội dung thông thường thường không cần.
Những nơi có thể làm việc này thường thuộc vài nhóm: dịch vụ cần giao tiếp thời gian thực như họp video, hỗ trợ khách hàng trực tuyến và một số trang phát trực tiếp; các site phụ thuộc nhiều vào quảng cáo hoặc chống gian lận; và các nền tảng có hệ thống kiểm soát rủi ro tương đối hoàn chỉnh. Quá trình đọc diễn ra ở phần không nhìn thấy của giao diện, và sau khi dữ liệu được thu thập, bạn thường không nhận được thông báo về cách nó được sử dụng.
Cũng có một tình huống không liên quan trực tiếp đến website. Trong khoảng thời gian rất ngắn khi proxy kết nối lại hoặc chuyển nút, yêu cầu STUN từ trình duyệt có thể rơi xuống mạng cục bộ. Cửa sổ thời gian ngắn, nhưng đủ để ghi nhận một lần.
Ba tình huống lỗi phổ biến
Proxy dạng tiện ích mở rộng trình duyệt thường chỉ tiếp quản các yêu cầu HTTP/HTTPS. UDP nằm ngoài phạm vi của chúng, và việc bật tùy chọn “toàn cục” trên giao diện cũng không thay đổi điều này.
Proxy toàn cục ở cấp hệ thống có vẻ triệt để hơn vì bao phủ lưu lượng của cả thiết bị. Tuy nhiên, việc thu thập địa chỉ ứng viên có thể gắn trực tiếp với giao diện mạng cục bộ và bỏ qua bảng định tuyến của hệ thống, khiến đường hầm vẫn hở ở bước này.
Vấn đề thứ ba không chỉ là kỹ thuật mà còn do cách hệ thống kiểm soát rủi ro thay đổi theo thời gian. Ngày càng nhiều hệ thống đưa địa chỉ WebRTC vào nhóm tín hiệu tham khảo để liên kết tài khoản. Dữ liệu trước đây không đo được hoặc bị bỏ qua giờ có thể được tính vào quyết định.
Mục tiêu là làm cho đầu ra nhất quán, không chỉ tắt một công tắc
Có vài cách tiếp cận chung. Nếu quy trình làm việc hoàn toàn không cần giao tiếp thời gian thực, tắt WebRTC là cách đơn giản nhất, đổi lại các chức năng như gọi video và hỗ trợ khách hàng trực tuyến cũng sẽ không dùng được.
Nếu cần giữ các chức năng này, cách phổ biến là làm cho địa chỉ trả về ở tầng WebRTC nhất quán với điểm thoát của proxy. Cách chắc chắn hơn là chuyển cả các yêu cầu STUN qua kênh proxy để giao diện không làm lộ địa chỉ cục bộ. Nếu cần P2P hoặc gọi video thì toàn bộ lưu lượng UDP phải đi qua proxy, chứ không chỉ xử lý tầng HTTP.
Một sai lầm thường gặp là nghĩ rằng chỉ cần tắt WebRTC thì toàn bộ môi trường sẽ sạch. Điều cần đảm bảo là sự nhất quán giữa điểm thoát mạng, phân giải DNS, chủ sở hữu IP và ASN, múi giờ và ngôn ngữ, cùng các đặc điểm thiết bị. Chỉ cần một mục không khớp cũng có thể tạo ra tín hiệu bất thường; WebRTC chỉ là một trong những mục dễ bị bỏ sót nhất.
Cách kiểm tra rất đơn giản. Hãy kiểm tra một lần sau khi chuyển nút và một lần nữa trước khi đưa môi trường vào sử dụng bình thường: mở trang kiểm tra rò rỉ và xem mục WebRTC trả về điểm thoát proxy, địa chỉ cục bộ hay địa chỉ công khai thật. Trang tra cứu IP thông thường không hiển thị mục này.
Giải pháp cô lập môi trường ở cấp nhân trình duyệt có thể đặt chính sách địa chỉ WebRTC riêng cho từng môi trường và ghép nó với điểm thoát mạng của môi trường đó. PurpleMark cung cấp loại khả năng này. Nếu nhiều môi trường dùng chung một điểm thoát hoặc chính sách địa chỉ của từng môi trường không nhất quán, giá trị của việc cô lập sẽ giảm đáng kể.
Nội dung trên chỉ nhằm giải thích nguyên lý kỹ thuật. Hãy sử dụng các công cụ liên quan trong phạm vi tuân thủ quy định của nền tảng và pháp luật địa phương.
