Tests de performances du pare-feu avec Xena VulcanBay

Dans ce cas de test concret, nous avons utilisé une baie Xena VulcanBay avec deux interfaces QSFP+ 2 Gbit/s pour tester les performances de pare-feu nouvelle génération. Plus précisément, nous nous sommes intéressés aux scénarios de test suivants :

• Débit pur
• Nombre élevé de connexions (charge de session)
• Utilisation de NAT
• Trafic réaliste
• Périodes de test plus longues au cours desquelles nous avons « poussé » de nouvelles règles de pare-feu pour détecter d'éventuelles violations de débit

Dans cet article, nous allons montrer comment nous avons utilisé Xena VulcanBay, y compris sa gestion, VulcanManager et un commutateur Cisco Nexus pour connecter les clusters de pare-feu. Nous détaillons nos scénarios de test et donnons quelques indications sur les obstacles potentiels.

Pour nos tests, nous disposions d'une baie Xena VulcanBay Vul-28PE-40G avec la version de firmware 3.6.0, des licences pour les deux interfaces 40 G et des 28 moteurs de paquets disponibles. VulcanManager fonctionnait avec la version 2.1.23.0. Comme nous n'utilisions qu'une seule baie VulcanBay (et non plusieurs sur les sites distribués), le seul utilisateur administrateur pouvait répartir équitablement les 28 moteurs de paquets sur ces deux ports.

 

Pour les tests avec un débit allant jusqu'à 80 G, deux modules QSFP+ (à gauche) ainsi que la répartition des moteurs de paquets sur ces ports (à droite) étaient suffisants.Câblage

Nous avons utilisé un seul commutateur Cisco Nexus, doté de suffisamment de modules QSFP+ et du débit correspondant, pour connecter le VulcanBay aux clusters de pare-feu correspondants. Comme nous avions connecté simultanément tous les clusters de pare-feu et le VulcanBay à ce commutateur, et que nous avions toujours utilisé les mêmes plages d'adresses IPv4/IPv6 pour les tests, nous avons pu choisir le fabricant de pare-feu à tester, en utilisant uniquement la fonction « arrêt/non-arrêt » des interfaces individuelles. L'ensemble du laboratoire était ainsi contrôlable à distance, ce qui était très pratique pour un télétravailleur. De plus, il était très facile de connecter le VulcanBay « à lui-même » afin d'obtenir des valeurs de référence pertinentes pour tous les tests. À cette fin, les deux interfaces 40 G du VulcanBay ont été temporairement configurées dans le même VLAN.

 

Avec deux lignes pour le client et deux pour le serveur, tous les clusters de pare-feu étaient connectés à un commutateur central. Le VulcanBay de Neox Networks.

Il existe des commutateurs avec des modules QSFP+, qui sont cependant conçus comme 4x 10 G et *pas* comme 1x 40 G. Pour la connexion du VulcanBay avec ses interfaces 40 G, ce dernier est inévitable.

 

Grâce aux emplacements QSFP+ modernes avec interfaces 40 G, un débit duplex de 80 Gbit/s peut être atteint avec seulement deux connexions.Sous-réseaux IP

Dans notre cas, nous souhaitions tester différents pare-feu en mode couche 3. Afin d'intégrer ce routage « périphérique testé » (DUT), nous avons créé des sous-réseaux appropriés, aussi bien pour le protocole IPv4 obsolète que pour IPv6. Les sous-réseaux IP simulés par VulcanBay sont ensuite directement connectés au pare-feu. Dans le cas d'un sous-réseau IPv4 /16, network, exactement ceci /16 network Il doit également être configuré au niveau du pare-feu. La passerelle par défaut est particulièrement importante, par exemple 10.0.0.1 pour le client IPv4. networkSi vous activez également l'option « Utiliser ARP » (à droite), vous n'aurez pas à vous soucier des adresses MAC affichées. VulcanBay s'en charge automatiquement.

 

La plage d'adresses doit être ajustée afin que les tests effectués ne soient pas équivalents à une inondation MAC.

