Étiquette : Reseau

Catégories
Reseau

Tester la performance de votre réseau avec Iperf

Iperf est un des outils indispensable pout tout administrateur réseau qui se respecte. En effet, ce logiciel de mesure de performance réseau, diponible sur de nombreuses plateformes (Linux, BSD, Mac, Windows…), se présente sous la forme d’une ligne de commande à executer sur deux machines disposées aux extrémités du réseau à tester.

Iperf fonctionne comme un client/serveur selon le diagramme suivant:

Iperf

Iperf doit être lancé sur deux machines se trouvant de part et d’autre du réseau à tester. La première machine lance Iperf en « mode serveur » (avec l’option -s), la seconde en « mode client » (option -c). Par défaut le test réseau se fait en utilsant le protocole TCP (mais il est également possible d’utiliser le mode UDP avec l’option -u).

Nous allons commencer par installer iperf en utilisant la commande suivante (sous Fedora):

# yum install iperf

Pour les autres système d »exploitation, vous pouvez vous rendre sur cette page.

Premier exemple d’utilisation

Ensuite, sur une des deux machines de test, nous allon slancer le serveur grâce à la commande suivante:

# iperf -s

Sur le client, il ne reste plus qu’a lancer le client en précisant l’adresse du serveur:

# iperf -c <adresse IP du serveur>

Vous devriez avoir le rapport qui s’affiche après 10 secondes de test.

————————————————————
Client connecting to 192.168.29.1, TCP port 5001
TCP window size: 65.0 KByte (default)
————————————————————
[ 3] local 192.168.29.157 port 50675 connected with 192.168.29.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 110 MBytes 92.6 Mbits/sec

Avec les options par défaut, le test est fait en TCP sur une durée de 10 secondes. Sur un réseau local vous devriez donc obtenir un valeur proche de la capacité de commutation de vos équipements (par exemple 92.6 Mbits/sec qui est une valeur proche de 100 Mbits/sec).

Pour afficher des rapports intermédiaires (par exemple toutes les secondes) , il suffit d’ajouter l’option (-i 1) sur le client et/ou le serveur.

# iperf -s -i 1
————————————————————
Server listening on TCP port 5001
TCP window size: 56.0 KByte (default)
————————————————————
[ 6] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 50692
[ 6] 0.0- 1.0 sec 10.1 MBytes 84.8 Mbits/sec
[ 6] 1.0- 2.0 sec 11.1 MBytes 93.0 Mbits/sec
[ 6] 2.0- 3.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 3.0- 4.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 4.0- 5.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 5.0- 6.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 6.0- 7.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 7.0- 8.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 8.0- 9.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 9.0-10.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 0.0-10.0 sec 111 MBytes 92.9 Mbits/sec

Une autre option de base est (-t) qui permet de fixer au niveau du client le temps du test (en secondes). Par exemple pour effectuer un test pendant 1 minute:

# ipert -c <adresse IP du serveur> -t 60

Exemple de test en utilisant le protocole UDP

Iperf permet également de générer un traffic de type UDP (-u). Dans ce cas là, il faut penser à fixer la bande passante cible (contrairement au protocole TCP, UDP ne peut pas faire de contrôle de flux). On utilise pour cela l’argument -b au niveau du client:

Sur le serveur:

# iperf -s -u

Sur le client:

# ipert -c <adresse IP du serveur> -u -b 512k

Ce couple de commandes va générer un test avec un flux réseau UDP de 512 Kbits/sec.

Comme vous pouvez le voir Iperf est également un bon outil de génération de flux. Je l’ai déjà testé pour générer un flux UDP constant pendant plusieurs jours.

Exemple de test en multicast (UDP)

Iperf peut fonctionner en mode multicast (-B). Il faut le lancer de la manière suivante:

Sur le serveur:

# iperf -s -u -B 226.10.11.12

Sur le/les clients:

# iperf -c 226.10.11.12 -u -T 32 -b 512k

