Khi nào thì mô-đun conntrack của iptable theo dõi trạng thái của các gói?
Đầu tiên nó cần lưu trữ các trạng thái. Với một số tường lửa BSD cũ mà tôi đã sử dụng, tôi đoán được đặt tên là IPFW, tôi đã sử dụng để đặt một quy tắc "theo dõi trạng thái của gói tin đang rời" và điều này được đặt trên hướng đi của các giao diện. Sau đó, một quy tắc khác về hướng đi đã kiểm tra chúng so với những trạng thái đã được tạo bởi quy tắc về hướng đi. Vì vậy, đã từng có 2 quy tắc: (1) để điền vào bảng trạng thái, đây là theo hướng đi và (2) để tra cứu bảng trạng thái, đây là theo hướng đến.
Nhưng với connntrack, tôi thấy nó được áp dụng trên chuỗi INPUT, chẳng hạn như quy tắc này:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Điều này khiến tôi tự hỏi, thực ra câu nói đó có tác dụng gì?
- Có phải nó nói rằng nó sẽ bắt đầu theo dõi các gói phù hợp với quy tắc đó bằng cách đưa thông tin của chúng vào bảng trạng thái không?
- Hay nó nói rằng nó đã có thông tin trạng thái và nó sẽ hành động chống lại các thông điệp gửi đến dựa trên nó? (ví dụ: chấp nhận nếu chúng thuộc về một kết nối được chấp nhận trước đó?). Nhưng, trong trường hợp này, bảng trạng thái được điền ở đâu? Nó tuân theo quy tắc nào? Hay là nó không có quy tắc và ngầm hiểu?
Trả lời
Phần trình bày giới thiệu về Netfilter và conntrack
Đầu tiên, sơ đồ bắt buộc về luồng gói trong Netfilter và Mạng chung:
Netfilter là khung lọc gói tự chèn vào phần còn lại của ngăn xếp mạng (được thể hiện bằng "quyết định định tuyến" và các phần hộp tròn viền trắng khác). Netfilter cung cấp các hook và API cho các hệ thống con và "máy khách" khác. Trong số các phần này có conntrack (trình theo dõi kết nối) và iptables (hoặc nftables ). Sự tách biệt giữa Netfilter và conntrack khá mờ nhạt. Bạn chỉ có thể coi conntrack là một phần tích hợp của Netfilter.
Trong sơ đồ mô tả các bước khác nhau mà một gói tin truyền đi, bạn có thể thấy rằng tại một số điểm (giữa raw / PREROUTING và mangle / PREROUTING, hoặc giữa raw / OUTPUT và mangle / OUTPUT) gói tin sẽ truyền qua conntrack .
Tại thời điểm này, conntrack sẽ tìm kiếm trong các bảng tra cứu của riêng nó (một cơ sở dữ liệu tra cứu nhỏ được lưu trong bộ nhớ hạt nhân):
- nếu đặc điểm của gói này không được tìm thấy (và nếu không được khai báo là UNTRACKED trong bảng thô), một mục nhập tuple hai chiều liên kết mới (giao thức, sau đó là thông tin giao thức và họ cụ thể: nguồn và cổng ban đầu, đích và cổng ban đầu, nguồn trả lời và cổng, điểm đến và cổng trả lời (hai điểm cuối cùng thường là ngược lại, trừ khi có sự tham gia của NAT hoặc một số giao thức lạ, chẳng hạn như phản hồi echo khớp với yêu cầu echo cho ICMP)) mô tả luồng được tạo với trạng thái MỚI.
- nếu nó khớp (theo bất kỳ hướng nào) với mục nhập trước đó và tương thích với trạng thái của luồng này, thì trạng thái luồng có thể bị thay đổi (ví dụ: thay đổi từ MỚI thành THIẾT LẬP nếu trước đây không phải như vậy).
- nếu vì một lý do cụ thể nào đó mà gói tin không thể khớp với một luồng hiện có mặc dù nó có các đặc điểm của nó (ví dụ: một gói TCP muộn nhận được sau khi truyền lại đã được khởi động thành công, vì vậy không liên quan đến chuỗi và giá trị SACK) gói sẽ được gắn thẻ INVALID.
- có một vài trường hợp khác như LIÊN QUAN: đây là về các gói không phải là một phần của chính luồng mà liên quan đến một luồng mới có thể được liên kết với một luồng khác hiện có (tức là: trong cơ sở dữ liệu). Hai ví dụ là lỗi ICMP được tạo ra từ việc nhận một gói (ví dụ: không thể truy cập cổng UDP) hoặc khi một trình trợ giúp giao thức đặc biệt như mô-đun hạt nhân
nf_conntrack_ftp, là một plugin cho hệ thống con conntrack , phát hiện rằng một gói là một phần của luồng dữ liệu riêng biệt được liên kết với các lệnh FTP PASV / EPSV hoặc PORT / EPRT được thực hiện trên luồng lệnh (trên cổng 21).
Giải quyết câu hỏi
Tất cả những điều này đang được nói, đây là câu trả lời cho hai gạch đầu dòng của bạn:
trong không gian tên mạng chính, conntrack bắt đầu theo dõi các kết nối ngay sau khi các mô-đun của nó (bao gồm các mô-đun phụ có thể có liên quan theo giao thức cụ thể) được tải. Đối với không gian tên mạng không phải ban đầu (vùng chứa ...), điều này cũng yêu cầu một số hệ thống con khác tham chiếu đến nó (chẳng hạn như mô-đun conntrack của iptables của OP hoặc sử dụng một lần lệnh
conntrackđược mô tả sau). Đây là mặc định và một gói phải được đánh dấu cụ thể như không được theo dõi trước khi các conntrack hệ thống phụ nhìn thấy nó cho gói này để không bị theo dõi. Trên Linux, chỉ có một số trường hợp không cần theo dõi, nhưng tất nhiên sau đó tường lửa trạng thái và NAT trạng thái / động sẽ không khả dụng nữa (NAT không cố định thậm chí có thể yêu cầu sử dụng UNTRACKED ngay từ đầu, vẫn có thể xong, nhưng không phải với iptables . tc hoặc nftables có thể). Để tránh conntrack xử lý một số gói, loại quy tắc iptables này có thể được sử dụng (ví dụ: cổng 80 / tcp):iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrackKhi gói đi qua bộ lọc / INPUT và đạt đến quy tắc này:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTCác iptables module cụ thể hạt nhân 's
xt_conntracktruy vấn conntrack hệ thống phụ (xử lý bởi các module kernel khác nhau có liên quannf_conntrack*) và hỏi về tình trạng của gói tin này trong cơ sở dữ liệu tra cứu của mình. Nếu câu trả lời làRELATEDhoặcESTABLISHEDgói tin khớp và chuyển sang phán quyết CHẤP NHẬN. Trên thực tế, kết quả đã được lưu trong bộ nhớ cache trong gói lần đầu tiên việc tra cứu được thực hiện (thường là bằng conntrack ) vì vậy đây là một "tra cứu" rẻ tiền. Do đó, đây là quy tắc chung để xử lý các luồng đã được chấp nhận trước đây. Những luồng đó ban đầu có thể được chấp nhận trong các quy tắc đề cập rõ ràng-m conntrack --ctstate NEWhoặc chỉ đơn giản là các quy tắc không đề cập đến nó nhưng được đặt sau quy tắc chung này (nhưng hãy nhớ trạng thái INVALID, thường phải được DỪNG trước khi làm như vậy).thêm một viên đạn: việc xử lý các gói dữ liệu vào và gói đi là khá đối xứng giữa PREROUTING và OUTPUT (ngay cả khi những không nhìn đối xứng): conntrack giao diện trong PREROUTING cũng như trong OUTPUT (và ở một vài nơi khác, xem xét NAT là làm việc với conntrack , ngoại trừ gói đầu tiên của nó ở trạng thái MỚI duyệt qua bảng nat của iptables ). Điều này có thể hơi khác so với mô tả bạn đã viết về IPFW. Nếu một máy chủ đang chạy các ứng dụng cũng đang hạn chế các luồng gửi đi, thì rất có thể nó cần quy tắc iptables chung này cả trong bộ lọc / OUTPUT và trong bộ lọc / INPUT, để cho phép các gói trả lời đi của lưu lượng đến đã được chấp nhận đi qua.
Thông tin bổ sung
Có những công cụ chuyên dụng để tương tác với conntrack bảng tra cứu hệ thống phụ của từ conntrack-công cụ .
conntrack: để truy vấn, xóa hoặc cập nhật nội dung của các bảng tra cứu do conntrack xử lý .
Vài ví dụ.
Bạn có thể liệt kê tất cả các mục được theo dõi (có thể lớn mà không cần thêm bộ lọc) với:
conntrack -LNếu hệ thống của bạn đang làm NAT (ví dụ như một router trước một mạng LAN riêng, hoặc chạy máy ảo và container), bạn có thể sử dụng
--any-nat,--src-nathoặc--dst-natchỉ resp hiển thị. tất cả NAT, tất cả NAT nguồn (masquerade) hoặc tất cả NAT đích (thường dành cho các cổng được chuyển tiếp):Giám sát thời gian thực các sự kiện conntrack :
conntrack -Econntrackd: một daemon có hai mục đích chính là tính toán và thống kê luồng (conntrack), hoặc đồng bộ hóa trạng thái cụm tường lửa trạng thái khả dụng cao .
Theo dõi kết nối là một chức năng riêng biệt của Netfilter và nó không được định cấu hình với IPTables.
Trong hình, có hai conntrackbước trong đường dẫn INPUT và một bước trong đường dẫn OUTPUT. Các bước này liên kết các gói riêng lẻ với các kết nối hiện có được theo dõi trong bảng theo dõi kết nối hoặc tạo các mục theo dõi kết nối mới trong bảng.
Chức năng Conntrack là một mô-đun nhân Linux và nó thường được bao gồm trong nhân trong cấu hình mặc định.
Hoạt động của Conntrack có thể được điều chỉnh bằng cách điều chỉnh net.netfilter.nf_conntrackcác giá trị sysctl.
Thay thế thứ hai của bạn là những gì sẽ xảy ra. Thông tin trạng thái được ghi lại bởi hàm Conntrack và quy tắc IPTables chỉ đơn giản là tham khảo bảng Conntrack để biết thông tin.