Debug Flow & Flow Trace FortiGate — Công cụ Troubleshooting Quan trọng nhất

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

Một khách hàng mới triển khai Firewall Policy cho VPN Site-to-Site báo rằng traffic từ chi nhánh không ra được Internet dù cấu hình "nhìn có vẻ đúng": policy đã tạo, NAT đã bật, route đã có. Anh Nam kiểm tra từng phần cấu hình cả buổi sáng mà không tìm ra vấn đề.

Chị Lan gợi ý: "Đừng đọc cấu hình tĩnh nữa — hãy để FortiGate tự kể cho em nghe nó xử lý gói tin đó như thế nào." Chị hướng dẫn anh chạy Debug Flow:

FGT # diagnose debug flow filter addr 192.168.3.221
FGT # diagnose debug flow show function-name enable
FGT # diagnose debug enable
FGT # diagnose debug flow trace start 20

Ngay khi máy client tạo traffic, output hiện ra chi tiết từng bước: gói tin được nhận vào, tìm route, tìm policy... và dừng lại đột ngột ở bước "Denied by forward policy check" — hóa ra có một Local-In Policy tạo trước đó vô tình chặn traffic transit đi qua interface VPN, một chi tiết không thể thấy được nếu chỉ đọc cấu hình Firewall Policy thông thường.

"Đây chính là lý do Debug Flow là công cụ quan trọng nhất trong bộ troubleshooting của FortiGate," chị Lan kết luận. "Nó không đoán, nó cho em thấy chính xác quyết định thực tế của engine xử lý gói tin."

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

2.1 Debug Flow là gì và khác gì Packet Capture

Như đã phân biệt ở bài Packet Capture, Packet Capture cho biết gói tin có đến/đi hay không và nội dung ra sao, còn Debug Flow cho biết chính xác FortiGate đã ra quyết định gì với gói tin đó ở từng bước xử lý nội bộ: route lookup, policy match, NAT, UTM inspection, session creation... Đây là công cụ duy nhất trả lời trực tiếp câu hỏi "vì sao gói tin này bị chặn/cho phép".

2.2 Quy trình 5 bước chuẩn

Bước 1 — Đặt filter để giới hạn phạm vi debug, tránh output tràn ngập từ toàn bộ traffic đang chạy qua thiết bị:

diagnose debug flow filter addr 203.160.224.97

Có thể lọc theo nhiều tiêu chí khác: filter saddr (IP nguồn), filter daddr (IP đích), filter port (cổng), filter proto (giao thức). Dùng IPv6 thì thay filter bằng filter6.

Bước 2 — (Tùy chọn) Bật hiển thị tên hàm để có thêm ngữ cảnh kỹ thuật sâu hơn khi cần gửi cho Fortinet TAC:

diagnose debug flow show function-name enable

Bước 3 — Bật debug console và bắt đầu trace:

diagnose debug enable
diagnose debug flow trace start 100

Số 100 là số lượng gói tối đa sẽ được trace trước khi tự dừng — nên đặt giới hạn hợp lý thay vì để chạy vô hạn trên thiết bị production.

Bước 4 — Tạo traffic khớp filter từ máy client hoặc hệ thống liên quan, quan sát output hiện trực tiếp trên CLI.

Bước 5 — Dừng debug ngay khi đã thu thập đủ dữ liệu:

diagnose debug flow trace stop
diagnose debug disable

⚠️ Lưu ý: Quên thực hiện Bước 5 là lỗi phổ biến nhất của người mới — để debug console chạy liên tục trên thiết bị production tiêu tốn tài nguyên CPU không cần thiết, đặc biệt nếu filter đặt quá rộng (ví dụ không filter gì, bắt toàn bộ traffic).

2.3 Đọc hiểu output Debug Flow

Một đoạn trace điển hình trông như sau:

id=20085 trace_id=209 func=resolve_ip_tuple_fast line=2700
msg="vd-root received a packet(proto=6, 192.168.3.221:1487->203.160.224.97:80) from port5."
id=20085 trace_id=209 func=resolve_ip_tuple line=2799
msg="allocate a new session-00000e90"
id=20085 trace_id=209 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.11.254 via port6"
id=20085 trace_id=209 func=get_new_addr line=1219
msg="find SNAT: IP-192.168.11.59, port-31925"
id=20085 trace_id=209 func=fw_forward_handler line=317
msg="Allowed by Policy-12"

Đọc theo trình tự logic: nhận gói vào (interface nào, IP/cổng nguồn-đích) → tạo session mới hoặc tìm session hiện có → route lookup (tìm gateway/interface ra) → NAT (nếu có) → kết quả match Policy (allow/deny, số ID policy). Nếu trace dừng đột ngột giữa chừng mà không tới bước "Allowed", nghĩa là gói tin bị chặn ở đúng bước cuối cùng xuất hiện trong log — đây chính là manh mối quan trọng nhất để định vị vấn đề.