Ce couple de commandes génére un flux multicast UDP (sur l’adresse 226.10.11.12, avec un TTL de 32) de 512 Kbits/sec.

Autres options

NOUVEAU: Consultez cet autre article (cliquez ici) pour une description des options avancés de Iperf.

Et bien entendu, il reste la fameuse commande:

# iperf –help

…pour avoir la liste complète des options. Si vous avez des questions, n’hésitez pas !

Sur le même sujet

Pour mes propres besoins, j’ai ecrit un programme nommé SJitter permettant, comme le fait Iperf (c’est à dire sous la forme d’un client/serveur), de mesurer la gigue réseau (ou jitter en anglais). Paramètre très important si vous souhaitez mettre en place de la voie sur IP sur votre réseau.

Catégories
Reseau

Monter un répertoire distant en SSH

Je me sers exlusivement du protocole SSH pour administrer mes machines via une console. Ce protocole permet également d’effectuer des transferts de fichiers via le protocole SCP. Cependant, il était jusqu’a maintenant nécessaire d’utiliser un client (scp sous Linux/BSD, WinSCP sur Windows ou Fugu sur Mac). Cette contrainte n’est plus d’actualité depuis l’apparition de Fuse.

« Pour rappel, Fuse (pour Filesystem in Userspace) permet à un utilisateur (non root) de créer son propre système de fichier sans avoir à modifier le noyau du systeme. Il existe par exemple une extension pour accéder à votre compte Gmail comme si celui-ci était un répertoire de votre disque dur (GmailFS). Fuse a de plus le bon goût d’être développé sous licence open-source GPL et LGPL. »

Pour notre besoin, nous allons utiliser le module SSHFS (SSH sur Fuse).

Installation (sur Fedora)

# yum install fuse-sshfs

Utilisation (sur Linux)

La première chose à faire est de créer, sur votre machine cliente, le répertoire dans lequel sera monté le répertoire distant:

# mkdir /mnt/test

Ensuite, on monte le répertoire distant /home/test qui se trouve sur la machine 192.168.0.2:

# sshfs 192.168.0.2:/home/test/ /mnt/test/

On vérifie en faisant un ls dans le répertorie /mnt/test. Il doit afficher le contenu du répertoire distant.

# ls /mnt/test
test.zip

Pour démonter le répertoire distant, il faut taper la commande suivante:

# fusermount -u /mnt/test

Et voila le travail…

Catégories
Reseau

Tutorial TCPdump

TCPdump est un outil en ligne de commande pour écouter ce qui se passe sur une interface réseau. Il est disponible sur la plupart des operating system (Linux, Mac, Wins…). Comme son nom ne l’indique pas il est capable de déchiffrer tout les paquets IP.

Comment lancer TCPdump

Il est préférable de lancer TCPdump en mode super user. En effet, il passe votre interface réseau en « promiscuous mode » (c’est à dire que votre interface va accepter tous les paquets IP, même ceux qui ne lui sont pas destinés), ce qui nécessite certain priviléges.

Voici une première commande pour écouter ce qui se passe sur l’interface par défaut de botre système:

# tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes
11:21:49.128471 802.1d unknown version
11:21:50.629554 arp who-has 192.168.29.149 tell 192.168.29.179
11:21:51.116336 IP 192.168.29.11.34236 > broadcasthost.34235: UDP, length 186
11:21:51.129803 802.1d unknown version
11:21:51.543959 IP 192.168.29.157.49575 > 192.168.29.1.domain: 5186+ PTR? 149.29.168.192.in-addr.arpa. (45)
11:21:51.616221 IP 192.168.29.1.domain > 192.168.29.157.49575: 5186 NXDomain* 0/1/0 (142)
11:21:51.617724 IP 192.168.29.157.49576 > 192.168.29.1.domain: 55735+ PTR? 179.29.168.192.in-addr.arpa. (45)
11:21:51.618069 IP 192.168.29.1.domain > 192.168.29.157.49576: 55735 NXDomain 0/1/0 (122)
11:21:51.619695 IP 192.168.29.157.49577 > 192.168.29.1.domain: 34419+ PTR? 11.29.168.192.in-addr.arpa. (44)
11:21:51.691880 IP 192.168.29.1.domain > 192.168.29.157.49577: 34419 NXDomain* 0/1/0 (141)
11:21:52.693682 IP 192.168.29.157.49578 > 192.168.29.1.domain: 10774+ PTR? 1.29.168.192.in-addr.arpa. (43)
11:21:52.766304 IP 192.168.29.1.domain > 192.168.29.157.49578: 10774 NXDomain* 0/1/0 (140)
11:21:53.131204 802.1d unknown version
11:21:53.770691 IP 192.168.29.157 > 224.0.0.251: igmp v2 report 224.0.0.251
11:21:53.847442 arp who-has 192.168.29.175 tell 192.168.29.1
11:21:54.768652 arp who-has 192.168.29.1 tell 192.168.29.157
11:21:54.768916 arp reply 192.168.29.1 is-at 00:0d:61:60:3b:2f (oui Unknown)
11:21:54.768942 IP 192.168.29.157.49580 > 192.168.29.1.domain: 35687+ PTR? 251.0.0.224.in-addr.arpa. (42)
11:21:54.769366 IP 192.168.29.1.domain > 192.168.29.157.49580: 35687 NXDomain 0/1/0 (100)
11:21:54.770771 IP 192.168.29.157.49581 > 192.168.29.1.domain: 47393+ PTR? 175.29.168.192.in-addr.arpa. (45)
11:21:54.843466 IP 192.168.29.1.domain > 192.168.29.157.49581: 47393 NXDomain* 0/1/0 (142)

TCPdump génére une ligne par paquet IP. Avec les options par défaut, une ligne ressemble à:

11:21:54.768942 IP 192.168.29.157.49580 > 192.168.29.1.domain
-> Heure d’arrivée du paquet sur l’interface réseau
11:21:54.768942 IP 192.168.29.157.49580 > 192.168.29.1.domain
-> Type de protocole (ici IP, peut être aussi ARP, IGMP, GRE …)
11:21:54.768942 IP 192.168.29.157.49580 > 192.168.29.1.domain
-> Adresse réseau source
11:21:54.768942 IP 192.168.29.157.49580 > 192.168.29.1.domain
-> Port réseau source
11:21:54.768942 IP 192.168.29.157.49580 > 192.168.29.1.domain
-> Adresse réseau destination
11:21:54.768942 IP 192.168.29.157.49580 > 192.168.29.1.domain
-> Port réseau destination (domain = requête DNS UDP/53)

Remarque: pour trouver le numero de port correspondant au nom du port, il faut chercher dans le fichier /etc/services. Par exemple:

# grep domain /etc/services
domain 53/udp # Domain Name Server

Je veux plus d’informations

(ok ok …). Si vous souhaitez avoir plus d’information, vous pouvez utiliser le tag -v:

# tcpdump -v
…
11:34:23.480144 IP (tos 0x0, ttl 64, id 10784, offset 0, flags [DF], proto: UDP (17), length: 67) 192.168.29.246.32794 > 192.168.29.1.domain: 8576+ A? ftp.redhat.ikoula.com. (39)
…

On peut alors voir les informations supplémentaires suivantes:

(tos 0x0, ttl 64, id 10784, offset 0, flags [DF], proto: UDP (17), length: 67)
Associés au champs IP, elle fournie des informations sur le protocole (flags, protocole UDP, taille du paquet…).
8576+ A? ftp.redhat.ikoula.com. (39)
 Donne un apercu du champ data (dans notre exemple, on peut voir que c’est une requête DNS qui demande l’adresse IP du serveur ftp.redhat.ikoula.com)

