Hạ tầng mạng VPN doanh nghiệp và trục mạng Anycast toàn cầu đòi hỏi năng lực mở rộng băng thông khổng lồ. Khi hàng ngàn đường hầm kết nối gom cụm qua các nhà cung cấp đám mây, lưu lượng đường trục không thể chỉ phụ thuộc vào một tuyến truyền dẫn đơn lẻ. Thay vào đó, mạng hiệu năng cao dựa vào định tuyến đa đường chi phí bằng nhau (ECMP) và nhóm gom liên kết (LAG) để phân bổ gói tin qua hàng chục đường truyền vật lý song song.

Tuy nhiên, các giao thức tạo đường hầm điểm-nối-điểm truyền thống—đặc biệt là Generic Routing Encapsulation (GRE, RFC 2784) và IP-in-IP (RFC 2003)—bị gãy vỡ trước kiến trúc chuyển mạch đa đường hiện đại. Do các giao thức này đóng gói gói tin bên trong trực tiếp vào tiêu đề IP bên ngoài mà không có số cổng tầng giao vận (Layer 4), các thiết bị chuyển mạch trung gian không thể phân biệt được các luồng dữ liệu riêng lẻ.

Hạn chế này dẫn tới hiện tượng phân cực băm ECMP (Hash Polarization) nghiêm trọng. Hàng ngàn phiên làm việc khác nhau đi qua đường hầm bị dồn cứng vào đúng một liên kết vật lý duy nhất, gây nghẽn và giật độ trễ, trong khi các liên kết song song khác hoàn toàn nhàn rỗi. Để giải quyết triệt để vấn đề này, IETF đã chuẩn hóa RFC 8086 (Đóng gói GRE trong UDP) cùng các chuẩn mạng ảo hóa tiên tiến như GENEVE (RFC 8926).

Nút thắt mạng phủ overlay: Lý do đường hầm VPN truyền thống làm gãy định tuyến đa đường

Trong mạng doanh nghiệp thông thường không dùng mạng phủ (overlay), các thiết bị chuyển mạch cân bằng tải lưu lượng bằng cách tính toán hàm băm ECMP dựa trên tiêu đề giao vận. Các luồng TCP và UDP mang số cổng nguồn và cổng đích phong phú, tạo ra độ ngẫu nhiên tự nhiên giúp chuyển mạch rải đều các gói tin qua các chặng kế tiếp ECMP.

Khi gói tin đi vào đường hầm VPN truyền thống, khả năng nhận diện này biến mất:

  1. Đóng gói tiêu đề: Cổng mạng bọc gói tin IP gốc cùng dữ liệu TCP/UDP vào tiêu đề GRE.
  2. Gán tiêu đề IP ngoài: Cổng mạng thiết lập trường Protocol của tiêu đề IP ngoài thành 47 (GRE).
  3. Mất độ ngẫu nhiên: Gói ngoài hoàn toàn không có cổng Layer 4. Toàn bộ lưu lượng giữa Cổng A (198.51.100.1) và Cổng B (203.0.113.2) đều có chung địa chỉ IP và chung số giao thức 47.

Đối với các bộ định tuyến trung gian của nhà mạng viễn thông, hàng triệu cuộc hội thoại riêng biệt hiển thị như một dòng chảy đơn khối duy nhất.

Giải phẫu thuật toán băm ECMP: Cách chuyển mạch trung gian lựa chọn liên kết vật lý

Các thiết bị chuyển mạch lõi spine-leaf sử dụng vi mạch chuyên dụng (ASIC) để chuyển tiếp hàng triệu gói tin mỗi giây. Nhằm ngăn ngừa việc gói tin đến sai thứ tự—vốn làm sụt giảm nghiêm trọng hiệu năng truyền tải TCP—thiết bị không phân phối theo kiểu xoay vòng (round-robin). Thay vào đó, ASIC áp dụng hàm băm xác định (như CRC32 hoặc Jenkins hash) lên các trường của luồng dữ liệu để chỉ định cổng vật lý xuất khẩu.

