Quy trình chẩn đoán sự cố chuẩn trên FortiGate — Tổng hợp Policy Lookup & Debug Flow

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

Suốt khóa học, anh Nam đã học rải rác nhiều công cụ troubleshooting: Policy Lookup, diagnose debug flow, diagnose sniffer packet, diagnose sys session list... Nhưng khi khách hàng gọi báo "không kết nối được tới server ERP" lúc 9 giờ tối, anh Nam bối rối không biết nên bắt đầu từ công cụ nào trước.

"Đây là lỗi rất phổ biến của người mới," chị Lan nói. "Có công cụ trong tay không có nghĩa là biết troubleshooting. Cái thiếu là quy trình — thứ tự kiểm tra hợp lý, để không nhảy lung tung giữa các bước, mất thời gian mà không ra kết quả."

Bài này tổng hợp lại toàn bộ công cụ chẩn đoán đã học ở Nhóm 7 thành một quy trình chuẩn, có thứ tự rõ ràng, áp dụng được cho phần lớn sự cố "traffic không đi qua được" trên FortiGate.

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

2.1 Nguyên tắc chung: đi theo đúng thứ tự lớp xử lý gói tin

Theo tài liệu chính thức Fortinet (Parallel Path Processing — Life of a Packet), traffic đi qua FortiGate trải qua chuỗi xử lý sau: Interface (ingress) → DoS/IP Integrity check → DNAT → Routing → Policy Lookup (stateful inspection) → UTM/NGFW Inspection → SNAT → Session table → Egress interface.

⚠️ Lưu ý dễ nhầm lẫn: NAT không phải một khối xử lý duy nhất mà tách làm 2 giai đoạn cách xa nhau trong pipeline: DNAT xảy ra trước Routing (vì FortiGate cần biết địa chỉ đích thật sau khi NAT để định tuyến đúng), còn SNAT xảy ra sau Policy Lookup và UTM Inspection, ngay trước khi session được tạo. Đây là lý do khi troubleshoot NAT, cần phân biệt rõ đang nghi ngờ DNAT (VIP/Virtual Server sai) hay SNAT (IP Pool/Central SNAT sai) — vì hai lỗi này nằm ở hai vị trí khác nhau hoàn toàn trong luồng xử lý.

Nguyên tắc quan trọng khi chẩn đoán: xác nhận từng lớp trước khi chuyển sang lớp tiếp theo, tránh việc vừa sửa NAT vừa nghi ngờ policy cùng lúc, dễ gây rối loạn không biết thay đổi nào thực sự giải quyết vấn đề. Quy trình 6 bước cụ thể trình bày từ mục 2.2 trở đi được sắp xếp theo mức độ dễ quan sát (từ ngoài vào trong) chứ không nhất thiết bám sát tuyệt đối thứ tự pipeline nội bộ nêu trên — ví dụ kiểm tra session cũ (bước 4) đặt trước NAT/Routing (bước 5) vì đây là nguyên nhân phổ biến và nhanh loại trừ hơn.

2.2 Bước 1 — Xác nhận gói tin có đến được FortiGate không

Trước khi nghi ngờ policy hay routing, cần chắc chắn gói tin thực sự tới được đúng interface mong đợi:

diagnose sniffer packet any 'host 10.10.10.50 and port 443' 4 20

Nếu không thấy gói tin nào xuất hiện, vấn đề nằm ở tầng vật lý/routing phía trước FortiGate (switch, cáp, định tuyến ở thiết bị khác) — chưa cần đụng tới cấu hình FortiGate. Kỹ thuật này đã trình bày chi tiết ở Packet Capture trên FortiGate.

2.3 Bước 2 — Policy Lookup (GUI) — kiểm tra nhanh không cần tạo traffic thật

Trước khi vào CLI, công cụ Policy Lookup trên GUI (Policy & Objects > Firewall Policy > Policy Lookup) cho phép nhập bộ 5-tuple (source IP, destination IP, port, protocol, incoming interface) để xem ngay policy nào sẽ khớp — mà không cần thiết bị thật gửi traffic. Đây là bước kiểm tra nhanh, phù hợp khi cần xác nhận thiết kế policy trước khi debug sâu hơn bằng CLI.

