Ba chế độ WebRTC và mỗi chế độ cho website thấy gì

Những điểm chính

• Một trang web có thể mở một lần thử kết nối WebRTC mà không cần xin quyền camera hay micro, và danh sách ứng viên nó thu thập được có thể chứa IP công khai thật, ngay cả khi trình duyệt đã qua proxy.
• Agilelogin cung cấp một cài đặt cho mỗi Profile, webrtc.mode. Trình chỉnh sửa cho chọn ba chế độ: privacy, replace và disable. Nhân giữ lại hai giá trị cũ, forward_stun và allow, cho các Profile hiện có và để gỡ lỗi; Profile mới không thể chọn chúng.
• privacy là mặc định của sản phẩm kể từ 2026-07-27: không có ứng viên host hay server-reflexive nào bị lộ, khớp với điều mà chính sách doanh nghiệp của Chrome gọi là disable_non_proxied_udp.
• Trình chỉnh sửa từ chối replace trên proxy xoay vòng, và giá trị cũ forward_stun bị từ chối trên Profile có proxy, vì cả hai đều sẽ đưa ra một danh sách ứng viên mà việc gán mạng thực tế không thể bảo đảm.
• Chế độ này được đọc một lần lúc khởi động và giữ nguyên suốt phiên; nó không bao phủ mọi đường đi WebRTC mà một trang có thể dùng, và không chế độ nào che giấu được địa chỉ thật khỏi một trang web tự vận hành máy chủ STUN của riêng mình.

Những gì một website biết được trước khi bạn cho phép bất cứ điều gì

WebRTC ban đầu được tạo ra để hai trình duyệt trao đổi trực tiếp âm thanh, video hoặc dữ liệu, mà không cần mỗi gói tin đi qua một máy chủ. Để kết nối trực tiếp đó thành hiện thực, mỗi bên phải cho bên kia biết cách liên hệ với mình, và quá trình thương lượng đó — Interactive Connectivity Establishment, hay ICE — chạy ngay khi một trang mở một RTCPeerConnection, trước cả khi bất kỳ hộp thoại xin quyền camera hay micro nào xuất hiện. Chỉ cần một RTCPeerConnection với một data channel duy nhất là đủ để kích hoạt nó, và trang web không cần người dùng đồng ý bất cứ điều gì.

ICE thu thập cái được gọi là các ứng viên, và một trang lắng nghe sự kiện icecandidate có thể thu thập tất cả chúng. Ứng viên host mô tả một địa chỉ trên chính giao diện mạng của máy; Chromium hiện đại che giấu địa chỉ thật đó sau một tên mDNS .local được tạo ngẫu nhiên thay vì để lộ trực tiếp IP mạng nội bộ. Ứng viên server-reflexive (srflx) là địa chỉ mà một máy chủ STUN nói cho trình duyệt biết nó trông như thế nào từ bên ngoài — thường là IP công khai thật, bị phát hiện bất kể phần lưu lượng còn lại có qua proxy hay không, vì lưu lượng STUN không buộc phải đi qua proxy HTTP theo cách các yêu cầu trang thông thường phải đi. Ứng viên relay, khi có TURN tham gia, là một địa chỉ trên máy chủ chuyển tiếp mà lưu lượng thực sự đi qua. Gộp lại, đây chính là con đường “rò rỉ WebRTC” nổi tiếng: trình duyệt có thể đang chuyển lưu lượng HTTP của nó qua proxy trong khi các ứng viên ICE của nó vẫn trao cho trang web IP công khai bên dưới.

Ba chế độ và hai giá trị cũ, đặt cạnh nhau

Agilelogin chỉ cung cấp đúng một cài đặt điều khiển toàn bộ chuyện này, webrtc.mode, đặt theo từng Profile. Trình chỉnh sửa cho chọn ba giá trị: Privacy (privacy), Replace IP (replace) và Block connections (disable). Hai giá trị còn lại, allow và forward_stun, là giá trị cũ mà nhân giữ lại cho các Profile hiện có và để gỡ lỗi. Trình chỉnh sửa chỉ hiện giá trị đó trên Profile đang dùng nó, nên Profile mới không thể chọn giá trị nào trong hai. Bảng dưới liệt kê cả năm giá trị của nhân:

allow chính là hành vi nguyên bản của Chromium, không hề bị chỉnh sửa: không khâu nào trong việc thu thập ứng viên bị động chạm tới. disable đi xa nhất theo hướng ngược lại — không ứng viên loại nào tới được trang, và không kết nối TURN nào từng được mở, dù bản thân đối tượng RTCPeerConnection vẫn tồn tại để một script có thể tạo ra; trang không thể biết được, qua cách gọi, rằng API này đang bị cố tình giữ lại. forward_stun và replace đều nhắm thẳng vào ứng viên srflx: cái đầu để lộ địa chỉ thật, cái sau viết lại nó thành IP thoát của proxy thuộc Profile đó trước khi trang kịp thấy.

Vì sao privacy là mặc định