Chỉ số liên kết được tính theo phép chia lấy dư:

$$ ext{Chỉ số liên kết} = ext{Hash}( ext{Tuple của luồng}) \pmod N$$

Trong đó $N$ là số lượng đường truyền song song khả dụng (thường là 8, 16, 32 hoặc 64 liên kết).

Tình thế lưỡng nan của 5-Tuple: Thiếu cổng giao vận trong giao thức GRE 47

Thiết bị chuyển mạch tiêu chuẩn thường đọc bộ 5-tuple: IP nguồn, IP đích, giao thức, cổng nguồn và cổng đích. Khi ASIC xử lý gói tin có Protocol = 47:

;; Gói tin IP thông thường (TCP/UDP)
[ Tiêu đề IP ngoài ] [ Tiêu đề TCP/UDP ] [ Dữ liệu ]
-> Đầu vào băm: IP nguồn, IP đích, Giao thức (6/17), Cổng nguồn, Cổng đích (Entropy cao)

;; Gói tin đường hầm GRE truyền thống (RFC 2784)
[ Tiêu đề IP ngoài ] [ Tiêu đề GRE ] [ Gói tin IP bên trong ]
-> Đầu vào băm: IP nguồn, IP đích, Giao thức (47), [Không có cổng Layer 4] (Entropy = 0)

ASIC buộc phải hạ cấp xuống băm 2-tuple hoặc 3-tuple: chỉ dựa vào IP nguồn, IP đích và giao thức. Do cả ba tham số này cố định trong suốt vòng đời của đường hầm, hàm băm luôn cho ra một kết quả toán học duy nhất trên mọi gói tin.

Phân cực băm: Hiện tượng nghẽn nghiêm trọng trên hạ tầng mạng đa liên kết

Khi nhiều thiết bị chuyển mạch trong cấu trúc liên kết chạy cùng thuật toán băm trên dữ liệu tuple giống hệt nhau, tình trạng nghẽn tích tụ thành hiện tượng phân cực băm:

[ Cổng A ] === (100% Lưu lượng GRE dồn vào Liên kết 1) ===> [ Chuyển mạch 1 ]
   Liên kết 1: [==================== Tải 100% - RƠI GÓI TIN ]
   Liên kết 2: [ Tải 0% - Hoàn toàn nhàn rỗi               ]
   Liên kết 3: [ Tải 0% - Hoàn toàn nhàn rỗi               ]
   Liên kết 4: [ Tải 0% - Hoàn toàn nhàn rỗi               ]

Dù hạ tầng sở hữu tổng dung lượng 400 Gbps trên 4 đường 100 Gbps, đường hầm VPN vẫn làm quá tải một đường duy nhất. Người dùng phải chịu đựng hiện tượng đầy bộ đệm (bufferbloat), rơi gói tin và độ trễ tăng vọt, trong khi 75% băng thông tổng thể bị lãng phí.

Nếu chuyển mạch cố gắng kiểm tra gói sâu (DPI) để đọc tiêu đề bên trong, chúng sẽ thất bại khi luồng trong được mã hóa bảo mật (như WireGuard hoặc IPsec ESP), hoặc khi gói tin bị phân mảnh.

Kiến trúc chuẩn RFC 8086: Đóng gói GRE bên trong gói tin UDP

Nhằm khôi phục khả năng phân phối lưu lượng đa đường mà không đòi hỏi thiết bị chuyển mạch phải giải mã gói tin bên trong, IETF đã ban hành RFC 8086. Tiêu chuẩn này đề xuất giải pháp kỹ thuật tinh gọn: bọc gói tin GRE bên trong một tiêu đề User Datagram Protocol (UDP).

+-----------------------------------+
|          Tiêu đề IP ngoài         |  (Protocol = 17 cho UDP)
+-----------------------------------+
|         Tiêu đề UDP ngoài         |  (Cổng nguồn = Entropy, Cổng đích = 4754)
+-----------------------------------+
|            Tiêu đề GRE            |  (RFC 2784 / RFC 2890)
+-----------------------------------+
|        Gói tin IP bên trong       |  (Dữ liệu IPv4 hoặc IPv6)
+-----------------------------------+

