Bộ giao thức IPsec là tiêu chuẩn công nghiệp nhằm bảo vệ liên lạc ở tầng mạng qua các hạ tầng công cộng không tin cậy. Được thiết kế trong kỷ nguyên mà mọi máy chủ trên internet đều được dự kiến sở hữu địa chỉ IPv4 định tuyến toàn cầu, IPsec dựa vào giao thức Đóng gói Tải trọng An ninh (ESP, IP Protocol 50) để cung cấp tính bảo mật, xác thực nguồn gốc dữ liệu và chống phát lại gói tin. Tuy nhiên, tình trạng cạn kiệt địa chỉ IPv4 đã dẫn đến việc triển khai phổ biến kỹ thuật Dịch địa chỉ mạng (NAT) và Dịch địa chỉ cổng (PAT). Do giao thức ESP thuần túy hoạt động trực tiếp trên tầng IP mà không có số hiệu cổng ở tầng giao vận L4, các bộ định tuyến NAT không thể theo dõi hoặc phân luồng luồng dữ liệu mã hóa phản hồi. Hai tiêu chuẩn RFC 3947 ("Negotiation of NAT-Traversal in the IKE") và RFC 3948 ("UDP Encapsulation of IPsec ESP Packets") đã giải quyết xung đột kiến trúc này bằng cách đóng gói ESP vào trong các gói tin UDP qua cổng 4500.

Kiến trúc ESP thuần túy (Thất bại qua cổng PAT/NAT):
[Tiêu đề IP (Proto 50)] [Tiêu đề ESP: SPI (4B), Seq (4B)] [Tải trọng mã hóa]
                      └──> Không có cổng UDP/TCP! PAT không thể định tuyến gói phản hồi.

Đóng gói ESP qua NAT-T (RFC 3948 qua cổng 4500):
[Tiêu đề IP (Proto 17)] [Tiêu đề UDP (Src 4500, Dst 4500)] [Tiêu đề ESP] [Dữ liệu]
                      └──> Cổng L4 định tuyến được giúp duy trì bảng trạng thái liên tục.

Nan đề biên dịch cổng PAT: Vì sao giao thức ESP thuần túy thất bại qua NAT

Để hiểu rõ sự cần thiết của cơ chế duyệt NAT trong IPsec (NAT-Traversal hay NAT-T), cần phân tích cách các cổng kết nối NAT và PAT có trạng thái xử lý tiêu đề gói tin.

Sự vô hình ở tầng giao vận: Sự thiếu vắng cổng TCP/UDP trong ESP

Khi nhiều thiết bị nội bộ sau bộ định tuyến văn phòng hoặc mạng di động CGNAT truy cập tài nguyên bên ngoài, cổng chuyển dịch sẽ ánh xạ các địa chỉ IP nguồn riêng sang một địa chỉ IP công cộng dùng chung. Để phân biệt gói tin phản hồi thuộc về thiết bị nội bộ nào, cổng chuyển dịch sẽ gán một số hiệu cổng nguồn L4 duy nhất cho mỗi phiên kết nối TCP hoặc UDP gửi đi.

ESP hoạt động ở tầng mạng L3 với số hiệu giao thức IP Protocol 50. Khác với TCP (Giao thức 6) hay UDP (Giao thức 17), ESP hoàn toàn không có khái niệm số hiệu cổng. Bốn byte đầu tiên của tiêu đề ESP chứa Chỉ số Tham số An ninh (SPI), một giá trị 32-bit tùy ý do phía nhận chỉ định để xác định Hiệp hội An ninh (SA):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index (SPI)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Payload Data (Variable)                    |

Khi một gói tin ESP gửi đi gặp cổng PAT, bộ định tuyến có thể ghi lại IP nguồn nhưng không thể gán cổng ánh xạ. Khi gói tin ESP từ xa phản hồi về, thiết bị PAT kiểm tra tiêu đề: do không có cổng đích, thiết bị không có cách nào xác định được IP nội bộ nào cần nhận gói tin. Một số bộ định tuyến gia đình cố gắng áp dụng cơ chế "SPI passthrough", nhưng giải pháp tình thế này sụp đổ ngay khi có từ hai thiết bị nội bộ trở lên cùng kết nối tới một máy chủ VPN từ xa.

