WANem.C.A. !
WANem est un outil qui ne plaît pas à Christine Boutin, forcément c’est indien donc pas très chrétien, et en plus c’est fait par la société Tata… En ce temps de croisade contre ces pédérastes et autres grosses Tatas, il y a de quoi faire sauter l’incestueuse ancienne ministre au plafond (oups, aux ogives de la cathédrale) !…WANem pour Wide Area Network Emulator, permet de simuler un réseau WAN. C’est un outil très pratique pour étudier le comportement des applications à travers un réseau aux performances… Disons Inégales, à l’instar d’internet… Il va en effet être possible d’influer sur un certain nombre de caractéristiques telles que le temps de réponse, le taux de perte, le taux de corruption et encore quelques autres… Afin de compléter l’expérience WAN, il va également être possible de générer aléatoirement des déconnexions de plusieurs types… Un intérêt évident que l’on peut trouver à cet outil est pouvoir tester des composants VoIP au travers d’un internet simulé et donc entièrement configurable…
Mise en place de la maquette
Théoriquement il aurait été plus correct de faire passer la communication retour (serveur web vers client) par le serveur WANem, paresse m’oblige à ne pas tenir compte de la logique… Sic vita est.
Network Configuration
Je vous passe les détails de configuration réseau, peu de chance que quelqu’un s’intéresse à un émulateur WAN sans savoir configurer une interface !
Pardonnez la prétérition, je vous donne tout de même quelques indications sur ma maquette, afin de vous faciliter la lecture de ce document.
Serveur WANem
Interface de Management
Eth0 : 192.168.1.235/24 GW 192.168.1.254
Interface maquette
Eth1 : 192.168.17.253/24 GW 0.0.0.0
- Routes : 192.168.11.0/24 via 192.168.17.133
Le point important est, évidemment, de ne pas dupliquer les passerelles par défaut et de configurer une route pour atteindre le réseau 192.168.11.0.
Machine cliente
0x0ff@kali:~ #route add -net 192.168.11.0/24 gw 192.168.17.253 0x0ff@kali:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.17.0 * 255.255.255.0 U 0 0 0 eth1 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 192.168.11.0 192.168.17.253 255.255.255.0 UG 0 0 0 eth1 default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
Génération de trafic
Pour générer un trafic important nous permettant de constater les variations de qualité de la communication entre notre client et notre serveur nous allons générer un flux continu de données. Soit en envoyant un fichier volumineux, soit en utilisant astucieusement les variables de notre distribution favorite. :)
Serveur en écoute
Notre serveur distant va écouter sur le port 1337 et retransmettre sur la sortie standard les informations qui seront envoyées :
0x0ff@tserver-web:~# nc -l 1337
Méthode par envoi d’un fichier
Sur la machine cliente nous allons générer un fichier de 10Go que nous pourrons ensuite envoyer vers notre serveur :
root@kali:~# dd if=/dev/random of=10GB.file bs=1000 count=0 seek=$[1024*1024*10] 0+0 records in 0+0 records out 0 bytes (0 B) copied, 1.3743e-05 s, 0.0 kB/s
root@kali:~# ls -lh 10GB.file -rw-r--r-- 1 root root 9.8G Aug 2 04:00 10GB.file
Ensuite, pour procéder à l’envoi, cette simple commande fera l’affaire :
root@kali:~# nc 192.168.11.196 1337 < 10GB.file
Méthode plus cool
Plutôt que d’envoyer un fichier, de bloquer 10Go sur votre client et votre serveur, vous pouvez utiliser cette ligne de commande pour générer du trafic en continu vers le serveur :
root@kali:~# while true; do echo $RANDOM ; done 2>&1 | nc 192.168.1.196 1337
Wanalyzer
Les interactions avec WANem peuvent se faire grâce à un simple navigateur internet en atteignant l’une des adresses IP de votre émulateur WAN suffixé de /WANem. L’interface Web intègre un outil d’analyse baptisé WANalyze qui vous permettra de vérifier l’état de la connexion entre WANem et une machine quelconque.
Basic Mode
Ce mode de simulation rapide permet de se placer dans des conditions similaires au WAN en quelques clics seulement. Il suffit de configurer l’interface voulue en indiquant une bande passante nominale et ajouter un délai, puis valider la configuration en cliquant sur Apply settings.
Lorsque l’on agit sur le champ Delay Time(ms), on constate bien une augmentation du ping de 100ms.
0x0ff@kali:~# ping 192.168.11.196 PING 192.168.11.196 (192.168.11.196) 56(84) bytes of data. 64 bytes from 192.168.11.196: icmp_seq=1 ttl=63 time=6.81 ms 64 bytes from 192.168.11.196: icmp_seq=2 ttl=63 time=0.821 ms 64 bytes from 192.168.11.196: icmp_seq=3 ttl=63 time=1.02 ms 64 bytes from 192.168.11.196: icmp_seq=4 ttl=63 time=1.08 ms 64 bytes from 192.168.11.196: icmp_seq=5 ttl=63 time=1.04 ms 64 bytes from 192.168.11.196: icmp_seq=6 ttl=63 time=101 ms 64 bytes from 192.168.11.196: icmp_seq=7 ttl=63 time=101 ms 64 bytes from 192.168.11.196: icmp_seq=8 ttl=63 time=101 ms 64 bytes from 192.168.11.196: icmp_seq=9 ttl=63 time=101 ms 64 bytes from 192.168.11.196: icmp_seq=10 ttl=63 time=101 ms
Variation de la configuration
La courbe Network History retranscrit des modifications successives des paramètres du mode basique.
Advanced
Le mode avancé permet d’influer sur un grand nombre de paramètres pour rendre la simulation la plus proche possible des conditions réelles. Dans un soucis de réalisme, les développeurs ont intégré une variable correlation à chaque levier. Cette variable permet d’indiquer que l’on souhaite utiliser le résultat obtenu sur le précédent paquet à un certain pourcentage. Cette variable va nous permettre de produire un effet de burst. Par exemple, il est fréquent que plusieurs paquets consécutifs soient perdus plutôt qu’un seul et unique. En influent sur la corrélation du taux de perte, il est possible de simuler ce comportement.
Pour rendre la démonstration un poile plus parlante, je vais exagérer les valeurs des différents indicateurs. Pour simuler une situation réelle nous choisirions plutôt des valeurs inférieurs à 1% !
Delay – Temps de réponse
La configuration de la latence inclut un paramètre jitter qui va faire varier le temps de réponse. Dans le cas ci-dessous nous avons donc un temps de latence moyen de 100ms (+/- 10ms).
0x0ff@kali:~# ping 192.168.11.196 PING 192.168.11.196 (192.168.11.196) 56(84) bytes of data. 64 bytes from 192.168.11.196: icmp_req=1 ttl=63 time=95.3 ms 64 bytes from 192.168.11.196: icmp_req=2 ttl=63 time=96.5 ms 64 bytes from 192.168.11.196: icmp_req=3 ttl=63 time=110 ms 64 bytes from 192.168.11.196: icmp_req=4 ttl=63 time=106 ms 64 bytes from 192.168.11.196: icmp_req=5 ttl=63 time=91.9 ms
Loss – Taux de perte
Avec 30% de perte et 50% de corrélation, le débit maximum chute radicalement et la connexion est plus qu’instable !
Duplication – …
La duplication de paquets est moins impactant pour la connexion. Avec un taux de 30% (pas de corrélation sur cet indicateur), la connexion demeure relativement stable et le débit moyennement élevé.
Reordering – Paquet TCP dans le désordre
Avec 20% de paquets désordonnés corrélés à 50%, la connexion est une nouvelle fois très instable…
Corruption – …
La corruption des paquets influence grandement la qualité de la liaison entre le client et le serveur. Avec 10% de paquets corrompus, le trafic est à l’agonie.
Disconnections – Déconnections
Je ne me suis pas trop attardé sur cette partie qui n’est pourtant pas dénuée d’intérêt, cependant je suis en mesure de vous montrer qu’en jouant avec ces indicateurs, il est possible de générer des comportements plutôt intéressants… Presque funs ! :p
Bug & Debug
Perte de connexion
Après quelques dizaines de minutes, j’ai eu à lancer deux commandes pour rétablir la connectivité :
0x0ff@WANem:~# echo 1 > /proc/sys/net/ipv4/ip_forward 0x0ff@WANem:~# iptables –P FORWARD ACCEPT
HD installation problème
Je n’ai pas réussi à installer WANem sous VMWare, j’ai pourtant essayé plusieurs configurations… Je n’ai pas poussé plus loin mes recherches.
Solution : Télécharger la machine virtuelle préparée WANem !
