Các cổng giao tiếp mạng riêng ảo (VPN) hoạt động trên hạ tầng mạng mở luôn phải đối mặt với các luồng lưu lượng bất thường. Trong điều kiện bình thường, các đường hầm bảo mật xác thực danh tính đối tác thông qua bắt tay khóa công khai. Tuy nhiên, trong các đợt tấn công từ chối dịch vụ phân tán (DDoS), kẻ xấu khai thác sự bất đối xứng về chi phí tính toán: kẻ tấn công phát tán hàng triệu gói tin UDP khởi tạo giả mạo với băng thông tối thiểu, trong khi máy chủ tiếp nhận buộc phải thực thi các phép toán mật mã phức tạp và cấp phát bộ nhớ trạng thái trong nhân hệ điều hành.

Các kiến trúc VPN truyền thống như OpenVPN hoặc IPsec IKEv2 thường gặp trở ngại lớn trong tình huống này. Chúng cấp phát cấu trúc điều khiển truyền dữ liệu hoặc bộ đệm liên kết bảo mật (SA) ngay khi nhận gói tin thăm dò đầu tiên, khiến hàng đợi bộ nhớ của hệ thống dễ rơi vào tình trạng quá tải. WireGuard loại bỏ hoàn toàn bề mặt tấn công này. Bằng việc thực thi nghiêm ngặt nguyên tắc phi trạng thái trước khi hoàn tất bắt tay và áp dụng hệ thống mã xác thực thông điệp hai tầng (mac1 và mac2) kết hợp cookie mật mã xoay vòng, WireGuard bảo vệ tài nguyên máy chủ trước nguy cơ bão hòa.

Trong mã nguồn nhân Linux, cơ chế phòng thủ then chốt này được hiện thực hóa tại tệp drivers/net/wireguard/cookie.c. Việc phân tích cấu trúc mật mã của module này sẽ làm sáng tỏ cách các đường hầm tốc độ cao duy trì khả năng phục hồi liên tục mà không tiêu hao tài nguyên cho các đối tượng chưa được xác thực.

Thách thức bắt tay bất đối xứng và khả năng phục hồi phi trạng thái

Khuôn mẫu Noise IK mà WireGuard ứng dụng yêu cầu hai bên xác thực lẫn nhau bằng các phép nhân vô hướng Curve25519 Diffie-Hellman. Phép nhân điểm trên đường cong elip tiêu tốn nhiều chu kỳ xử lý của CPU hơn đáng kể so với việc định tuyến một gói tin thông thường. Nếu máy chủ VPN tiếp nhận mọi gói tin Type 1: Handshake Initiation và lập tức tính toán khóa bí mật dùng chung, một kẻ tấn công gửi luồng UDP giả mạo nguồn có thể dễ dàng chiếm dụng toàn bộ các lõi CPU, gây nghẽn băng thông của các kết nối hợp lệ.

WireGuard giải quyết lỗ hổng này bằng cách chia quy trình kiểm tra gói tin thành các tầng vận hành tách biệt:

[ Gói tin bắt tay gửi đến ]
              │
              ▼
   Kiểm tra MAC1 (Khóa tĩnh)
      ├─ Không khớp ──► Thả rơi im lặng (Zero Response)
      └─ Khớp hợp lệ
              │
              ▼
   Hệ thống có đang tải cao? (ratelimiter.c)
      ├─ Không ──► Xử lý phép nhân vô hướng Curve25519
      └─ Có tải cao
              │
              ▼
   Kiểm tra MAC2 (Cookie xoay vòng)
      ├─ Hợp lệ     ──► Xử lý phép nhân vô hướng Curve25519
      └─ Không khớp ──► Gửi Type 3: Cookie Reply (Phi trạng thái)

Ở trạng thái thông thường khi tải hệ thống dưới ngưỡng cảnh báo từ ratelimiter.c, máy chủ kiểm tra mac1 và tiếp tục quy trình trao đổi khóa. Khi lưu lượng tăng đột biến có nguy cơ làm bão hòa CPU, cổng kết nối kích hoạt hàng rào thứ hai, yêu cầu mọi gói tin bắt tay gửi đến phải đính kèm mã xác thực mac2 hợp lệ được sinh ra từ cookie do chính máy chủ cấp phát.