Sửa đổi đường truyền và lỗi kiểm tra tổng Checksum TCP/UDP

Trở ngại thứ hai phát sinh trong chế độ IPsec Transport Mode. Thuật toán kiểm tra tổng checksum giả tiêu đề của TCP và UDP tính toán tính toàn vẹn dựa trên IP nguồn, IP đích, giao thức và độ dài phân đoạn. Khi bộ định tuyến NAT trung gian thay đổi địa chỉ IP nguồn hoặc đích, giá trị checksum ban đầu do máy trạm tính toán sẽ bị sai lệch. Vì phần thân gói tin đã bị ESP mã hóa, thiết bị NAT trung gian không thể tính toán lại checksum. Khi máy đích giải mã gói tin TCP/UDP bên trong, việc kiểm tra checksum thất bại khiến nhân hệ điều hành âm thầm đánh rơi gói tin.

Khám phá NAT theo RFC 3947: Phát hiện thiết bị trung gian

Để khắc phục tự động sự không tương thích với NAT, RFC 3947 (được tích hợp hoàn chỉnh trong IKEv2 RFC 7296) thiết lập quy trình Khám phá NAT (NAT-D) ngay trong giai đoạn đàm phán hiệp hội an ninh khởi đầu.

Tải trọng NAT-D và đối chiếu chuỗi băm trong IKE_SA_INIT

Trong lượt trao đổi IKE_SA_INIT qua cổng UDP 500, bên khởi tạo và bên phản hồi trao đổi các tải trọng NAT-D (NAT_DETECTION_SOURCE_IP và NAT_DETECTION_DESTINATION_IP). Mỗi tải trọng chứa một chuỗi băm SHA-1 tính trên các giá trị SPI, địa chỉ IP và cổng UDP:

$$\text{Hash} = \text{SHA-1}(\text{SPI}_i ,|, \text{SPI}_r ,|, \text{IP} ,|, \text{Port})$$

Quá trình này đánh giá hai góc nhìn độc lập:

  1. Tính băm nguồn: Bên khởi tạo băm địa chỉ IP cục bộ và cổng nguồn (500). Khi bên phản hồi nhận gói tin, hệ thống tính toán giá trị băm dựa trên IP nguồn và cổng thực tế quan sát được trên tiêu đề gói tin ngoài cùng. Nếu hai chuỗi băm khác nhau, chứng tỏ có thiết bị NAT đã can thiệp sửa đổi gói tin trên đường truyền ra.
  2. Tính băm đích: Bên khởi tạo băm IP đích và cổng từ xa. Phía phản hồi kiểm tra giá trị này với địa chỉ giao diện cục bộ. Nếu không khớp, phía phản hồi đang nằm sau một thiết bị NAT đích.
Trình tự phát hiện NAT-Discovery:
Bên khởi tạo (IP nội bộ: 192.168.1.50)              Bên phản hồi (IP tĩnh: 203.0.113.1)
  │                                                     │
  ├─ IKE_SA_INIT (UDP 500) ────────────────────────────>│ NAT đổi IP nguồn thành 198.51.100.2
  │  NAT-D (Nguồn: Băm của 192.168.1.50:500)            │ Phía phản hồi tính Hash(198.51.100.2:500)
  │  NAT-D (Đích: Băm của 203.0.113.1:500)              │ Chuỗi băm không khớp => Phát hiện có NAT!
  │<─ IKE_SA_INIT Response (UDP 500) ───────────────────┤
  ▼                                                     ▼
Cả hai đầu nhận diện NAT => Tự động chuyển dịch sang cổng UDP 4500.

Chuyển dịch cổng: Bước chuyển liền mạch từ UDP 500 sang UDP 4500

