Testez les performances du Sophos Firewall avec iPerf

iPerf est un bon outil si vous souhaitez mesurer les performances d’un itinéraire réseau spécifique. Pour un Sophos Firewall, par exemple, cela s’applique aux tests entre deux réseaux internes, sur une connexion de site à site VPN, sur Remote Access VPN ou entre un client derrière le pare-feu et un serveur sur Internet.

Un test iPerf ne remplace pas un test d’application normal ou un pur test de vitesse WAN directement sur le pare-feu. Il répond à une autre question : quel débit TCP ou UDP cette route atteint-elle entre deux points de terminaison définis dans les conditions de test sélectionnées ?

Domaine d’application et modèle de mesure

iPerf est utile si vous souhaitez mesurer une distance spécifique de manière reproductible. Avant d’exécuter des commandes, il convient de préciser clairement ce qui est mesuré et ce à quoi le test ne répond délibérément pas.

Quand iPerf a du sens

iPerf est particulièrement utile lorsqu’une déclaration de performance doit être reproductible :

après une migration de pare-feu ou un changement de modèle
avant et après les modifications des règles de pare-feu, IPS, TLS Inspection ou mise en forme du trafic
pour les connexions lentes entre les VLAN ou les emplacements
pour les problèmes de performances de VPN via IPsec, SSL VPN ou Sophos Connect
pour les sujets UDP tels que la voix, les flux de conférence ou certaines applications industrielles
pour différencier pare-feu, WAN, WLAN, client, serveur et application

Pour un test Internet pur du point de vue du pare-feu, l’article Internet Speedtest via la CLI Sophos Firewall est plus approprié. Sophos Firewall Vérifier les mesures de performances convient également pour classer l’utilisation du pare-feu.

Ce que iPerf mesure

iPerf établit une connexion de test entre un serveur et un client. La valeur mesurée s’applique donc exactement à ce chemin, cette direction, ce port, ce protocole et ces points finaux.

L’interprétation correcte est importante :

TCP affiche le débit réalisable avec le contrôle de la congestion, les retransmissions et la taille des fenêtres.
UDP affiche la perte de paquets et la gigue, mais nécessite une bande passante cible définie.
Un seul test ne constitue pas une déclaration fiable de capacité.
Le WiFi, le client CPU, les machines virtuelles, les adaptateurs réseau USB et les fonctions d’économie d’énergie peuvent limiter la mesure.
Les fonctions de sécurité du Sophos Firewall n’affectent le résultat que si la connexion test s’exécute via une règle et une politique appropriées.

Planifier la configuration des tests

Avant la première commande, il doit être clair quelle route est vérifiée :

Où se trouve le serveur iPerf ?
Où se trouve le client iPerf ?
Dans quelle direction le test doit-il être effectué ?
Quelle règle de pare-feu s’applique à cette connexion ?
Y a-t-il NAT, VPN, Traffic Shaping, IPS ou TLS Inspection sur le chemin ?
Le test s’effectue-t-il via câble ou WLAN ?
Devez-vous vérifier le débit de TCP, la perte de UDP ou les deux ?

Pour les tests derrière un Sophos Firewall, une structure propre est généralement plus importante que la valeur maximale individuelle. Un client sur WiFi, un hyperviseur surchargé ou un serveur Public-iPerf lent peuvent imiter un faux problème de pare-feu.

Installer iPerf

iPerf est disponible pour Windows, macOS, Linux, Android et iOS. Une source de téléchargement bien connue est iPerf.fr.

Outil de test de vitesse iPerf3 sous Windows — iPerf3 sous Windows

Pour des mesures productives, iPerf3 est le choix habituel. Si possible, le serveur et le client doivent utiliser la même version majeure.

Exécuter iPerf

Si la configuration du test est claire, vous démarrez d’abord le serveur, puis effectuez des tests clients ciblés. TCP, UDP, flux en sens inverse et flux parallèles répondent à des questions différentes et ne doivent donc pas être mélangés.

Démarrez le serveur iPerf

Sur le système cible, iPerf est démarré en mode serveur :

iperf3 -s

Par défaut, iPerf3 écoute sur le port TCP 5201. Si un port différent doit être utilisé, il est spécifié de la même manière sur le serveur et le client :

iperf3 -s -p 5200

Attention : Sous Windows, macOS ou Linux, le pare-feu de l’hôte local peut bloquer le port iPerf. Si le client ne peut pas atteindre le serveur, le pare-feu local sur le serveur iPerf doit être vérifié en premier.

Démarrer le test TCP

Sur le client, le serveur est adressé avec son adresse IP :

iperf3 -c 10.10.10.50

Pour des résultats plus stables, un test plus long est judicieux :

iperf3 -c 10.10.10.50 -t 30