RFC 8086 chỉ định cổng đích IANA tiêu chuẩn: UDP Port 4754 (hoặc cổng tùy chọn trong mạng nội bộ). Thiết bị chuyển mạch trung gian lập tức nhận diện đây là gói tin UDP thông thường và kích hoạt thuật toán băm 5-tuple sẵn có mà không cần bất kỳ thay đổi phần cứng nào.

Cổng nguồn Entropy: Phân tán luồng động mà không cần kiểm tra gói sâu

Cốt lõi công nghệ của RFC 8086 nằm ở cách cổng mạng đóng gói thiết lập giá trị cho Cổng nguồn UDP ngoài.

Thay vì dùng cổng cố định, thiết bị tính toán giá trị ngẫu nhiên 16-bit (Entropy Hash) từ tiêu đề của gói tin bên trong:

  1. Nhận diện luồng bên trong: Với gói tin IPv4/IPv6 bên trong, cổng mạng băm bộ 5-tuple gốc (IP nguồn, IP đích, Giao thức, Cổng nguồn, Cổng đích).
  2. Khai thác nhãn luồng IPv6: Với gói tin IPv6 bên trong, thiết bị trích xuất trực tiếp trường Flow Label 20-bit.
  3. Phân tán luồng mã hóa: Với đường hầm lồng đường hầm (như các phiên WireGuard), thiết bị băm định danh phiên kết nối hoặc dữ liệu bắt tay mật mã.
  4. Ánh xạ dải cổng động: Giá trị băm được chuyển vào dải cổng tạm thời (ephemeral port) theo RFC 6335 (49152 đến 65535):

$$ ext{Cổng nguồn UDP ngoài} = 49152 + ( ext{Hash}( ext{Luồng trong}) \pmod{16384})$$

Nhờ mỗi phiên làm việc của người dùng tạo ra một cổng nguồn entropy khác nhau, chuyển mạch trung gian sẽ tính toán các giá trị băm ECMP khác nhau. Lưu lượng tự động phân tán đồng đều qua toàn bộ 32 hoặc 64 liên kết vật lý. Các gói tin trong cùng một luồng luôn có chung giá trị entropy, triệt tiêu hoàn toàn nguy cơ xáo trộn thứ tự gói tin.

So sánh các chuẩn đóng gói: GRE-in-UDP, VXLAN và GENEVE RFC 8926

GRE-in-UDP nằm trong chuỗi tiến hóa của các giải pháp mạng phủ dựa trên nền tảng UDP:

Giao thức Chuẩn RFC Cổng ngoài Chi phí tiêu đề Khả năng mở rộng / Metadata
GRE Cổ điển RFC 2784 Không có (Proto 47) 24 - 36 byte Khóa tĩnh / Số thứ tự
GRE-in-UDP RFC 8086 UDP 4754 32 - 44 byte Tương thích ngược GRE
VXLAN RFC 7348 UDP 4789 50 byte Định danh VNI 24-bit cố định
GENEVE RFC 8926 UDP 6081 50+ byte Tùy chọn TLV độ dài tùy biến

Trong khi VXLAN tập trung mở rộng phân đoạn Layer 2 trong trung tâm dữ liệu, GENEVE (Generic Network Virtualization Encapsulation, RFC 8926) đại diện cho chuẩn mực quy mô lớn hiện đại. Hoạt động trên cổng UDP 6081, GENEVE cung cấp các tùy chọn Type-Length-Value (TLV) độ dài linh hoạt, cho phép kỹ sư mạng nhúng trực tiếp dữ liệu đo từ xa mạng nội bộ (INT), thẻ phân tách thuê bao và cờ truy vết tuyến đường vào tiêu đề gói tin.

Chi phí tiêu hao và Path MTU: Giảm thiểu phình to tiêu đề và giới hạn MSS