2.4 Các lý do dừng trace thường gặp và ý nghĩa

2.5 Kết hợp Debug Flow với Policy Lookup

Với các trường hợp chỉ cần biết "gói tin này sẽ match Policy nào" mà không cần trace toàn bộ luồng xử lý, GUI có công cụ nhẹ hơn: Policy & Objects > Firewall Policy > Policy Lookup — nhập 5-tuple (IP nguồn, IP đích, cổng, giao thức, interface) và FortiGate trả về ngay policy sẽ match mà không cần tạo traffic thật. Nên dùng Policy Lookup trước cho các câu hỏi đơn giản, và chỉ cần Debug Flow đầy đủ khi vấn đề phức tạp hơn (liên quan NAT, routing, hoặc UTM profile).

🔄 Khác biệt version FortiOS: Từ FortiOS 7.2, GUI bổ sung công cụ Debug Flow trực quan (System > Feature Visibility hoặc trong FortiView) cho phép chạy debug flow và xem kết quả có định dạng ngay trên web, không cần CLI thuần. Cú pháp CLI cơ bản không thay đổi so với 7.0.

3. Hỏi & Đáp

Debug Flow có ảnh hưởng tới traffic thật đang chạy qua FortiGate không?

Bản thân việc bật debug không chặn hay thay đổi traffic — nó chỉ quan sát và ghi log các bước xử lý. Tuy nhiên nếu filter đặt quá rộng và để chạy lâu trên thiết bị có tải cao, việc sinh log liên tục có thể ảnh hưởng nhẹ tới hiệu năng CPU, nên luôn giới hạn phạm vi và thời gian chạy.

Vì sao trace không hiện gì cả dù tôi đã tạo traffic đúng như filter?

Nguyên nhân phổ biến nhất là quên chạy diagnose debug enable trước khi trace start, hoặc filter đặt sai chiều (ví dụ dùng daddrthay vì saddr). Cũng cần kiểm tra traffic có thực sự đi qua đúng FortiGate đang debug hay không, đặc biệt trong môi trường có nhiều thiết bị định tuyến song song.

Có thể dùng Debug Flow để chẩn đoán vấn đề VPN IPsec không?

Debug Flow phù hợp cho traffic đã đi vào tunnel (matching Firewall Policy trên interface VPN), nhưng để chẩn đoán bản thân quá trình thiết lập tunnel (Phase 1/Phase 2), công cụ chuyên dụng hơn là diagnose vpn ike log và diagnose vpn tunnel list đã học ở bài Troubleshooting VPN Nhóm 4.

4. Quiz

Câu 1: Debug Flow khác Packet Capture ở điểm cốt lõi nào?

• A. Debug Flow cho biết gói tin có đến FortiGate hay không
• B. Debug Flow cho biết FortiGate xử lý gói tin qua những bước nào và ra quyết định gì bên trong
• C. Debug Flow chỉ dùng được cho traffic IPv6
• D. Debug Flow thay thế hoàn toàn cho Firewall Policy

Câu 2: Lệnh nào bắt buộc phải chạy trước khi diagnose debug flow trace start để debug thực sự hoạt động?

• A. diagnose debug enable
• B. diagnose sniffer packet
• C. get system performance status
• D. diagnose sys session list

Câu 3: Nếu trace dừng lại ở thông báo "Denied by forward policy check", nên kiểm tra điều gì đầu tiên?

• A. Cấu hình DNS server
• B. Firewall Policy có match đúng address/service object hay không
• C. Dung lượng ổ đĩa còn trống
• D. Phiên bản firmware hiện tại

Câu 4: Công cụ nào phù hợp hơn khi chỉ cần biết nhanh một traffic sẽ match Policy nào mà không cần trace toàn bộ luồng xử lý?

• A. Debug Flow đầy đủ
• B. Policy Lookup
• C. diagnose sniffer packet
• D. FortiView Applications

👉 Đáp án

Câu 1: B Đây chính là điểm khác biệt cốt lõi — Debug Flow tiết lộ logic xử lý nội bộ, không chỉ là "có gói tin hay không".

Câu 2: A Nếu không bật debug console trước, lệnh trace start sẽ không sinh ra output nào dù filter đúng.

Câu 3: B Thông báo này nghĩa là không có policy nào match — cần rà lại address/service object và thứ tự policy.

Câu 4: B Policy Lookup cho kết quả tức thì mà không cần tạo traffic thật hay chạy trace đầy đủ, phù hợp cho câu hỏi đơn giản.

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

🧭 Điều hướng