Màn hình máy tính hiển thị biểu tượng đường hầm mạng riêng ảo (VPN) đang hoạt động ổn định. Trạng thái kết nối mã hóa xanh lá, cơ chế Kill Switch báo hiệu sẵn sàng ngắt mạng nếu sự cố xảy ra. Thế nhưng, từng yêu cầu HTTP, truy vấn DNS và dữ liệu nhạy cảm phát sinh từ trình duyệt khi truy cập Wi-Fi quán cà phê lại âm thầm truyền thẳng đến máy chủ của kẻ tấn công dưới dạng các khung Ethernet hoàn toàn không mã hóa.
Kỹ thuật bóc tách lưu lượng này mang mã định danh CVE-2024-3661, hay còn gọi là TunnelVision. Được phát hiện bởi các chuyên gia bảo mật tại Leviathan Security Group, TunnelVision không bắt nguồn từ lỗi tràn bộ đệm hay lỗ hổng phá vỡ thuật toán mật mã. Kỹ thuật này khai thác một tính năng quản trị mạng cốt lõi có sẵn trong Giao thức Cấu hình Động Máy chủ (DHCP) từ năm 2002: tùy chọn DHCP Option 121 (quy định trong RFC 3442, The Classless Static Route Option).
Bằng cách cài cắm các bản ghi định tuyến tĩnh trong quá trình cấp phát IP cục bộ, kẻ tấn công trên cùng mạng nội bộ (LAN) thao túng trực tiếp bảng định tuyến của nhân hệ điều hành, hướng toàn bộ lưu lượng ra ngoài đường hầm VPN mà không làm gián đoạn kết nối VPN đang mở.
[Ứng dụng người dùng / Trình duyệt web]
│
▼
[Bảng Định tuyến Kernel OS]
┌─────────────────────────┐
│ Đánh giá Quy tắc Route │
└───────────┬─────────────┘
│
┌───────────┴───────────────────────────────┐
│ │
[Tuyến mặc định VPN] [Tuyến ép từ DHCP Option 121]
Prefix: 0.0.0.0/0 (Metric 1) Prefix: 0.0.0.0/1 + 128.0.0.0/1
Interface: tun0 (Mã hóa VPN) Interface: wlan0 (Không mã hóa)
│ │
│ (Bị bỏ qua: Tiền tố ngắn hơn) │ (Được chọn: Khớp tiền tố dài hơn!)
│ ▼
▼ [Cổng Gateway Giả mạo / Bắt gói]
[Máy chủ VPN An toàn] (Đọc trộm toàn bộ dữ liệu thô)
Bản chất của TunnelVision: Khai thác nguyên lý Longest Prefix Match
Để hiểu rõ vì sao TunnelVision có thể vô hiệu hóa cơ chế bảo vệ của VPN truyền thống, cần xem xét nguyên lý cốt lõi của việc chuyển tiếp gói tin IP: quy tắc khớp tiền tố dài nhất (Longest Prefix Match - LPM).
Khi nhân hệ điều hành chuẩn bị chuyển tiếp một gói tin ra mạng, bảng định tuyến sẽ đối chiếu địa chỉ IP đích với các quy tắc hiện có. Nếu có nhiều tuyến đường cùng bao hàm dải IP đích, hệ điều hành bắt buộc phải chọn tuyến đường có mặt nạ mạng con (subnet mask) cụ thể hơn — tức là tiền tố mạng có số bit dài hơn — bất chấp độ ưu tiên metric hay loại giao diện mạng.
Khi ứng dụng VPN kích hoạt, phần mềm thường thiết lập một tuyến đường mặc định (Default Route):
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.1 0.0.0.0 UG 50 0 0 tun0
Tuyến mặc định 0.0.0.0/0 đại diện cho toàn bộ không gian Internet nhưng có độ dài tiền tố bằng 0 bit (/0), nghĩa là mức độ ưu tiên khớp thấp nhất trong bảng định tuyến.
Khi thiết bị kết nối vào một mạng Wi-Fi công cộng độc hại, máy trạm phát gói tin DHCP Discover. Máy chủ DHCP giả mạo của kẻ tấn công phản hồi kèm trường Option 121. Thay vì chỉ cấp địa chỉ IP và gateway thông thường, Option 121 ép hai tuyến đường tĩnh bao phủ toàn bộ Internet:
0.0.0.0/1trỏ về gateway cục bộ192.168.1.1(bao phủ từ0.0.0.0đến127.255.255.255)128.0.0.0/1trỏ về gateway cục bộ192.168.1.1(bao phủ từ128.0.0.0đến255.255.255.255)
Do tiền tố /1 dài hơn /0, nhân hệ điều hành ưu tiên gửi toàn bộ gói tin ra giao diện vật lý wlan0 thay vì giao diện ảo tun0. Dữ liệu duyệt web thoát ra mạng nội bộ dưới dạng văn bản thô, tạo điều kiện cho kẻ tấn công bắt trọn phiên truyền tải.
+--------------------------+-----------------+-------------------+-----------------------+
| Bản ghi Định tuyến | Độ dài tiền tố | Giao diện xuất | Mức độ ưu tiên |
+--------------------------+-----------------+-------------------+-----------------------+
| Tuyến mặc định (0.0.0.0/0)| /0 (Bao quát) | tun0 (Đường hầm) | Bị đè bởi tiền tố /1 |
| Option 121 (0.0.0.0/1) | /1 (Cụ thể) | wlan0 (Thô cục bộ)| Được chọn (Nửa đầu IP)|
| Option 121 (128.0.0.0/1) | /1 (Cụ thể) | wlan0 (Thô cục bộ)| Được chọn (Nửa sau IP)|
| Địa chỉ Host riêng (/32) | /32 (Tuyệt đối) | wlan0 (Thô cục bộ)| Ưu tiên tuyệt đối |
+--------------------------+-----------------+-------------------+-----------------------+
Vì sao công tắc ngắt mạng (Kill Switch) truyền thống bị qua mặt?
Nhiều người dùng tin tưởng rằng tính năng Kill Switch sẽ ngăn chặn mọi rò rỉ dữ liệu. Tuy nhiên, phần lớn Kill Switch thế hệ cũ được thiết kế để ứng phó sự cố sập kết nối chứ không phải tình huống đầu độc bảng định tuyến:
- Giám sát trạng thái giao diện: Kill Switch thông thường chỉ kiểm tra tiến trình VPN hoặc trạng thái của bộ điều hợp ảo (
tun0hay TAP). Khi TunnelVision diễn ra, tiến trình VPN vẫn kết nối bình thường, các gói tin giữ kết nối (keepalive) vẫn phản hồi, do đó Kill Switch không hề kích hoạt. - Quy tắc tường lửa cho phép mạng nội bộ: Nhằm duy trì khả năng in ấn qua Wi-Fi hoặc chia sẻ tệp NAS trong mạng nội bộ, Kill Switch thường cho phép ngoại lệ các gói tin gửi đến dải mạng LAN cục bộ. Khi Option 121 biến toàn bộ Internet thành các tuyến đường LAN qua gateway cục bộ, tường lửa nhận diện nhầm đây là lưu lượng nội bộ hợp lệ và cho phép đi qua.
- Sự khác biệt giữa các hệ điều hành: Windows và nhiều bản phân phối Linux tự động áp dụng các tuyến RFC 3442 từ DHCP theo mặc định, khiến máy tính dễ tổn thương nếu không được cấu hình tường lửa chuyên biệt.
Kiến trúc phòng vệ: Triệt tiêu rò rỉ định tuyến
Để hóa giải TunnelVision, hệ thống bảo vệ cần thiết lập ranh giới cô lập ở cấp độ nhân hệ điều hành thay vì chỉ phụ thuộc vào các lệnh định tuyến cơ bản.
[Ứng dụng người dùng (Trình duyệt, Email, Ứng dụng)]
│
▼
[Không gian mạng riêng (Network Namespace)] <── (Cô lập tuyệt đối)
│
▼
[Giao diện tun0 / wg0]
│ (Dòng chảy WireGuard mã hóa)
▼
[Không gian vật lý: wlan0] ──> [Chỉ cho phép gói tin mã hóa đi ra]
1. Phân tách không gian mạng (Network Namespaces)
Trên hệ thống Linux, Network Namespaces cung cấp khả năng cô lập hoàn chỉnh. Bằng cách chạy các ứng dụng trong một không gian mạng riêng biệt chỉ chứa giao diện VPN ảo (wg0 hoặc tun0), ứng dụng hoàn toàn không nhìn thấy giao diện vật lý wlan0. Dù máy chủ DHCP giả mạo có gửi bao nhiêu tuyến tĩnh vào bảng định tuyến chính, các tiến trình bên trong không gian riêng không thể chuyển hướng ra ngoài.
2. Định tuyến theo chính sách (Policy-Based Routing) và đánh dấu gói tin
Các phiên bản triển khai WireGuard hiện đại sử dụng kỹ thuật đánh dấu gói tin tường lửa (fwmark) kết hợp bảng định tuyến độc lập:
# Điều hướng tất cả gói tin không có dấu vào bảng định tuyến 51820
ip rule add not fwmark 51820 table 51820
ip rule add table main suppress_prefixlength 0
Quy tắc suppress_prefixlength 0 đảm bảo rằng bảng định tuyến chính không thể dùng các tuyến cụ thể để đè lên quy tắc bảo mật của đường hầm VPN.
3. Vô hiệu hóa tiếp nhận Option 121 trên mạng không tin cậy
Người dùng có thể cấu hình trình quản lý mạng hoặc tệp cấu hình DHCP (/etc/dhcp/dhclient.conf) để loại bỏ hoàn toàn rfc3442-classless-static-routes khỏi danh sách yêu cầu, ngăn chặn việc tự ý tiếp nhận định tuyến từ trạm phát lạ.
4. Cơ chế bảo vệ tầng mạng của RiceGuard
Giao thức RiceGuard của VPNRice giải quyết triệt để vấn đề này ở tầng điều khiển lưu lượng lõi. Thông qua các quy tắc lọc gói tin nftables/eBPF ở cấp độ nhân, RiceGuard thiết lập rào chắn chủ động: mọi gói tin không mã hóa cố tình rời khỏi giao diện mạng vật lý hướng đến các địa chỉ ngoài mạng cục bộ đều bị tiêu hủy ngay lập tức, vô hiệu hóa hoàn toàn âm mưu dẫn dụ lưu lượng của kẻ xấu.
Khuyến nghị an toàn khi sử dụng Wi-Fi công cộng
- Kiểm tra bảng định tuyến thường xuyên: Chạy lệnh
ip route show(trên Linux) hoặcroute print(trên Windows) để phát hiện các bản ghi lạ dạng/1trỏ về gateway mạng công cộng. - Ưu tiên điểm phát sóng cá nhân: Hạn chế kết nối vào các mạng Wi-Fi mở không yêu cầu xác thực nơi kẻ xấu dễ dàng dựng máy chủ DHCP giả mạo.
- Xác thực địa chỉ IP thực tế: Sử dụng công cụ kiểm tra thông tin mạng độc lập để đảm bảo lưu lượng luôn thoát ra từ máy chủ VPN thay vì nhà mạng cục bộ.



