Trong các mô hình mạng riêng ảo kết nối chi nhánh (site-to-site) và truy cập từ xa, đường hầm mã hóa đòi hỏi khả năng nhận biết chính xác trạng thái sẵn sàng của thiết bị đối tác. IPsec hoạt động dựa trên sự phân tách hoàn toàn giữa mặt phẳng điều khiển và mặt phẳng dữ liệu: giao thức IKE (IKEv1 RFC 2409, IKEv2 RFC 7296) chịu trách nhiệm thương thảo các thông số mật mã, trong khi tải trọng bảo mật đóng gói (ESP, RFC 4303) trực tiếp vận chuyển các khung dữ liệu mã hóa đơn hướng bên trong ngăn xếp mạng của nhân hệ điều hành. Do bản chất giao thức IP là phi kết nối (connectionless), cả hai giao thức đều không tự động cung cấp trạng thái phiên hai chiều liên tục. Nếu một cổng VPN phía đối tác khởi động lại đột ngột, đứt cáp quang hoặc mất nguồn điện, đầu cuối còn lại vẫn tiếp tục đẩy các luồng dữ liệu quan trọng vào một "hố đen" không có lời hồi đáp.

Các giải pháp truyền thống dựa vào việc phát các gói tin "nhịp tim" (heartbeat) định kỳ qua đường truyền rảnh rỗi bộc lộ nhiều hạn chế nghiêm trọng: gây hao phí băng thông, làm cạn kiệt pin trên thiết bị di động và kích hoạt việc phá vỡ đường hầm sai lệch khi mạng dao động tạm thời. Tiêu chuẩn RFC 3706 ("A Traffic-Based Method of Detecting Dead Internet Key Exchange Peers") giải quyết triệt để vấn đề này thông qua cơ chế Dead Peer Detection (DPD) — một kiến trúc hướng sự kiện, ưu tiên phân tích luồng gói tin thực tế trước khi phát sinh các truy vấn chẩn đoán tường minh.

Sự cố hố đen bất đối xứng (Khi không có DPD):
[Cổng A]  ====== (Mất điện / Đứt mạng nhà cung cấp) =====x    [Cổng B (Sập)]
   │
   └──> Tiếp tục gửi gói tin ESP vào vô định; SA vẫn hoạt động trong nhân
   └──> 100% dữ liệu bị rơi rụng; không kích hoạt chuyển vùng dự phòng

Kiến trúc DPD kích hoạt theo tải (RFC 3706 / RFC 7296):
[Cổng A]  <── Nhận thấy lưu lượng ESP chiều vào bình thường ──  [Cổng B]
   │       └──> Lưu lượng đến chứng minh cổng còn sống: Không gửi gói thăm dò.
   │  (Ngừng nhận dữ liệu + Có dữ liệu chiều đi đang chờ gửi)
   ▼
[Cổng A]  ── Gửi gói tin thăm dò R-U-THERE / INFORMATIONAL ──>   [Cổng B]
[Cổng A]  <── Nhận phản hồi R-U-THERE-ACK / Gói tin rỗng ─────   [Cổng B]
           └──> Xác nhận cổng hoạt động; đặt lại bộ đếm thời gian.

Nan đề hố đen đường hầm: Vì sao nhịp tim định kỳ thất bại

Để hiểu rõ tính tất yếu của RFC 3706, các kỹ sư mạng cần nhìn nhận những điểm nghẽn mà cơ chế thăm dò định kỳ gây ra trên hạ tầng VPN quy mô lớn.

Sự lãng phí tài nguyên của gói tin duy trì vô điều kiện

Các thế hệ phần mềm VPN ban đầu phụ thuộc vào cơ chế kiểm tra định kỳ cố định. Cứ sau mỗi chu kỳ cố định, hai đầu thiết bị lại trao đổi các cặp gói tin yêu cầu - phản hồi bất kể đường truyền đang bận rộn hay nhàn rỗi. Trên các máy chủ tập trung (hub) phục vụ hàng chục ngàn nhánh kết nối đồng thời, việc gửi gói tin nhịp tim vô điều kiện tạo ra hàng triệu gói tin dư thừa mỗi phút.