⚠️ Lưu ý: Policy Lookup chỉ mô phỏng logic match theo cấu hình tĩnh — nó không phản ánh được các yếu tố runtime như session đã tồn tại từ trước, hay trạng thái NAT pool đã cạn. Nếu Policy Lookup báo "sẽ match policy X" nhưng traffic thật vẫn không qua được, cần chuyển sang bước debug flow để xem chuyện gì thực sự xảy ra.

2.4 Bước 3 — diagnose debug flow — công cụ trung tâm của toàn bộ quy trình

Đây là công cụ đã học ở Debug Flow & Flow Trace, và là trung tâm của quy trình chẩn đoán chuẩn:

diagnose debug flow filter saddr 10.10.10.50
diagnose debug flow filter daddr 172.16.5.10
diagnose debug flow filter port 443
diagnose debug flow show iprope enable
diagnose debug flow trace start 20
diagnose debug enable

Tham số show iprope enable đặc biệt hữu ích khi nghi ngờ vấn đề nằm ở khâu chọn policy — nó in ra chi tiết các policy được "iprope" (cơ chế lookup policy ở tầng kernel) xem xét, cùng kết quả match/không match của từng policy, giúp xác định chính xác vì sao traffic bị policy A chặn thay vì khớp policy B như kỳ vọng.

Đọc output debug flow theo checklist:

1. Có dòng allocate a new session không? → xác nhận FortiGate đã nhận và bắt đầu xử lý gói tin.
2. Có dòng thể hiện policy ID được match không, hay dừng ở no matching policy found?
3. Nếu có NAT, có dòng thể hiện SNAT/DNAT đúng như kỳ vọng không?
4. Có dòng traffic bị drop bởi UTM profile (IPS, AV...) không?
5. Có dòng route lookup thất bại (no route found) không?

2.5 Bước 4 — Đối chiếu với diagnose sys session list nếu nghi ngờ session cũ

Đôi khi vấn đề không phải do policy sai, mà do một session cũ vẫn còn tồn tại trong bảng session với thông tin route/NAT đã lỗi thời (ví dụ sau khi đổi cấu hình SD-WAN hoặc routing). Khi đó cần đối chiếu với kỹ thuật đã học ở Session table & Session TTL:

diagnose sys session list | grep 10.10.10.50

Nếu thấy session cũ với thông tin không còn đúng, có thể cần xóa thủ công (diagnose sys session clear, dùng thận trọng vì lệnh này ảnh hưởng toàn bộ session nếu không lọc đúng) để buộc FortiGate tạo session mới theo cấu hình hiện tại.

2.6 Bước 5 — Kiểm tra NAT/Routing nếu traffic tới sai đích

Nếu debug flow cho thấy traffic được policy chấp nhận nhưng vẫn không tới đúng đích, quay lại các kỹ thuật đã học ở Troubleshooting NAT/Routing thường gặp — kiểm tra VIP mapping, kiểm tra static route/policy route có xung đột hay bị ưu tiên sai thứ tự (distance/priority).

2.7 Bước 6 — Kiểm tra tài nguyên hệ thống nếu traffic bị drop ngẫu nhiên

Nếu hiện tượng không cố định — lúc được lúc không, không rõ quy luật theo policy — nên loại trừ khả năng thiết bị đang chịu áp lực tài nguyên bằng kỹ thuật đã học ở Performance tuning cơ bản (CPU/Memory, Conserve Mode):

get system performance status
diagnose hardware sysinfo memory

Nếu thiết bị đang trong conserve mode, hành vi drop traffic có thể là do cơ chế tự bảo vệ của FortiOS, không liên quan gì tới policy hay routing.

2.8 Sơ đồ quy trình chẩn đoán tổng hợp

🔄 Khác biệt version FortiOS: Từ FortiOS 7.4.1, GUI bổ sung công cụ Policy Match Tool nâng cấp từ Policy Lookup cũ, hiển thị trực quan hơn thứ tự các policy được xét qua — hữu ích khi cần giải thích logic match cho người không quen CLI, nhưng bản chất vẫn chỉ mô phỏng tĩnh như Policy Lookup ở bản 7.0.

