Troubleshooting VPN: các lệnh chẩn đoán quan trọng

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

Sau khi triển khai một loạt tunnel VPN suốt các bài học vừa qua, chi nhánh mới báo cáo: "Tunnel hiện trạng thái Up trên GUI, nhưng không ping được máy chủ bên trụ sở chính." Anh Nam nhìn màn hình VPN Monitor thấy đúng là trạng thái xanh, nhưng vẫn không có traffic nào đi qua được.

Chị Lan gợi ý: "Trạng thái Up trên GUI chỉ cho biết Phase 1 và Phase 2 đã thương lượng xong — không đồng nghĩa traffic thực sự đi qua đúng cách. Cần debug theo từng lớp: từ IKE, tới SA, tới routing, rồi mới tới Firewall Policy — đừng nhảy thẳng vào nghi ngờ Policy khi còn chưa xác nhận các lớp thấp hơn đã ổn."

Bài này tổng hợp các lệnh chẩn đoán VPN quan trọng nhất trên FortiGate — quy trình debug có hệ thống từ Phase 1 tới Firewall Policy.

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

2.1 Quy trình debug theo từng lớp

Nguyên tắc quan trọng: luôn debug từ lớp thấp lên cao — xác nhận Phase 1 ổn trước khi nghi ngờ Phase 2, xác nhận Phase 2 ổn trước khi nghi ngờ routing, và chỉ xem xét Firewall Policy sau khi đã chắc chắn traffic thực sự đi vào đúng tunnel interface.

2.2 Kiểm tra Phase 1 — IKE Gateway

get vpn ike gateway
diagnose vpn ike gateway list

Output cho biết trạng thái Phase 1 hiện tại, thuật toán đã thương lượng, và thời gian còn lại trước khi SA hết hạn. Nếu không thấy gateway nào xuất hiện, Phase 1 chưa bao giờ được khởi tạo — kiểm tra lại remote-gw, psksecret, hoặc kết nối mạng cơ bản (ping) tới IP đối tác.

2.3 Xem log chi tiết quá trình thương lượng IKE

Khi Phase 1 không lên được, cần xem chi tiết log để biết chính xác nguyên nhân:

diagnose vpn ike log filter clear
diagnose vpn ike log filter name "vpn-chi-nhanh-a"
diagnose debug application ike -1
diagnose debug enable

Sau khi bật debug, thử kích hoạt lại tunnel và quan sát output — các thông báo lỗi phổ biến:

⚠️ Lưu ý: Luôn tắt debug sau khi hoàn tất kiểm tra (diagnose debug disable, diagnose debug reset) — để debug chạy liên tục trên hệ thống production tốn tài nguyên và có thể ảnh hưởng hiệu năng, đặc biệt khi có nhiều tunnel hoạt động đồng thời.

2.4 Kiểm tra Phase 2 — IPsec Tunnel Status

get vpn ipsec tunnel summary
diagnose vpn tunnel list

Output hiển thị trạng thái từng Phase 2 SA, bao gồm số byte đã truyền qua mỗi chiều (in/out) — nếu số liệu này bằng 0 dù tunnel hiện "up", đây là dấu hiệu tunnel đã thương lượng xong nhưng chưa từng có traffic thực sự đi qua, đúng như tình huống mở đầu bài.

diagnose vpn tunnel list name "vpn-chi-nhanh-a-p2"

Xem chi tiết một tunnel cụ thể, bao gồm cả selectors (dải subnet đã thương lượng) — đối chiếu với src-subnet/dst-subnet đã cấu hình để xác nhận không có sai lệch.

2.5 Kiểm tra Routing

get router info routing-table all | grep "vpn-chi-nhanh-a"

Xác nhận route tới subnet đối diện thực sự tồn tại và trỏ đúng qua tunnel interface — nếu route bị thiếu (quên khai static route) hoặc bị route khác ưu tiên hơn "che" mất (theo nguyên tắc Distance/Priority đã học ở bài Routing tĩnh), traffic sẽ không bao giờ tới được tunnel dù Phase 1/Phase 2 hoàn toàn khỏe mạnh.

2.6 Kiểm tra Firewall Policy và session

diagnose sys session list | grep "203.0.113.10"
diagnose firewall iprope lookup 10.1.1.1 10.2.1.1 0 0 0

Nếu đã xác nhận Phase 1, Phase 2, và routing đều ổn nhưng traffic vẫn không qua, bước cuối là kiểm tra Firewall Policy — đảm bảo có đủ Policy hai chiều (srcintf/dstintf đúng tunnel interface) như đã học ở bài Site-to-Site VPN, và không bị Policy khác phía trên "chặn nhầm" theo nguyên tắc Policy Lookup.

2.7 Packet Sniffer — xác nhận traffic thực sự đi đâu

diagnose sniffer packet any "host 10.2.1.1" 4

Chạy sniffer trên cả hai đầu tunnel đồng thời (nếu có quyền truy cập cả hai FortiGate) giúp xác định chính xác gói tin dừng lại ở đâu — traffic có rời khỏi LAN không, có tới được tunnel interface không, có ra khỏi tunnel ở đầu bên kia không.

⚠️ Lưu ý (nhắc lại từ bài IPsec Hardware Offload): Nếu traffic đã được offload xuống NP, sniffer sẽ không thấy nội dung chi tiết — đây là dấu hiệu tốt (traffic đang được xử lý ở tầng phần cứng), không phải traffic bị mất. Kết hợp thêm diagnose sys session list để xác nhận session có tồn tại hay không.