privacy nằm giữa hai thái cực không phải ngẫu nhiên — nó đã được ghi rõ vào mọi mẫu Profile kể từ 2026-07-27. Nó triệt tiêu hoàn toàn cả ứng viên host lẫn server-reflexive — không tên mDNS, không IP thật qua STUN — trong khi vẫn cho phép một ứng viên relay xuất hiện nếu máy chủ TURN của trang tình cờ chạy qua TCP hoặc TLS, và trong trường hợp đó địa chỉ trang thấy là IP thoát của proxy, không phải địa chỉ của máy. Đây không phải hành vi tự bịa ra: nó tạo ra đúng hiệu ứng mà chính sách doanh nghiệp WebRTCIPHandlingPolicy của Chrome tạo ra khi đặt thành disable_non_proxied_udp — mặc định của Agilelogin khớp với một chế độ mà chính Chrome đã cung cấp cho các triển khai được quản lý, chỉ khác là áp dụng theo từng Profile thay vì theo từng máy.

Lý do đặt nó làm mặc định là tính nhất quán, không phải để che giấu. Một Profile đã được gán proxy cho lưu lượng HTTP và dấu vân tay trình duyệt của nó nên cho trang web thấy cùng một danh tính mạng ở mọi nơi danh tính đó bị kiểm tra, kể cả WebRTC — người vận hành chạy nhiều Profile song song muốn mỗi Profile trông như một môi trường mạch lạc, tự nhất quán, chứ không phải một nơi thanh địa chỉ nói một quốc gia còn ứng viên WebRTC lại nói một quốc gia khác. Tính nhất quán đó quan trọng không kém khi một Profile được điều khiển bởi một quy trình tự động hóa thay vì một người nhấp chuột thủ công, vì một script không có cách nào tự nhận ra rằng một tín hiệu đang âm thầm mâu thuẫn với phần còn lại.

Hai tổ hợp bị trình chỉnh sửa từ chối

Hai giá trị can thiệp vào ứng viên server-reflexive đều đi kèm một rào chắn riêng. forward_stun cố tình để lộ IP công khai thật; Profile mới không thể chọn nó, và trình chỉnh sửa Profile từ chối nó trên Profile đã gán proxy; buộc lộ IP thật ra ngoài qua WebRTC trong khi mọi tín hiệu khác đều đến từ proxy sẽ chỉ tái tạo lại đúng lỗ rò mà toàn bộ cấu hình còn lại tồn tại để bịt kín.

Rào chắn của replace hẹp hơn: nó bị từ chối trên một Profile dùng proxy xoay vòng. Việc viết lại ứng viên srflx thành “IP thoát của proxy” chỉ có ý nghĩa khi IP thoát đó là một giá trị cố định, đã biết, mà cả phiên có thể neo vào; một proxy xoay vòng không có giá trị như vậy. Và ngay cả trên một proxy tĩnh, nếu nhân không biết IP thoát của proxy đó tại thời điểm ICE thu thập ứng viên, replace sẽ lùi về hành xử như privacy thay vì đưa ra một địa chỉ đã lỗi thời hoặc sai — một phỏng đoán không được viết lại còn tệ hơn là không có ứng viên nào cả.

Những chế độ này không bao phủ điều gì

webrtc.mode chỉ được đọc một lần, qua một kênh stdin riêng tư, khi nhân khởi động một Profile — nó không thể thay đổi trong khi thực thể trình duyệt đó vẫn đang chạy, nên một Profile cần chế độ khác cần khởi động lại, không phải chuyển đổi trực tiếp. Với replace và forward_stun, các giá trị đã bị viết lại hoặc chuyển tiếp vẫn nhất quán ở mọi nơi mà trang có thể tìm cách kiểm tra — RTCPeerConnection.getConfiguration(), icecandidateerror.url, cùng các URL ứng viên hiển thị trong getStats() và sự kiện iceTransport đều khớp với những gì thực sự được gửi ra. Điều đó bịt lại cách đối chiếu chéo rõ ràng mà một trang lẽ ra có thể thực hiện, nhưng nó có một giới hạn cứng: một trang web tự vận hành máy chủ STUN của riêng mình sẽ thấy địa chỉ mà mỗi yêu cầu thực sự đến từ đó, và có thể so sánh nó với ứng viên mà trang đã được cung cấp. replace không thể thay đổi những gì máy chủ đó quan sát được. Đây là một cơ chế kiểm soát quyền riêng tư và tính nhất quán cho góc nhìn phía trang, không hơn.

Còn hai giới hạn nữa đáng nói thẳng thay vì lướt qua. Hành vi của ứng viên IPv6 chưa được xác minh riêng với bất kỳ giá trị webrtc.mode nào, nên bài viết này không đưa ra khẳng định nào về điều đó theo bất kỳ hướng nào. Và các chế độ này không quản lý mọi bề mặt liên quan đến WebRTC mà Chromium để lộ — trong nhân tồn tại một API RtcTransport mới hơn, nằm hoàn toàn ngoài phạm vi của webrtc.mode, dù nó chưa được để lộ trong các bản phát hành chính thức hiện nay, nên hiện tại một trang chưa thể chạm tới đường đó. Tất cả những điều này là hành vi đã được ghi lại của nhân Polychrome, đo trên bản dựng M150; hiện chưa có bản tải về công khai nào của ứng dụng desktop, nên hãy xem bài viết này như mô tả những gì nhân đang làm hôm nay, chứ không phải một tính năng để thử trong một bản phát hành đã ra mắt.