Các cổng mạng riêng ảo vận hành trên hạ tầng Internet công cộng phải đối mặt với một sự bất đối xứng điện toán căn bản. Khi một máy khách bắt đầu thiết lập phiên đường hầm bảo mật, các giao thức mật mã buộc phải thực hiện các phép toán bất đối xứng tốn kém—chẳng hạn như nhân vô hướng trên đường cong elliptic Curve25519—để thỏa thuận các khóa phiên đã xác thực.

Trong khi phép nhân Curve25519 chỉ mất chưa tới một mili giây trên các bộ vi xử lý máy chủ hiện đại, thì việc truyền một gói tin UDP giả mạo 148 byte qua cổng mạng 10-gigabit chỉ tốn vài nano giây. Một kẻ tấn công phát tán hàng loạt gói tin khởi tạo với địa chỉ IP nguồn giả mạo có thể nhanh chóng làm nghẽn các lõi CPU của cổng kết nối, gây cạn kiệt tài nguyên xử lý và ngăn cản người dùng hợp lệ hoàn tất quy trình bắt tay.

Để ngăn chặn nguy cơ từ chối dịch vụ (DoS) mật mã và tràn bộ nhớ, WireGuard tích hợp một bộ giới hạn tốc độ theo thuật toán thùng thẻ (token bucket) chuyên dụng trực tiếp vào đường dẫn dữ liệu mạng của nhân Linux (drivers/net/wireguard/ratelimiter.c). Bằng cách điều tiết lưu lượng bắt tay chưa xác thực theo từng địa chỉ IP nguồn trước khi gọi tới các thuật toán đường cong elliptic, WireGuard duy trì năng lực xử lý gói tin tốc độ dây định lượng ngay cả dưới những cuộc tấn công dữ dội.

+-----------------------------------------------------------------------------+
|             QUY TRÌNH GIỚI HẠN TỐC ĐỘ BẮT TAY TRONG NHÂN WIREGUARD          |
|                                                                             |
| Gói tin UDP đi vào (Loại 1: Khởi tạo bắt tay)                               |
| [ Xác thực MAC1 hợp lệ qua BLAKE2s ]                                        |
|                     |                                                       |
|                     v                                                       |
|        wg_ratelimiter_allow_ip(net, ip_addr)                                |
|                     |                                                       |
|                     v                                                       |
|        Bắt đầu vùng bảo vệ rcu_read_lock()                                  |
|        Tính ngăn băm bằng SipHash: siphash(&ip, secret_key)                 |
|                     |                                                       |
|                     v                                                       |
|        Duyệt ngăn danh sách liên kết hlist trong table_v4 / table_v6        |
|                     |                                                       |
|         +-----------+-----------+                                           |
|         |                       |                                           |
|         v                       v                                           |
|   [ Đã có mục IP ]       [ Chưa có mục IP ]                                 |
|         |                       |                                           |
|         |                       v                                           |
|         |                Cấp phát ratelimiter_entry mới                     |
|         |                Chèn vào ngăn băm (khóa nguyên tử)                 |
|         |                       |                                           |
|         +----------->+<---------+                                           |
|                      |                                                      |
|                      v                                                      |
|         Hồi phục thẻ dựa trên số nano giây đã trôi qua                      |
|         (Dung lượng: 20 thẻ, Tốc độ nạp: 1 thẻ mỗi 100ms)                   |
|                      |                                                      |
|         +------------+------------+                                         |
|         |                         |                                         |
|         v                         v                                         |
|   [ Còn đủ thẻ >= 1 ]       [ Hết thẻ (Số thẻ < 1) ]                        |
|         |                         |                                         |
|         v                         v                                         |
|   Khấu trừ 1 thẻ            Từ chối tính toán bắt tay trực tiếp             |
|   rcu_read_unlock()         Kích hoạt yêu cầu Cookie MAC2 (cookie.c)        |
|   Tiếp tục thực hiện nhân   Thả gói tin nếu Cookie thiếu hoặc sai           |
|   vô hướng Curve25519                     |                                 |
|                                           v                                 |
|                                     rcu_read_unlock()                       |
+-----------------------------------------------------------------------------+

Lỗ hổng bất đối xứng bắt tay trong các giao thức đường hầm cổ điển

