DiffServ RFC 2983 và rò rỉ metadata DSCP trong đường hầm VPN

Kênh rò rỉ ngầm: Cách thức trường QoS tiết lộ thông tin người dùng

Khi các ứng dụng mạng tạo ra lưu lượng dữ liệu IP, hệ điều hành phân loại gói tin bằng trường Điểm mã Dịch vụ Phân biệt (DSCP - Differentiated Services Code Point), một trường 6-bit nằm trong byte Type of Service (ToS) của IPv4 hoặc Traffic Class của IPv6 theo tiêu chuẩn RFC 2474. Các ứng dụng đàm thoại thoại qua IP (VoIP) thường gắn nhãn Chuyển tiếp Khẩn cấp (DSCP EF, mã nhị phân 101110, giá trị thập phân 46), các luồng họp truyền hình trực tuyến gắn nhãn Đảm bảo Chuyển tiếp (như AF41, giá trị 34), và các trò chơi trực tuyến nhiều người chơi gắn các giá trị ưu tiên độ trễ thấp.

Trong mô hình đường hầm bảo mật lý tưởng, việc đóng gói mã hóa lưu lượng (như WireGuard, IPsec ESP hay OpenVPN) nhằm mục đích che giấu hoàn toàn hành vi giao tiếp của người dùng. Tải trọng mã hóa bên ngoài trông như một chuỗi bit ngẫu nhiên không thể phân biệt.

Tuy nhiên, rất nhiều cấu hình đường hầm mặc định lại mắc phải một sơ hở kiến trúc nghiêm trọng: hệ thống tự động sao chép byte ToS/DSCP của gói tin gốc bên trong ra tiêu đề IP đóng gói bên ngoài.

Khi một bên nghe lén, kẻ quan sát trên mạng Wi-Fi công cộng hoặc nhà cung cấp dịch vụ Internet (ISP) kiểm tra tiêu đề bên ngoài của luồng dữ liệu VPN mã hóa, họ hoàn toàn không thể giải mã nội dung. Dẫu vậy, do các bit DSCP bên ngoài phản ánh trung thực nhãn ưu tiên bên trong, kẻ giám sát ngay lập tức nhận diện được đặc tính của lưu lượng:

Nhà mạng dễ dàng xác định thời điểm bắt đầu, thời lượng và tần suất của các cuộc gọi thoại mã hóa.
Các thiết bị mạng trung gian phân biệt được luồng tải tệp dung lượng lớn (Best Effort 000000) với các phiên dòng lệnh SSH tương tác (DSCP AF11).
Các hệ thống phân tích gói tin sâu (DPI) kết hợp kích thước gói, khoảng cách thời gian giữa các cụm xung dữ liệu và nhãn DSCP rõ ràng để nhận diện chính xác ứng dụng người dùng đang sử dụng.

Mô hình đường hầm có sơ hở (Uniform Model):
[ Gói tin gốc: VoIP (DSCP 46 / EF) ] ---> [ Đóng gói ] ---> [ Tiêu đề ngoài (DSCP 46 / EF) ]
                                                                        |
                                                                        v
                                                          ISP nhận biết cuộc gọi thoại!

Mô hình đường hầm bảo mật (RFC 2983 Pipe Model):
[ Gói tin gốc: VoIP (DSCP 46 / EF) ] ---> [ Đóng gói ] ---> [ Tiêu đề ngoài (DSCP 0 / Best Effort) ]
                                                                        |
                                                                        v
                                                          ISP chỉ thấy luồng dữ liệu đồng nhất

Các mô hình đường hầm DiffServ theo RFC 2983: Uniform và Pipe

Nhằm chuẩn hóa cách thức dịch vụ phân biệt vận hành qua các tầng đóng gói mạng, tổ chức IETF đã ban hành tài liệu RFC 2983 ("Differentiated Services and Tunnels"). Tài liệu này định nghĩa ba kiến trúc đường hầm rõ rệt:

1. Mô hình Uniform (Uniform Model)

Trong mô hình Uniform, mạng truyền dẫn xem đường hầm như một phần liên tục của mạng nội bộ:

Tiêu đề ngoài sao chép trực tiếp giá trị DSCP từ tiêu đề bên trong khi gói tin đi vào đường hầm.
Các router trung gian trên mạng Internet định tuyến và xử lý hàng đợi dựa trên giá trị ưu tiên sao chép này.
Khi gói tin đến điểm kết thúc đường hầm, mọi thay đổi về DSCP do các mạng trung gian thực hiện sẽ được ghi đè ngược lại vào tiêu đề gói tin gốc trước khi chuyển tiếp.