Cấu trúc kiểm tra MAC hai tầng (mac1 và mac2)

Mỗi gói tin khởi tạo của WireGuard dành riêng hai trường 16 byte ở phần đuôi dữ liệu: mac1 (từ byte 116 đến 131) và mac2 (từ byte 132 đến 147). Hai trường này đóng vai trò như các cổng kiểm soát bổ trợ:

  1. Cổng kiểm soát mac1: Được tính theo công thức BLAKE2s-128(key = Hash(Label-Mac1 || Responder_PublicKey), message = packet[0..115]). Vì mac1 được tạo bằng khóa dẫn xuất từ khóa công khai của máy chủ, chỉ những máy trạm được cấu hình chính xác địa chỉ đích mới có thể tạo ra thẻ xác thực hợp lệ. Các gói tin quét cổng ngẫu nhiên đều thất bại ở bước này và bị hủy bỏ trong im lặng mà không gửi lại bất kỳ phản hồi ICMP nào.
  2. Cổng kiểm soát mac2: Được tính theo công thức BLAKE2s-128(key = Cookie, message = packet[0..131]). Cần lưu ý rằng mac2 bao trùm toàn bộ gói tin, bao gồm cả trường mac1 hợp lệ. Khóa 16 byte sử dụng cho mac2 chính là một cookie mật mã tạm thời do máy chủ cấp riêng cho các địa chỉ IP đã chứng minh được quyền sở hữu.

Trong điều kiện mạng thông thường, máy trạm truyền mac2 gồm 16 byte số không (0x00). Khi máy chủ chuyển sang chế độ phòng thủ tải cao, các gói tin có mac2 rỗng hoặc sai lệch sẽ bị từ chối tính toán mật mã. Thay vì ghi nhận trạng thái kết nối hay hủy gói tin vô điều kiện, máy chủ khởi tạo chu trình thách thức - phản hồi phi trạng thái.

Khi ratelimiter.c thông báo trạng thái quá tải, hàm wg_cookie_checker_create_payload() trong cookie.c sẽ tiếp quản luồng xử lý. Nhân Linux tiến hành đóng gói một gói tin Type 3: Handshake Cookie Reply có kích thước 64 byte với cấu trúc chặt chẽ:

┌────────────────────────────────────────────────────────┐
│ Loại gói: 3 (1 byte) │ Phần dự phòng: 0 (3 bytes)       │
├────────────────────────────────────────────────────────┤
│ Chỉ mục máy nhận: Echo sender_index máy trạm (4 bytes) │
├────────────────────────────────────────────────────────┤
│ XChaCha20 Nonce: Sinh từ nguồn ngẫu nhiên CSPRNG (24B) │
├────────────────────────────────────────────────────────┤
│ Thẻ Cookie mã hóa: XChaCha20-Poly1305 (32 bytes)       │
│ - 16 bytes cookie dạng văn bản rõ                      │
│ - 16 bytes thẻ xác thực Poly1305                       │
└────────────────────────────────────────────────────────┘

Việc xây dựng gói tin phản hồi này tiêu tốn lượng chu kỳ CPU không đáng kể. Quan trọng hơn cả, máy chủ không phải cấp phát bất kỳ byte bộ nhớ động nào (kmalloc). Gói tin phản hồi gửi ngược lại sender_index để máy trạm nhận biết phiên bắt tay tương ứng, trong khi phần cookie nhạy cảm được mã hóa bảo vệ bằng thuật toán XChaCha20-Poly1305.

Khóa mã hóa đối xứng của cookie được tính toán một cách tiền định:

Cookie_Encryption_Key = BLAKE2s-256(
    key = Hash(Label-Cookie || Responder_PublicKey),
    message = Initiator_MAC1
)

Do giá trị Initiator_MAC1 đã được máy chủ kiểm tra tính hợp lệ trước đó, nó trở thành một giá trị muối mật mã riêng biệt cho lần bắt tay cụ thể đó, ngăn chặn việc kẻ nghe lén trên đường truyền tính toán trước khóa giải mã.

Cơ chế xoay vòng bí mật và chứng minh quyền sở hữu IP