Các giao thức đường hầm truyền thống thường khởi tạo phiên thông qua các tiến trình bắt tay nhiều bước phức tạp, đặt gánh nặng trạng thái lớn lên máy chủ. Trong kiến trúc IPsec trao đổi khóa Internet (IKEv2, RFC 7296), máy chủ phải cấp phát cấu trúc trạng thái mở một phần ngay khi nhận được yêu cầu IKE_SA_INIT, lưu giữ các nonce và đề xuất mật mã trong bộ nhớ trước khi đối tác được xác thực. Các đợt ngập lụt gói tin nhanh chóng làm cạn kiệt bộ nhớ nhân slab, dẫn đến sự cố sập hệ thống vì hết bộ nhớ (OOM).

OpenVPN phụ thuộc vào máy trạng thái OpenSSL hoặc mbedTLS chạy trong không gian người dùng. Mỗi gói tin TLS Client Hello đi vào đều kích hoạt quá trình phân tích cú pháp ASN.1 phức tạp, xác thực chuỗi chứng chỉ và kiểm tra chữ ký số công khai RSA hoặc ECDSA. Do các thao tác này diễn ra sau nhiều lần chuyển ngữ cảnh giữa nhân và không gian người dùng, một luồng tấn công chỉ vài nghìn gói tin mỗi giây cũng đủ đẩy mức sử dụng CPU của cổng VPN lên 100%, làm rớt kết nối của toàn bộ người dùng đang hoạt động.

Thêm vào đó, các cơ chế giới hạn tốc độ IP đơn giản triển khai ở không gian người dùng hoặc tường lửa thông thường dễ gặp phải các rào cản kỹ thuật:

  1. Phình to bảng trạng thái: Việc theo dõi hàng trăm nghìn địa chỉ IPv4 và IPv6 giả mạo từ các mạng botnet phân tán khiến bảng theo dõi kết nối tường lửa bị quá tải.
  2. Nghẽn khóa đồng thời: Các bộ giới hạn đa luồng sử dụng khóa mutex tập trung chịu ảnh hưởng nghiêm trọng từ hiện tượng tranh chấp khóa khi nhiều lõi CPU cùng giành giật quyền đọc ghi bộ đệm cache.
  3. Thoái hóa độ phức tạp (Hash-DoS): Việc dùng hàm băm không có khóa bí mật cho phép kẻ tấn công tạo các địa chỉ IP rơi vào cùng một chuỗi liên kết, làm tốc độ tra cứu sụt giảm từ $O(1)$ xuống $O(N)$ và đình trệ toàn bộ ngăn xếp mạng.

Cấu trúc bên trong ratelimiter.c: Cơ chế thùng thẻ trong nhân

WireGuard khắc phục triệt để các hạn chế kiến trúc trên bằng cách xây dựng một hệ thống giới hạn tốc độ độc lập ngay tại drivers/net/wireguard/ratelimiter.c. Trình điều khiển khởi tạo hai bảng băm chuyên biệt: table_v4 cho IPv4 và table_v6 cho IPv6.

struct ratelimiter_entry {
    u64 last_time_ns;
    u32 tokens;
    spinlock_t lock;
    struct hlist_node hash;
    struct rcu_head rcu;
    union {
        __be32 ip;
        struct in6_addr ip6;
    };
};

Mỗi mục trong bảng băm đại diện cho một thùng thẻ riêng biệt gắn liền với một địa chỉ IP từ xa:

  • Dung lượng tích lũy (PACKETS_BURST): Được thiết lập ở mức 20 thẻ, cho phép người dùng hợp lệ bùng nổ lưu lượng tức thời khi thử lại mạng hoặc chuyển mạng di động mà không gặp trễ giả lập.
  • Tốc độ hồi phục (PACKETS_PER_SECOND): Nạp đều đặn 10 thẻ mỗi giây (1 thẻ mỗi 100 mili giây), được tính toán động dựa trên dấu thời gian nano giây của nhân (ktime_get_coarse_boottime_ns()).
  • Chi phí bộ nhớ tối ưu: Cấu trúc cực kỳ thu gọn đảm bảo hàng chục nghìn kết nối đồng thời chỉ chiếm một dung lượng RAM khiêm tốn trong nhân.

1. Phòng thủ va chạm bảng băm bằng SipHash

Để bản thân bộ giới hạn tốc độ không trở thành mục tiêu của tấn công độ phức tạp thuật toán, vị trí các ngăn băm được tính toán thông qua hàm SipHash (siphash_1u32 cho IPv4 và siphash_2u64 cho IPv6). Khi khởi tạo giao diện mạng, WireGuard rút một khóa bí mật ngẫu nhiên 128-bit từ nguồn hỗn loạn của nhân:

static inline u32 entry_hash(const struct ratelimiter_entry *entry)
{
    return siphash_1u32((__force u32)entry->ip, &table_key);
}

Bởi vì table_key hoàn toàn cô lập trong bộ nhớ nhân và thay đổi mỗi khi khởi động lại giao diện mạng, kẻ tấn công bên ngoài không thể dự đoán được địa chỉ IP nào sẽ gây xung đột ngăn băm. Sự phân bố dữ liệu tuân thủ chuẩn xác phân phối Poisson, đảm bảo thời gian tra cứu ngăn băm luôn là $O(1)$.

2. Tra cứu không khóa qua RCU và khóa xoay cục bộ

Để phục vụ lưu lượng gói tin khổng lồ, WireGuard thực hiện tra cứu bảng băm trong vùng bảo vệ đọc Read-Copy Update (RCU):

bool wg_ratelimiter_allow_ip(struct ratelimiter *limiter, struct sk_buff *skb)
{
    struct ratelimiter_entry *entry;
    u32 hash;

    rcu_read_lock();
    hash = entry_hash_from_skb(skb);
    hlist_for_each_entry_rcu(entry, &limiter->table_v4[hash & limiter->mask], hash) {
        if (entry->ip == ip) {
            bool allowed = deduct_token(entry);
            rcu_read_unlock();
            return allowed;
        }
    }
    rcu_read_unlock();
    return allocate_and_insert_entry(limiter, ip);
}

Trên đường dẫn xử lý nhanh, các luồng nhân định vị mục IP mà không cần khóa toàn cục. Sau khi tìm thấy cấu trúc ratelimiter_entry, luồng xử lý chỉ khóa xoay cục bộ (entry->lock) của riêng mục đó để cập nhật thời gian và trừ thẻ. Các lõi CPU khác xử lý gói tin từ những địa chỉ IP khác nhau hoàn toàn chạy song song trên các đường truyền bộ nhớ tách biệt.

Khi một địa chỉ IP gửi vượt quá số thẻ cho phép, WireGuard không đơn thuần hủy bỏ kết nối. Thay vào đó, giao thức kích hoạt một phản hồi phòng thủ thông minh:

Trạng thái bình thường (Thẻ khả dụng):
Gói tin máy khách [ Loại 1 | Chưa xác thực | MAC1 ]
    --> Bộ giới hạn cho phép
    --> Tiến hành tính toán khóa phiên Curve25519
    --> Trả lời gói tin Loại 2

Trạng thái quá tải (Hết thẻ trong thùng):
Gói tin máy khách [ Loại 1 | Tần suất cao hoặc cạn thẻ | MAC1 ]
    --> Bộ giới hạn từ chối tính toán khóa trực tiếp
    --> Nếu MAC2 chưa có: Gửi phản hồi Cookie Loại 3 (Thử thách phi trạng thái)
    --> Máy khách tính Cookie MAC2 và gửi lại Loại 1 [ MAC1 + MAC2 ]
    --> Cổng VPN kiểm tra Cookie và thực hiện bắt tay an toàn

Dưới các đợt ngập lụt, cổng VPN từ chối thực hiện phép tính Curve25519 nặng nề đối với những yêu cầu chưa rõ nguồn gốc. Thay vào đó, máy chủ yêu cầu máy khách gửi kèm một Cookie phi trạng thái (tạo từ IP, cổng và khóa bí mật luân phiên). Do việc tạo Cookie chỉ tốn một phép băm đối xứng BLAKE2s siêu nhẹ, máy chủ có thể phản hồi hàng triệu gói tin mỗi giây ở tốc độ phần cứng. Khách hàng hợp lệ nhận được Cookie sẽ tính MAC2 và kết nối bình thường, trong khi các luồng tấn công IP giả mạo bị triệt tiêu hoàn toàn.

Thu dọn bộ nhớ tự động bằng cơ chế hoãn việc

Trong những đợt tấn công từ chối dịch vụ phân tán quy mô lớn với hàng triệu địa chỉ IP giả mạo, bảng theo dõi có nguy cơ tăng trưởng mất kiểm soát nếu không có giải pháp dọn dẹp.

