ADVPN: VPN động tự động tạo shortcut tunnel

1. Liên hệ thực tế

Công ty của khách hàng phát triển lên 10 chi nhánh, tất cả kết nối VPN về một Hub trung tâm theo mô hình hub-spoke đã học. Nhưng hai chi nhánh HCM và Hà Nội thường xuyên trao đổi dữ liệu trực tiếp với nhau — mỗi lần như vậy, traffic phải đi vòng qua Hub trước, làm tăng độ trễ và tốn gấp đôi băng thông Hub (một lần nhận từ HCM, một lần gửi tới Hà Nội).

Anh Nam hỏi: "Có cách nào để hai chi nhánh nói chuyện trực tiếp với nhau mà không cần vòng qua Hub, nhưng vẫn giữ được sự đơn giản của mô hình hub-spoke (mỗi spoke chỉ cần cấu hình 1 tunnel duy nhất tới Hub, không phải tự dựng tunnel riêng với từng spoke khác)?"

Chị Lan: "Đây chính là bài toán mà ADVPN (Auto-Discovery VPN) sinh ra để giải quyết — các Spoke vẫn chỉ cấu hình một tunnel về Hub như bình thường, nhưng khi có traffic giữa hai Spoke, hệ thống tự động phát hiện và dựng thêm một 'đường tắt' (shortcut tunnel) trực tiếp giữa chúng, không cần cấu hình thủ công."

Bài này giới thiệu ADVPN — cơ chế tự động tạo shortcut tunnel trong kiến trúc hub-spoke, giúp tối ưu độ trễ và băng thông mà vẫn giữ đơn giản trong quản lý cấu hình.

2. Kiến thức cốt lõi

2.1 Vấn đề của mô hình Hub-Spoke thuần túy

Trong mô hình hub-spoke thông thường (đã áp dụng từ bài Site-to-Site VPN), mọi traffic giữa hai Spoke bất kỳ đều phải đi qua Hub — kể cả khi hai Spoke đó có kết nối Internet trực tiếp tốt hơn nhiều so với việc vòng qua Hub. Với số lượng Spoke lớn và traffic liên-chi-nhánh thường xuyên, Hub trở thành điểm nghẽn cả về băng thông lẫn độ trễ.

2.2 ADVPN hoạt động như thế nào

Khi Spoke A cần gửi traffic tới Spoke B lần đầu, traffic vẫn đi qua Hub như bình thường (đúng mô hình hub-spoke gốc). Đồng thời, Hub gửi thông báo IKE đặc biệt cho cả hai Spoke, cung cấp thông tin cần thiết để chúng nhận ra nhau. Hai Spoke sau đó tự thương lượng một shortcut tunnel trực tiếp — các gói tin tiếp theo giữa A và B sẽ đi thẳng qua shortcut tunnel này, không cần vòng qua Hub nữa.

2.3 Cấu hình phía Hub

config vpn ipsec phase1-interface
    edit "advpn-hub"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set auto-discovery-sender enable
        set proposal aes256gcm-prfsha384
        set dhgrp 21
        set authmethod psk
        set psksecret "MatKhauManhCanKy2024!"
    next
end

config vpn ipsec phase2-interface
    edit "advpn-hub-p2"
        set phase1name "advpn-hub"
        set proposal aes256gcm
        set pfs enable
        set dhgrp 21
    next
end

auto-discovery-sender enable trên Hub cho phép nó chủ động gửi thông báo tới các Spoke để kích hoạt shortcut tunnel khi phát hiện traffic liên-Spoke.

2.4 Cấu hình phía Spoke

config vpn ipsec phase1-interface
    edit "advpn-spoke"
        set type static
        set interface "wan1"
        set ike-version 2
        set remote-gw 203.0.113.1
        set auto-discovery-receiver enable
        set proposal aes256gcm-prfsha384
        set dhgrp 21
        set authmethod psk
        set psksecret "MatKhauManhCanKy2024!"
    next
end

auto-discovery-receiver enable cho phép Spoke này tiếp nhận thông báo từ Hub và tự thương lượng shortcut tunnel với Spoke khác khi cần.

⚠️ Lưu ý: ADVPN bắt buộc dùng Route-based VPN (đã học ở bài so sánh Route-based vs Policy-based) — Policy-based không có khả năng tạo interface động cho shortcut tunnel. Ngoài ra, ADVPN yêu cầu routing động (thường là BGP) chạy qua các tunnel để tự động cập nhật route khi shortcut tunnel hình thành hoặc biến mất.

2.5 BGP — thành phần bắt buộc đi kèm ADVPN

Vì shortcut tunnel hình thành/biến mất linh hoạt theo nhu cầu traffic thực tế, cấu hình routing tĩnh không theo kịp — ADVPN cần BGP chạy qua các tunnel để tự động học và cập nhật route mỗi khi topology thay đổi.