Dù mô hình Uniform duy trì được tính liên tục của chính sách QoS giữa các mạng tin cậy, nó lại phá vỡ quyền riêng tư trong môi trường mở, vô tình phơi bày ngữ cảnh của ứng dụng cho các thực thể bên ngoài.

2. Mô hình Pipe (Pipe Model)

Trong mô hình Pipe, đường hầm được coi như một kênh truyền dẫn riêng biệt có chính sách QoS hoàn toàn độc lập:

Tại nút bắt đầu, hệ thống ấn định giá trị DSCP cho tiêu đề ngoài dựa theo chính sách truyền dẫn của nhà cung cấp đường hầm, hoàn toàn không phụ thuộc vào giá trị DSCP của gói tin gốc.
Tiêu đề ngoài thường được đặt cố định ở mức mặc định Best Effort (0x00) hoặc một mức ưu tiên truyền tải đồng nhất.
Các sửa đổi của router trung gian chỉ tác động đến việc xếp hàng trên đường truyền ngoài.
Tại nút giải mã, tiêu đề ngoài bị hủy bỏ hoàn toàn. Gói tin gốc được phục hồi nguyên vẹn với nhãn DSCP ban đầu.

Mô hình Pipe thiết lập sự cách ly hoàn chỉnh về mặt siêu dữ liệu: bên ngoài chỉ quan sát thấy một luồng gói tin có nhãn đồng nhất.

3. Mô hình Short-Pipe (Short-Pipe Model)

Mô hình Short-Pipe hoạt động tương tự mô hình Pipe trên toàn bộ tuyến truyền dẫn trung gian. Điểm khác biệt nằm ở thiết bị giải mã đầu ra: việc lập lịch truyền gói trên giao diện ra của gateway giải mã sẽ dựa vào nhãn DSCP của tiêu đề ngoài thay vì nhãn bên trong trước khi đưa gói tin vào mạng đích.

Rủi ro của mô hình Uniform trong các dịch vụ VPN thương mại

Các dịch vụ VPN thương mại và cổng truy cập từ xa cho doanh nghiệp thường xuyên phải vận hành trên hạ tầng mạng công cộng tiềm ẩn nguy cơ giám sát. Việc áp dụng mô hình Uniform trong môi trường này gây ra nhiều bất lợi nghiêm trọng:

Yếu tố rủi ro	Tác động của mô hình Uniform	Tác động của mô hình Strict Pipe
Nhận diện lưu lượng	Cao: ISP liên kết được các luồng gọi thoại, video	Không: Luồng ngoài hiển thị giá trị DSCP đồng nhất
Bóp băng thông có chọn lọc	ISP chủ động giảm tốc luồng video (AF4x)	Lưu lượng được đối xử bình đẳng như gói tin UDP
Rò rỉ kênh phụ	Nhận biết thao tác gõ phím qua nhãn tương tác	Biến thiên thời gian được làm phẳng bởi tiêu đề chung
Can thiệp trạng thái	Router trung gian can thiệp nhãn QoS nội bộ	Mọi thay đổi bên ngoài bị loại bỏ khi giải mã

Khi các mạng trung gian quan sát được nhãn DSCP bên ngoài, họ có thể áp dụng các biện pháp bóp tốc độ hoặc ưu tiên có chọn lọc mà không cần phải giải mã các thuật toán mật mã bên trong.

Tách biệt cơ chế ECN (RFC 6040) khỏi việc xóa bỏ DSCP (RFC 2474)

Một sai sót thường gặp của các kỹ sư mạng khi xử lý rò rỉ DSCP là xóa toàn bộ byte ToS về giá trị 0. Trường 8-bit này thực tế được chia thành hai phần riêng biệt:

 0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|          DSCP         |  ECN  |
+---+---+---+---+---+---+---+---+
      Mã phân loại         Thông báo tắc nghẽn
     (Bit 0 đến 5)            (Bit 6 và 7)

DSCP (Bit 0-5): Điều khiển mức ưu tiên của gói tin. Phần này cần được che giấu (đặt về 000000) trên tiêu đề ngoài nhằm ngăn rò rỉ siêu dữ liệu.
ECN (Bit 6-7): Quản lý Thông báo Tắc nghẽn Tường minh theo RFC 3168 và RFC 6040. Các bit này truyền tín hiệu cảnh báo tắc nghẽn sớm giữa các router mà không làm rơi gói tin (00 = Không hỗ trợ, 01 = ECT(1), 10 = ECT(0), 11 = CE - Đã gặp tắc nghẽn).

