ความแตกต่างระหว่าง -m conntrack --ctstate และ -m state --state

ฉันกำลังอ่านวิธีนี้และมีบางอย่างเช่นนี้:

เราสามารถอนุญาตให้เซสชันที่กำหนดไว้รับการรับส่งข้อมูล:

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

กฎข้างต้นไม่มีช่องว่างทั้งสองข้างของเครื่องหมายจุลภาคใน ESTABLISHED ที่เกี่ยวข้อง

หากบรรทัดด้านบนใช้งานไม่ได้คุณอาจใช้ VPS ที่มีผู้ให้บริการซึ่งไม่ได้ให้บริการส่วนขยายซึ่งในกรณีนี้สามารถใช้เวอร์ชันที่ต่ำกว่าเป็นทางเลือกสุดท้าย:

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

มีความแตกต่างอย่างมีนัยสำคัญในการทำงานระหว่าง-m conntrack --ctstateและ-m state --state? พวกเขาบอกว่าอาจไม่ทำงาน แต่พวกเขาไม่พูดว่าทำไม ทำไมฉันถึงต้องเลือกอันหนึ่งมากกว่าอีกอัน?

ฉันไม่ได้อ้างว่าเป็นผู้เชี่ยวชาญที่มีiptablesกฎ แต่คำสั่งแรกใช้ประโยชน์จากส่วนขยายการติดตามการเชื่อมต่อ ( conntrack) ในขณะที่คำสั่งที่สองใช้ประโยชน์จากstateส่วนขยาย

จุดข้อมูล # 1

ตามเอกสารนี้ขยายแทนที่conntrackstate

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

จุดข้อมูล # 2

ถึงกระนั้นฉันก็พบคำถามและคำตอบของ SF นี้: คำถามเกี่ยวกับสถานะและนโยบายของไฟร์วอลล์? โดยที่ OP อ้างว่าได้ถามคำถามนี้กับ IRC ใน # iptables @ freenode หลังจากพูดคุยกันแล้วเขาก็สรุปว่า:

ในทางเทคนิคแล้วการแข่งขันแบบ conntrack นั้นจะใช้แทนการแข่งขันแบบรัฐ แต่ในทางปฏิบัติแล้วการจับคู่ของรัฐนั้นไม่ล้าสมัย แต่อย่างใด

จุดข้อมูล # 3

สุดท้ายฉันพบคำถามและคำตอบของ SF นี้: Iptables อะไรคือความแตกต่างระหว่าง -m state และ -m conntrack? . คำตอบจากคำถามนี้น่าจะเป็นหลักฐานที่ดีที่สุดและให้คำแนะนำเกี่ยวกับวิธีการดูการใช้งานของและconntrackstate

สิ่งที่สกัดมา

ทั้งสองใช้เคอร์เนล internals เดียวกันภายใต้ (ระบบย่อยการติดตามการเชื่อมต่อ)

ส่วนหัวของ xt_conntrack.c:

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

ดังนั้นฉันจะบอกว่า - โมดูลรัฐนั้นง่ายกว่า (และอาจเกิดข้อผิดพลาดได้น้อยลง) มันยังยาวในเคอร์เนล conntrack ในด้านอื่น ๆ มีตัวเลือกมากขึ้นและคุณสมบัติ[1]

การโทรของฉันคือการใช้ conntrack หากคุณต้องการคุณสมบัติของมันมิฉะนั้นยึดติดกับโมดูลสถานะ

• คำถามที่คล้ายกันใน netfilter maillist

[1]ค่อนข้างมีประโยชน์เช่น"-m conntrack --ctstate DNAT -j MASQUERADE" การกำหนดเส้นทาง / DNAT fixup ;-)

จุดข้อมูล # 4

ฉันพบกระทู้นี้จากการสนทนา netfilter@vger.kernel.org netfilte / iptables หัวข้อ: การจับคู่สถานะล้าสมัย 1.4.17ซึ่งค่อนข้างบอกว่าstateเป็นเพียงนามแฝงconntrackดังนั้นจึงไม่สำคัญว่าคุณจะใช้ใน conntrackทั้งสถานการณ์ที่คุณกำลังใช้

สิ่งที่สกัดมา

ที่จริงฉันต้องยอมรับ ทำไมเราไม่ให้สถานะเป็นนามแฝงและยอมรับไวยากรณ์เก่าใน "conntrack"?

ขณะนี้สถานะเป็นนามแฝงและแปลเป็น conntrack ใน iptables หากเคอร์เนลมีอยู่ ไม่มีสคริปต์ใดเสียหาย

หากนามแฝงเสร็จสิ้นใน userspace แล้วส่วนของเคอร์เนลสามารถลบออกได้ - สักวันหนึ่ง

นามแฝงเสร็จเรียบร้อยแล้วใน userspace หนึ่งประเภทใน "สถานะ" และถูกแปลงเป็น "conntrack" และที่ถูกส่งไปยังเคอร์เนล (เท่าที่ฉันเห็นถ้า ipt_state, aliases โมดูลอื่น ๆ ถูกเพิ่มเข้ากับโมดูล conntrack, แม้กระทั่งโมดูลเคอร์เนลสถานะก็สามารถลบออกได้)

อ้างอิง

• คำถามเกี่ยวกับสถานะและนโยบายของไฟร์วอลล์
• iptables: ความแตกต่างโดยใช้โมดูลควบคุมหรือสถานะ

ฉันไม่ได้เป็นผู้เชี่ยวชาญด้าน netfilter แต่ฉันดูที่ iptables-extension man-page และ suprise มีอยู่

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

ดังนั้นรัฐจึงเป็นส่วนหนึ่งของ conntrack และเป็นเวอร์ชั่นที่เรียบง่ายกว่าถ้าคุณต้องการจริงๆ - สถานะและไม่ใช่คุณสมบัติที่แปลกใหม่ของ conntrack