Il en va de même pour IPv6. Ici, le network L'adresse IP n'est pas saisie au format habituel avec barres obliques ; seules la passerelle et la plage d'adresses sont déterminées. Grâce à l'option « Utiliser NDP », VulcanBay résout automatiquement l'adresse MAC de couche 2 en adresse IPv6 de couche 3.

 

« Utiliser la passerelle » indique à VulcanBay qu’un routeur/pare-feu intermédiaire doit être utilisé pour les tests.

Inondation MAC ! Selon les scénarios de test utilisés, VulcanBay peut simuler des millions d'adresses IPv4/IPv6 sur le segment client ou serveur. Il s'agit d'une véritable inondation d'adresses MAC pour chaque commutateur ou pare-feu intermédiaire. Les pondérations haut de gamme courantes peuvent contenir jusqu'à 128 16 adresses MAC dans leur table d'adresses MAC. Si vous conservez la plage par défaut de 4 millions (!) d'adresses IPv1.8, ou 10 x 19^6 adresses IPv65 définies par défaut par Xena Networks, les résultats des tests sont insignifiants. Par conséquent, nous recommandons fortement de réduire les plages d'adresses dès le départ à des valeurs réalistes, comme le montre la capture d'écran ci-dessus (marquage jaune : XNUMX XNUMX adresses).

Pour les valeurs de référence, le VulcanBay était également « connecté à lui-même » pour tous les tests. Bien que l'IPv4 ait permis d'utiliser les mêmes « sous-réseaux », networkAvec des plages d'adresses différentes, IPv6 exigeait des sous-réseaux au sein du *même* préfixe /64.Cas de test

1) Débit pur : Dans le premier scénario de test, nous nous sommes uniquement intéressés au débit des pare-feu. Nous avons choisi le scénario « Modèle », une fois pour IPv4 et une fois pour IPv6, qui définit automatiquement le ratio à 50-50. Dans les paramètres, nous avons également sélectionné « Bidirectionnel » pour transmettre les données dans les deux sens, c'est-à-dire en duplex, dans les deux cas. Nous avons ainsi pu atteindre le débit maximal de 80 G avec les deux interfaces 2 G. Afin de répartir la bande passante sur plusieurs sessions (ce qui est le cas de test le plus réaliste en réalité), nous avons sélectionné 40 1000 utilisateurs, qui devaient établir des connexions depuis 100 ports sources vers 10 serveurs chacun. Cela représente 1 million de sessions pour IPv4 et IPv6. Avec un temps de montée en puissance de 5 secondes, soit une augmentation progressive des connexions au lieu d'une charge maximale immédiate, le test pur a duré 120 secondes, avant d'être également soumis à un temps de descente en puissance de 5 secondes.

 

Scénario de test « Modèle » avec une répartition 50/50 d'IPv4 et d'IPv6. Le « Profil de charge » (à droite) montre les utilisateurs à simuler sur l'axe temporel.

Pendant le test, VulcanManager affiche déjà des données utiles, telles que les connexions TCP ou le débit de la couche 1. Les graphiques de la partie supérieure permettent d'avoir une bonne idée du résultat. La capture d'écran suivante montre que le nombre de connexions actives est inférieur à la moitié du nombre prévu (mauvais), tandis que le débit des couches 5 à 7 présente une anomalie peu visible au début du test. Ces deux problèmes se sont avérés être des erreurs dans l'implémentation IPv6 de l'appareil testé.

 

Alors que théoriquement 2 millions de sessions à un débit de 80 G auraient dû passer le pare-feu, moins de la moitié d'entre elles l'ont fait sans problème.

Le graphique « Sessions actives » ne montre pas les sessions actives réelles, mais le nombre d'utilisateurs simulés dans la vue en direct pendant le test, ainsi que dans le rapport PDF ultérieur. Bien que le graphique soit correct pour les 2000 2 utilisateurs, il y a en réalité eu XNUMX millions de sessions pendant le test.

2) Nombre élevé de connexions (charge de session) : Pour IPv4 et IPv6 également, 20 millions de sessions TCP parallèles ont été établies et maintenues au cours de ce test. Non seulement la somme des sessions était pertinente, mais aussi le court temps de démarrage de seulement 30 secondes, ce qui correspondait à un taux d'établissement de 667,000 60 connexions par seconde ! Les sessions ont été laissées en attente pendant 30 secondes, mais sans transfert de données. Au bout de XNUMX secondes supplémentaires, elles ont été interrompues, comme c'est généralement le cas pour TCP via FIN-ACK. L'objectif était que les pare-feu testés puissent, d'une part, laisser passer les connexions correctement et, d'autre part, les démanteler correctement (et ainsi libérer leur mémoire).