Vì sao chọn BGP mà không phải OSPF? Nhắc lại từ bài OSPF cơ bản: OSPF thiết kế cho topology tương đối ổn định, hội tụ dựa trên việc mọi router trong cùng Area đồng bộ toàn bộ link-state database — không phù hợp khi có hàng chục Spoke, mỗi Spoke có thể hình thành/gỡ shortcut liên tục. BGP hoạt động theo mô hình path-vector, chỉ trao đổi route đã chọn (không cần đồng bộ toàn bộ topology), chịu tải tốt hơn nhiều với số lượng neighbor lớn và thay đổi topology thường xuyên — đây chính là lý do BGP gần như là lựa chọn duy nhất thực tế cho ADVPN quy mô lớn.

Cấu hình phía Hub:

config router bgp
    set as 65000
    set router-id 10.255.255.1
    config neighbor-group
        edit "advpn-spokes"
            set remote-as 65001
            set route-reflector-client enable
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.99.99.0 255.255.255.0
            set neighbor-group "advpn-spokes"
        next
    end
end

Cấu hình trên dùng neighbor-range kết hợp neighbor-group — cho phép Hub chấp nhận BGP peering từ bất kỳ Spoke nàonằm trong dải subnet 10.99.99.0/24 (chính là dải IP nội bộ của tunnel interface ADVPN) mà không cần khai từng Spoke một theo IP cụ thể, quan trọng khi số lượng Spoke lớn hoặc liên tục thêm mới.

Cấu hình phía Spoke — mỗi Spoke chỉ cần một neighbor duy nhất trỏ về Hub:

config router bgp
    set as 65001
    set router-id 10.99.99.2
    config neighbor
        edit "10.99.99.1"
            set remote-as 65000
            set route-reflector-client disable
        next
    end
    config network
        edit 1
            set prefix 192.168.10.0 255.255.255.0
        next
    end
end

Mỗi Spoke quảng bá đúng dải LAN nội bộ của mình (network statement) lên Hub — Hub học được toàn bộ route từ tất cả Spoke, rồi phản xạ (reflect) lại cho các Spoke khác.

route-reflector-client enable — vì sao cần thiết: Theo nguyên tắc BGP tiêu chuẩn, route học được từ một iBGP peer (cùng AS) thì không được quảng bá tiếp cho iBGP peer khác — nếu không có Route Reflector, Hub sẽ nhận route từ Spoke A nhưng không thể chuyển tiếp cho Spoke B, khiến các Spoke hoàn toàn không thấy nhau. Bật Route Reflector trên Hub phá vỡ đúng giới hạn này một cách có kiểm soát, cho phép Hub đóng vai trò trung chuyển route giữa các Spoke mà không cần full-mesh iBGP giữa từng cặp Spoke (vốn không khả thi khi có hàng chục Spoke).

Cơ chế next-hop khi shortcut hình thành: Đây là phần tinh tế nhất của ADVPN. Khi Spoke A và Spoke B chưa có shortcut, route Hub phản xạ cho biết "muốn tới LAN của B, đi qua Hub" (next-hop là Hub). Khi ADVPN phát hiện traffic A↔B và dựng xong shortcut tunnel, next-hop của route được cập nhật lại thành chính Spoke B — BGP trên Spoke A tự động nhận ra thay đổi này qua route update, chuyển traffic từ "qua Hub" sang "đi thẳng qua shortcut" mà không cần can thiệp thủ công.

⚠️ Lưu ý: Trong thời gian ngắn giữa lúc traffic A→B bắt đầu và lúc shortcut tunnel + BGP route update hoàn tất, traffic vẫn tiếp tục đi qua Hub — đây là hành vi bình thường, không phải lỗi. Nếu traffic liên-Spoke chỉ diễn ra trong thời gian rất ngắn (dưới vài giây) trước khi kết thúc, shortcut có thể chưa kịp hình thành và mang lại lợi ích thực tế; ADVPN phát huy giá trị rõ rệt nhất với các phiên traffic liên-Spoke kéo dài hoặc lặp lại thường xuyên.

2.6 Khi nào nên triển khai ADVPN

ADVPN phù hợp khi:

• Số lượng Spoke lớn (hàng chục trở lên), với traffic liên-Spoke thường xuyên và đáng kể.
• Muốn giữ đơn giản trong quản lý cấu hình (mỗi Spoke chỉ cần 1 tunnel tới Hub) nhưng vẫn tối ưu được hiệu năng traffic liên-Spoke.
• Đã có kinh nghiệm với routing động (BGP), vì ADVPN không thể vận hành hiệu quả chỉ với static route.

ADVPN không cần thiết khi:

• Số lượng chi nhánh ít (2-3 site), traffic liên-chi-nhánh không đáng kể — mô hình hub-spoke thông thường hoặc full-mesh thủ công đã đủ dùng.
• Đội ngũ vận hành chưa quen với BGP, vì độ phức tạp tăng thêm có thể không tương xứng với lợi ích trong quy mô nhỏ.