Ngay khi cả hai bên xác nhận sự hiện diện của thiết bị NAT trung gian, hệ thống lập tức thực hiện chuyển dịch cổng:

  • Lượt trao đổi IKE_AUTH tiếp theo chuyển toàn bộ từ cổng UDP 500 sang cổng UDP 4500.
  • Tất cả các gói dữ liệu ESP con sau đó đều được bọc trong tiêu đề UDP hướng tới cổng 4500.

Việc chuyển dịch cổng giúp loại bỏ xung đột với các bộ định tuyến NAT xử lý cổng 500 theo các quy tắc tĩnh cứng nhắc, mở ra kênh truyền thông suốt cho cả lưu lượng điều khiển IKE lẫn dữ liệu mã hóa.

Kiến trúc đóng gói RFC 3948: Cấu trúc Non-ESP Marker 4-byte

RFC 3948 chuẩn hóa định dạng đóng gói trên đường truyền để ghép kênh các thông điệp điều khiển IKE và gói dữ liệu ESP trên một socket UDP cổng 4500 duy nhất.

Định dạng đóng gói UDP theo RFC 3948:
+---------------------------------------------------------------+
|                       Tiêu đề IPv4 hoặc IPv6                  |
+---------------------------------------------------------------+
|             Tiêu đề UDP (Cổng nguồn, Cổng đích 4500)          |
+---------------------------------------------------------------+
|                      Điểm rẽ nhánh phân luồng                 |
|  [4 Byte đầu == 0x00000000]      |   [4 Byte đầu != 0x000000] |
|               │                  |              │             |
|               ▼                  |              ▼             |
|        Non-ESP Marker            |      Tiêu đề ESP (SPI)     |
|    (Gói tin điều khiển IKE)      |     (Gói dữ liệu mã hóa)   |
+----------------------------------+----------------------------+

Phân luồng lưu lượng điều khiển IKE và tải trọng dữ liệu ESP

Do cả thông điệp điều khiển IKE (luân chuyển khóa, kiểm tra sống còn, hủy SA) và gói dữ liệu người dùng đều đi chung cổng UDP 4500, nhân hệ điều hành phải phân biệt chúng với độ trễ tối thiểu mà không cần phân tích sâu nội dung phức tạp.

RFC 3948 giải quyết bài toán này thông qua quy ước định dạng:

  1. Non-ESP Marker cho IKE: Mọi thông điệp IKE truyền qua cổng UDP 4500 đều được gắn thêm tiền tố 4 byte số 0 (0x00000000).
  2. Vị trí SPI trực tiếp cho ESP: Mọi gói dữ liệu ESP đóng gói đều đặt trường SPI 32-bit ngay sau 8 byte của tiêu đề UDP.

Vì RFC 4301 quy định rõ giá trị SPI 0 (0x00000000) là không hợp lệ và không bao giờ được cấp cho bất kỳ Hiệp hội An ninh nào, ngăn xếp mạng phía nhận chỉ cần thực hiện phép so sánh $O(1)$ trên 4 byte đầu tiên sau tiêu đề UDP:

  • Nếu 32 bit đầu tiên bằng 0x00000000, hệ thống loại bỏ 4 byte tiền tố và chuyển gói tin lên tiến trình IKE ở không gian người dùng (user-space).
  • Nếu 32 bit đầu tiên khác 0, gói tin là dữ liệu ESP mã hóa. Nhân hệ điều hành sử dụng 32 bit này làm SPI để tra cứu trong Cơ sở Dữ liệu Hiệp hội An ninh (SAD) và chuyển trực tiếp tới các khối xử lý mật mã của nhân để giải mã.

Quy tắc này giúp loại bỏ hoàn toàn chi phí chuyển đổi ngữ cảnh cho luồng dữ liệu truyền dẫn, duy trì thông lượng tối đa qua các cổng NAT.

Cơ chế NAT Keepalive và bộ định thời bảng dịch trạng thái