Nếu người quản trị xóa toàn bộ byte ToS (ToS = 0x00), họ vô tình vô hiệu hóa khả năng hoạt động của ECN. Các thuật toán quản lý hàng đợi chủ động hiện đại (như CoDel, FQ-CoDel và CAKE) dựa vào ECN để nhận biết tình trạng đầy bộ đệm. Khi mất tín hiệu ECN, các router buộc phải hủy gói tin thay vì đánh dấu, gây ra hiện tượng giật lag và giảm thông lượng truyền dẫn.

Tiêu chuẩn RFC 6040 quy định rõ ràng việc lan truyền ECN qua đường hầm:

Khi đóng gói, các bit ECN bên ngoài phải phản ánh khả năng ECN của gói tin bên trong.
Khi giải mã, nếu tiêu đề ngoài nhận cảnh báo Đã gặp tắc nghẽn (11), tín hiệu này phải được hợp nhất vào tiêu đề bên trong.

Vì vậy, kiến trúc VPN chuẩn mực cần xóa bỏ nhãn DSCP (bit 0-5) nhưng phải bảo toàn và lan truyền chính xác các bit ECN (bit 6-7).

Cấu hình trong nhân Linux: XFRM, WireGuard và Netfilter Mangle

1. Hành vi của Linux IP-XFRM (IPsec)

Trong cấu hình IPsec trên Linux điều khiển qua công cụ ip xfrm, trạng thái của nhân (struct xfrm_state) mặc định sao chép giá trị ToS bên trong ra tiêu đề ngoài nếu không được chỉ định rõ. Quản trị viên có thể kiểm tra và áp dụng cấu hình cố định ToS qua iproute2:

# Xem các trạng thái XFRM hiện hữu
ip xfrm state show

# Cấu hình cố định giá trị ToS bên ngoài để áp dụng mô hình Pipe RFC 2983:
ip xfrm state update src 203.0.113.10 dst 198.51.100.20 \
    proto esp spi 0x1000 reqid 1 mode tunnel \
    tos 0x00

2. Xử lý trong mã nguồn WireGuard

Trong mô-đun WireGuard của nhân Linux (drivers/net/wireguard/), quá trình truyền gói tin xử lý tiêu đề UDP bên ngoài tại tệp send.c:

/* Đoạn mã trích xuất quy trình gán tiêu đề gói tin WireGuard */
static void wg_send_packet(struct wg_device *wg, struct sk_buff *skb)
{
    ...
    /* WireGuard trích xuất ECN trong khi đặt DSCP ngoài về 0 */
    u8 ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb);
    ...
}

WireGuard đã chủ động thiết lập sẵn một biến thể bảo mật của mô hình Pipe: gói tin UDP bên ngoài luôn mang giá trị DSCP bằng 0, đồng thời kết hợp đúng các bit ECN. Dù vậy, một số ứng dụng bọc ngoài ở không gian người dùng trên các hệ điều hành khác đôi khi vô tình ghi đè cấu hình này bằng cờ mặc định của hệ thống.

Chuẩn hóa lưu lượng xuất với eBPF và Nftables

Nhằm bảo đảm ngăn chặn rò rỉ siêu dữ liệu trên mọi giao thức đường hầm, quản trị viên có thể áp dụng bộ lọc gói tin tại tầng ra của hệ điều hành.

1. Chuẩn hóa bằng quy tắc Nftables

Quy tắc nftables sau đây can thiệp vào các gói tin UDP của đường hầm (ví dụ cổng 51820), đặt 6 bit đầu của trường ToS về 0 trong khi giữ nguyên 2 bit ECN cuối:

table inet vpn_sanitizer {
    chain egress_filter {
        type filter hook postrouting priority mangle; policy accept;

        # Đặt DSCP ngoài về cs0, giữ nguyên bit 6-7 (mặt nạ ECN 0x03)
        udp dport 51820 ip dscp set cs0
        udp dport 51820 ip6 dscp set cs0
    }
}

2. Chuẩn hóa bằng chương trình eBPF (tc-bpf)

