netfilter / iptables: ทำไมไม่ใช้ตารางดิบ?

ภายใต้ Linux เรามักจะใช้ตาราง "ตัวกรอง" เพื่อทำการกรองแบบทั่วไป:

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

ตามแผนภูมิการไหลของ netfilter ด้านล่างแพ็คเก็ตเดินทางผ่านตาราง "ดิบ" เป็นครั้งแรก:

ดังนั้นเราสามารถเขียน:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

• แพ็กเก็ตได้รับการจัดการเร็วกว่าโดยไม่จำเป็นต้องไปถึงแม้ว่าการกำหนดเส้นทาง conntrack + mangle + nat + CPU / หน่วยความจำที่ใช้น้อยกว่าเล็กน้อย (และในทางกลับกันก็ชดเชยด้วยความจริงที่ว่าโมดูล iptable_raw จะต้องโหลด)
• กฎเดียวเท่านั้นในกรณีที่กล่องเป็นเราเตอร์ (จะไม่เป็นไรสำหรับทุกกฎอย่างชัดเจน) เพราะไม่จำเป็นต้องเพิ่มกฎเดียวกันสำหรับตัวกรอง / ส่งต่อ

ฉันทำการทดสอบอย่างรวดเร็วเท่านั้นและใช้งานได้ดีอย่างสมบูรณ์
เอกสารที่ฉันพบมักอธิบายตารางดิบที่จะใช้ในกรณีที่เข้มงวด แต่ไม่มีใครให้เหตุผลที่เล็กที่สุดแม้แต่น้อย

คำถาม: มีเหตุผลใดบ้างที่จะไม่ใช้ตารางดิบ

จากผู้ชาย iptables :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

วิเคราะห์ :

ดังนั้นตาราง RAW นั้นอยู่ก่อน conntrack และได้รับการออกแบบโดยมีวัตถุประสงค์เพื่อใช้ในการตั้งค่าเครื่องหมาย NOTRACK บนแพ็กเก็ตที่คุณไม่ต้องการติดตามใน netfilter

เป้าหมาย -j ไม่ได้ถูก จำกัด ไว้ที่ NOTRACK เท่านั้นดังนั้นคุณต้องทำการกรองแพ็กเก็ตในตาราง raw ด้วยข้อดีของการใช้ CPU / หน่วยความจำน้อยลง

บ่อยครั้งที่เซิร์ฟเวอร์ไม่จำเป็นต้องติดตามการเชื่อมต่อทั้งหมด คุณจะต้องติดตามหากคุณต้องการกรองแพ็กเก็ตใน iptables ตามการเชื่อมต่อที่สร้างไว้ก่อนหน้า บนเซิร์ฟเวอร์ที่ให้บริการเพื่อจุดประสงค์ที่เรียบง่ายเช่นเดียวกับพอร์ต 80 เท่านั้น (และอาจ 21) ที่เปิดอยู่ไม่จำเป็นต้องใช้สิ่งนั้น ในกรณีเหล่านั้นคุณสามารถปิดใช้งานการติดตามการเชื่อมต่อ

อย่างไรก็ตามหากคุณกำลังพยายามเรียกใช้เราเตอร์ NAT สิ่งต่าง ๆ มีความซับซ้อนเล็กน้อย เพื่อที่จะ NAT สิ่งคุณจำเป็นต้องติดตามการเชื่อมต่อเหล่านั้นเพื่อให้คุณสามารถส่งแพ็คเก็ตจากเครือข่ายภายนอกไปยังเครือข่ายภายใน

หากการเชื่อมต่อทั้งหมดถูกตั้งค่าไว้ที่ NOTRACK คุณจะไม่สามารถติดตามการเชื่อมต่อที่เกี่ยวข้องได้เช่นกันผู้ช่วย Conntrack และ nat ก็จะไม่สามารถใช้งานได้สำหรับการเชื่อมต่อที่ไม่ได้ติดตาม คุณจะต้องเปิดรับสิ่งเหล่านี้ด้วยตนเองในคำอื่น ๆ เมื่อพูดถึงโปรโตคอลที่ซับซ้อนเช่น FTP และ SCTP และอื่น ๆ การจัดการนี้ทำได้ยากมาก

ใช้กรณี :

ตัวอย่างหนึ่งคือหากคุณมีเราเตอร์ที่มีการดูแลมากที่คุณต้องการไฟร์วอลล์ที่ทราฟฟิกขาเข้าและขาออก แต่ไม่ใช่ทราฟฟิกที่ถูกกำหนดเส้นทาง จากนั้นคุณสามารถตั้งค่า NOTRACK เพื่อเพิกเฉยต่อปริมาณข้อมูลที่ส่งต่อเพื่อประหยัดพลังงานในการประมวลผล

อีกตัวอย่างหนึ่งที่สามารถใช้ NOTRACK ได้ก็คือหากคุณมีเว็บเซิร์ฟเวอร์ที่มีการดูแลการแสดงผลสูงคุณสามารถตั้งค่ากฎที่เปลี่ยนการติดตามพอร์ต 80 ในที่อยู่ IP ที่เป็นของท้องถิ่นทั้งหมด จากนั้นคุณสามารถเพลิดเพลินไปกับการติดตามสถานะในบริการอื่น ๆ ทั้งหมดยกเว้นการรับส่งข้อมูลบนเว็บซึ่งอาจประหยัดพลังงานในการประมวลผลบางอย่างในระบบที่มีการโอเวอร์โหลดอยู่แล้ว

ตัวอย่าง -> การเรียกใช้ -a-semi-stateless-linux-router-for-private-network

สรุป : ไม่มีเหตุผลที่ดีที่จะไม่ใช้ตารางดิบ แต่มีเหตุผลบางอย่างที่ควรระวังเมื่อใช้เป้าหมาย NOTRACK ในตารางดิบ