Các tường lửa có trạng thái và cổng CGNAT luôn duy trì bảng ánh xạ trong bộ nhớ RAM. Khi một thiết bị nội bộ khởi tạo phiên UDP, cổng mạng sẽ tạo một mục trạng thái liên kết địa chỉ IP/cổng nội bộ với ánh xạ công cộng bên ngoài. Nếu không có gói tin nào đi qua trong một khoảng thời gian nhất định (thường chỉ 30 đến 60 giây trên mạng di động), cổng mạng sẽ xóa mục trạng thái này. Một khi mục trạng thái bị xóa, các gói tin mã hóa từ máy chủ VPN gửi về sẽ bị đánh rơi hoàn toàn.

RFC 3948 định nghĩa gói tin NAT Keepalive chuẩn hóa:

  • Định dạng: Một byte duy nhất mang giá trị 0xFF đặt ngay sau tiêu đề UDP trên cổng 4500.
  • Dung lượng: Đúng 1 byte dữ liệu.
  • Chu kỳ gửi: Thường được phát đều đặn mỗi 20 đến 25 giây khi đường truyền không có lưu lượng dữ liệu.
Gói tin NAT Keepalive theo RFC 3948:
+-----------------------------------------------+
| Tiêu đề IP (Protocol 17)                      |
+-----------------------------------------------+
| Tiêu đề UDP (Src 4500, Dst 4500, Length 9)    |
+-----------------------------------------------+
| 0xFF (Tải trọng đúng 1 Octet)                 |
+-----------------------------------------------+

Khi máy chủ nhận được gói tin UDP có độ dài tải trọng đúng 1 byte và mang giá trị 0xFF, hệ thống sẽ âm thầm loại bỏ byte này mà không ghi log lỗi. Gói tin này thuần túy đóng vai trò làm mới bộ đếm thời gian (timer) của bảng dịch NAT trên các thiết bị mạng trung gian, giữ cho tuyến kết nối phản hồi luôn mở.

Chi phí đóng gói, khám phá MTU đường truyền và kẹp biên TCP MSS

Việc bọc gói tin ESP vào tiêu đề UDP làm tăng thêm kích thước tiêu đề tổng thể, ảnh hưởng trực tiếp đến dung lượng truyền tải hữu ích.

Việc bổ sung thêm 8 byte tiêu đề UDP làm giảm Đơn vị Truyền dẫn Cực đại (MTU) hiệu dụng. Trên đường truyền Ethernet chuẩn 1.500 byte:

  • Tiêu đề ESP IPv4 thông thường chiếm từ 50 đến 60 byte tùy thuộc vào thuật toán mã hóa (AES-GCM-128 so với AES-CBC-256 kèm HMAC-SHA256).
  • Việc đóng gói UDP làm tăng thêm 8 byte, nâng tổng chi phí tiêu đề đường hầm lên 62–72 byte.
  • Giá trị TCP MSS bên trong bắt buộc phải được kẹp biên (clamp) từ mức chuẩn 1.460 byte xuống khoảng 1.360–1.380 byte.

Nếu không thực hiện kẹp biên TCP MSS, các gói tin lớn vượt quá MTU đường truyền sẽ bị phân mảnh. Do nhiều thiết bị mạng của nhà mạng thường xuyên loại bỏ các phân mảnh ở tầng IP, cấu hình MTU không chuẩn xác sẽ gây ra hiện tượng tắc nghẽn vô hình và suy giảm nghiêm trọng tốc độ đường truyền.

Độ bền vững mạng CGNAT doanh nghiệp: Tích hợp cùng RiceGuard

Trong hệ thống VPNRice, động cơ bảo mật RiceGuard ứng dụng chuẩn mực RFC 3948 NAT-T nhằm đảm bảo kết nối bền bỉ qua các mạng di động phức tạp, kiến trúc mạng nội bộ NAT lồng nhau (Dual-NAT) và các tầng tường lửa doanh nghiệp.

Kiến trúc Zero-Trust NAT-T của RiceGuard:
Thiết bị di động / Điểm cuối từ xa
  │  (Nằm sau hạ tầng mạng CGNAT / NAT kép)
  │  Khởi tạo kết nối IKE_SA_INIT qua UDP 500
  ▼
Xác minh tự động NAT-D
  │  - Nhận diện sự thay đổi địa chỉ IP ngoài
  │  - Chuyển dịch tức thì sang cổng UDP 4500
  │  - Gắn Non-ESP Marker 4-byte cho các gói điều khiển
  ▼
