STUN Server: nó là gì, cách hoạt động và được sử dụng ở đâu

Máy chủ STUN là gì

STUN Server (Session Traversal Utilities for NAT) là một dịch vụ mạng hoạt động theo giao thức được định nghĩa trong RFC 5389 và cập nhật trong RFC 8489. Nhiệm vụ chính của máy chủ STUN là cung cấp cho máy khách thông tin về địa chỉ IP công khai và cổng của nó như được nhìn thấy từ mạng bên ngoài, cũng như xác định loại thiết bị NAT giữa máy khách và internet.

Kiến trúc STUN bao gồm hai thành phần: một máy khách STUN được nhúng trong ứng dụng (ví dụ: trình duyệt hoặc ứng dụng WebRTC gốc) và một máy chủ STUN được triển khai trong mạng công khai. Máy khách gửi một Binding Request đến máy chủ, máy chủ trong phản hồi của nó chỉ ra địa chỉ IP nguồn và cổng của yêu cầu — tức là các địa chỉ công khai của máy khách như máy chủ nhìn thấy. Bằng cách so sánh dữ liệu này với các địa chỉ cục bộ của mình, máy khách có thể xác định loại NAT đang được sử dụng trong mạng của nó.

Giao thức STUN

STUN hoạt động trên UDP (cổng 3478 mặc định) hoặc TCP (cổng 3478 hoặc 5349 cho TLS). Một thông điệp STUN bao gồm phần đầu 20 byte và một số lượng thuộc tính thay đổi. Phần đầu chứa loại thông điệp (Binding Request, Binding Response, Binding Error Response), độ dài và một định danh giao dịch duy nhất (96 bit) cho phép so khớp các yêu cầu và phản hồi. Mỗi Binding Response chứa thuộc tính XOR-MAPPED-ADDRESS — địa chỉ bên ngoài của máy khách, được mã hóa với mặt nạ để bảo vệ khỏi các cuộc tấn công dựa trên việc chặn lưu lượng STUN.

Máy chủ STUN hoạt động như thế nào

Một máy chủ STUN hoạt động theo giao thức yêu cầu-phản hồi đơn giản. Máy khách ở phía sau NAT tạo một Binding Request và gửi nó đến máy chủ STUN. Máy chủ nhận gói tin, trích xuất địa chỉ IP nguồn và cổng người gửi từ phần đầu UDP, sau đó tạo một Binding Response, đóng gói địa chỉ này vào thuộc tính XOR-MAPPED-ADDRESS. Phản hồi được gửi trở lại địa chỉ nguồn của yêu cầu.

Máy khách nhận được phản hồi và trích xuất XOR-MAPPED-ADDRESS, chứa địa chỉ IP bên ngoài và cổng được chỉ định bởi thiết bị NAT. Sau đó, máy khách so sánh địa chỉ này với địa chỉ cục bộ (RFC 1919 — riêng tư) của nó. Nếu các địa chỉ trùng khớp — máy khách không ở phía sau NAT. Nếu chúng khác nhau — máy khách ở phía sau NAT, và địa chỉ bên ngoài được sử dụng làm ứng viên cho ICE (Interactive Connectivity Establishment) trong WebRTC.

Quá trình khám phá NAT

Máy chủ STUN cho phép xác định loại NAT thông qua một chuỗi các yêu cầu kiểm tra. Máy khách gửi các yêu cầu với các cờ khác nhau (CHANGE-REQUEST) và phân tích các phản hồi. Chu kỳ khám phá đầy đủ bao gồm việc gửi các yêu cầu đến các địa chỉ IP và cổng khác nhau của máy chủ STUN. Nếu máy chủ trả lời yêu cầu với một cổng đã thay đổi — NAT thuộc loại Restricted Cone. Nếu nó không trả lời yêu cầu với cổng và IP đã thay đổi — NAT thuộc loại Symmetric. Thông tin này rất quan trọng để chọn chiến lược ICE trong WebRTC.

Máy chủ STUN và các loại NAT

Một máy chủ STUN có thể phát hiện bốn loại NAT chính, mỗi loại ảnh hưởng khác nhau đến khả năng thiết lập kết nối P2P. Loại NAT xác định liệu STUN có thể cho phép kết nối trực tiếp giữa hai máy khách hay không. Nó cũng xác định ứng viên ICE nào — host, server reflexive hay relay — sẽ được sử dụng cho kết nối.

Symmetric NAT là loại duy nhất mà STUN không thể xử lý. Với Symmetric NAT, mỗi yêu cầu mới đến một máy chủ đích mới nhận được một địa chỉ bên ngoài khác (IP và/hoặc cổng). Vì máy chủ STUN báo cáo địa chỉ cho kết nối với chính máy chủ STUN, địa chỉ này không phù hợp để kết nối với một máy khách khác. Trong những trường hợp như vậy, WebRTC sử dụng máy chủ TURN để chuyển tiếp lưu lượng. Theo nghiên cứu (Ford et al., RFC 3489, 2003), khoảng 8–10% tất cả các thiết bị NAT trên internet là đối xứng.