Avant chaque test, nous avons supprimé la table d'adresses MAC du commutateur, ainsi que les caches de session, ARP et NDP des pare-feu. Chaque test a donc été effectué de zéro à zéro.

3) Scénarios NAT : Le même test qu’au point 1) a été utilisé, à la seule différence que les connexions IPv4 provenaient du client. network au serveur network Un NAT source a été configuré sur les pare-feu. L'objectif était de déterminer si cela entraînerait une dégradation des performances des pare-feu.

4) Trafic réaliste : Grâce à un « Datacenter Mix » prédéfini, nous avons pu simuler le flux de deux connexions HTTPS, SMB2, LDAP et AFS (via UDP et TCP) pour plusieurs milliers d'utilisateurs en quelques clics. Il ne s'agissait pas d'un test de charge complet des pare-feu, mais de la vitesse d'installation et de désinstallation, ainsi que de la détection des applications. Selon que les identifiants d'application des pare-feu étaient activés ou désactivés, des différences importantes ont été constatées.

5) 10 minutes de fonctionnement continu avec commits : Ce test, plus spécifique, comprenait les scénarios 1 et 4, à savoir une charge complète (1) avec configuration et arrêt simultanés constants de sessions (4). Ce test a duré 10 minutes en continu, tandis que nous installions 500 règles supplémentaires sur chaque pare-feu. Nous souhaitions déterminer si ce processus créait une baisse mesurable du débit sur les pare-feu, ce qui était en partie le cas.Résultats de test

À la fin de chaque test, VulcanManager affiche la page Statistiques et Rapports avec tous les détails possibles. « Créer un rapport » permet de créer un PDF contenant, outre tous les détails, des informations sur le scénario de test sélectionné et sur l'appareil testé. La difficulté consiste à distinguer les chiffres pertinents des moins pertinents et à les replacer dans le contexte approprié pour obtenir des résultats significatifs. Lors de nos comparaisons de différents pare-feu nouvelle génération, nous nous sommes limités au « débit constant de couche 1 (bit/s) » pour le test de débit, ou aux « Connexions TCP réussies » pour le test de connexion. Comparés aux valeurs de référence auxquelles le VulcanBay était connecté à lui-même, nous avons obtenu des résultats comparables significatifs, facilement visualisables sous forme de tableau et de graphique.

 

La page Statistiques et rapports fournit un aperçu approximatif (au milieu) et la possibilité de lire les valeurs de test de toutes les couches OSI et des scénarios de test sélectionnés (liens, onglets dépliants).

 

Détail d'un rapport PDF avec tous les détails.

Les différents scénarios « Application Mix » existants de Xena Networks ne permettent pas une comparaison directe des performances des pare-feu, mais plutôt la génération ciblée de network Le trafic. De cette façon, les détections d'applications peuvent être vérifiées ou d'autres scénarios exécutés en parallèle peuvent être un peu plus « sollicités ».Autres fonctionnalités

Notez que VulcanManager possède d'autres fonctionnalités intéressantes que nous n'avons pas utilisées dans cette étude de cas, telles que le trafic TLS (pour tester l'interception TLS) et la relecture de paquets (pour tester des scénarios personnalisés et plus spécifiques extraits des PCAP téléchargés). De plus, nous n'avons pas utilisé beaucoup de scénarios de test orientés applications ou protocoles tels que Dropbox, eBay, LinkedIn ou HTTPS, IMAP et NFS. Cela est dû à nos objectifs de test, qui étaient fortement axés sur le débit pur et le nombre de sessions.Conclusion

Le VulcanBay de XENA Networks est l'appareil de test idéal pour comparer différents pare-feu de nouvelle génération. En très peu de temps, nous avons configuré et testé différents scénarios de test. La multitude de résultats était initialement impressionnante. L'astuce consistait à se concentrer sur les informations pertinentes.