Test de vitesse iPerf des performances du TCP

Si un Sophos Firewall se trouve entre le client et le serveur, la règle de pare-feu adaptée doit autoriser le trafic. Si l’attribution de la règle n’est pas claire, tester les règles Sophos Firewall de manière ciblée aide. En cas de problèmes de connexion, Packet Capture sur Sophos Firewall et les journaux de service Sophos Firewall sont les étapes suivantes.

Vérifiez spécifiquement la direction

Les problèmes de performances ne surviennent souvent que dans un seul sens. iPerf3 peut inverser le flux de données sans permuter le serveur et le client :

iperf3 -c 10.10.10.50 -t 30 -R

Ceci est particulièrement utile pour les routes VPN, le routage asymétrique, les problèmes de téléchargement ou les lignes WAN avec une bande passante descendante et montante différente.

Effectuer le test UDP

UDP doit toujours être testé avec une bande passante cible raisonnable. Sans une bande passante cible appropriée, le test ne mesure pas la charge réelle attendue.

iperf3 -c 10.10.10.50 -u -b 100M -t 30

Pour une route de 1 Gbit, une valeur cible plus élevée peut être logique :

iperf3 -c 10.10.10.50 -u -b 1G -t 30

Ces valeurs sont particulièrement importantes pour UDP :

Datagrammes perdus/total : Perte de paquets
Gigue : Variation du temps de transit des paquets
Débit : bande passante effective envoyée ou reçue

Un test UDP avec une bande passante cible trop élevée crée intentionnellement une surcharge. Cela peut être utile pour les tests de limites, mais ne doit pas être interprété à tort comme un test de ligne normal.

Utiliser plusieurs flux

Un seul flux TCP peut être limité par la latence, la taille de la fenêtre TCP ou les performances du client. Vous pouvez utiliser plusieurs flux parallèles pour les tests de capacité :

iperf3 -c 10.10.10.50 -t 30 -P 4

Le résultat montre une plus grande partie de la capacité totale utilisable de l’itinéraire. Pour une seule application, un test à flux unique est souvent plus significatif.

Utiliser le serveur public-iPerf

Un serveur public iPerf peut être utilisé pour des comparaisons approximatives sur Internet. Cependant, les serveurs publics ne peuvent pas être contrôlés : l’utilisation, les limitations, l’accessibilité et la distance peuvent varier considérablement. Un aperçu bien entretenu peut être trouvé, par exemple, dans la liste des Serveurs publics iPerf sur GitHub.

Lorsqu’il s’agit de savoir si le pare-feu local, le VPN ou une politique spécifique le ralentit, un serveur iPerf distinct de l’autre côté est généralement beaucoup plus fiable.

Mesure et évaluation comparatives

Une seule valeur iPerf est assez rare. Le test n’a de sens que lorsque la direction, les paramètres, la règle de pare-feu et la durée de la mesure sont documentés et répétés ultérieurement dans les mêmes conditions.

Planifier les mesures de référence et de comparaison

iPerf est particulièrement utile lorsque des mesures comparables sont effectuées avant et après un changement. Un seul test après une réclamation ne montre que l’état actuel. Il n’est pas encore indiqué si l’itinéraire était déjà lent au préalable ou si une nouvelle règle de pare-feu, un profil IPS, TLS Inspection, une régulation du trafic, un paramètre VPN ou un problème de fournisseur ont déclenché le changement.

Pour des comparaisons fiables, ces conditions de test doivent être enregistrées :

Date et heure : Les sauvegardes, les mises à jour, les rapports ou la charge du fournisseur peuvent fausser les résultats.
Source et destination : D’autres clients, serveurs ou VLAN génèrent d’autres chemins.
Direction : Téléchargement, Téléchargement et -R peuvent afficher des valeurs très différentes.
Protocole et paramètres : TCP, UDP, les flux, la durée et la bande passante cible doivent rester comparables.
Règle de pare-feu applicable : Les profils de sécurité, la journalisation, NAT et la mise en forme du trafic dépendent de la politique.
Chemin VPN ou WAN : L’état SD-WAN, Route Precedence, Gateway et le type de tunnel affectent l’itinéraire.
Environnement : Le câble, le WLAN, l’hyperviseur, la charge CPU et le trafic parallèle doivent être classifiés.

Si des changements sont prévus, un processus simple s’impose :

Effectuez un test de référence avant d’apporter des modifications.
Documentez la règle de pare-feu, la politique, le chemin VPN et les paramètres de mesure.
Effectuez exactement une modification.
Exécutez à nouveau le même test.
S’il y a des écarts, vérifiez Log Viewer, Packet Capture, l’erreur d’interface et la charge du système.
Ensuite seulement, testez la modification suivante.

