VPN hay relay TURN: cái nào thực sự mang một cuộc gọi WebRTC?
Đường hầm thay đổi tuyến đường mà ICE nhìn thấy; nó không bao giờ cấp phát relay và không cung cấp báo hiệu. Hãy so sánh những gì đầu ra VPN và máy chủ TURN cung cấp.
Trang tải qua VPN nhưng cuộc gọi không bao giờ kết nối: hai lỗi khác nhau trên cùng một thanh địa chỉ. Đường hầm đã thay đổi tuyến đường mà trình duyệt sử dụng; nó không trở thành dịch vụ báo hiệu, máy chủ STUN hay relay, và nó cũng không quyết định ICE sẽ chọn cặp ứng viên nào. Chính việc tách bạch công việc của từng thành phần là thứ biến một câu mơ hồ “WebRTC bị chặn” thành một lỗi cụ thể.
Bốn công việc, và đường hầm chỉ chạm vào một
Ứng dụng trao đổi thông tin phiên qua một cơ chế báo hiệu nào đó, và đó là công việc thứ nhất. ICE thu thập địa chỉ ứng viên và thử các cặp cho đến khi một cặp hoạt động, đó là công việc thứ hai. STUN cho phép đối tác biết lưu lượng của mình trông thế nào từ bên ngoài, và TURN cấp phát một relay cho những trường hợp không có tuyến đường trực tiếp. Bốn vai trò đó khác nhau, và VPN tác động đến các địa chỉ và việc lọc mà chúng gặp phải thay vì tự cung cấp bất kỳ vai trò nào.
Vì thế một lần đăng nhập thành công không nói gì về tuyến đường của phương tiện. Báo hiệu thường đi trên cùng HTTPS mà trang đã dùng, ở cổng 443, trong khi phương tiện có thể đi qua UDP đến một đích hoàn toàn khác.
Đánh địa chỉ riêng làm sự nhầm lẫn tồi tệ hơn. Địa chỉ đường hầm chỉ hữu ích cho đối tác khi đối tác có một tuyến đường dự định quay lại đó; việc là địa chỉ riêng không phải bằng chứng về khả năng tiếp cận lẫn nhau, và trình duyệt không coi như vậy khi loại bỏ những ứng viên không thể kiểm tra. Một ứng viên trông có vẻ cục bộ với bạn có thể không kiểm tra được từ phía bên kia. Khoảng trống đó đáng để loại trừ trước khi kết luận rằng đường hầm đang làm rơi phương tiện.
So sánh một đầu ra VPN với một relay TURN
Cả hai đều chuyển tiếp gói, vì thế chúng bị nhầm lẫn, và bảng so sánh ở trên đáng để đọc theo từng cột chứ không phải như một danh sách tính năng. Việc cấp phát relay là một đối tượng cho mỗi phiên được tạo bởi một yêu cầu đã xác thực; đường hầm là một tuyến. Một bên có thông tin xác thực hết hạn, bên kia có địa chỉ đối tác hoặc tiếp cận được hoặc không.
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
Số cổng làm cho sự khác biệt trở nên cụ thể. TURN theo mặc định lắng nghe trên 3478 cho UDP và TCP và trên 5349 cho TLS, và một mạng cho phép 443 nhưng bỏ các cổng đó sẽ làm cuộc gọi qua relay thất bại trong khi việc duyệt web vẫn tiếp tục bình thường. Thay đổi cổng của VPN không cấu hình bất cứ điều gì trong số đó, vì những cổng quan trọng thuộc về dịch vụ relay, không thuộc về đường hầm.
Đọc chẩn đoán, rồi thử cuộc gọi
Trình duyệt hiển thị thông tin cần thiết mà không cần bắt gói. Mở trang chẩn đoán WebRTC của trình duyệt, thực hiện cuộc gọi và đọc cặp ứng viên được chọn thay vì danh sách đã thu thập: những loại ứng viên cục bộ và từ xa nào được chọn, qua phương thức vận chuyển và họ địa chỉ nào, và tuyến đường là trực tiếp hay qua relay.
Hai cách đọc nên biết trước. Nếu cặp được chọn là host-với-host trên địa chỉ riêng, phương tiện ở lại trên một tuyến đường mà bạn có thể lập luận; nếu là relay-với-relay, cuộc gọi tiêu tốn dung lượng relay và phụ thuộc vào khả năng sẵn có của dịch vụ đó. Một lỗi dừng ở “đang kiểm tra” mà không có cặp được chọn nghĩa là các ứng viên đã được thu thập nhưng không có cái nào vượt qua các kiểm tra kết nối.
Sau đó so sánh cùng hai điểm cuối trong cùng cuộc gọi khi chỉ thay đổi một điều kiện đã được chấp thuận, và chấp nhận kết quả dựa trên phương tiện hoặc dữ liệu hai chiều chứ không dựa trên chỉ báo “đã kết nối”. Việc thu thập ứng viên thành công trong nhiều trường hợp không mang một khung âm thanh nào. Lặp lại cuộc gọi ở phía bên kia của thay đổi và giữ cả hai bản ghi chẩn đoán, vì so sánh hai lần chạy cho nhiều thông tin hơn là đọc riêng từng lần. Cùng điểm cuối, cùng codec, một biến đã thay đổi.
Một ứng dụng cố ý đặt chính sách vận chuyển ICE của mình thành relay chỉ yêu cầu các ứng viên relay. Cài đặt đó không tạo ra relay và không sửa thông tin xác thực bị thiếu; nó làm cho yêu cầu trở nên rõ ràng, điều hữu ích khi ai đó đổ lỗi cho VPN về một chính sách do trang web tự chọn.
Giữ tuyên bố về quyền riêng tư hẹp như bằng chứng
Việc lộ ứng viên phụ thuộc vào chính sách của trình duyệt và ứng dụng, không chỉ vào trạng thái đường hầm, và đặc tả kết nối ngang hàng của W3C coi việc xử lý IP là vấn đề riêng của nó. Vì thế một VPN đang kết nối là nền tảng yếu để hứa rằng cuộc gọi chỉ tiết lộ một địa chỉ được chọn. Hai đối tác sau cùng một đường hầm thậm chí có thể chọn một tuyến không bao giờ rời khỏi máy chủ, điều đó đồng thời là cải thiện quyền riêng tư và hạn chế kết nối.
Điều bạn có thể nói chính xác thì hẹp hơn và hữu ích hơn: cặp ứng viên nào được chọn, phương thức vận chuyển nào đã mang nó, và tuyến đó có ở lại trong đường hầm hay không. Ghi lại ba sự thật đó cho một cuộc gọi hoạt động và một cuộc gọi thất bại, và sự khác biệt thường gọi tên thành phần cần sửa.
Khi kết nối hoạt động, hãy tách hiệu năng khỏi khả năng tiếp cận. Mất gói, độ trễ, hàng đợi và MTU đều nằm ở hạ nguồn của một cặp ứng viên đúng, và việc coi một cuộc gọi chập chờn là lỗi kết nối sẽ đưa bạn trở lại danh sách ứng viên mà không có lý do.