Phần nhân hiển thị số liệu thống kê như vậy trong /proc phương pháp hệ thống tập tin là ở đó:
nếu (v == SEQ_START_TOKEN) {
seq_puts(seq, "các mục tìm kiếm được tìm thấy mới không hợp lệ bỏ qua xóa delete_list chèn insert_failed drop Early_drop icmp_error kỳ vọng_new kỳ vọng_tạo kỳ vọng_xóa tìm kiếm_restart\n");
trả về 0;
}
seq_printf(seq, "%08x %08x %08x %08x %08x %08x %08x %08x"
"%08x %08x %08x %08x %08x %08x %08x %08x %08x\n",
nr_conntracks,
0,
st-> tìm thấy,
0,
st->không hợp lệ,
st-> bỏ qua,
0,
0,
st->chèn,
st->insert_failed,
st->thả,
st->early_drop,
st->lỗi,
st->mong đợi_new,
st-> mong_tạo,
st-> mong đợi_xóa,
st->search_restart
);
như có thể thấy, các lĩnh vực tìm kiếm (được thay thế bởi một lĩnh vực khác trong các hạt nhân sau này), Mới, xóa bỏ, xóa_list luôn hiển thị 0: không có gì cung cấp cho các trường này.
Như tôi đã nghi ngờ trong câu trả lời trước của mình ("hoặc có thể đã lỗi thời") không có thống kê nào về điều này với phương pháp cũ hơn hoặc phương pháp mới hơn.
Đây là cam kết từ năm 2016 đã loại bỏ chúng (có lẽ cho kernel 4.9):
netfilter: conntrack: xóa số liệu thống kê về đường dẫn nóng của gói
Các quầy này nằm trong đường dẫn nóng và hiển thị hoàn hảo, điều này đặc biệt
true cho 'đã tìm thấy' và 'đã tìm kiếm' sẽ tăng dần cho mỗi gói
xử lý.
Thông tin như
đã tìm kiếm=212030105
mới=623431
đã tìm thấy=333613
xóa=623327
ngày nay dường như không quá hữu ích:
trên các hệ thống bận rộn được tìm thấy và tìm kiếm sẽ tràn ra sau mỗi vài giờ
(đây là những số nguyên 32 bit), những số khác bận rộn hơn cứ sau vài ngày.
để gỡ lỗi, có các phương pháp tốt hơn, chẳng hạn như mục tiêu theo dõi của iptables,
các hệ thống nhật ký conntrack. Ngày nay chúng ta cũng có công cụ hoàn hảo.
Điều này loại bỏ các bộ đếm thống kê đường dẫn gói ngoại trừ những bộ đếm
dự kiến là 0 (hoặc gần bằng 0) trên một hệ thống bình thường, ví dụ:
'insert_failed' (cuộc đua đã xảy ra) hoặc 'không hợp lệ' (từ chối trình theo dõi proto).
Chỉ số chèn được giữ lại cho trường hợp ctnetlink.
Chỉ số tìm thấy được giữ lại để kiểm tra tuple-is-taken khi NAT phải
xác định xem nó có cần chọn một địa chỉ nguồn khác hay không.
Người ký tắt: Florian Westphal [email protected]
Người ký: Pablo Neira Ayuso [email protected]
Thay thế
Bạn có thể dùng conntrackd công cụ (được đóng gói trên Ubuntu ở đó) có thể được định cấu hình để ghi nhật ký sự kiện nhằm chỉ cung cấp nhật ký và số liệu thống kê (thay vì mục đích sử dụng chính của nó để chuyển đổi dự phòng trong suốt giữa nhiều tường lửa trong một cụm có tính sẵn sàng cao). Ubuntu có thể cung cấp cấu hình cho số liệu thống kê theo mặc định (hoặc trong tài liệu). Đây là một ví dụ về một hệ thống nơi conntrackd dịch vụ đang chạy:
# conntrackd -s ct; ngủ 5; conntrackd -s ct
[Thứ Sáu ngày 15 tháng 10 08:34:08 năm 2021] (pid=3443753) [cảnh báo] cấu hình tồn đọng unix không dùng nữa, bỏ qua.
số liệu thống kê bộ đệm:
kết nối hoạt động hiện tại: 65
kết nối đã tạo: 121807 không thành công: 0
kết nối được cập nhật: 116158 không thành công: 0
kết nối bị phá hủy: 121742 không thành công: 0
lưu lượng truy cập được xử lý:
0 Byte 0 Pckts
[Thứ Sáu ngày 15 tháng 10 08:34:13 năm 2021] (pid=3443756) [cảnh báo] cấu hình tồn đọng unix không dùng nữa, bỏ qua.
số liệu thống kê bộ đệm:
kết nối hoạt động hiện tại: 68
kết nối đã tạo: 121811 không thành công: 0
kết nối được cập nhật: 116163 không thành công: 0
kết nối bị phá hủy: 121743 không thành công: 0
lưu lượng truy cập được xử lý:
0 Byte 0 Pckts
Công cụ cho biết kết nối được tạo: đã đi từ 121807 đến 121811. Tôi tin rằng điều đó tương đương với Mới trường bị xóa khỏi kernel.
Ghi chú: lưu lượng truy cập được xử lý: chắc chắn là dành cho giao tiếp giữa tường lửa với tường lửa giữa hai conntrackd daemon (vì vậy sẽ luôn là 0 ở đây).