Surtout avec VPN et les tests de localisation, cette procédure évite la confusion de plusieurs causes. Si MTU, IPS, SD-WAN, les règles de pare-feu et les profils client sont ajustés en même temps, il est difficile d’attribuer une meilleure valeur iPerf ultérieurement.

Évaluer les résultats

Lors de l’évaluation, il ne faut pas seulement prêter attention au nombre Mbit/s le plus élevé.

Observations typiques :

Faible débit TCP avec de nombreuses retransmissions : cela indique une perte de paquets, un problème duplex/lien, la qualité WAN ou un sujet MTU/MSS.
Bon téléchargement, mauvais téléchargement : Une ligne asymétrique, un routage, une mise en forme du fournisseur ou une direction VPN sont possibles.
Perte de paquets UDP même sous une charge modérée : Les causes courantes sont une surcharge, une mauvaise qualité WAN, une mise en forme incorrecte ou un WLAN.
Valeurs très fluctuantes : Vérifiez la charge parallèle, le WLAN, la limite CPU ou l’environnement virtuel.
Seuls les serveurs publics sont lents : Le serveur externe ou le peering est alors affecté, pas automatiquement le pare-feu local.

Pendant le test, la RAM, la charge de l’interface, la charge IPS et les règles concernées doivent être vérifiées sur le Sophos Firewall CPU. Les valeurs peuvent être mieux classées à l’aide des mesures de performances et des journaux en direct.

Erreurs et liste de contrôle

De nombreuses fausses conclusions découlent du fait que le chemin de test n’est pas clairement défini ou que les serveurs publics, le WLAN, les pare-feu de l’hôte local et la direction VPN ne sont pas pris en compte.

Erreurs courantes

Le port iPerf est bloqué sur le serveur par le pare-feu local de l’hôte.
La mauvaise direction est testée.
Un client WLAN est utilisé pour une déclaration de performances du pare-feu.
UDP est testé sans bande passante cible appropriée ou avec une bande passante cible irréaliste.
Un serveur public iPerf est utilisé comme seule preuve de ses performances Internet.
Le flux unique TCP et plusieurs flux parallèles TCP sont mélangés.
La règle Sophos Firewall applicable n’est pas cochée.
Les tests VPN sont évalués sans examiner MTU, MSS, le CPU et le site distant.

Courte liste de contrôle

Définir l’itinéraire et la direction du test.
Démarrez le serveur iPerf sur un point de terminaison approprié.
Vérifiez le pare-feu de l’hôte local sur le serveur iPerf.
Identifiez la règle Sophos Firewall appropriée.
Exécutez le test TCP pendant au moins 30 secondes.
Si nécessaire, testez dans le sens opposé avec -R.
Testez UDP uniquement avec une bande passante cible réaliste.
Vérifiez les métriques du pare-feu, les journaux et Packet Capture en parallèle.
Répétez le test après les modifications et documentez les résultats.
Utilisez les mêmes paramètres, direction et chemin lors de la réalisation de mesures de comparaison.

FAQ

iPerf mesure-t-il la vitesse Internet de Sophos Firewall ?

iPerf mesure le débit entre deux points de terminaison définis. Pour un test WAN directement sur le pare-feu, un test de vitesse du pare-feu distinct utilisant SSH est plus approprié. Pour VPN, les VLAN, les connexions de site ou les routes client à serveur, iPerf est souvent plus informatif.

Devez-vous utiliser un serveur public iPerf ?

Les serveurs publics iPerf ne conviennent qu’à des comparaisons approximatives. Pour un pare-feu fiable, VPN ou des tests de localisation, il est préférable d’avoir votre propre serveur iPerf de l’autre côté, car la charge, la distance, le peering et les limites du serveur public peuvent autrement fausser le résultat.

Pourquoi les résultats TCP et UDP sont-ils différents ?

TCP répond à la perte de paquets, à la latence et aux retransmissions avec un contrôle de congestion. UDP envoie avec une bande passante cible spécifiée et affiche principalement la perte, la gigue et le débit binaire atteint. Les deux tests répondent à des questions différentes et ne doivent pas être directement assimilés.

Pourquoi devriez-vous tester la direction opposée avec -R ?

De nombreux problèmes de performances ne surviennent que dans un seul sens. -R inverse le sens des données sans permuter le serveur et le client. Cela aide avec les lignes asymétriques, les chemins de retour VPN, les chemins SD-WAN ou les problèmes de téléchargement.

Un test iPerf lent prouve-t-il un problème de pare-feu ?

Non. Un test iPerf lent montre initialement uniquement que cet itinéraire spécifique est lent dans les conditions sélectionnées. Après cela, la règle de pare-feu, NAT, le chemin VPN, MTU/MSS, la qualité WAN, le client, le serveur, le WLAN et la charge parallèle doivent être vérifiés séparément.