Để giữ bộ nhớ vật lý luôn trong ngưỡng an toàn, WireGuard sử dụng hàng đợi hoãn việc của Linux (schedule_delayed_work) để dọn rác ngầm định kỳ:

static void cleanup_entries(struct work_struct *work)
{
    struct ratelimiter_entry *entry;
    struct hlist_node *n;
    u64 now = ktime_get_coarse_boottime_ns();

    spin_lock_bh(&table_lock);
    for (int i = 0; i < HASH_SIZE; ++i) {
        hlist_for_each_entry_safe(entry, n, &table[i], hash) {
            if (now - entry->last_time_ns > EXPIRATION_INTERVAL_NS) {
                hlist_del_rcu(&entry->hash);
                kfree_rcu(entry, rcu);
            }
        }
    }
    spin_unlock_bh(&table_lock);
}

Tiến trình dọn dẹp tự động quét qua các mục:

  • Hết hạn do không hoạt động: Bất kỳ mục nào không nhận thêm gói tin trong khoảng thời gian quy định (thường vài giây) sẽ bị tách khỏi bảng băm bằng hlist_del_rcu().
  • Giải phóng an toàn qua RCU: Bộ nhớ chỉ được giải phóng thực sự qua kfree_rcu() sau khi tất cả các lõi CPU đã hoàn tất việc đọc mục đó, ngăn chặn hoàn toàn lỗi use-after-free.
  • Giới hạn dung lượng thích ứng: Nếu số lượng mục vượt ngưỡng cho phép trong đợt tấn công dữ dội, hệ thống chủ động loại bỏ các mục cũ nhất, bảo đảm bộ nhớ máy chủ luôn hoạt động ổn định.

Kiểm tra hiệu năng và tối ưu thông số cổng mạng

Quản trị viên hệ thống vận hành máy chủ VPN Linux có thể giám sát hàng đợi socket và tinh chỉnh thông số nhân mạng bằng các công cụ tích hợp sẵn.

Kiểm tra trạng thái bộ đệm nhận UDP trên cổng dịch vụ WireGuard:

# Giám sát dung lượng hàng đợi nhận socket UDP
ss -u -a -m -p | grep 51820

Phân tích phân phối tải xử lý ngắt mạng mềm (softirq) trên các lõi vi xử lý:

# Đánh giá phân bổ tải xử lý ngắt mạng trên hệ thống đa lõi
mpstat -P ALL 1 5

Tinh chỉnh các tham số mạng nhân để tăng cường năng lực chịu tải:

# Tối ưu hàng đợi backlog và bộ đệm nhận gửi cho đường hầm băng thông lớn
sysctl -w net.core.netdev_max_backlog=100000
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864
sysctl -w net.ipv4.udp_rmem_min=16384

Khả năng phòng thủ tốc độ dây trong hạ tầng VPNRice

Việc bảo đảm dịch vụ mạng riêng ảo ổn định ở cấp độ doanh nghiệp đòi hỏi hệ thống phải đứng vững trước các đợt bùng nổ lưu lượng phân tán. VPNRice áp dụng triệt để cơ chế giới hạn tốc độ tầng nhân trên toàn bộ mạng lưới Anycast toàn cầu:

  1. Lọc ngập lụt ngay tại tầng nhân: Bằng cách áp dụng thuật toán thùng thẻ ngay trên đường dẫn gói tin của nhân, các nút biên VPNRice chặn đứng các luồng tấn công bắt tay giả mạo trước khi chúng chạm tới bước tính toán mật mã bất đối xứng.

  2. Tự động kích hoạt thử thách Cookie: Khi phát hiện lưu lượng bất thường, các cổng VPNRice chuyển đổi mượt mà sang cơ chế xác minh Cookie MAC2, duy trì kết nối trong suốt cho người dùng thật trong khi loại bỏ các luồng tấn công ở tốc độ phần cứng.

  3. Phân tách khóa SipHash theo Namespace: Mỗi nút VPNRice tạo khóa SipHash độc lập cho từng không gian định tuyến mạng, ngăn chặn hoàn toàn các nỗ lực tấn công va chạm bảng băm chéo.

Sự kết hợp giữa giải thuật thùng thẻ, bảng băm SipHash và quản lý bộ nhớ RCU không khóa mang lại cho hệ thống đường hầm VPN khả năng vận hành bền bỉ, tốc độ cao và độ trễ thấp ngay cả trong điều kiện mạng khắc nghiệt nhất.