Lượng dữ liệu rác này tiêu tốn năng lực xử lý của chip tăng tốc mật mã, làm đầy bảng trạng thái tường lửa và buộc các modem di động phải duy trì công suất phát sóng liên tục. Quan trọng hơn, việc phát một gói tin chẩn đoán trên một liên kết đang truyền tải hàng megabit dữ liệu ESP bình thường là hoàn toàn thừa thãi: sự xuất hiện liên tục của các gói tin người dùng đã được ký số là bằng chứng mật mã rõ ràng nhất cho thấy đối tác vẫn đang vận hành.

Hố đen bất đối xứng: Khi cổng kết nối biến mất không dấu vết

Kịch bản lỗi nghiêm trọng nhất trong các liên kết IPsec không được giám sát là hiện tượng hố đen một chiều. Xét tình huống một cổng kết nối chi nhánh đang kết nối về trung tâm dữ liệu chính:

  1. Thiết bị định tuyến trung tâm gặp sự cố sập nguồn đột ngột hoặc mất kết nối tuyến trên.
  2. Do không có cờ TCP FIN hay bản tin ICMP unreachable nào quay trở lại, nhân Linux tại chi nhánh vẫn lưu giữ các mục hợp lệ trong cơ sở dữ liệu liên kết bảo mật (SAD) và chính sách bảo mật (SPD).
  3. Các ứng dụng nội bộ tại chi nhánh tiếp tục tạo ra các phiên kết nối mới hướng về trung tâm.
  4. Cổng chi nhánh tuần tự mã hóa các gói tin này và gửi ra ngoài dưới dạng khung ESP đến địa chỉ IP đã chết.
  5. Dữ liệu biến mất không dấu vết. Các ứng dụng bị treo, còn các giao thức định tuyến dự phòng không chuyển mạch vì giao diện mạng vật lý vẫn ở trạng thái mở.

Nếu không có cơ chế giám sát đối tác tự động, hiện tượng nghẽn ngầm này sẽ kéo dài cho đến khi thời hạn của liên kết bảo mật (SA) hết hạn — vốn có giá trị mặc định lên tới 8 giờ (28.800 giây) trong cấu hình IPsec tiêu chuẩn.

Kiến trúc RFC 3706: Phát hiện nút mạng dựa trên lưu lượng

RFC 3706 tái định nghĩa quy trình giám sát đối tác bằng cách chuyển từ cơ chế định kỳ sang đánh giá dựa trên trạng thái lưu lượng. Thay vì đặt câu hỏi cố định, DPD chỉ thăm dò khi có dấu hiệu nghi ngờ đối tác gặp trục trặc.

Thăm dò theo nhu cầu: Chỉ gửi truy vấn khi có tải xuất mạng

Nguyên lý cốt lõi của RFC 3706 là sự tối giản trong vận hành:

$$\text{Phát DPD Probe} \iff (\text{Có tải xuất mạng}) \land (\Delta t_{\text{nhận_lần_cuối}} > T_{\text{ngưỡng}})$$

Theo cỗ máy trạng thái này:

  • Nếu Cổng A truyền dữ liệu tới Cổng B và đồng thời vẫn nhận đều đặn các gói ESP từ Cổng B, đối tác được coi là hoàn toàn bình thường. Không có gói DPD nào được tạo ra.
  • Nếu cả hai cổng đều không có dữ liệu truyền nhận, đường hầm rơi vào trạng thái ngủ yên. Hệ thống không phát sinh gói tin thăm dò, cho phép các thiết bị di động tiết kiệm tối đa năng lượng.
  • Nếu Cổng A có dữ liệu chuẩn bị gửi đi nhưng đã trải qua một khoảng thời gian chờ (thường từ 15 đến 30 giây) mà không nhận được bất kỳ khung tin nào từ Cổng B, trạng thái nghi ngờ sẽ kích hoạt. Chỉ khi đó, Cổng A mới phát một gói tin thăm dò trực tiếp.

Giao thức trao đổi bản tin R-U-THERE và R-U-THERE-ACK

