Xena VulcanBay ile Güvenlik Duvarı Performans Testi

Bu somut test durumunda, performansları açısından bazı yeni nesil güvenlik duvarlarını test etmek için 2x 40 Gbps QSFP+ arayüzlü bir Xena VulcanBay kullandık. Özellikle, aşağıdaki test senaryolarıyla ilgilendik:

• Saf verim
• Yüksek bağlantı sayısı (oturum yükü)
• NAT Kullanımı
• Gerçekçi trafik
• Potansiyel verim ihlallerini tespit etmek için yeni güvenlik duvarı kurallarını "zorladığımız" daha uzun test süreleri

Bu makalede, Xena VulcanBay'i, yönetimini, VulcanManager'ı ve bir Cisco Nexus Switch'i güvenlik duvarı kümelerini bağlamak için nasıl kullandığımızı göstermek istiyoruz. Test senaryolarımızı listeliyoruz ve olası tökezleme blokları hakkında bazı ipuçları veriyoruz.

Testlerimiz için 28 firmware sürümüne sahip bir Xena VulcanBay Vul-40PE-3.6.0G'miz vardı, hem 40 G arayüzleri hem de tam 28 Paket Motoru için lisanslar mevcuttu. VulcanManager 2.1.23.0 sürümünde çalışıyordu. Sadece tek bir VulcanBay kullandığımızdan (ve dağıtılmış konumlarda birkaç tane kullanmadığımızdan), tek yönetici kullanıcı tam 28 Paket Motorunu bu iki portta eşit şekilde dağıtabildi.

 

80 G veri hacmine kadar olan testler için iki adet QSFP+ modülü (sol) ve bu portlara paket motorlarının dağıtımı (sağ) yeterli oldu.Kablolama

VulcanBay'i ilgili güvenlik duvarı kümelerine bağlamak için yeterli QSFP+ modülü ve karşılık gelen verime sahip tek bir Cisco Nexus anahtarı kullandık. Tüm güvenlik duvarı kümelerini ve VulcanBay'i aynı anda bu anahtara bağladığımız ve testler için her zaman aynı IPv4/IPv6 adres aralıklarını kullandığımız için, yalnızca bireysel arayüzlerin "kapatma/kapatmama" özelliğiyle hangi güvenlik duvarı üreticisini test etmek istediğimize karar verebildik. Böylece tüm laboratuvar uzaktan kontrol edilebiliyordu. Tipik bir ev ofisi çalışanı için oldukça pratikti. Dahası, tüm testler için anlamlı referans değerleri elde etmek amacıyla VulcanBay'i "kendisine" bağlamak çok kolaydı. Bu amaçla, VulcanBay'e giden her iki 40 G arayüzü de geçici olarak aynı VLAN'da yapılandırıldı.

 

İstemci ve sunucu için ikişer hat olmak üzere toplam dört hat ile tüm güvenlik duvarı kümeleri merkezi bir anahtara bağlandı. Ayrıca VulcanBay de bu bağlantıya dahildi. Neox Networks.

QSFP+ modüllü anahtarlar da vardır, ancak bunlar 4x 10 G olarak tasarlanmıştır ve 1x 40 G olarak *değildir*. VulcanBay'in 40 G arayüzleriyle bağlantısı için ikincisi kaçınılmazdır.

 

40 G arayüzlü modern QSFP+ slotları sayesinde sadece iki bağlantıyla 80 Gbit/sn'lik dupleks veri akışı sağlanabiliyor.IP Alt Ağları

Bizim durumumuzda, Katman 3 modunda farklı güvenlik duvarlarını test etmek istedik. Bu "Test Edilen Cihaz" (DUT) yönlendirmesini entegre etmek için, hem eski IPv4 protokolü hem de IPv6 için uygun alt ağlar oluşturduk. VulcanBay tarafından simüle edilen IP alt ağları daha sonra doğrudan güvenlik duvarına bağlanır. /16 IPv4 durumunda networktam olarak bu /16 network Güvenlik duvarında da yapılandırma yapılması gerekir. Özellikle varsayılan ağ geçidi önemlidir, örneğin istemci IPv4 için 10.0.0.1. networkEğer ayrıca "ARP Kullan" seçeneğini (sağ tarafta) kullanırsanız, görüntülenen MAC adresleri konusunda endişelenmenize gerek kalmaz. VulcanBay bunları kendisi çözümler.

 

Yapılan testlerin MAC flood'una eşdeğer olmaması için adres aralığının ayarlanması gerekmektedir.

Aynı durum IPv6 için de geçerlidir. Burada network MAC adresi, alışılagelmiş eğik çizgi gösterimiyle girilmez; bunun yerine yalnızca ağ geçidi ve adres aralığı belirlenir. "NDP Kullan" seçeneği aracılığıyla VulcanBay, Katman 2 MAC adresini otomatik olarak Katman 3 IPv6 adresine çözümler.

 