Cổng Gateway Anycast công suất cao RiceGuard
  │  - Tiếp nhận các khung ESP đóng gói UDP 4500
  │  - Tra cứu SAD siêu tốc nhờ cơ chế tăng tốc nhân XFRM
  │  - Điều chỉnh tần suất keepalive thích ứng theo đường truyền
  ▼
Mạng trục bảo mật / Truy cập internet an toàn
  1. Chuyển cổng xác định: RiceGuard tự động nhận diện điều kiện mạng NAT khi khởi tạo đường hầm, chủ động chuyển sang UDP 4500 để tránh việc bị lọc cổng 500 ở cấp độ nhà mạng.
  2. Lịch phát Keepalive thích ứng: Thay vì sử dụng chu kỳ cố định, RiceGuard chủ động điều biến tần suất phát keepalive dựa trên đặc tính của mạng di động, vừa bảo toàn pin thiết bị vừa duy trì trạng thái mở của cổng NAT.
  3. Tăng tốc xử lý trong nhân: Ứng dụng chính sách socket Linux XFRM với khả năng dỡ tải đóng gói UDP nguyên bản, RiceGuard chuyển dữ liệu mã hóa thẳng tới phần cứng xử lý mật mã, đồng thời phân luồng các gói điều khiển lên tầng ứng dụng quản trị một cách tối ưu.

Xác thực chẩn đoán: Kiểm tra Socket NAT-T và cơ sở dữ liệu SAD trong nhân Linux

Quản trị viên hệ thống có thể kiểm tra trực tiếp các phiên làm việc NAT-T trên máy chủ Linux bằng các công cụ chẩn đoán sẵn có.

Kiểm tra trạng thái Socket UDP 4500

Xác nhận tiến trình IPsec đang lắng nghe trên cổng 4500:

# Kiểm tra các socket UDP đang mở cho IKE và NAT-T
ss -uan '( sport = :500 or sport = :4500 )'

Kết quả mẫu:

State    Recv-Q    Send-Q       Local Address:Port        Peer Address:Port
UNCONN   0         0                  0.0.0.0:500              0.0.0.0:*
UNCONN   0         0                  0.0.0.0:4500             0.0.0.0:*

Kiểm tra trạng thái XFRM trong nhân về đóng gói UDP

Kiểm tra Cơ sở Dữ liệu Hiệp hội An ninh (SAD) trong nhân Linux để xác thực các tham số đóng gói UDP:

# Hiển thị chi tiết trạng thái IPsec bao gồm thông tin đóng gói
ip xfrm state show

Đoạn trích kết quả:

src 198.51.100.2 dst 203.0.113.1
	proto esp spi 0xc7a41289 reqid 1 mode tunnel
	replay-window 64 flag af-unspec
	auth-trunc hmac(sha256) 0x6e7a... 128
	enc cbc(aes) 0x4f12...
	encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
	sel src 0.0.0.0/0 dst 0.0.0.0/0

Dòng chỉ thị encap type espinudp khẳng định nhân Linux đang chủ động bọc các gói tin ESP phát đi trong tiêu đề UDP cổng 4500 và đón nhận các gói tin có cấu trúc tương tự, bảo đảm dữ liệu lưu thông thông suốt qua mọi thiết bị trung gian.

Tiêu chuẩn RFC 3948 là một bước đột phá thiết yếu giúp IPsec duy trì khả năng hoạt động trên một mạng internet bị chi phối bởi các cổng NAT. Bằng cách bọc các gói tin ESP không trạng thái vào các khung UDP 4500 tiêu chuẩn và phân định ranh giới rõ ràng thông qua Non-ESP Marker, cơ chế NAT-Traversal mang lại khả năng kết nối mã hóa mạnh mẽ và ổn định trên mọi môi trường mạng viễn thông.

Để thiết lập đường hầm zero-trust kiên cố vận hành thông suốt qua các lớp thiết bị trung gian phức tạp, Tải VPNRice.