Trong giao thức IKEv1, RFC 3706 quy định hai tải trọng thông báo được thỏa thuận qua chuỗi định danh nhà cung cấp trong Giai đoạn 1: R-U-THERE (Kiểu 36201) và R-U-THERE-ACK (Kiểu 36202).

Để ngăn chặn các cuộc tấn công phát lại (replay attack) và lỗi đảo lộn thứ tự truyền dẫn, mỗi gói thăm dò đều gắn kèm một số thứ tự 32-bit tăng đơn điệu:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tải kế tiếp   |    DỰ PHÒNG   |         Độ dài tải trọng      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Định danh giao thức (1) |       Kích thước SPI (16)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Kiểu thông báo (Bản tin R-U-THERE)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Số thứ tự 32-bit tăng đơn điệu                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Khi Cổng B nhận được gói R-U-THERE hợp lệ được bảo vệ bởi IKE SA, nó sao chép chính xác số thứ tự 32-bit vào bản tin phản hồi R-U-THERE-ACK. Cổng A đối chiếu số thứ tự nhận được với bảng theo dõi cục bộ. Nếu trùng khớp, tính toàn vẹn của liên kết hai chiều được xác nhận và bộ đếm thời gian được cài đặt lại.

Tích hợp trong IKEv2: Thăm dò nút mạng bằng bản tin INFORMATIONAL

Cơ chế DPD đã được nâng cấp toàn diện trong giao thức IKEv2 (RFC 7296). Thay vì sử dụng các phần mở rộng tùy biến, IKEv2 tích hợp cơ chế kiểm tra sự sống vào ngay trong lõi giao thức.

Trao đổi đánh số thứ tự tuần tự và cửa sổ truyền lại

Theo Mục 2.4 của tiêu chuẩn RFC 7296, đầu cuối IKEv2 kiểm tra trạng thái đối tác bằng các bản tin trao đổi INFORMATIONAL rỗng:

Bên khởi tạo (Cổng A)                     Bên phản hồi (Cổng B)
---------------------------------------------------------------
HDR (Message ID=N), Bản tin mã hóa []     -->
                                          <-- HDR (Message ID=N), Bản tin mã hóa []

Kiểm tra sự sống trong IKEv2 mang lại những ưu thế vượt bậc:

  1. Bảo vệ bằng mật mã vững chắc: Toàn bộ bản tin yêu cầu và phản hồi đều được xác thực và mã hóa bằng khóa phiên IKE SA (sử dụng các thuật toán hiện đại như AES-GCM hoặc ChaCha20-Poly1305), ngăn chặn việc làm giả từ kẻ đứng giữa.
  2. Quản lý theo Message ID: Mỗi bản tin IKEv2 đều chứa một định danh Message ID 32-bit. Bên nhận bắt buộc phải phản hồi tuần tự theo từng Message ID. Nếu quá hạn chờ phản hồi, bên gửi sẽ thực hiện truyền lại theo thuật toán lùi lũy thừa.
  3. Không tải trọng dư thừa: Bản tin trao đổi thông tin rỗng không chứa phần thân dữ liệu, giúp giảm chi phí truyền dẫn xuống mức tối thiểu (dưới 80 byte qua cổng UDP 4500).

Chiến lược xử lý sự cố: Các hành vi Clear, Hold và Restart

Khi đối tác không phản hồi sau một số lần thử nghiệm liên tiếp trong khoảng thời gian quy định, tiến trình giám sát sẽ tuyên bố nút mạng đã chết và áp dụng một trong ba chính sách cấu hình:

Hành vi        | Tác động SAD / SPD       | Trạng thái định tuyến | Tình huống áp dụng thực tế
---------------+--------------------------+-----------------------+------------------------------------------
clear          | Xóa sạch SA ngay lập tức | Xóa tuyến đường hầm   | Người dùng di động, kết nối quay số
hold           | Cài đặt bẫy trap / drop  | Giữ nguyên định tuyến | Đường nối chi nhánh kích hoạt theo yêu cầu
restart        | Xóa SA cũ & đàm phán lại | Giữ nguyên định tuyến | Tuyến trục doanh nghiệp dự phòng cao
  • Clear: Tiến trình xóa bỏ toàn bộ các liên kết ESP và IKE tương ứng khỏi nhân hệ điều hành. Tuyến định tuyến trỏ vào hầm bị hủy bỏ, ngăn ngừa việc tích lũy các socket rác.
  • Hold: Tiến trình giải phóng các SA đang hoạt động nhưng duy trì chính sách SPD ở trạng thái chờ (trap). Khi có gói tin mới phát sinh, nhân hệ điều hành sẽ phát tín hiệu yêu cầu đàm phán lại.
  • Restart: Hệ thống chủ động chuyển sang vai trò khởi tạo, lập tức gửi các gói IKE_SA_INIT mới đến các địa chỉ dự phòng hoặc các cụm máy chủ khác.

Đối chiếu DPD và NAT Keepalive: Phân biệt duy trì tuyến và kiểm tra nút

Trong vận hành mạng, kỹ sư thường nhầm lẫn giữa cơ chế duy trì NAT Keepalive (RFC 3948) và Dead Peer Detection (RFC 3706). Dù đều sử dụng các gói tin UDP qua cổng 4500, hai cơ chế này giải quyết hai bài toán hoàn toàn khác nhau:

Tiêu chí đánh giá     | Gói tin NAT Keepalive (RFC 3948)    | Cơ chế DPD (RFC 3706 / RFC 7296)
----------------------+-------------------------------------+---------------------------------------
Mục tiêu tác động     | Bảng dịch cổng trên thiết bị NAT    | Tiến trình IKE và liên kết mật mã SA
Cấu trúc gói tin      | Gói UDP chứa 1 byte 0xFF không mã   | Tải trọng IKE được ký số và mã hóa
Chiều tương tác       | Đơn hướng (không cần phản hồi)      | Hai chiều (bắt buộc yêu cầu - phản hồi)
Điều kiện phát gói    | Định kỳ theo giây cố định (vd: 20s) | Kích hoạt khi có dữ liệu xuất mạng
Hậu quả khi thất bại  | Mất phiên dịch cổng trung gian      | Hủy bỏ SA, kích hoạt chuyển vùng mạng

Gói tin NAT keepalive chỉ có nhiệm vụ làm tươi bảng dịch trên các bộ định tuyến trung gian, trong khi DPD kiểm tra xem hệ điều hành và ngăn xếp mã hóa của đối tác có thực sự còn sống hay không.

Độ khả dụng cao cho doanh nghiệp: Động cơ chuyển vùng RiceGuard

Trong hệ sinh thái VPNRice, lõi bảo mật RiceGuard ứng dụng các chỉ số DPD theo RFC 3706 để vận hành hệ thống đường hầm doanh nghiệp với độ ổn định cao.

Kiến trúc giám sát và chuyển hầm dự phòng của RiceGuard:
Cổng kết nối chi nhánh / Thiết bị người dùng
  │  Đang truyền dữ liệu về Cổng máy chủ chính
  ▼
Đánh giá lưu lượng cấp nhân liên tục
  │  - Giám sát bộ đếm gói tin XFRM trong nhân Linux
  │  - Phát hiện 0 gói tin chiều vào trong khoảng thời gian T_ngưỡng
  ▼
Kích hoạt gói tin DPD theo tải
  │  - Phát gói thăm dò IKEv2 Informational có bảo vệ mật mã
  │  - Chờ gói tin xác nhận số thứ tự tuần tự
  ▼
[Phân tích phản hồi liên kết]
  ├─► Nhận được ACK ──► Đặt lại bộ đếm; duy trì đường hầm chính
  │
  └─► Mất gói vượt ngưỡng (Sau 3 lần thăm dò liên tiếp không hồi đáp)
        │
        ▼
Kích hoạt chuyển vùng dự phòng nguyên tử
  ├─► Dọn dẹp các mục SAD/SPD cũ trong nhân
  ├─► Điều chỉnh bảng định tuyến đa đường (ECMP)
  ├─► Tái lập đường hầm bảo mật với Nút Anycast dự phòng
  ▼