Việc đóng gói tiêu đề tạo ra kích thước byte bổ sung, có thể ảnh hưởng đến thông lượng mạng nếu kích thước truyền tối đa (MTU) bị cấu hình sai:

  • Tiêu đề IP ngoài IPv4: 20 byte
  • Tiêu đề UDP ngoài: 8 byte
  • Tiêu đề GRE: 4 byte (hoặc lên đến 16 byte nếu kèm Khóa và Số tuần tự)
  • Tổng chi phí tiêu đề: 32 đến 44 byte mỗi gói tin

Nếu một máy khách TCP bên trong truyền gói tin 1500 byte tiêu chuẩn qua mạng vật lý có MTU 1500 byte, gói tin sau khi đóng gói sẽ nở rộng lên 1532+ byte.

[ Gói tin trong: 1500 Byte ] + [ Đóng gói: 32 Byte ] = 1532 Byte -> RƠI GÓI (Cần phân mảnh)

Để ngăn chặn hiện tượng phân mảnh:

  1. Khám phá MTU tuyến đường (PMTUD): Cổng mạng xử lý gói tin ICMP "Cần phân mảnh" và IPv6 "Gói tin quá lớn" (RFC 8201).
  2. Kẹp biên TCP MSS: Cổng mạng viết lại giá trị MSS trong quá trình bắt tay ba bước, giới hạn tải trọng xuống mức 1420 hoặc 1440 byte.
  3. Sử dụng Jumbo Frames: Trong các tuyến truyền dẫn đám mây riêng, hạ tầng được thiết lập MTU vật lý lên 9000 byte, chứa trọn tiêu đề bổ sung mà không phải kẹp giảm gói tin.

Ngữ nghĩa Checksum: Checksum bằng không và quy tắc xác thực UDP IPv6

Tiêu đề UDP chứa một trường checksum 16-bit. Trong IPv4 tiêu chuẩn, việc tính toán checksum UDP là tùy chọn; thiết lập giá trị 0x0000 biểu thị việc người gửi bỏ qua phép kiểm tra này.

Cấu trúc tiêu đề và tăng tốc Zero-Checksum trong chuyển mạch lưu lượng lớn

Đối với đường hầm GRE-in-UDP chạy trên IPv4, RFC 8086 Mục 3.2 cho phép đặt checksum UDP ngoài bằng 0. Do gói tin bên trong thường đã có cơ chế bảo vệ tính toàn vẹn (như TCP checksum, xác thực WireGuard Poly1305 hoặc IPsec ESP), việc tính toán lại checksum UDP ngoài trên từng gói tin gây lãng phí chu kỳ xử lý của CPU cổng mạng.

Việc thiết lập checksum bằng 0 cho phép card mạng (NIC) truyền gói tin ở tốc độ dây tối đa mà không chịu chi phí tính toán phần mềm.

Xử lý yêu cầu Checksum IPv6 ngoài theo chuẩn RFC 6935 và RFC 6936

Trong chuẩn IPv6 (RFC 8200), việc tính checksum UDP là bắt buộc. Một nút IPv6 nhận gói tin UDP có checksum bằng 0 phải hủy gói tin đó.

Quy định này từng gây trở ngại lớn cho các đường hầm lưu lượng lớn qua hạ tầng IPv6. Để tháo gỡ, RFC 6935 và RFC 6936 đã cập nhật ngoại lệ cho các giao thức đóng gói đường hầm, cho phép checksum UDP bằng 0 dưới các ràng buộc nghiêm ngặt:

  • Các đầu cuối đường hầm phải xác nhận tải trọng bên trong có cơ chế phát hiện lỗi tin cậy.
  • Cổng mạng phải kiểm tra cổng tiếp nhận riêng biệt, tránh để ứng dụng thông thường nhận nhầm gói hỏng.
  • Hạ tầng truyền dẫn phải là mạng được kiểm soát với tỷ lệ lỗi bit cực thấp.

Trục kết nối Anycast RiceGuard: Kiến trúc lưới đa đường triệt tiêu phân cực