3. Hỏi & Đáp

Có bắt buộc phải làm đúng thứ tự 6 bước này không, hay có thể nhảy cóc?

Không bắt buộc cứng nhắc — với kỹ thuật viên có kinh nghiệm, đôi khi có thể đoán ngay vấn đề nằm ở đâu dựa trên triệu chứng và nhảy thẳng tới bước liên quan. Nhưng với người mới hoặc trường hợp phức tạp không rõ nguyên nhân, đi tuần tự giúp tránh bỏ sót và tránh sửa nhầm chỗ không phải nguyên nhân gốc.

Vì sao Policy Lookup báo match đúng policy nhưng traffic thật vẫn không qua được?

Thường do yếu tố runtime mà Policy Lookup không mô phỏng được — ví dụ NAT pool đã cạn IP, UTM profile chặn traffic sau khi đã qua policy match, hoặc session cũ với thông tin lỗi thời vẫn còn tồn tại. Đây chính là lý do bước 3 (debug flow) luôn cần thiết dù đã chạy Policy Lookup ở bước 2.

Lệnh diagnose debug flow có ảnh hưởng tới traffic đang chạy không?

Bản thân lệnh debug flow chỉ quan sát và in log, không làm thay đổi hành vi xử lý traffic. Tuy nhiên nên luôn giới hạn phạm vi bằng filter (saddr, daddr, port...) và dùng trace start <n> với số lượng gói giới hạn, tránh để chế độ debug chạy không giới hạn trên thiết bị production gây tốn tài nguyên CPU không cần thiết.

4. Quiz

Câu 1: Vì sao nên xác nhận packet capture trước khi nghi ngờ policy hay routing?

• A. Vì packet capture luôn phải chạy đầu tiên theo quy định của Fortinet
• B. Để chắc chắn gói tin thực sự tới được đúng interface, tránh mất thời gian sửa policy khi vấn đề nằm ở tầng vật lý/routing trước FortiGate
• C. Vì packet capture nhanh hơn debug flow
• D. Vì debug flow không hoạt động nếu chưa chạy packet capture trước

Câu 2: Tham số nào trong diagnose debug flow giúp hiển thị chi tiết các policy được xem xét và kết quả match/không match?

• A. show iprope enable
• B. trace start
• C. filter saddr
• D. debug enable

Câu 3: Policy Lookup (GUI) có hạn chế gì so với debug flow?

• A. Policy Lookup chỉ mô phỏng logic match theo cấu hình tĩnh, không phản ánh yếu tố runtime như session cũ hay NAT pool đã cạn
• B. Policy Lookup không hỗ trợ IPv6
• C. Policy Lookup chỉ dùng được qua CLI
• D. Policy Lookup yêu cầu license riêng

Câu 4: Nếu traffic bị drop không theo quy luật rõ ràng (lúc được lúc không), bước nào trong quy trình nên được kiểm tra?

• A. Kiểm tra lại tên address object
• B. Kiểm tra tài nguyên hệ thống (CPU/Memory/Conserve mode)
• C. Đổi port quản trị mặc định
• D. Kiểm tra license VDOM

👉 Đáp án

Câu 1: B Nếu gói tin còn chưa tới được FortiGate, mọi thay đổi ở policy hay routing trên thiết bị đều vô nghĩa — cần loại trừ nguyên nhân ở tầng vật lý/kết nối trước.

Câu 2: A show iprope enable kích hoạt log chi tiết từ cơ chế lookup policy ở tầng kernel (iprope), cho thấy rõ policy nào được xét và vì sao match hoặc không match.

Câu 3: A Policy Lookup chỉ tính toán tĩnh theo cấu hình hiện tại, không phản ánh được các yếu tố phát sinh trong runtime như session cũ còn tồn tại hay tài nguyên NAT pool đã hết.

Câu 4: B Hiện tượng drop không theo quy luật cố định (không gắn với một policy hay điều kiện cụ thể) thường gợi ý nguyên nhân liên quan tới áp lực tài nguyên hệ thống, cần kiểm tra CPU/Memory/conserve mode.

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

🧭 Điều hướng