Sự khác biệt giữa -m conntrack --ctstate và -m state --state

Tôi đang đọc hướng dẫn này và có một cái gì đó như thế này:

Chúng tôi có thể cho phép các phiên được thiết lập để nhận lưu lượng truy cập:

$ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Quy tắc trên không có khoảng trắng ở hai bên dấu phẩy trong THÀNH LẬP, LIÊN QUAN

Nếu dòng trên không hoạt động, bạn có thể sử dụng VPS bị thiến mà nhà cung cấp chưa cung cấp tiện ích mở rộng, trong trường hợp đó, phiên bản kém hơn có thể được sử dụng làm giải pháp cuối cùng:

$ sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Có sự khác biệt đáng kể trong làm việc giữa -m conntrack --ctstatevà -m state --state? Họ nói rằng một người có thể không làm việc, nhưng họ không nói tại sao. Tại sao tôi nên thích cái này hơn cái kia?

Tôi không tự nhận là một chuyên gia về các iptablesquy tắc nhưng lệnh đầu tiên là sử dụng tiện ích mở rộng theo dõi kết nối ( conntrack) trong khi thứ hai là sử dụng statetiện ích mở rộng.

Điểm dữ liệu số 1

Theo tài liệu này , conntrackphần mở rộng thay thế state.

 Obsolete extensions:
  • -m state: replaced by -m conntrack

Điểm dữ liệu số 2

Mặc dù vậy tôi đã tìm thấy câu hỏi và trả lời SF này có tiêu đề: Câu hỏi tường lửa về trạng thái và chính sách? nơi OP tuyên bố đã hỏi câu hỏi này trên IRC trong # iptables @ freenode. Sau khi thảo luận về nó, ông đã đi đến kết luận rằng:

Về mặt kỹ thuật, trận đấu conntrack thay thế - và do đó, lỗi thời - trận đấu trạng thái. Nhưng thực tế, trận đấu nhà nước không bị lỗi thời theo bất kỳ cách nào.

Điểm dữ liệu số 3

Cuối cùng tôi đã tìm thấy SF Q & A này có tiêu đề: Iptables, sự khác biệt giữa trạng thái -m và -m conntrack là gì? . Câu trả lời từ câu hỏi này có lẽ là bằng chứng và lời khuyên tốt nhất về cách xem cách sử dụng conntrackvà state.

đoạn trích

Cả hai đều sử dụng cùng một phần bên trong kernel (hệ thống con theo dõi kết nối).

Tiêu đề của xt_conntrack.c:

xt_conntrack - Netfilter module to match connection tracking
information. (Superset of Rusty's minimalistic state match.)

Vì vậy, tôi sẽ nói - mô-đun trạng thái đơn giản hơn (và có thể ít bị lỗi hơn). Nó cũng dài hơn trong kernel. Conntrack ở phía bên kia có nhiều tùy chọn và tính năng hơn _[1] .

Cuộc gọi của tôi là sử dụng conntrack nếu bạn cần các tính năng của nó, nếu không thì gắn bó với mô-đun trạng thái.

• Câu hỏi tương tự trên maillist netfilter.

[1] Khá hữu ích như "-m conntrack --ctstate DNAT -j MASQUERADE" định tuyến / sửa lỗi DNAT ;-)

Điểm dữ liệu số 4

Tôi tìm thấy thread này từ netfilte netfilter@vger.kernel.org / iptables thảo luận, với tựa đề: trận đấu nhà nước là lỗi thời 1.4.17 , mà khá nhiều nói rằng statechỉ là một bí danh để conntrackvì vậy nó không thực sự quan trọng mà bạn sử dụng, trong cả hai trường hợp bạn đang sử dụng conntrack.

đoạn trích

Thật ra, tôi phải đồng ý. Tại sao chúng ta không giữ "trạng thái" như một bí danh và chấp nhận cú pháp cũ trong "conntrack"?

trạng thái hiện được đặt bí danh và được dịch thành conntrack trong iptables nếu kernel có nó. Không có kịch bản bị hỏng.

Nếu việc khử răng cưa được thực hiện trong không gian người dùng, phần kernel có thể bị xóa - một ngày nào đó có thể.

Việc đặt bí danh đã được thực hiện trong không gian người dùng. Một loại trong "trạng thái" và nó được chuyển đổi thành "conntrack" và sau đó được gửi đến kernel. (Theo như tôi thấy nếu các bí danh mô-đun ipt_state, v.v. đã được thêm vào mô-đun conntrack, thậm chí có thể loại bỏ mô-đun hạt nhân trạng thái.)

Người giới thiệu

• Câu hỏi tường lửa về nhà nước và chính sách?
• iptables: sự khác biệt khi sử dụng conntrack hoặc mô đun trạng thái

Tôi không phải là một chuyên gia về bộ lọc mạng, nhưng tôi đã xem xét trang con người mở rộng iptables và bất ngờ, nó đây rồi

The "state" extension is a subset of the "conntrack" module.

Vì vậy, trạng thái là một phần của conntrack và chỉ là một phiên bản đơn giản hơn của nó nếu bạn thực sự chỉ cần --state và không có các tính năng lạ mắt hơn của conntrack