“Ağ Geçidi Kullan” seçeneği VulcanBay’e testler için ara bir yönlendirici/güvenlik duvarı kullanılması gerektiğini söyler.

MAC Flooding! Kullanılan test senaryolarına bağlı olarak, VulcanBay istemci veya sunucu segmentinde milyonlarca IPv4/IPv6 adresini simüle edebilir. Bu, her ara anahtar veya güvenlik duvarı için saf bir MAC adresi selidir. Yaygın üst düzey ağırlıklar, MAC adres tablolarında maksimum 128 k MAC adresi tutabilir. Varsayılan olarak Xena Networks tarafından ayarlanan 16 milyon (!) IPv4 adresi veya 1.8 x 10^19 IPv6 adresi aralığını bırakırsanız, herhangi bir test sonucu anlamsız olur. Bu nedenle, yukarıdaki ekran görüntüsünde görebileceğiniz gibi (sarı işaretli: 65 k adres) adres aralıklarını baştan itibaren gerçekçi değerlere düşürmenizi kesinlikle öneririz.

Referans değerleri için, VulcanBay tüm testler boyunca "kendisine bağlı" olarak tutuldu. IPv4 aynı "alt ağların" kullanılmasına izin verirken, networkFarklı adres aralıklarına sahip olan IPv6, aynı /64 öneki içinde alt ağlar gerektiriyordu.Test durumları

1) Saf verim: İlk test senaryosunda, sadece güvenlik duvarlarının verimiyle ilgileniyorduk. Bunun için, bir kez IPv4 ve bir kez IPv6 için, oranı otomatik olarak 50-50 olarak ayarlayan "Desen" senaryosunu seçtik. Ayarlarda ayrıca, her iki durumda da verileri her iki yönde, yani dupleks olarak iletmek için "Çift yönlü" seçeneğini seçtik. Böylece 80x 2 G arayüzle 40 G'lik maksimum verime ulaşabildik. Bant genişliğini birkaç oturuma dağıtmak için (gerçek hayatta daha gerçekçi test durumu budur), her biri 1000 sunucuya 100 kaynak portundan bağlantı kurması gereken 10 kullanıcı seçtik. IPv1 ve IPv4 için her biri 6 milyon oturum oluşturur. 5 saniyelik bir artış süresiyle, yani anında tam yük yerine bağlantıların düzgün bir şekilde artmasıyla, saf test 120 saniyelik bir düşüş süresine sahip olmadan önce 5 saniye sonra çalıştı.

 

IPv50 ve IPv50'nın 4-6 dağılımına sahip "Desen" test senaryosu. "Yük Profili" (sağda) zaman ekseni kullanılarak simüle edilecek kullanıcıları gösterir.

Test sırasında, VulcanManager TCP Bağlantıları veya Katman 1 verimi gibi bazı yararlı verileri zaten görüntüler. Üst alandaki grafikler aracılığıyla, kişi ilk bakışta iyi bir izlenim edinir. Aşağıdaki ekran görüntüsünde, aktif bağlantı sayısının planlananın yarısından az olduğunu (kötü) görebilirsiniz, Katman 5-7 İyi Verimi ise testin başında çekici olmayan bir bükülmeye sahiptir. Her iki sorunun da test edilen cihazın IPv6 uygulamasındaki hatalar olduğu ortaya çıktı.

 

Teorik olarak 2 G veri hacminde 80 milyon oturumun güvenlik duvarını geçmesi gerekirken, bunların yarısından azı temiz bir şekilde geçebildi.

"Aktif Oturumlar" grafiği gerçek aktif oturumları değil, test sırasında Canlı Görünüm'de ve daha sonraki PDF raporunda simüle edilen kullanıcı sayısını gösterir. Grafik 2000 kullanıcı için doğru olsa da, test sırasında gerçekte 2 milyon oturum vardı.

2) Yüksek bağlantı sayısı (oturum yükü): IPv4 ve IPv6 için de bu test sırasında 20 milyon paralel TCP oturumu kuruldu ve sürdürüldü. Sadece oturumların toplamı değil, aynı zamanda saniyede 30 bağlantılık bir kurulum oranına karşılık gelen sadece 667,000 saniyelik kısa rampa süresi de önemliydi! Oturumlar 60 saniye boyunca bekletildi, ancak herhangi bir veri aktarılmadı. 30 saniye daha sonra tekrar sonlandırıldılar, bu da FIN-ACK aracılığıyla TCP için tipiktir. Amaç, test edilecek güvenlik duvarlarının öncelikle bağlantıların temiz bir şekilde geçmesine izin vermesi ve ikinci olarak da bunları temiz bir şekilde sökebilmesiydi (ve böylece belleklerini boşaltabilmeleriydi).