Sử dụng máy chủ STUN trong WebRTC

Máy chủ STUN được tích hợp vào WebRTC thông qua cấu hình RTCPeerConnection. Trình duyệt hoặc ứng dụng gốc sử dụng STUN để thu thập các ứng viên ICE, sau đó được trao đổi qua Signaling Server. Trong cấu hình WebRTC, máy chủ STUN được chỉ định trong mảng iceServers với tiền tố stun: cho UDP hoặc stuns: cho các kết nối TLS.

Hãy xem xét một ví dụ về cấu hình máy chủ STUN trong JavaScript khi tạo RTCPeerConnection cho một ứng dụng WebRTC.

const config = {
    iceServers: [
        {
            urls: "stun:stun.l.google.com:19302"
        },
        {
            urls: "stun:stun1.l.google.com:19302"
        }
    ]
};

const pc = new RTCPeerConnection(config);

pc.onicecandidate = (event) => {
    if (event.candidate) {
        console.log("Ứng viên ICE:", event.candidate.candidate);
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Ví dụ này sử dụng các máy chủ STUN công khai của Google (stun.l.google.com:19302). Khi tạo offer hoặc answer, trình duyệt tự động gửi một Binding Request STUN đến các máy chủ được chỉ định, nhận địa chỉ bên ngoài (ứng viên server reflexive) và thêm nó vào danh sách các ứng viên ICE. Sau khi thu thập tất cả các ứng viên, chúng được gửi đến peer từ xa qua Signaling Server để thử thiết lập kết nối P2P trực tiếp.

Các loại ứng viên ICE và STUN

Trong quá trình ICE, có ba loại ứng viên: host (địa chỉ cục bộ), srflx (server reflexive — thu được từ STUN) và relay (được chuyển tiếp qua TURN). Máy chủ STUN cho phép tạo các ứng viên srflx, có ưu tiên cao hơn các ứng viên relay vì kết nối dựa trên STUN là trực tiếp và không yêu cầu chuyển tiếp. Quá trình ICE kiểm tra tất cả các tổ hợp ứng viên (cục bộ và thu được từ STUN) của cả hai peer, bắt đầu từ các ưu tiên cao nhất.

Các hạn chế của giao thức STUN

Máy chủ STUN có những hạn chế cơ bản liên quan đến kiến trúc giao thức. Hạn chế chính là không thể hoạt động với Symmetric NAT, nơi mỗi yêu cầu mới đến một máy chủ bên ngoài nhận được một cổng bên ngoài duy nhất. Trong trường hợp này, địa chỉ thu được từ máy chủ STUN không thể được sử dụng để kết nối với một peer khác vì NAT đã tạo một ràng buộc chỉ cho việc giao tiếp với chính máy chủ STUN.

Hạn chế thứ hai là STUN không cung cấp chuyển tiếp dữ liệu. Nếu kết nối P2P trực tiếp không thể thực hiện được (cả hai peer ở phía sau Symmetric NAT), STUN không cung cấp một đường dẫn thay thế để truyền dữ liệu. Trong trường hợp này, cần có một máy chủ TURN, nó hoạt động như một bộ chuyển tiếp lưu lượng phương tiện giữa các peer, nhận dữ liệu từ một người tham gia và gửi nó đến người khác thông qua địa chỉ IP công khai của nó.

• Symmetric NAT — STUN không hoạt động với NAT đối xứng vì địa chỉ bên ngoài là duy nhất cho mỗi máy chủ đích và không thể được sử dụng lại cho P2P.
• Tường lửa kiểm tra gói tin sâu — một số tường lửa chặn lưu lượng STUN bằng cách phát hiện các chữ ký giao thức trong các gói UDP trên cổng 3478.
• IPv6 — trong mạng IPv6, NAT thường không được sử dụng, do đó STUN không cần thiết, nhưng WebRTC trên IPv6 có thể sử dụng các ứng viên host mà không cần STUN hoặc TURN.
• Phụ thuộc vào khả năng khả dụng — máy chủ STUN phải có sẵn cho máy khách trong giai đoạn thiết lập kết nối, nếu không các ứng viên srflx sẽ không được thu thập.
• Bảo mật — giao thức STUN dễ bị tấn công khuếch đại nếu máy chủ được cấu hình không đúng và trả lời các yêu cầu với địa chỉ nguồn giả mạo.

Bất chấp những hạn chế, máy chủ STUN vẫn là một thành phần quan trọng của cơ sở hạ tầng WebRTC. Trong hầu hết các trường hợp (80–90%), kết nối P2P trực tiếp có thể được thiết lập bằng STUN, giúp tránh chi phí chuyển tiếp TURN và giảm độ trễ truyền dữ liệu phương tiện. Đối với các ứng dụng WebRTC công khai, nên sử dụng kết hợp các máy chủ STUN và TURN với dự phòng tự động để đảm bảo kết nối trong mọi điều kiện mạng.