3. Hỏi & Đáp

Tunnel hiện "Up" trên GUI nhưng traffic vẫn không đi qua, nên nghi ngờ điều gì đầu tiên?

Nên kiểm tra ngay số byte in/out qua diagnose vpn tunnel list — nếu bằng 0 dù tunnel up, khả năng cao vấn đề nằm ở routing hoặc Firewall Policy chứ không phải bản thân tunnel IPsec, vì Phase 1/Phase 2 chỉ xác nhận khả năng mã hóa, không đảm bảo traffic thực sự được định tuyến đúng vào tunnel.

no SA proposal chosen luôn có nghĩa là lỗi cấu hình thuật toán mã hóa?

Đây là nguyên nhân phổ biến nhất, nhưng không phải duy nhất — lỗi này cũng có thể xuất hiện khi DH Group không khớp, hoặc khi Phase 2 selectors (src-subnet/dst-subnet) không tương thích giữa hai đầu dù Phase 1 đã thành công. Cần đối chiếu toàn bộ tham số proposal ở cả hai lớp, không chỉ riêng thuật toán mã hóa.

Có cách nào theo dõi VPN liên tục mà không cần debug thủ công mỗi lần có sự cố không?

Có — kết hợp SNMP trap hoặc gửi log VPN tới FortiAnalyzer/Syslog Server (đã học ở bài Logging & Reporting) để có cảnh báo chủ động khi tunnel down, thay vì đợi người dùng báo cáo mới bắt đầu debug thủ công. Một số tổ chức còn thiết lập health-check định kỳ tự động ping qua tunnel để phát hiện sớm.

Debug application ike -1 có ảnh hưởng gì tới các tunnel khác đang hoạt động không?

Việc bật debug IKE toàn cục có thể ảnh hưởng nhẹ tới hiệu năng nếu có nhiều tunnel đồng thời đang thương lượng, vì log sinh ra cho toàn bộ hoạt động IKE chứ không lọc riêng theo tunnel cụ thể trừ khi đã dùng diagnose vpn ike log filter nameđể giới hạn phạm vi trước khi bật debug.

4. Quiz

Câu 1: Trạng thái "Up" của tunnel trên GUI VPN Monitor xác nhận điều gì?

• A. Traffic chắc chắn đang đi qua tunnel bình thường
• B. Phase 1 và Phase 2 đã thương lượng thành công, nhưng không đảm bảo traffic thực sự đã đi qua
• C. Firewall Policy đã cấu hình đúng
• D. Routing đã chắc chắn chính xác

Câu 2: Số byte in/out bằng 0 trong diagnose vpn tunnel list dù tunnel đang "up" là dấu hiệu của điều gì?

• A. Tunnel đã lên hoàn chỉnh và hoạt động bình thường
• B. Tunnel đã thương lượng xong nhưng chưa từng có traffic thực sự đi qua
• C. Lỗi phần cứng nghiêm trọng
• D. Không có ý nghĩa gì, số liệu ngẫu nhiên

Câu 3: Nguyên tắc debug VPN theo từng lớp nên tuân theo thứ tự nào?

• A. Firewall Policy trước, Phase 1 sau
• B. Phase 1 → Phase 2 → Routing → Firewall Policy
• C. Routing trước, sau đó mới tới Phase 1
• D. Không có thứ tự cụ thể, kiểm tra ngẫu nhiên

Câu 4: Thông báo lỗi no SA proposal chosen trong log IKE thường liên quan tới vấn đề gì?

• A. Sai địa chỉ IP nguồn
• B. Proposal (encryption/hash/DH group hoặc Phase 2 selectors) không khớp giữa hai đầu
• C. Hết dung lượng ổ đĩa
• D. Lỗi phần cứng NP

Câu 5: Vì sao nên tắt debug ngay sau khi hoàn tất kiểm tra VPN?

• A. Vì debug tự động tắt sau 1 phút
• B. Vì để debug chạy liên tục tốn tài nguyên và có thể ảnh hưởng hiệu năng hệ thống production
• C. Vì debug có thể làm hỏng cấu hình VPN
• D. Không cần tắt, để debug chạy mãi mãi không ảnh hưởng gì

👉 Đáp án

Câu 1: B Trạng thái "Up" chỉ xác nhận Phase 1 và Phase 2 đã thương lượng thành công (khả năng mã hóa đã sẵn sàng), không đảm bảo traffic thực sự đã được định tuyến đúng và đi qua tunnel.

Câu 2: B Byte in/out bằng 0 dù tunnel "up" cho thấy tunnel đã thương lượng xong về mặt kỹ thuật nhưng chưa từng có traffic thực sự đi qua — thường do vấn đề routing hoặc Firewall Policy.

Câu 3: B Nên debug theo thứ tự từ lớp thấp lên cao: Phase 1 → Phase 2 → Routing → Firewall Policy, tránh nghi ngờ nhầm lớp cao khi lớp thấp hơn còn chưa được xác nhận ổn định.

Câu 4: B no SA proposal chosen thường do các tham số proposal (encryption, hash, DH group ở Phase 1, hoặc selectors src/dst-subnet ở Phase 2) không khớp giữa hai đầu tunnel.

Câu 5: B Để debug chạy liên tục trên hệ thống production tốn tài nguyên xử lý và có thể ảnh hưởng hiệu năng, đặc biệt khi có nhiều tunnel hoạt động đồng thời — nên tắt ngay sau khi hoàn tất kiểm tra.

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

🧭 Điều hướng