Her testten önce switch üzerindeki MAC adres tablosunu ve güvenlik duvarlarındaki session, ARP ve NDP önbelleklerini sildik. Yani her test sıfırdan sıfıra yapıldı.

3) NAT senaryoları: 1) maddesindekiyle aynı test kullanıldı, tek fark istemciden gelen IPv4 bağlantılarının farklı olmasıydı. network sunucuya network Güvenlik duvarlarına kaynak NAT özelliği eklendi. Amaç, bunun güvenlik duvarlarının performansında bir düşüşe neden olup olmayacağını belirlemekti.

4) Gerçekçi Trafik: Önceden tanımlanmış bir "Veri Merkezi Karışımı" ile birkaç tıklamayla birkaç bin kullanıcı için iki HTTPS, SMB2, LDAP ve AFS (UDP ve TCP üzerinden) bağlantısının akışını simüle edebildik. Bu, güvenlik duvarlarının tam yük testiyle ilgili değildi, kurulum ve kaldırma hızları ve uygulama algılamalarıyla ilgiliydi. Güvenlik duvarlarının uygulama kimliklerinin etkinleştirilmesine veya devre dışı bırakılmasına bağlı olarak burada büyük farklılıklar vardı.

5) 10 dakikalık sürekli ateşleme ve commit'ler: Bu biraz daha spesifik test, senaryo 1 ve 4'ten oluşuyordu, yani aynı anda sürekli oturum kurulumu ve kapatma (1) ile tam yük (4). Bu, her bir güvenlik duvarına 10 kural daha yüklerken 500 dakika boyunca sürekli çalıştı. Burada, bu sürecin güvenlik duvarlarında ölçülebilir bir verim düşüklüğü yaratıp yaratmadığını bulmak istedik, ki bu kısmen böyleydi.Test sonuçları

Her testin sonunda, VulcanManager İstatistikler ve Raporlama sayfasını tüm olası ayrıntılarla görüntüler. "Rapor Oluştur" ile tüm ayrıntıların yanı sıra seçilen test senaryosu ve test edilen cihaz hakkında bilgi içeren bir PDF oluşturabilirsiniz. Zorluk, ilgili sayıları daha az ilgili olanlardan ayırmak ve anlamlı sonuçlar elde etmek için doğru bağlamda yerleştirmektir. Farklı Yeni Nesil Güvenlik Duvarlarını karşılaştırırken, kendimizi verim testi için "Katman 1 sabit verim (bps)" veya bağlantı testi için "Başarılı TCP Bağlantıları" ile sınırladık. VulcanBay'in kendisine bağlandığı referans değerleriyle karşılaştırıldığında, bu zaten hem tablo biçiminde hem de grafiksel olarak kolayca görüntülenebilen anlamlı karşılaştırılabilir sonuçlar verdi.

 

İstatistik ve Raporlama sayfası, genel bir bakış (ortada) ve tüm OSI katmanlarından ve seçili test senaryolarından (bağlantılar, açılır sekmeler) test değerlerini okuma olanağı sağlar.

 

Tüm detayların yer aldığı PDF raporunun detayı.

Xena Networks'ün mevcut çeşitli "Uygulama Karışımı" senaryoları, güvenlik duvarı performans değerlerinin doğrudan karşılaştırılmasına olanak sağlamaz, ancak hedeflenen üretim şu amaçlarla yapılır: network Bu sayede, uygulama tespitleri kontrol edilebilir veya paralel olarak yürütülen diğer senaryolar biraz daha "zorlanabilir".Diğer Özellikler

VulcanManager'ın bu vaka çalışmasında kullanmadığımız TLS Trafiği (TLS müdahalesini test etmek için) ve Paket Tekrarı (yüklenen PCAP'lerden çıkarılan özel ve daha spesifik senaryoları test etmek için) gibi bazı ilginç özelliklere sahip olduğunu unutmayın. Ayrıca Dropbox, eBay, LinkedIn veya HTTPS, IMAP, NFS gibi pek çok uygulama veya protokol odaklı test senaryosu kullanmadık. Bunun nedeni, saf verim ve oturum sayısına güçlü bir şekilde odaklanmış olan test amaçlarımızdır.Sonuç

XENA Networks'ün VulcanBay'i çeşitli yeni nesil güvenlik duvarlarını karşılaştırmak için ideal bir test cihazıdır. Çok kısa bir süre içinde çeşitli test senaryolarını yapılandırıp test ettik. Sadece test sonuçlarının bolluğu başlangıçta bunaltıcıydı. İşin püf noktası ilgili bilgilere konsantre olmaktı.