3. Hỏi & Đáp

Shortcut tunnel trong ADVPN có tồn tại vĩnh viễn sau khi được tạo không?

Không — shortcut tunnel thường có thời gian tồn tại giới hạn và tự động gỡ bỏ khi không còn traffic sử dụng trong một khoảng thời gian (tương tự cơ chế session timeout), giúp tránh việc duy trì quá nhiều tunnel không cần thiết chiếm tài nguyên hệ thống.

Nếu shortcut tunnel giữa 2 Spoke bị lỗi, traffic có bị gián đoạn không?

Về nguyên tắc thiết kế, nếu shortcut tunnel gặp sự cố, traffic có thể fallback về đường qua Hub (route gốc ban đầu) nhờ cơ chế BGP cập nhật lại route khi phát hiện shortcut không còn khả dụng — mức độ gián đoạn thực tế phụ thuộc vào tốc độ hội tụ (convergence) của BGP đã cấu hình.

ADVPN có yêu cầu tất cả Spoke phải có IP tĩnh không?

Không nhất thiết — kết hợp được với Dialup VPN đã học ở bài trước, Spoke có thể có IP động miễn Hub luôn ở địa chỉ tĩnh để làm điểm tham chiếu trung tâm cho toàn bộ Spoke.

Có thể có nhiều Hub trong một kiến trúc ADVPN không?

Có — các triển khai lớn thường dùng nhiều Hub để dự phòng (redundancy) hoặc phân vùng địa lý, kết hợp BGP để đảm bảo route hội tụ đúng dù có nhiều điểm trung tâm — đây là kiến trúc nâng cao hơn phạm vi giới thiệu cơ bản của bài này.

4. Quiz

Câu 1: ADVPN giải quyết vấn đề gì trong mô hình Hub-Spoke thông thường?

• A. Giảm chi phí license VPN
• B. Traffic giữa hai Spoke phải vòng qua Hub, gây tốn băng thông và tăng độ trễ
• C. Không hỗ trợ mã hóa mạnh
• D. Không thể kết nối quá 2 chi nhánh

Câu 2: Shortcut tunnel trong ADVPN được hình thành như thế nào?

• A. Admin phải tự cấu hình thủ công cho từng cặp Spoke
• B. Hub gửi thông báo IKE cho các Spoke liên quan, hai Spoke tự thương lượng tunnel trực tiếp
• C. Chỉ hình thành khi khởi động lại thiết bị
• D. Không bao giờ tự động hình thành

Câu 3: ADVPN bắt buộc dùng kiểu VPN nào?

• A. Policy-based
• B. Route-based
• C. Cả hai như nhau
• D. Không liên quan tới kiểu VPN

Câu 4: Vì sao ADVPN cần routing động (BGP) thay vì static route?

• A. Vì BGP nhanh hơn về tốc độ mã hóa
• B. Vì shortcut tunnel hình thành/biến mất linh hoạt theo traffic thực tế, static route không theo kịp
• C. Vì static route không hỗ trợ IPsec
• D. Không có lý do kỹ thuật cụ thể

Câu 5: Vai trò của Hub trong kiến trúc BGP kết hợp ADVPN thường là gì?

• A. Chỉ đóng vai trò lưu trữ log
• B. Route Reflector — giúp các Spoke học route của nhau mà không cần BGP peering trực tiếp giữa từng cặp
• C. Không có vai trò gì trong BGP
• D. Chỉ dùng để cấp phát địa chỉ IP

👉 Đáp án

Câu 1: B Trong mô hình Hub-Spoke thông thường, traffic giữa hai Spoke bất kỳ phải vòng qua Hub, gây tốn băng thông Hub và tăng độ trễ — đây chính là vấn đề ADVPN giải quyết bằng shortcut tunnel.

Câu 2: B Khi có traffic giữa hai Spoke, Hub gửi thông báo IKE đặc biệt cho cả hai bên, giúp chúng tự thương lượng và thiết lập shortcut tunnel trực tiếp mà không cần admin cấu hình thủ công.

Câu 3: B ADVPN bắt buộc dùng Route-based VPN vì cần khả năng tạo interface động cho shortcut tunnel — điều Policy-based không hỗ trợ được.

Câu 4: B Vì shortcut tunnel hình thành và biến mất linh hoạt theo nhu cầu traffic thực tế, cấu hình static route cố định không thể theo kịp những thay đổi topology liên tục này; BGP tự động cập nhật route phù hợp.

Câu 5: B Hub thường đóng vai trò Route Reflector trong BGP, giúp các Spoke học được route của nhau thông qua Hub mà không cần thiết lập BGP peering trực tiếp giữa từng cặp Spoke.

📚 Bài viết thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng