Linux iptables / masalah kinerja conntrack

9

Saya memiliki tes-pengaturan di lab dengan 4 mesin:

2 mesin P4 lama (t1, t2)
1 Xeon 5420 DP 2.5 GHz 8 GB RAM (t3) Intel e1000
1 Xeon 5420 DP 2.5 GHz 8 GB RAM (t4) Intel e1000

untuk menguji kinerja firewall linux sejak kami digigit oleh sejumlah serangan syn-banjir dalam beberapa bulan terakhir. Semua mesin menjalankan Ubuntu 12.04 64bit. t1, t2, t3 saling terhubung melalui sakelar 1GB / s, t4 terhubung ke t3 melalui antarmuka tambahan. Jadi t3 mensimulasikan firewall, t4 adalah targetnya, t1, t2 memainkan penyerang menghasilkan packetstorm melalui thorugh (192.168.4.199 adalah t4):

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

t4 menjatuhkan semua paket yang masuk untuk menghindari kebingungan dengan gateway, masalah kinerja t4 dll. Saya menonton statistik paket di iptraf. Saya telah mengkonfigurasi firewall (t3) sebagai berikut:

stok 3.2.0-31-generik # 50-Ubuntu SMP kernel
rhash_entries = 33554432 sebagai parameter kernel

sysctl sebagai berikut:

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

(Saya telah men-tweak banyak untuk menjaga t3 berjalan ketika t1 + t2 mengirim paket sebanyak mungkin).

Hasil dari upaya ini agak aneh:

t1 + t2 berhasil mengirim masing-masing sekitar 200k paket / s. t4 dalam kasus terbaik melihat total 200k sehingga setengah dari paket hilang.
t3 hampir tidak dapat digunakan pada konsol meskipun paket mengalir melaluinya (jumlah soft-irqs tinggi)
kolektor sampah cache rute tidak dapat diprediksi dan dalam pengaturan default kewalahan oleh sangat sedikit paket (<50k paket / s)
mengaktifkan aturan iptables stateful membuat tingkat paket tiba di t4 turun menjadi sekitar 100 k paket / s, secara efektif kehilangan lebih dari 75% dari paket

Dan ini - ini adalah perhatian utama saya - dengan dua mesin P4 tua mengirimkan paket sebanyak mungkin - yang berarti hampir semua orang di internet harus mampu melakukan ini.

Jadi begini pertanyaan saya: Apakah saya mengabaikan beberapa poin importand di konfigurasi atau dalam pengaturan pengujian saya? Apakah ada alternatif untuk membangun sistem firewall terutama pada sistem smp?

linux firewall

— tim
sumber

Apakah mungkin Anda hanya menjenuhkan jaringan? Itu akan menjelaskan beberapa paket yang hilang.

— Preston

Saya tidak berpikir demikian karena jaringan pada 1Gb / s masing-masing terhubung melalui saklar 2848 hp, kontrol aliran aktif dan beban tinggi dan cache rute meluap pada t3 menunjukkan bahwa t3 sendiri adalah titik lemah.

— tim

1

Saya akan bermigrasi ke Kernel> = 3.6 yang tidak lagi memiliki cache routing. Itu harus menyelesaikan sebagian dari masalah Anda.

— BatchyX
sumber

0

Bagaimana pengaturan logging Anda di T3? Jika semua paket yang dijatuhkan dicatat, disk I / O mungkin penyebabnya.

Karena ini adalah lingkungan pengujian, Anda dapat mencoba tes dengan logging T3 dimatikan.

— John Siu
sumber