ปัญหาประสิทธิภาพของ iptables / conntrack Linux


9

ฉันมีการตั้งค่าการทดสอบในห้องปฏิบัติการด้วย 4 เครื่อง:

  • เครื่อง P4 เก่า 2 เครื่อง (t1, t2)
  • 1 Xeon 5420 DP 2.5 GHz RAM 8 GB (t3) Intel e1000
  • 1 Xeon 5420 DP 2.5 GHz RAM 8 GB (t4) Intel e1000

เพื่อทดสอบประสิทธิภาพของไฟร์วอลล์ linux เนื่องจากเราถูกกัดจากการโจมตีของ syn-flood ในช่วงหลายเดือนที่ผ่านมา เครื่องทั้งหมดใช้ Ubuntu 12.04 64 บิต t1, t2, t3 เชื่อมต่อผ่านสวิตช์ 1GB / s, t4 เชื่อมต่อกับ t3 ผ่านทางอินเทอร์เฟซพิเศษ ดังนั้น t3 จึงจำลองไฟร์วอลล์ t4 คือเป้าหมาย, t1, t2 เล่นผู้โจมตีที่สร้าง packetstorm thorugh (192.168.4.199 คือ t4):

hping3 -I eth1 --rand-source --syn --flood 192.168.4.199 -p 80

t4 ดร็อปแพ็กเก็ตที่เข้ามาทั้งหมดเพื่อหลีกเลี่ยงความสับสนกับเกตเวย์ปัญหาประสิทธิภาพของ t4 ฯลฯ ฉันดูสถิติแพ็คเก็ตใน iptraf ฉันได้กำหนดค่าไฟร์วอลล์ (t3) ดังนี้:

  • หุ้น 3.2.0-31-generic # 50-Ubuntu SMP kernel
  • rhash_entries = 33554432 เป็นพารามิเตอร์เคอร์เนล
  • sysctl ดังต่อไปนี้:

    net.ipv4.ip_forward = 1
    net.ipv4.route.gc_elasticity = 2
    net.ipv4.route.gc_timeout = 1
    net.ipv4.route.gc_interval = 5
    net.ipv4.route.gc_min_interval_ms = 500
    net.ipv4.route.gc_thresh = 2000000
    net.ipv4.route.max_size = 20000000
    

(ฉันปรับแต่งมากมายเพื่อให้ t3 ทำงานต่อเนื่องเมื่อ t1 + t2 กำลังส่งแพ็คเก็ตให้มากที่สุด)

ผลลัพธ์ของความพยายามนี้ค่อนข้างแปลก:

  • t1 + t2 จัดการส่งแต่ละแพ็คเก็ตประมาณ 200k t4 ในกรณีที่ดีที่สุดจะเห็นว่ามีค่ารวม 200k ดังนั้นครึ่งหนึ่งของแพ็กเก็ตจะหายไป
  • t3 เกือบจะใช้ไม่ได้บนคอนโซลแม้ว่าแพ็กเก็ตจะไหลผ่านมัน (ซอฟต์ irqs จำนวนมาก)
  • ตัวรวบรวมขยะแคชเส้นทางไม่สามารถคาดการณ์ได้และอยู่ในการตั้งค่าเริ่มต้นที่มีจำนวนแพ็กเก็ตน้อยมาก (<50k แพ็กเก็ต / s)
  • การเปิดใช้งานกฎ iptables stateful ทำให้อัตราแพ็คเก็ตมาถึงบน t4 ลดลงไปประมาณ 100k แพ็คเก็ต / s สูญเสียมากกว่า 75% ของแพ็คเก็ต efectively

และนี่คือข้อกังวลหลักของฉัน - ด้วยเครื่อง P4 เก่าสองเครื่องที่ส่งแพ็คเก็ตให้มากที่สุดซึ่งหมายความว่าทุกคนในเน็ตควรมีความสามารถ

ดังนั้นต่อไปนี้เป็นคำถามของฉัน: ฉันมองข้ามจุดนำเข้าและจุดหนึ่งในการกำหนดค่าหรือในการตั้งค่าการทดสอบของฉันหรือไม่? มีทางเลือกอื่นสำหรับการสร้างระบบไฟร์วอลล์โดยเฉพาะอย่างยิ่งในระบบ smp หรือไม่?


เป็นไปได้หรือไม่ที่คุณเพิ่งอิ่มตัวเครือข่าย นั่นจะอธิบายบางส่วนของการสูญหายของแพ็คเก็ต
เพรสตัน

ฉันไม่คิดอย่างนั้นเนื่องจากเครือข่ายอยู่ที่ 1Gb / s แต่ละตัวเชื่อมต่อผ่านสวิตช์ hp 2848 การควบคุมการไหลและการโหลดสูงและการแคชเส้นทางมากเกินไปบน t3 บ่งบอกว่าตัวเอง t3 เป็นจุดอ่อน
ทิม

คำตอบ:


1

ฉันจะย้ายไปยังเคอร์เนล> = 3.6 ซึ่งไม่มีแคชเส้นทาง ที่ควรแก้ปัญหาของคุณเป็นส่วนหนึ่ง


0

การตั้งค่าการบันทึกของคุณบน T3 เป็นอย่างไร หากแพ็กเก็ตที่ถูกดร็อปถูกบันทึกล็อก I / O ดิสก์อาจเป็นสาเหตุ

เนื่องจากนี่คือสภาพแวดล้อมการทดสอบคุณสามารถลองทดสอบโดยปิดการบันทึก T3

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.