Tester les performances de Sophos Firewall avec iPerf3
iPerf3 mesure le débit TCP ou UDP entre deux points de terminaison définis. Il permet de vérifier si un chemin entre des VLAN, à travers un Sophos Firewall ou via un tunnel VPN est plus lent que prévu. Toutefois, une seule valeur élevée ou faible ne suffit pas à démontrer un problème de pare-feu.
Un test fiable nécessite d’abord une mesure de référence qui évite le chemin suspect. La même mesure est ensuite répétée à travers le pare-feu. Le sens, la durée, le protocole, les flux, la règle de pare-feu et les profils de sécurité doivent rester documentés. Dans le cas contraire, les résultats comparés ne sont pas techniquement équivalents.
⚠️ Planifier le test de charge : iPerf3 peut saturer entièrement une liaison. Les tests en production doivent être effectués pendant une fenêtre de maintenance ou volontairement limités à une valeur inférieure à la bande passante disponible. Ne laissez jamais le serveur accessible depuis Internet sans nécessité.
Ce que mesure iPerf3
iPerf3 se compose d’un serveur et d’un client. Par défaut, le client envoie les données de test au serveur. L’option -R inverse le sens. La valeur mesurée ne s’applique qu’à ces points de terminaison, à ce chemin et à ces paramètres précis.
Les trois principaux types de tests répondent à des questions différentes :
| Test | Interprétation |
|---|---|
| TCP, un flux | Débit d’une connexion individuelle classique, avec contrôle de congestion et retransmissions |
| TCP, plusieurs flux | Capacité totale exploitable lorsqu’un flux unique est limité par la latence ou les performances des points de terminaison |
| UDP avec débit cible | Perte, Jitter et Bitrate atteint sous une charge volontairement définie |
iPerf3 ne mesure pas les performances d’une application. SMB, RDP, VoIP ou une application web peuvent rester lents malgré de bonnes valeurs iPerf. À l’inverse, sur un chemin à forte latence, un seul flux TCP peut rester en dessous de la capacité disponible de la liaison alors que le pare-feu et le WAN fonctionnent correctement.
Pour un test Internet directement depuis l’appliance, l’article Test de débit Internet de Sophos Firewall via SSH est plus approprié. iPerf3 est plus pertinent lorsqu’il faut analyser deux points de terminaison contrôlés et le chemin qui les relie.
Planifier le chemin de test et la référence
Avant d’exécuter la première commande, définissez le client, le serveur et le chemin à vérifier. Une série de mesures pertinente comporte trois étapes :
- Référence des points de terminaison : testez le client et le serveur sur le même réseau local ou via un switch rapide connu. Si cette valeur est déjà mauvaise, examinez d’abord le client, le serveur, la carte réseau, le pare-feu de l’hôte, l’hyperviseur ou le WLAN.
- Chemin à travers le pare-feu : testez les mêmes points de terminaison via les VLAN ou zones prévus et la véritable règle Sophos Firewall.
- Chemin WAN ou VPN : répétez ensuite seulement le test via le fournisseur, le SD-WAN, le Site-to-Site VPN ou le Remote Access.
Les points de terminaison câblés fournissent une meilleure indication sur le pare-feu que les clients WLAN. Sur les deux systèmes, il faut connaître les fonctions d’économie d’énergie, la charge CPU, les cartes réseau virtuelles et le trafic parallèle. Le serveur et le client doivent, si possible, utiliser la même version majeure d’iPerf3 ; iPerf2 et iPerf3 ne sont pas compatibles.
Préparer la règle de pare-feu
iPerf3 utilise par défaut le port 5201. Un test TCP nécessite TCP 5201. Lors d’un test UDP, les données de test transitent via UDP 5201, mais la connexion de contrôle reste en TCP. Un groupe de services Sophos destiné aux tests UDP doit donc contenir TCP et UDP 5201.
La règle temporaire sous Rules and policies > Firewall rules doit autoriser uniquement l’adresse IP source précise, l’adresse IP de destination précise et le service iPerf. Activez Log firewall traffic et notez la Rule ID. Ne créez ni règle Any étendue ni accès depuis Internet uniquement pour démarrer le test plus rapidement.
Après l’enregistrement, vérifiez dans Log viewer que cette règle précise est appliquée. Si l’affectation reste incertaine, consultez Tester de manière ciblée les règles Sophos Firewall.
Installer iPerf3 et sécuriser le serveur
La documentation officielle du projet et les paquets sources sont disponibles sur le site ESnet iPerf3. ESnet indique Ubuntu Linux, FreeBSD et macOS comme plateformes officiellement prises en charge. En pratique, les paquets binaires pour Windows proviennent souvent de fournisseurs tiers ; iPerf.fr en propose une liste connue.
Sur le système cible, démarrez le serveur comme suit :
iperf3 -s
Il est plus sûr de lier le processus à l’adresse IP de test et de l’arrêter automatiquement après une connexion client :
iperf3 -s -B 10.10.10.50 -1
-B lie iPerf3 à l’adresse indiquée. -1 accepte au maximum une connexion client, puis arrête le serveur. La commande doit être relancée pour chaque nouveau test individuel. Si vous utilisez un autre port, indiquez-le de manière identique des deux côtés :
iperf3 -s -B 10.10.10.50 -p 5200 -1
Le pare-feu local de l’hôte peut également bloquer le port sur le serveur. Limitez aussi cette autorisation à la source de test et à la durée nécessaires.
Tester TCP dans les deux sens
Le premier test utilise un seul flux TCP et s’exécute pendant 30 secondes :
iperf3 -c 10.10.10.50 -t 30
Par défaut, le client envoie les données au serveur. Testez ensuite le sens inverse avec les mêmes points de terminaison :
iperf3 -c 10.10.10.50 -t 30 -R
Si les deux sens diffèrent fortement, une bande passante WAN asymétrique, le routage, le SD-WAN, des erreurs d’interface, les paramètres VPN ou un point de terminaison sont plus probables qu’une limitation générale du débit.
Après le test avec un flux unique, comparez si nécessaire le résultat avec quatre flux parallèles :
iperf3 -c 10.10.10.50 -t 30 -P 4
Si -P 4 est nettement plus rapide, un seul flux TCP peut être limité par la latence, la fenêtre TCP ou les performances du point de terminaison. Le résultat ne correspond pas automatiquement à la vitesse qu’une application individuelle peut atteindre. --bidir sollicite les deux sens simultanément et convient davantage à un test de charge ciblé qu’à une comparaison propre entre les sens.
Tester UDP de manière contrôlée
Un test UDP nécessite toujours un débit cible réaliste. Sans -b, iPerf3 utilise par défaut seulement 1 Mbit/s, ce qui ne permet pas d’évaluer une liaison à 100 Mbit/s ou Gigabit.
Exemple avec 100 Mbit/s :
iperf3 -c 10.10.10.50 -u -b 100M -t 30
Ne commencez pas immédiatement avec le débit théorique de la liaison. Testez d’abord, par exemple, 60 à 80 pour cent de la bande passante utile attendue, puis augmentez progressivement la valeur cible. Pour un VPN, il faut également tenir compte de la surcharge liée au protocole et au chiffrement.
Pour UDP, trois valeurs sont déterminantes :
- Bitrate : débit de données réellement atteint.
- Jitter : variation du temps de transit entre les paquets.
- Lost/Total Datagrams : perte de paquets détectée par le récepteur.
Un débit cible volontairement trop élevé provoque lui-même une perte de paquets. Il s’agit d’un test de limite, mais pas de la preuve d’un dysfonctionnement du pare-feu. Testez également le sens inverse séparément avec -R pour UDP.
Observer Sophos Firewall pendant le test
Un résultat iPerf ne devient pertinent que lorsqu’il est corrélé dans le temps avec le pare-feu. Pendant le test de 30 secondes, les éléments suivants doivent être visibles :
- Dans Log viewer, la Firewall Rule ID, la source, la destination, le service et la connexion autorisée correspondent au test.
- Dans Control center, CPU, Memory, Bandwidth et Sessions indiquent si l’appliance atteint une limite pendant le test.
- Sous Diagnostics > System graphs, vérifiez dans les Interface graphs les Bits, Drops, Errors et Collisions sur les interfaces concernées.
- Sous Diagnostics > Packet capture, un filtre restrictif sur le client, le serveur et le port 5201 peut montrer si des paquets sont rejetés ou traités par des modules inattendus.
Packet Capture affiche notamment le numéro de règle du pare-feu ainsi que les numéros des politiques Web, Application et IPS. Limitez la durée de la capture, appliquez un filtre précis et arrêtez-la après le test. L’article Packet Capture sur Sophos Firewall décrit plus précisément son analyse.
Isoler les profils de sécurité
Si la référence des points de terminaison est bonne et que seul le chemin à travers le pare-feu est lent, ne désactivez pas tout simultanément. Documentez d’abord la règle réellement appliquée et ses profils de sécurité. Ensuite, pendant une fenêtre de maintenance, modifiez exactement une variable et répétez le même test.
Une règle de diagnostic sans contrôle supplémentaire doit être strictement limitée à la source de test, à la destination de test et au service iPerf. Désactivez-la ou supprimez-la immédiatement après la mesure comparative. Vous pouvez ainsi déterminer si IPS, Application Control, Traffic Shaping ou une autre politique est impliquée, sans laisser le reste du trafic sans protection.
Interpréter correctement les résultats
Pour TCP, les synthèses pour sender et receiver, ainsi que les retransmissions, sont importantes. De nombreuses retransmissions indiquent une perte ou un chemin perturbé, mais pas automatiquement une insuffisance de CPU sur le pare-feu. Une bonne valeur de référence locale et une mauvaise valeur à travers le pare-feu réduisent le périmètre de recherche, sans toutefois identifier encore la cause.
Profils typiques :
- Déjà lent sur le même LAN : vérifiez les points de terminaison, les pilotes de carte réseau, la plateforme virtuelle, le pare-feu de l’hôte ou le WLAN.
- Lent uniquement à travers le pare-feu : examinez la règle, les profils de sécurité, Traffic Shaping, les erreurs d’interface et la charge système.
- Lent uniquement via VPN : vérifiez la qualité du WAN, la latence, le profil de chiffrement, la route du tunnel ainsi que MTU et MSS.
- Lent dans un seul sens : comparez le test inversé, les compteurs d’interface, le routage asymétrique et le réseau amont du fournisseur.
- Un flux unique lent, plusieurs flux rapides : évaluez la latence, la fenêtre TCP et les performances du point de terminaison avant de conclure à une limite du pare-feu.
- Un seul serveur public est lent : la charge, la distance ou le peering du serveur distant peuvent limiter le résultat.
Les serveurs iPerf publics conviennent tout au plus à une comparaison Internet approximative. Pour diagnostiquer un pare-feu, un VPN ou une connexion entre sites, un serveur contrôlé sur le site distant fournit des résultats plus fiables.
Documenter la mesure et rétablir la configuration
Afin qu’une comparaison avant-après reste compréhensible, consignez au minimum la date, le client, le serveur, le sens, la commande, la Rule ID, les profils de sécurité, le chemin VPN ou WAN ainsi que le résultat sender/receiver. Pendant une analyse d’erreur, ne modifiez qu’une seule variable entre deux exécutions.
Après le test :
- Arrêtez le serveur iPerf3.
- Supprimez l’autorisation dans le pare-feu de l’hôte.
- Désactivez ou supprimez la règle temporaire Sophos Firewall et le service de test s’ils ne sont plus nécessaires.
- Rétablissez les profils de sécurité modifiés dans l’état prévu.
- Vérifiez une nouvelle fois dans Log viewer et les compteurs d’interface s’il existe des Drops ou des erreurs.
FAQ
iPerf3 mesure-t-il la vitesse Internet de Sophos Firewall ?
Un test UDP nécessite-t-il les ports TCP et UDP 5201 ?
Pourquoi le test UDP est-il si lent sans -b ?
-b, le débit cible UDP par défaut est de 1 Mbit/s. Pour obtenir une mesure pertinente, il faut définir un débit cible réaliste et l’augmenter progressivement.Pourquoi faut-il tester le sens inverse avec -R ?
-R fait envoyer les données du serveur vers le client sans inverser les rôles des appareils. Cela permet de détecter plus rapidement les problèmes liés à une liaison asymétrique, au routage, au VPN ou aux interfaces.