Trên các gateway xử lý lưu lượng mạng tốc độ nhiều gigabit, việc nạp một chương trình eBPF vào điểm móc clsact cho phép sửa đổi tiêu đề gói tin trực tiếp trong bộ đệm vòng của nhân với độ trễ tối thiểu:

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>

SEC("classifier/egress_dscp")
int sanitize_outer_dscp(struct __sk_buff *skb)
{
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    struct ethhdr *eth = data;

    if ((void *)(eth + 1) > data_end)
        return BPF_OK;

    if (eth->h_proto == __constant_htons(ETH_P_IP)) {
        struct iphdr *iph = (void *)(eth + 1);
        if ((void *)(iph + 1) > data_end)
            return BPF_OK;

        /* Kiểm tra nếu gói tin là UDP gửi đến cổng đường hầm */
        if (iph->protocol == IPPROTO_UDP) {
            /* Bảo tồn ECN (mặt nạ 0x03) và xóa 6 bit DSCP */
            __u8 old_tos = iph->tos;
            __u8 new_tos = old_tos & 0x03;

            if (old_tos != new_tos) {
                bpf_l3_csum_replace(skb, offsetof(struct iphdr, check),
                                    old_tos, new_tos, sizeof(new_tos));
                iph->tos = new_tos;
            }
        }
    }
    return BPF_OK;
}

char _license[] SEC("license") = "GPL";

Cách thức giao thức RiceGuard áp dụng mô hình Strict Pipe

VPNRice xây dựng toàn bộ lộ trình xử lý dữ liệu của giao thức RiceGuard xoay quanh nguyên tắc bảo vệ quyền riêng tư toàn diện. Cả máy khách và máy chủ gateway đều áp dụng nghiêm ngặt mô hình Pipe theo RFC 2983:

[ Lưu lượng Ứng dụng người dùng ]
  - Đàm thoại trực tuyến: DSCP AF41 (0x22)
  - Dữ liệu trò chơi:     DSCP CS2  (0x10)
  - Duyệt web thông thường: DSCP CS0 (0x00)
             |
             v
[ Động cơ Đóng gói RiceGuard tại máy khách ]
  1. Ghi nhận trạng thái DSCP và ECN ban đầu trong bộ nhớ phiên.
  2. Mã hóa tải trọng bằng thuật toán ChaCha20-Poly1305.
  3. Tạo tiêu đề IP/UDP bên ngoài với nhãn DSCP bắt buộc là CS0 (0x00).
  4. Áp dụng quy tắc chuyển tiếp ECN theo chuẩn RFC 6040 cho bit 6-7.
             |
             v
[ Đường truyền Internet công cộng / Nhà mạng ISP ]
  - Hình thức bên ngoài: Luồng gói tin UDP đồng nhất, không có đặc tính riêng biệt.
  - Hoàn toàn vô hiệu hóa nỗ lực phân loại cuộc gọi, video hay tệp tin.
             |
             v
[ Gateway Giải mã RiceGuard ]
  1. Xác thực và giải mã an toàn tải trọng dữ liệu.
  2. Đọc cảnh báo tắc nghẽn ECN bên ngoài và hợp nhất vào gói tin bên trong.
  3. Khôi phục nhãn DSCP ban đầu để tối ưu chất lượng truyền mạng nội bộ.

Bề mặt nhận diện đồng nhất: Mọi gói tin truyền qua mạng công cộng giữa thiết bị người dùng và máy chủ VPNRice đều xuất hiện dưới dạng lớp lưu lượng CS0 đơn nhất. Kẻ nghe lén không thể phân tách luồng truyền thông khẩn cấp với các tác vụ tải dữ liệu nền.
Bảo tồn trọn vẹn ECN: Nhờ tuân thủ chuẩn mực RFC 6040, RiceGuard duy trì tín hiệu cảnh báo sớm hiện tượng nghẽn hàng đợi, hỗ trợ các thuật toán AQM chống nghẽn bộ đệm mà không làm rơi rớt dữ liệu.
Kiểm soát chặt chẽ tại tầng nhân: Việc tích hợp bộ chuẩn hóa gói tin ngay trong lõi xử lý ngăn chặn các ứng dụng ngoài can thiệp làm thay đổi đặc tính truyền dẫn, duy trì tính ổn định xuyên suốt.

Thông qua việc khắc phục triệt để rò rỉ metadata QoS theo tiêu chuẩn RFC 2983, VPNRice mang lại sự an tâm tuyệt đối trước các kỹ thuật phân tích lưu lượng kênh phụ trên môi trường mạng toàn cầu.