Đặc tính bảo mật then chốt của cơ chế cookie trong WireGuard là khả năng xác nhận quyền sở hữu IP mà không lưu vết phiên. Máy chủ dẫn xuất cookie dựa trên một khóa bí mật 32 byte nội bộ (cookie_checker->secret) được sinh ra từ bộ sinh số ngẫu nhiên an toàn của nhân (get_random_bytes).

Công thức tính toán gắn chặt địa chỉ mạng vật lý của bên khởi tạo vào bên trong cookie:

Cookie = BLAKE2s-128(
    key = cookie_checker->secret,
    message = Initiator_IP_Address || Initiator_Port
)

Để ngăn ngừa việc kẻ tấn công tích trữ các cookie hợp lệ cho các chiến dịch kéo dài, máy chủ định kỳ xoay vòng giá trị bí mật này sau mỗi 120 giây (COOKIE_SECRET_MAX_AGE = 120).

Để xử lý độ trễ mạng và các gói tin đang trên đường truyền, cookie.c lưu trữ đồng thời hai thế hệ khóa bí mật:

  • secret[0]: Khóa bí mật hiện hành dùng để tạo cookie mới và kiểm tra các gói tin vừa đến.
  • secret[1]: Khóa bí mật của chu kỳ 120 giây trước đó, cho phép các gói tin bắt tay phát đi sát thời điểm chuyển giao vẫn được chấp nhận hợp lệ.

Khi kẻ tấn công phát động chiến dịch ngập lụt bằng các địa chỉ IP nguồn giả mạo, máy chủ gửi các gói tin Type 3: Cookie Reply trở lại chính những IP giả mạo đó thông qua giao thức UDP. Vì kẻ phát tán không kiểm soát các đầu cuối định tuyến thực tế, chúng không thể thu thập được dữ liệu cookie mã hóa.

Ngược lại, máy trạm hợp lệ nhận được Cookie Reply sẽ gọi hàm wg_cookie_message_consume(). Máy trạm giải mã thẻ, ghi nhận vào bộ nhớ đệm cục bộ (peer->latest_cookie), đánh dấu thời điểm cookie_birthdate = jiffies và lập tức gửi lại gói tin Handshake Initiation với trường mac2 đã điền đầy đủ. Máy chủ xác minh mac2 trong thời gian hằng số O(1), xác nhận địa chỉ IP gửi đến là có thực và an tâm tiến hành tính toán khóa Curve25519.

Đồng quy không khóa và kiến trúc RiceGuard

Hiệu năng ấn tượng của module cookie.c xuất phát từ cấu trúc không sử dụng khóa chặn (lockless). Việc đọc khóa bí mật xoay vòng và tính toán thẻ xác thực diễn ra hoàn toàn bên trong vùng găng rcu_read_lock(). Máy chủ không cần dùng khóa quay spinlock trên đường truyền nhận gói tin, cho phép toàn bộ các lõi CPU xử lý song song mac1 và mac2 mà không gây hiện tượng tranh chấp bộ nhớ.

Gói tin bắt tay ──► [Hàng đợi Rx mạng] ──► Khóa đọc RCU ──► Xác thực BLAKE2s MAC ──► Luồng xử lý

Trong môi trường triển khai thực tế với quy mô lớn, các cổng VPN phải tiếp nhận hàng chục triệu gói tin mỗi giây. Tại VPNRice, giải pháp RiceGuard nâng tầm cơ chế nhân này bằng cách tích hợp cookie.c với trình điều khiển eBPF và XDP (eXpress Data Path) được tối ưu ở tầng phần cứng mạng.

Bằng cách tính toán và kiểm tra MAC hai tầng ngay tại trình điều khiển cạc mạng trước khi cấp phát cấu trúc bộ đệm sk_buff, RiceGuard hóa giải các đợt tấn công giả mạo nguồn quy mô lớn ngay tại ranh giới vật lý. Nhờ vậy, người dùng luôn duy trì kết nối ổn định, bảo toàn tính bí mật chuyển tiếp hoàn hảo và duy trì độ trễ cực thấp ngay cả khi hạ tầng mạng chịu áp lực lớn.