Si vous voulez encore plus d’informations (coquin va…), vous pouvez utiliser les options -vv et même -vvv (mais ou s’arrêteront t’ils ?).

Si vous souhaité avoir un dump du contenu du de chaque paquet, vous pouvez utiliser l’option -A, par exemple:

# tcpdump -v -A
11:46:00.607145 IP (tos 0x0, ttl 64, id 33771, offset 0, flags [DF], proto: TCP (6), length: 765) 192.168.29.157.49659 > mu-in-f104.google.com.http: P 1543672215:1543672940(725) ack 1290089933 win 65535
E…..@.@.}……U.h…P\…L.5.P…9…GET / HTTP/1.1
Host: www.google.fr
User-

Ce paquet correspnd donc à une requette HTTP sur le site www.google.fr.

Mon dieu, il y a trop d’informations !!!

(faut savoir ce que tu veux….). Heureusement, TCPdump inclut un système de filtrage très pointu.

Quelques exemples (consulter le man tcpdump pour une liste exhaustive):

# tcpdump host www.google.fr
Affiche seulement les paquets qui ont pour adresse source ou destination www.google.fr

# tcpdump dst www.google.fr
Affiche seulement les paquets qui ont pour adresse destination www.google.fr

# tcpdump port http
Affiche seulement les paquets HTTP (web)

# tcpdump proto gre
Affiche seulement les paquets GRE (utilisés lors de tunnel ipsec)

Il est bien sur possible de mixer plusieurs filtres:

# tcpdump dst 192.168.29.10 and port domain
Affiche tous les paquets DNS (domain) à destination de l’adresse 192.168.29.10

J’en veux encore !

(ben voila, on donne la main il prend le bras…). Imaginons que l’on souhaite capturer les paquets transitant sur une interface réseau afin de les analyser plus tard, sur une autre machine ou dans un autre logiciel (par exemple dans Ethereal…). C’est possible et très simple avec l’option -w:

# tcpdump -w capture.dump
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes
656 packets captured
676 packets received by filter
0 packets dropped by kernel

Cette commande va capturer les paquets et sauvegarder le tout dans le fichier capture.dump.
Si vous souhaitez maintenant afficher le contenu de ce fichier avec l’option -r, il faut taper la commande:

# tcpdump -v -r capture.dump
reading from file capture.dump, link-type EN10MB (Ethernet)
13:28:09.495897 IP (tos 0x0, ttl 64, id 47730, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.29.246.49084 > ftp.fu-berl
in.de.60772: ., cksum 0x13d0 (correct), ack 1339443207 win 2003
13:28:09.503376 IP (tos 0x0, ttl 64, id 47731, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.29.246.49084 > ftp.fu-berl
in.de.60772: ., cksum 0x0e1d (correct), ack 1449 win 2003
13:28:09.506374 IP (tos 0x0, ttl 64, id 47732, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.29.246.49084 > ftp.fu-berl
in.de.60772: ., cksum 0x0872 (correct), ack 2897 win 2003

Voila une première initiation à la capture réseau. Vous pouvez toujours consulter le man de TCPdump pour exploiter les nombreuses options de ce logiciel.

Quelques options en bonus:
-n : ne pas faire de résolution de nom (affiche seulement les adresses IP).
-i : Force l’utilisation de l’interface (par exemple -i eth0)

Catégories
Reseau Web

Serveurs Web utilisés par le Top 10

Nmap permet d’identifier le type de serveur Web utilisée par un site Internet. Pour cela on utilse la commande suivante:

# nmap -sV -p 80 -P0 -O

Ou alors:

# yum install libwww-perl
# GET -ed

Voici donc le résultat de cette commande sur le Top 10 des sites Francais (donné par Alexa).

msn.com – Microsoft-IIS/6.0 – Windows
google.fr – Google httpd 2.1 (GWS) – Linux (Redhat)
yahoo.com – ? – ?
skyblog.com – Apache – ?
google.com – Google httpd 2.1 (GWS) – Linux
free.fr – Apache – IBM AIX 4.X
live.com – Microsoft-IIS/6.0 – Windows
orange.fr – Apache – Linux
ebay.ff – Apache – NetBSD
youtube.com – Apache – Linux (Redhat)

Pour rappel, il existe plusieurs méthodes pour masquer (ou changer) le nom du service Web / operating system. Ces informations sont donc à prendre avec des pincettes.

On peut donc voir que pour ce « Top 10 », seul Microsoft utilise le serveur IIS. Les autres sites utilises Apache. Seul expession, Google qui a du re-écrire un serveur Web maison (d’un autre coté ils font aussi leur propores alimentations pour les serveurs…).

Catégories
Reseau

Sjitter – Version pour MacOSX

Je viens de mettre en package la version 0.14b de Sjitter mon outil (en ligne de commande) de mesure de bande passante, de delais de transit et de gigue pour MacOSX.

Le site officiel est ici mais vous pouvez également trouvez le package ici ou la.

A+

Catégories
Reseau Systeme

Installation serveur FTP avec support LDAP

Voici un tutorial pour installer un serveur en 5 minutes chrono un serveur FTP avec le support LDAP pour l’authentification des utilisateurs sous Fedora (ou d’autres système Linux).

Top chrono…

La première chose à faire est de récupérer la dernière version de ProFTPd (serveur FTP) à l’adresse suivante:

# wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.0a.tar.gz

PS: l’installation par yum ne convient pas car le package n’est pas compilé avec l’option LDAP qui nous interesse dans ce post…

Ensuite, il faut compiler:

# tar zxvf proftpd-1.3.0a.tar.gz
# cd proftpd-1.3.0a
# ./configure –with-modules=mod_ldap
# make
# make install

Puis automatiser le démarrage pour le prochain reboot (vous pouvez lire ce post pour des informations complémentaires sur le lancement automatique des services sous Fedora):

# cp contrib/dist/rpm/proftpd.init.d /etc/init.d/proftpd
# chmod +x /etc/init.d/proftpd
# chkconfig –levels 235 proftpd on

Vient ensuite la configuration du serveur via le fichier /usr/local/etc/proftpd.conf:

# vi /usr/local/etc/proftpd.conf
…
LDAPServer
LDAPDNInfo
LDAPDoAuth on
LDAPDefaultAuthScheme « clear »
CreateHome on 711
LDAPGenerateHomeDir on 711
LDAPForceGeneratedHomedir on
LDAPGenerateHomedirPrefix /usr/local/data/
…

Dans cette configuration, à chaque connection d’un utilisateur renseigné dans le LDAP, un sous-repertoire avec l’UID de l’utilisateur sera créé sous /usr/local/data. Par exemple quand l’utilisateur nico se connecte via un client FTP, le repertoire /usr/local/data/nico sera automatiquement créé pour stocker les fichiers FTP.

Et enfin le démarrage du service:

# service proftpd start

TOP ! 5 minutes chronos 🙂

Catégories
Reseau

Replication de serveur LDAP

Voici la problèmatique: je souhaite répliquer l’intégralité d’un serveur LDAP sur un autre des serveurs (pour des raisons de migration progressive…).

Mon serveur maître est basée sur OpenLDAP (ce sera également le cas de mon serveur esclave).
En cherchant un peu sur le net, je suis tombé sur plusieurs articles sur le sujet. Il y deux solutions possible, utiliser slurpd ou bien syncrepl. Cette deuxième méthode, plus souple sera développée dans ce post.

Syncrepl se base sur LDAP Content Synchronisation. Il y peu ou pas de modification à faire sur le serveur maître.

Configuration du serveur maître:
Nous partons sur le principe ou le serveur maître fonctionne parfaitement (exemple donnée pour le domaine dc=nicolargo,dc=net).
Il faut dans un premier temps créer un utilisateur avec les droits minimum (en lecture). C’est cet utilisateur qui sera utilisé pour la synchronisation (exemple donnée avec cn=syncuser,dc=nicolargo,dc=net).
La deuxième étape consiste à ajouter les lignes suivantes au fichier /etc/openldap/slapd.conf:

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

Pour en finir avec le serveur maître, il faut relancer le serveur LDAP:

# service ldap restart

Configuration du serveur esclave:
Une fois openldap correctemet installé et configuré, il faut ajouter les lignes suivantes au fichier /etc/openldap/slapd.conf:

syncrepl rid=100
provider=ldap://:389
type=refreshOnly
interval=00:01:00:00
searchbase= »dc=nicolargo,dc=net »
scope=sub
schemachecking=off
bindmethod=simple
binddn= »cn=syncuser,dc=nicolargo,dc=net »
credentials=syncestec

La synchronisation se fera toutes les heures à l’initiative du serveur esclave.
Le protocole réseau utilisé entre les deux serveur est LDAP: TCP/389.

Il suffit alors de lancer le serveur:

# service ldap start

La première synchronisation devrait initialiser votre serveur esclave. Pour vérifier que tout est ok, vous pouvez taper la commande suivante:

# ldapsearch -x

Et voili, si vous avez des questions…. le blog est fait pour ca.

PS: URL du site officiel sur le sujet: http://www.openldap.org/doc/admin23/syncrepl.html

Catégories
Reseau

Optimisation du stack TCP

Dans le cadre de mon boulot, je me suis intéressé à l’optimisation du stack TCP sous Linux. Les versions récentes de Linux intégrent maintenant un stack IP optimisé pour les réseau broadband, ce qui n’était pas le cas au début de l’aventure de l’OS Libre.

Afin de vérifier que tout est bien configuré sur votre poste, voici TCPtweak un petit script écrit en Perl qui va lire la configuration actuelle, tester votre liaison Internet et afficher la configuration conseillée.

Voici un exemple d’output:

#./tcptweak.pl -t
Current system configuration
—————————-
Default TCP Receive Window (bytes) = 109568
Maximum TCP Receive Window (bytes) = 131071
Default TCP Send Window (bytes) = 109568
Maximum TCP Send Window (bytes) = 131071
Timestamps (add 12 bytes to the TCP header) = YES
TCP selective acknowledgements = YES
Support for large TCP Windows = YES

Test your network
—————–
Bandwidth (Kbps) = 3691
Delay (ms) = 38
Bandwidth Delay Product (bytes) = 17532

Display the recommanded system configuration
——————————————–
On Linux OS copy/paste in /etc/sysctl.conf file:
Configuration optimized for LAN access:
net.core.rmem_default = 256960
net.core.rmem_max = 256960
net.core.wmem_default = 256960
net.core.wmem_max = 256960
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
Configuration optimized for the tested network:
net.core.rmem_default = 17532
net.core.rmem_max = 17532
net.core.wmem_default = 17532
net.core.wmem_max = 17532
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1

Et voili, a+

Catégories
Reseau

IPFW Log Monitor

Afin de surveiller en temps réel les logs générés par le firewall ipfw des operating system FreeBSD. J’ai écris un script permettant d’optimiser l’affichage de ces logs afin de les rendre plus lisible.

Affichage standard (sans le script):Affichage « optimisée » (avec le script):

Synaxe:

# tail -f /var/log/security | ipfwlogmonitor.pl

Cliquer ici pour télécharger le script (version 0.63).

Catégories
Reseau

Nouvelle version de SJitter (v0.14)

SJitter est un utilitaire que j’ai développé il y a quelques temps pour tester une liaison réseau. Il fournit notamment des informations sur la bande passante, la gigue (jitter dans la langue de qui vous savez), et les délais de transit.

Il fonctionne sous le principe d’un client/server. Le code est écrit en C sous licence GNU.

Voici la page du projet: http://freshmeat.net/projects/sjitter/

et le site officiel: http://www.nicolargo.com/dev/sjitter/