Danh mục sản phẩm
Session Table & Session TTL trên FortiGate — diagnose sys session list
1. Liên hệ thực tế
Một ứng dụng nội bộ của khách hàng bị "rớt kết nối" mỗi khi người dùng để màn hình idle khoảng 5 phút, dù không có lỗi hiển thị rõ ràng phía ứng dụng. Anh Nam nghi ngờ vấn đề không nằm ở ứng dụng mà ở việc FortiGate tự động xóa session khi hết thời gian chờ (timeout), khiến kết nối TCP bị cắt đột ngột từ phía firewall dù client và server vẫn "nghĩ" là kết nối còn sống.
Anh dùng lệnh:
FGT # diagnose sys session filter dst 10.10.30.15 FGT # diagnose sys session list
Kết quả cho thấy session tương ứng có expire=45 — chỉ còn 45 giây trước khi bị xóa, và giá trị TTL mặc định cho cổng ứng dụng đó (port 1521, Oracle) đang dùng theo timeout TCP mặc định khá ngắn so với đặc thù ứng dụng vốn có khoảng lặng dài giữa các truy vấn.
Chị Lan giải thích: "Đây là vấn đề rất điển hình với các ứng dụng database hoặc terminal có phiên làm việc dài nhưng ít traffic. Giải pháp không phải là sửa ứng dụng, mà là điều chỉnh Session TTL riêng cho cổng đó bằng config system session-ttl."
2. Kiến thức cốt lõi
2.1 Session table là gì
Mỗi khi có một luồng traffic mới đi qua FortiGate và được Firewall Policy cho phép, FortiGate tạo ra một session — một bản ghi trạng thái (stateful entry) lưu thông tin: IP/cổng nguồn-đích, giao thức, policy đã match, thông tin NAT, và thời gian còn lại trước khi hết hạn (TTL). Session table chính là toàn bộ tập hợp các bản ghi này đang tồn tại trên thiết bị tại một thời điểm.
Đây là nền tảng của kiến trúc session-based đã giới thiệu ở Nhóm 1 — Kiến trúc FortiOS: sau khi gói tin đầu tiên của một luồng được kiểm tra qua toàn bộ policy/UTM, các gói tiếp theo của cùng luồng đó được xử lý nhanh hơn nhiều nhờ khớp trực tiếp với session đã tồn tại, không cần lặp lại toàn bộ quá trình policy lookup.
2.2 Xem và lọc session table
diagnose sys session list
Liệt kê toàn bộ session — trên thiết bị production có hàng nghìn session, nên gần như luôn cần lọc trước:
diagnose sys session filter src 192.168.3.221 diagnose sys session filter dst 10.10.30.15 diagnose sys session filter dport 1521 diagnose sys session filter proto 6 diagnose sys session list
Lưu ý cú pháp hai bước: filter chỉ đặt điều kiện lọc, phải chạy tiếp diagnose sys session list mới thực sự hiển thị kết quả đã lọc. Dùng diagnose sys session filter clear để xóa toàn bộ điều kiện lọc trước khi đặt bộ lọc mới, tránh nhầm lẫn kết quả với lần lọc trước.
2.3 Đọc hiểu một bản ghi session
session info: proto=6 proto_state=01 duration=125 expire=3474 timeout=3600 policy_id=12 auth_info=0 chk_client_info=0 vd=0 state=may_dirty statistic(bytes/packets/allow_err)=1024/8/1 origin-shaper= reply-shaper= per_ip_shaper= class_id=0 ha_id=0 policy_dir=0 tunnel=/dscp=0/0 run_state=0 gen=1 mtu=1500 pmtu-time=3600 ... 192.168.3.221:52001->10.10.30.15:1521/1521->192.168.3.221:52001
Các trường quan trọng nhất cần đọc:
| Trường | Ý nghĩa |
|---|---|
proto=6 |
Giao thức (6=TCP, 17=UDP, 1=ICMP) |
duration |
Session đã tồn tại bao lâu (giây) |
expire |
Còn bao nhiêu giây trước khi session hết hạn nếu không có traffic mới |
timeout |
Giá trị TTL tối đa áp dụng cho session này |
policy_id |
Policy nào đã cho phép session này — đối chiếu nhanh ngược lại cấu hình |
Dòng cuối (IP:port->IP:port) |
Địa chỉ 5-tuple đầy đủ, thể hiện cả chiều gốc và chiều NAT nếu có |
2.4 Session TTL mặc định và cách tùy chỉnh
FortiOS áp dụng các giá trị timeout mặc định theo giao thức khi không có cấu hình riêng: kết nối TCP thường dùng mức mặc định khá dài (hàng giờ) để phù hợp với phần lớn ứng dụng, còn UDP và ICMP dùng mức ngắn hơn nhiều do bản chất phi kết nối. Giá trị chính xác đang áp dụng trên một thiết bị cụ thể luôn nên xác nhận trực tiếp qua:
show system session-ttl
Khi cần override TTL cho một dải cổng cụ thể (như tình huống Oracle DB ở phần Liên hệ thực tế), dùng:
config system session-ttl
config port
edit 1
set protocol 6
set start-port 1521
set end-port 1521
set timeout 7200
next
end
end
⚠️ Lưu ý: Tăng TTL quá cao cho nhiều dải cổng có thể khiến session table phình to bất thường trên thiết bị có traffic lớn, ảnh hưởng tới tài nguyên memory — chỉ nên override TTL cho các cổng ứng dụng thực sự cần, không áp dụng tràn lan cho toàn bộ traffic.
2.5 Xóa session thủ công khi cần
Trong một số tình huống troubleshooting (ví dụ cần buộc một kết nối phải thiết lập lại từ đầu sau khi thay đổi cấu hình NAT/routing), có thể xóa session thủ công:
diagnose sys session filter dst 10.10.30.15 diagnose sys session clear
⚠️ Lưu ý:
session clearxóa ngay lập tức mọi session khớp filter hiện tại, ngắt kết nối đang hoạt động của người dùng liên quan — chỉ nên dùng trong cửa sổ bảo trì đã thông báo trước, không nên chạy tùy tiện trên production giờ cao điểm.
2.6 Mối liên hệ với Debug Flow và Packet Capture
Session table cho biết trạng thái hiện tại của các luồng traffic đã được thiết lập, trong khi Debug Flow cho biết quá trình một gói tin được xử lý và tạo session ra sao, còn Packet Capture cho biết nội dung gói tin thực tế trên dây. Ba công cụ này bổ trợ nhau: khi nghi ngờ kết nối bị rớt bất thường, quy trình hợp lý là kiểm tra session table trước (có tồn tại không, TTL còn bao nhiêu), rồi mới cần tới debug flow hoặc packet capture nếu vấn đề phức tạp hơn.
3. Hỏi & Đáp
Vì sao ứng dụng của tôi bị rớt kết nối dù không có lỗi gì rõ ràng, và session table có thể giúp gì?
Nếu ứng dụng có khoảng lặng dài giữa các lần trao đổi dữ liệu (như phiên terminal, kết nối database giữ lâu), rất có thể FortiGate đã xóa session do hết TTL trước khi ứng dụng gửi traffic mới. Kiểm tra diagnose sys session list để xem giá trị expire/timeout thực tế, từ đó quyết định có cần override TTL cho cổng ứng dụng đó hay không.
Có nên tăng TTL mặc định cho toàn bộ TCP lên rất cao để tránh mọi vấn đề rớt session?
Không nên. Giá trị TTL mặc định được Fortinet cân bằng giữa trải nghiệm ứng dụng và hiệu quả sử dụng tài nguyên session table. Tăng tràn lan có thể khiến session "chết" (client đã đóng kết nối nhưng FortiGate chưa biết) tồn đọng lâu, chiếm tài nguyên không cần thiết. Chỉ nên override có chọn lọc cho cổng ứng dụng thực sự cần.
diagnose sys session clear có ảnh hưởng tới toàn bộ traffic không hay chỉ session khớp filter?
Chỉ ảnh hưởng tới các session khớp với filter đã đặt trước đó bằng diagnose sys session filter. Nếu quên đặt filter (hoặc filter còn sót điều kiện cũ), lệnh có thể xóa nhầm phạm vi rộng hơn dự định — luôn kiểm tra lại filter hiện tại trước khi chạy clear.
4. Quiz
Câu 1: Trường nào trong output diagnose sys session list cho biết session sẽ bị xóa sau bao nhiêu giây nữa nếu không có traffic mới?
- A.
duration - B.
expire - C.
policy_id - D.
proto
Câu 2: Để kiểm tra giá trị Session TTL mặc định đang áp dụng trên thiết bị, dùng lệnh nào?
- A.
show system session-ttl - B.
diagnose sys top - C.
diagnose debug flow trace start - D.
get system performance status
Câu 3: Vì sao không nên tăng TTL mặc định cho toàn bộ TCP lên rất cao?
- A. Sẽ làm FortiGate tự động reboot
- B. Có thể khiến session "chết" tồn đọng lâu, chiếm tài nguyên session table không cần thiết
- C. Sẽ vô hiệu hóa hoàn toàn Firewall Policy
- D. Làm mất kết nối VPN đang hoạt động
Câu 4: Lệnh diagnose sys session clear cần thận trọng vì lý do gì?
- A. Xóa toàn bộ cấu hình FortiGate
- B. Ngắt ngay lập tức các kết nối đang hoạt động khớp với filter hiện tại
- C. Chỉ hoạt động khi FortiGate ở chế độ Transparent
- D. Yêu cầu khởi động lại thiết bị sau khi chạy
👉 Đáp án
Câu 1: B expire cho biết số giây còn lại trước khi session bị xóa nếu không phát sinh traffic mới.
Câu 2: A show system session-ttl hiển thị cấu hình TTL hiện tại, bao gồm cả các override theo cổng nếu có.
Câu 3: B TTL quá cao khiến các session không còn hoạt động thực sự (client đã đóng) vẫn tồn tại lâu trong bảng, lãng phí tài nguyên.
Câu 4: B Lệnh này xóa ngay session khớp filter, đồng nghĩa ngắt kết nối thật của người dùng liên quan — cần dùng thận trọng và đúng filter.
📚 Bài viết thuộc khóa học FortiGate của VNExperts
🧭 Điều hướng
| ⬅️ Bài trước | 🏠 Mục lục khóa học | Bài kế tiếp ➡️ |
|---|---|---|
| Debug Flow & Flow Trace | Mục lục khóa học FortiGate | Troubleshooting NAT/Routing thường gặp |