VPNRice triển khai lưới kiến trúc RiceGuard Lớp 3 nhằm kết nối các điểm diện diện Anycast qua các nhà mạng Tier-1. Trong mạng phân tán mật độ cao, hiện tượng phân cực lưu lượng làm giảm sút chất lượng trải nghiệm của người dùng.

Kiến trúc RiceGuard loại bỏ hoàn toàn phân cực băm nhờ cơ chế định tuyến entropy UDP:

  • Entropy luồng động: Các nút Anycast tính toán giá trị băm 16-bit, đưa cổng nguồn ngẫu nhiên vào các gói tin liên trung tâm dữ liệu.
  • Phân phối đa đường cân bằng: Trục mạng phân bổ lưu lượng VPN đối xứng qua 32 và 64 đường dẫn ECMP mà không yêu cầu nhà mạng phải soi gói sâu.
  • Duy trì ổn định phiên: Giá trị entropy giữ nguyên cố định cho từng phiên, ngăn ngừa xáo trộn thứ tự gói và giữ độ giật dưới 1 mili-giây.
  • Bảo đảm không phân mảnh: RiceGuard tự động kẹp biên MSS, ngăn chặn tình trạng hố đen lưu lượng. Người dùng có thể kiểm tra thuộc tính kết nối thông qua /what-is-my-ip.

Người dùng cần bảo vệ kết nối có thể tải ứng dụng tại /download. Phân tích chuyên sâu về tính bền bỉ khi cập nhật BGP được trình bày tại /news/bgp-graceful-restart-rfc-4724-llgr-anycast-resilience, và cơ chế tái sử dụng cổng kết nối được phân tích trong /news/tcp-time-wait-state-rfc-1337-port-exhaustion-vpn.

Triển khai thực tiễn: Cấu hình GRE-in-UDP và FOU trên Linux

Nhân Linux hỗ trợ nguyên bản các đường hầm bọc trong UDP thông qua Foo-over-UDP (FOU). Quản trị viên có thể cấu hình đường hầm GRE-in-UDP hiệu năng cao bằng các lệnh iproute2 tiêu chuẩn.

Kích hoạt mô-đun FOU và cổng tiếp nhận:

# Nạp các mô-đun nhân cho FOU và GRE
modprobe fou
modprobe ip_gre

# Mở cổng nhận FOU cho GRE-in-UDP (cổng chuẩn RFC 8086 là 4754)
ip fou add port 4754 gue

Cấu hình giao diện đường hầm GRE-in-UDP:

# Tạo giao diện đường hầm trên Cổng A với entropy tự động
ip link add name tun-gre-udp type gre     remote 203.0.113.2 local 198.51.100.1     ttl 64     encap fou encap-sport auto encap-dport 4754

# Gán địa chỉ IP nội bộ và kích hoạt giao diện với MTU tối ưu
ip addr add 10.200.0.1/30 dev tun-gre-udp
ip link set dev tun-gre-udp up mtu 1440

Tham số encap-sport auto hướng dẫn nhân Linux tự động tính toán băm entropy cho mỗi luồng bên trong và ghi vào cổng nguồn UDP ngoài.

Kiểm tra phân tán đa đường qua giám sát gói tin:

Xác nhận tham số đóng gói đang hoạt động:

ip -d link show tun-gre-udp

Kiểm tra phân tán luồng bằng tcpdump:

tcpdump -ni eth0 udp port 4754

21:20:15.102482 IP 198.51.100.1.53120 > 203.0.113.2.4754: UDP, length 1448
21:20:15.102590 IP 198.51.100.1.61445 > 203.0.113.2.4754: UDP, length 1448
21:20:15.102645 IP 198.51.100.1.49812 > 203.0.113.2.4754: UDP, length 1448

Mỗi luồng dữ liệu phát đi với một cổng nguồn riêng biệt (53120, 61445, 49812), bảo đảm phân bổ tối ưu qua toàn bộ hạ tầng ECMP mà không làm ảnh hưởng đến độ an toàn của đường hầm.