Khôi phục thông suốt đường truyền RiceGuard (Thời gian gián đoạn < 850ms)
  1. Thu thập dữ liệu trực tiếp từ nhân: RiceGuard theo dõi trực tiếp các chỉ số thống kê của hệ thống XFRM qua giao tiếp Netlink, ghi nhận chính xác mốc thời gian của từng byte dữ liệu ESP mà không cần chuyển ngữ cảnh sang không gian người dùng.
  2. Đường cong thăm dò tương thích: Trong môi trường mạng di động có độ trễ dao động lớn, RiceGuard tự động điều chỉnh dãn cách thời gian thử lại, tránh ngắt kết nối oan do sóng vô tuyến chập chờn ngắn hạn.
  3. Chuyển mạch định tuyến nguyên tử: Khi phát hiện cổng chính mất liên lạc, hệ thống tự động cập nhật bảng định tuyến nhân Linux, chuyển luồng lưu lượng sang các máy chủ Anycast dự phòng chỉ trong chưa đầy một giây.

Xác thực và giám sát nhân Linux: Kiểm tra trạng thái DPD

Quản trị viên hệ thống có thể theo dõi và kiểm tra hoạt động của cơ chế Dead Peer Detection trên máy chủ Linux bằng các công cụ chuẩn.

Giám sát thăm dò IKE bằng swanctl và nhật ký hệ thống

Kiểm tra thông số cấu hình DPD trong cấu hình kết nối đang hoạt động:

# Liệt kê các kết nối đang chạy kèm tham số DPD
swanctl --list-conns

Mẫu cấu hình tham chiếu:

net-to-net:
  local:  203.0.113.10
  remote: 198.51.100.25
  version: 2
  rekey_time: 14400s
  dpd_delay: 15s
  dpd_timeout: 45s
  dpd_action: restart
  esp_proposals: aes256gcm128-sha256-modp2048

Theo dõi trực tiếp quá trình gửi nhận các gói tin thăm dò trong nhật ký dịch vụ:

# Xem các sự kiện DPD thời gian thực từ tiến trình charon
journalctl -u strongswan -f | grep -E "sending DPD request|received DPD response|peer not responding"

Dữ liệu ghi nhận:

charon: 11[IKE] sending DPD request to 198.51.100.25 [seq 0x3f1a]
charon: 11[IKE] received DPD response from 198.51.100.25 [seq 0x3f1a]
charon: 14[IKE] peer 198.51.100.25 is alive, restarting DPD query timer

Vòng đời trạng thái XFRM và dọn dẹp các SA rác

Kiểm tra nhân hệ điều hành Linux để đảm bảo các liên kết bảo mật hết hạn đã được giải phóng:

# Hiển thị trạng thái các liên kết bảo mật IPsec trong nhân
ip -s xfrm state show

Thông tin chi tiết:

src 198.51.100.25 dst 203.0.113.10
	proto esp spi 0x7c9b841a reqid 1 mode tunnel
	replay-window 64 flag esn
	auth-trunc hmac(sha256) 0x3a4f... 128
	enc cbc(aes) 0x18c9...
	lifetime config:
	  alloc: 0/0(bytes) curr: 421098/0(bytes)
	  packets: 0/0 curr: 3509/0
	stats:
	  replay-window 0 replay 0 failed 0

Khi hành vi DPD thực thi clear hoặc restart, nhân Linux lập tức dọn sạch các chỉ số SPI khỏi cơ sở dữ liệu XFRM, giải phóng hoàn toàn bộ đệm dữ liệu và kích hoạt cơ chế định tuyến lại qua kênh dự phòng.

Tiêu chuẩn RFC 3706 đã mang lại bước chuyển mình lớn trong kiến trúc mạng mã hóa khi thay thế các chu kỳ phát sóng định kỳ thô sơ bằng cơ chế đánh giá theo lưu lượng thông minh. Bằng cách kết hợp giữa việc thăm dò khi có tải và xác thực số thứ tự mật mã, IPsec hiện đại loại bỏ hoàn toàn nguy cơ tắc nghẽn hố đen mà vẫn tối ưu hóa băng thông và thời lượng pin thiết bị.

Để thiết lập các đường hầm zero-trust kiên cố cùng cơ chế giám sát và chuyển vùng tự động, Tải VPNRice.