Leur interface d’administration Web, nommée « Frontview » est accessible en HTTPS, ce qui, au premier abord, semble être une très bonne chose… Oui, mais voilà, le petit processeur « infrant » - architecture sparc -, qu’ils intègrent, est aussi efficace pour les traitements arithmétiques (et donc les fonctions de chiffrement SSL),  qu’un moteur de mobylette sur un Airbus A380. Résultat, même avec un pot polini  et un carbu 14, rien à faire, ça ne décolle pas.  C’est mou…c’est très mou, c’est très très mou !  J’ai résisté tant que j’ai pu, n’effectuant en somme que très peu de manipulations via cette interface, mais aujourd’hui, trop c’est trop, j’ai craqué ! Et quand je m’énerve, je change de couleur, mes proéminents muscles verts déchirent ma chemise et je casse tout sur mon passage.

J’ai donc commencé par m’attaquer à un pauvre crayon à papier et quant il a eu son sort (3 morceaux quand même !), je suis passé au serveur WEB de mon ReadyNAS. Mais, reprenant peu à peu ma raison, une couleur humaine et une chemise piquée sur un étendoir voisin, je me suis résigné à juste désactiver la couche SSL du serveur Apache.

Si comme moi, vous ragez, pestez et vociférez contre ce mollasson de Frontview, voici comment lui redonner un peu de peps, au détriment d’une bonne dose de sécurité, bien malheureusement. Qu’on se le dise, tout de même, si il avance beaucoup mieux après, il ne décolle quand même pas… Un moteur de mobylette reste un moteur de mobylette.

La première chose à faire, si ce n’est pas déjà fait, est d’installer de quoi se connecter en ssh sur la bête (enfin, le veau, pour être plus précis). Il faut pour cela le plugin : Enable Root SSH Access (version Sparc dans mon cas).

Le plugin s’installe par la voie normale : Menu système, Mise à jour – Installation, Image Locale – Module.

Ce module installé et le Nas redémarré, l’accès SSH est ouvert et le mot de passe root synchronisé avec celui du compte « Admin » utilisé pour se connecter à Frontview.

 Il suffit ensuite de se connecter, par ssh donc, pour modifier la configuration d’Apache.

Le fichier de configuration en question est :

/etc/frontview/apache/httpd.conf

• Rechercher la ligne « Listen 443  » , la commenter, ainsi que tout le bloc de configuration SSL suivant,
• Rechercher la ligne « include /etc/frontview/apache/Virtual.conf »  et la commenter (le fichier virtual.conf contient juste une directive de réécriture d’URL pour rediriger les requêtes http vers du https).

 Extrait :

...
 
# Listen 443
# SSLEngine On
# SSLSessionCache dbm:/ramfs/gcache.db
# SSLSessionCacheTimeout 600
# SSLCACertificatePath /etc/frontview/apache
# SSLCertificateFile /etc/frontview/apache/apache.pem
 
...
 
Include /etc/frontview/apache/Ports.conf
# Include /etc/frontview/apache/Virtual.conf
Include /etc/frontview/apache/addons/*.conf
Include /etc/frontview/apache/Shares.conf

Un petit reboot du NAS et l’interface devrait être accessible en http. (si quelqu’un peut m’expliquer comment redémarrer Apache/Frontview sans redémarrer tout le NAS, je suis preneur, j’avoue ne pas avoir cherché et n’ai pas trop étudié les scripts de démarrage sur ce type de machine).

Pour conclure, la manipulation telle que décrite, doit fonctionner sur tous les ReadyNAS; mais je n’ai pas testé d’autres modèles.

Bien évidemment, désactiver https si vous utilisez le NAS depuis Internet ou ailleurs qu’à la maison n’est vraiment pas une bonne idée.

Mais comme diraient mes amis « perlistes »… « perliens »… « perleurs »…bref… qui parlent Perl courrament  :

« There’s More Than One Way To Do It  » (TIMTOWTDI).

A l’extrême, une autre façon consiste à faire un bon « disk dump - dd » du disque vers un fichier « raw »   (ie par ex : # dd if=/dev/sda of=/chemin/fichier.raw). Ce fichier sera ensuite utilisé comme disque virtuel. Je n’ai jamais testé, mais je ne vois pas pourquoi ça ne fonctionnerait pas, à condition bien sûr, que le serveur d’origine n’intègre pas de matériels trop exotiques. Cependant, un des avantages de la virtualisation, lié à l’allocation dynamique de l’espace de stockage, est perdu. En effet, l’espace disque libre est « dumpé » et occupera de la place sur le serveur final. Paradoxal non ? Même si le procédé pourrait être amélioré en utilisant « partimage », pour gérer un peu mieux l’espace non occupé, il faut bien avouer que ce procédé demeure quelque peu « bourrin ».

Entre les deux, je vous propose d’explorer une piste nommée « Mondo ».

« Mondo Rescue »  est un utilitaire, sous licence GPL, qui permet de créer, sur des supports variés (CD, DVD, bande, montage réseau ou disque dur), une image complète ou partielle d’un système Linux.  A l’instar de Ignite sous HP-UX ou Ghost sous Windows.

Son premier atout, est qu’il s’installe sur le système et permet de créer l’archive à chaud. L’intégralité de la migration pourra se dérouler avec un serveur physique fonctionnel. Ce dernier sera arrêté au dernier moment, quand la machine virtuelle sera capable de prendre le relai.

Son deuxième atout est sa capacité à créer une image « iso » bootable et compressée, dont la fonction est de restaurer notre système en s’adaptant au nouveau matériel. A l’inverse de « dd » ou de « partimage », qui réalisent des copies physiques de blocs du système de fichier, Mondo re-crée le partitionnement mémorisé, y restaure les fichiers sauvegardés et en dernier lieu, réinstalle le « bootloader ».

Avant d’aller plus loin, j’attire votre attention, chers lecteurs, sur le fait que la solution « mondo » n’est pas fiable à 100%.  Il n’est pas rare, dans le cas de partitionnements un peu complexes (basés sur LVM entre autres), que ce dernier s’emmêle les pinceaux et donne envie irresistible de s’arracher les cheveux (pour peu qu’il nous en reste !). Je ne vais pas vous infliger le refrain « je ne suis pas responsable bla bla bla… », mais faites tout de même gaffe en production. Si je devais qualifier cette solution en quelques mots, je dirais qu’elle est performante mais reste assez artisanale. Ceci dit, si je prends la peine d’écrire ce billet, c’est qu’elle présente un intérêt (enfin, j’espère) et qu’elle peut tout de même rendre de fiers services.

Installation

Le site officiel fournit  les paquets pour de nombreuses distributions. Sous Debian, il est, en plus, possible d’utiliser les dépôts :

deb ftp://ftp.mondorescue.org/debian X.0 contrib

ou X est le numéro de version ( 4 pour Etch, 5 pour Lenny, 6 pour Squeeze).

Par exemple, pour l’installer sous Squeeze :

# echo « deb ftp://ftp.mondorescue.org/debian 6.0 contrib »  > /etc/apt/source.list.d/mondo.list

# apt-get update

# apt-get install mondo

 Note pour Squeeze : Mondo utilise les outils mkisofs pour la génération des images iso et cdrecord pour la gravure de CD. Ces outils ont été respectivement remplacés dans Squeeze, par  genisoimage et wodim. Il est possible de s’en sortir (pas très proprement), en créant des liens symboliques :

# ln -s /usr/bin/genisoimage /usr/bin/mkisofs

# ln -s /usr/bin/wodim /usr/bin/cdrecord

Il m’est arrivé de rencontrer quelques problèmes avec « Mindi » . Pour la création du boot de l’image iso, un ramdisk est utilisé, sur lequel on est parfois à l’étroit.  On peut l’augmenter en dé-commentant et en affectant une plus grande valeur au paramètre « EXTRA_SPACE » du  fichier de configuration de « Mindi »   (/etc/mindi/mindi.conf).

Utilisation

Il y a encore « More Than One Way » pour utiliser Mondo. La première se fait par une interface « curses », affichée par défaut, lors de l’exécution de mondoarchive sans paramètre.

La deuxième est bien entendu en ligne de commande :

# mondoarchive -O -p nomarchive -i -I / -d /destination -E /destination -T /temporaire -S /Scratchdir -s taille

• -O : pour créer une archive, par opposition à -V pour une vérification,
• -p nom : pour donner un nom à l’archive ( mondoarchive par défaut),
• -i : pour générer une ou des images iso,
• -I : pour spécifier de départ de l’arborescence à sauvegarder. « / » est par défaut, mais nous pouvons décider de ne sauvegarder qu’un bout de l’arborescence,
• -d : l’emplacement des fichiers finaux (iso),
• -E : Les répertoires à exclure. /tmp, /proc, /sys et les montages médias sont exclus par défaut, il convient, en plus, d’exclure le répertoire destination de l’image,
• -T : Le répertoire temporaire. Par défaut, Mondo choisira la partition disposant du plus grand espace disponible,
• -S   : Le répertoire du scratchdisk, c’est à dire le répertoire dans lequel seront construites les images pour la génération des fichiers iso, comme pour le répertoire temporaire, Mondo choisira par défaut la partition disposant du plus grand espace libre,
• -s : La taille maximale des fichiers iso. Si le but est de graver ces fichiers, il faudra choisir une taille adéquate en fonction du média utilisé  : ~ 700 Mo (700m) pour un CD, ~4.7 Go (4.7g) pour un DVD. Autant d’images que nécessaire seront générées.

Un exemple :

# mondoarchive -O -p serveur1 -i -I / -d /home/joel/mondo -E /home/joel/mondo -s 10g

Les images iso porteront le nom « serveur1-x.iso » (x = numéro incrémentiel) est seront placées dans le répertoire « /home/joel/mondo« . Ce répertoire est exclu de l’archive  et les images ne feront pas plus de 10 Go.

Les autres options sont laissées par défaut.

Ensuite, c’est le moment, tant connu des informaticiens, de laisser bosser la machines et d’aller vaquer à d’autres occupations.

Quelques « occupations » plus tard, l’image générée peut être utilisée pour installer la machine virtuelle, en la transférant sur l’hyperviseur  et en l’utilisant comme CDRom virtuel par exemple.

Au boot et après une détection du nouveau matériel, l’interface propose diverses options, dont l’une est « Automatique » pour une réinstallation à l’identique, une autre, « Manuelle », permet, entre autre, d’aller trifouiller le partitionnement et l’adapter –  Très utile quand la taille de l’espace disque allouée à la VM diffère du disque original.

Les données restaurées et avant l’écriture du secteur d’amorçage, il est possible de prendre la main dans un chroot, afin de vérifier le bon montage des partitions, modifier si nécessaire les fichiers de configuration et si besoin regénérer le initramfs  pour qu’il prenne en compte le nouveau matériel.

Pour terminer, je vous propose d’illustrer cet article par un screencast. Il reprend la migration d’un serveur physique sous Debian Squeeze vers une machine virtuelle Proxmox VE / KVM ( précédent article).

Click here to view the video on YouTube.

Sources :

• Site officiel,
• Wikipedia.

Proxmox Virtual Environnement

Proxmox VE s’installe sur un serveur nu, à partir d’une image iso téléchargeable sur le site officiel. Etant donné qu’il repose sur une distribution Debian Lenny, il est tout à fait possible de l’installer, sur un système existant, à partir de paquets. La dernière version (1.8) utilise les extensions de virtualisation des processeurs 64 bits, elle n’est disponible que pour cette architecture, inutile donc,  de tenter une installation sur une machine 32 bits.

Une interface web d’administration offre une surveillance et une gestion simplifiée des machines virtuelles KVM (kernel-based Virtual Machine) et para-virtuelles OpenVZ . Nous pouvons en quelques clics, créer, modifier, supprimer, démarrer, arrêter, suspendre ou visualiser l’état d’une machine.

Des outils, en lignes de commandes, permettent des fonctionnalités plus poussées, telles que la sauvegarde à chaud par snapshot ou la restauration.  Enfin, des fonctions de clustering permettent, par exemple, la migration à chaud de machines virtuelles d’un serveur physique à un autre.

Je vous propose ci-dessous, trois petites démonstrations en screencast. La première montre l’utilisation de l’interface Web pour la création et l’installation d’un serveur virtuel kvm sous Debian Squeeze, la deuxième, le clonage de ce serveur à l’aide des outils de snapshot et de restauration et enfin, la troisième, la création d’un cluster de deux serveurs Proxmox VE ainsi que la migration d’une machine virtuelle d’un serveur vers l’autre.

Démo n°1 – Installation d’un serveur virtuel Debian.

Click here to view the video on YouTube.

Démo n°2 – Utilisation des outils de sauvegarde et de restauration pour le clonage d’une VM.

Click here to view the video on YouTube.

Démo n°3 – Création d’un cluster Proxmox VE et migration à chaud.

Click here to view the video on YouTube.

Sources :

• Site officiel Proxmox,
• Wikipedia.

Le problème principal de système, tel qu’il est décrit, est l’absence de maîtrise de la bande passante utilisée… Quand les « synchros » se mettent en route, la connexion Internet en prend un coup, souvent au dépend d’autres services. En bref, « ça rame dur ! ».

Une bonne solution pour ne pas pénaliser l’utilisation courante du réseau serait de gérer de la QoS (qualité de service), mais ça reste assez lourd à mettre en place… La gestion de la QoS au sein d’un réseau fera très probablement l’objet d’un prochain billet. En attendant, je vais aborder une solution très simple, qui permet de limiter la bande passante au niveau des clients.

« Trickle » est un gestionnaire de bande passante en espace utilisateur. Dans son utilisation la plus simple, il permet de lancer une commande en limitant sa bande passante montante (upload)  ou descendante (download), avec, respectivement, les options ‘-u‘ et ‘-d‘.

L’exemple suivant va lancer « wget » (pour télécharger les sources d’un noyau linux depuis kernel.org) en limitant l’utilisation de la bande passante à 20 Ko/s :

$ trickle -d 20 wget -c  http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.35-rc3.tar.bz2

Autre exemple : l’utilisation d’unison pour synchroniser un dossier via ssh en limitant le débit montant à 10 Ko/s et le débit descendant à 30 Ko/s.

$ trickle -u 10 -d 30 unison ~/JopaOne ssh://joel@monserveur.jopa.fr//home/joel/JopaOne

Trickle peut fonctionner en mode « collaboratif » grâce à un démon : trickled, qui peut, lui aussi, être lancé en espace utilisateur. Contrairement à l’utilisation précédente, la limitation n’est plus définie pour chaque commande mais  la bande passante maximale est passée en paramètres au démon et partagée par toutes les instances de trickle.

$ trickled -u 10 -d 30 

$ trickle unison /home/joel/JopaOne ssh://joel@monserveur.jopa.fr//home/joel/JopaOne -batch

$ trickle wget -c  http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.35-rc3.tar.bz2

Si besoin, il est également possible de prioriser certaines applications par rapport à d’autres pour ce partage de ressources. Je vous renvoie vers le man ou le site du projet pour la liste des options et paramètres disponibles.

Lien :

Trickle (http://monkey.org/~marius/pages/?page=trickle)

Tor (The Onion Router) est un réseau permettant la transmission anonyme de paquets TCP au travers d’internet…

…Au lieu d’emprunter un itinéraire direct entre la source et la destination, les paquets de données suivent une trajectoire aléatoire à travers plusieurs relais…

La suite de ce billet donne une brève introduction à Tor et à son principe de fonctionnement, pour finir par un exemple pratique d’installation et d’utilisation.

Comment ça marche ?

Après interrogation d’un serveur Tor, le client reçoit une liste de noeuds. Il construit alors un chemin aléatoire au travers, de telle sorte que chaque relais ne connaisse que l’adresse de son prédécesseur et de son successeur. Aucun noeud ne connait à lui seul le chemin complet.

Un nouveau chemin sera recalculé régulièrement.

Pour garantir sa confidentialité dès le départ, un paquet tcp est chiffré « en couches » successives avec la clef publique de chaque noeud, en commençant par le dernier…

Lorsque le paquet parcours son chemin, chaque couche de chiffrement sera enlevée par son noeud respectif, jusqu’au dernier, qui transmettra alors le paquet en clair au serveur destinataire. Je vous laisse faire l’analogie avec l’oignon… Même si mon schéma est un peu « carré ».

Il faut être conscient, cependant, que Tor a ses limites : Il gère seulement le transport des paquets TCP et n’assure pas de protection en UDP. Protocole utilisé entre autres pour les requêtes DNS. De plus, une page web peut récolter directement des informations privées (dont l’adresse IP), directement auprès du navigateur, par l’utilisation de Javascript ou la lecture de cookies.

Pour la navigation Web, on va généralement coupler Tor  à un serveur mandataire (proxy) tel que privoxy. Ce dernier va faire l’interface entre le navigateur et Tor, tout en fournissant un filtrage anonymisant supplémentaire (gestion des cookies, des accès, suppression des pubs, etc…).

En pratique

Tor est disponible sous licence BSD et facilement installable pour la majorité des distributions Linux et BSD. Il est également disponible pour de nombreuses plateformes telles que Windows, OSX ou Androïd… si si !).

Sous Ubuntu 10.4 :

 # echo "deb http://deb.torproject.org/torproject.org lucid main" >
         /etc/apt/sources.list.d/tor.list
 # gpg --keyserver keys.gnupg.net --recv 886DDD89
 # gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
 # apt-get update
 # apt-get install tor privoxy
. 

Un (tout) petit peu de configuration…

/etc/privoxy/config/

...
#  Décommenter la ligne suivante pour connecter Privoxy à Tor
forward-socks5   /               127.0.0.1:9050 .
...
# Il peut être judicieux de commenter la ligne suivante pour
# que les logs ne soient pas écrits.
# logfile logfile
...

On redémarre tout ça :

 # /etc/init.d/tor restart
 # /etc/init.d/privoxy restart

Privoxy doit ensuite être déclaré comme proxy dans les préférences du navigateur ou directement dans les préférences réseaux de Gnome. Dans l’exemple, nous avons bien une installation locale (127.0.0.1) et le port laissé par défaut (8118).

Le premier indice permettant de conclure que la configuration est bonne est la lenteur de la navigation. Le passage au travers du réseau Tor ne se fait pas sans perte de performances…

Le second peut se trouver sur la page : http://www.monip.org, qui ne devrait plus retourner notre adresse IP publique, mais celle du dernier relai traversé.

Au delà de la navigation

Au delà de la navigation web et des services pris en charge par le proxy, TOR est capable de sécuriser les connexions d’autres services grâce à la commande « torify« . Par exemple, la commande suivante permet une connexion ssh à travers le réseau Tor.

$ torify ssh mon.serveur.public.et.fictif.com

Voilà pour un petit tour rapide au pays de Tor… Pour (beaucoup) plus d’informations, je vous conseille de visiter le site officiel du projet et sa page Wikipédia.

Liens :

• Tor Project,
• Wikipedia – Tor (Réseau),
• Privoxy.

Ces deux applications sont très similaires et proposent, entre autre, un espace de stockage en ligne de 2 Go, dans une version de base gratuite, ainsi que des options payantes permettant d’étendre la capacité à 50 Go ou plus. A ce jour, il faut compter un peu moins de 10 € par mois pour 50 Go. Dropbox propose un système de parrainage qui vous fera gagner 250 Mo supplémentaires chaque fois que vous parrainez une nouvel inscrit (dans la limite de 8Go).

Les fichiers sont accessibles depuis n’importe quel ordinateur connecté à Internet via une interface web. Ceci n’est pas pour déplaire à Mamie,  qui se voit rassurée de pouvoir sauvegarder ses précieuses recettes de cuisine à l’abri d’un incendie ou de je ne sais quelle autre catastrophe domestique.

L’installation d’un logiciel client sur un ou plusieurs postes va permettre de synchroniser un répertoire local avec l’espace de stockage en ligne. Ainsi, un fichier ajouté dans ce dossier sera automatiquement ajouté par synchronisation dans l’espace en ligne.  Ce dernier se synchronisera à son tour avec les autres machines sur lequel le client est installé. C’est très pratique pour Mamie, qui peut taper sa recette de cookies au chocolats sur l’ordinateur de son bureau et l’emporter à son club de cuisine sur son Ipad automatiquement synchronisé – Qu’elle frimeuse cette mamie –   Pour cela, je dois préciser qu’elle a une préférence pour DropBox, porté sur de nombreux systèmes, contrairement à Ubuntu One, qui reste encore limité à un environnement Ubuntu.

Image : Dropbox.com

Enfin, parmi les multiples utilisations possibles, nous trouvons bien entendu la possibilité de partager des fichiers ou des dossiers avec d’autres utilisateurs. Très pratique pour Mamie, qui peut diffuser, à toute la famille, les photos de ses pâtisseries qu’elle prend en 10 MégaPixel grâce à son réflex numérique.

Outre la capacité limitée dans les versions gratuites, le fait que les fichiers soient stockés en clair, on ne sais où, peut-être perturbant. Il est bien sûr possible de chiffrer les données avant leur stockage, mais il faut bien avouer que ce n’est pas très pratique.

Sachant que des outils libres, tels qu’ unison, on largement fait leurs preuves en matière de synchronisation, l’idée de construire ma propre architecture « JopaOne » m’a traversé l’esprit. C’est alors que je suis tombé sur le tuto de KIK-IT : UbuntuOne VS MyOne, décrivant exactement ce que je souhaitais faire : Un espace de stockage sur un de mes serveurs et des répertoires locaux sur mes différentes machines, le tout synchronisé grâce à unision,  de préférence à travers ssh…

Pour conclure et je pense que Mamie sera d’accord avec moi, ma préférence va vers DropBox pour le partage de fichiers non sensibles avec les amis. Ce dernier est plus abouti qu’Ubuntu One et bien plus rapide pour  les synchronisation. La disponibilité du client sous de multiples plateforme est un de ses atouts majeurs… Mamie nous fait remarquer que le client « Androïd » est très sympathique pour ajouter son Smartphone

Pour la synchronisation de documents entre mes machines, j’ai préféré une solution basée sur Unison et ssh… Il n’y a pas a dire, on est bien plus tranquille quand les fichiers sont sur un serveur bien à nous…

Liens :

• Ubuntu One
• DropBox
• MyOne (KIK-IT)

Avec son chipset wifi Atheros supportant le mode monitor et l’injection de packets, sans oublier son connecteur SMA permettant de raccorder une antenne extérieure, la Fonera semble toute indiquée pour tester la sécurité de son réseau Wifi (j’ai bien dit « son » !).  D’autant plus que la suite aircrack-ng est disponible en paquet sous Kamikaze. Ce qui va inévitablement pêcher, c’est la puissance du CPU (Atheros AR2315) avec ses pauvres 183.5 BogoMIPS et éventuellement un léger problème de stockage – Quoique, la Fonéra 2 et son port usb permettent de facilement palier à ce manque de place.

Nous pouvons, bien sûr, bricoler une solution pour contourner le problème en enregistrant les dumps sur une partition réseau (nfs, smb, etc…) ou un  quelconque support usb. Le tout étant de faire tourner les outils gourmands en ressources  sur une autre machine. Ca fonctionne, mais ça reste du bon vieux bricolage…

Heureusement, les supermans et spidermans de la team aircrack-ng ont prévu une solution bien plus élégante… Dans ce cas précis, c’est par airserv-ng qu’ils vont briller de mille éclats.

- Au passage, merci à eux pour tous leurs outils robustes et fonctionnels ! -

Airserv-ng est un serveur de cartes wifi qui va permettre à de nombreuses applications (au moins celles de la suite aircrack-ng) d’utiliser la carte via une connexion TCP client-serveur.

Son utilisation est assez triviale, nous allons le voir dans un petit exemple.

1 – Pré-requis

Pour notre exemple, nous utiliserons :

• Une Fonera
  • installée sous OpenWrt Kamikaze (version 8.09),
  • aircrack-ng installé  (version 1.0 rc1 r1142 : opkg update && opkg install aircrack-ng),
  • l’interface ethernet configurée (192.168.1.1) :
  ^?View Code INI

  # /etc/config/network # Copyright (C) 2006 OpenWrt.org   config interface loopback option ifname lo option proto static option ipaddr 127.0.0.1 option netmask 255.0.0.0   config interface lan option ifname eth0 option proto static option ipaddr 192.168.1.1 option netmask 255.255.255.0

• l’interface wifi activée (/etc/config/wireless) :

# /etc/config/wireless
config wifi-device       wifi0
   option disabled           0
   option diversity          0
   option type           atheros
   option channel          auto
   option txantenna         1
   option rxantenna         1

• Un PC sous Debian Lenny
  • aircrack-ng installé ( apt-get update && apt-get install aircrack-ng ),
  • L’interface ethernet configurée (192.168.1.2) et connectée à la Fonera.

2 – Sur la fonera (le serveur)

Commençons par passer la carte en mode monitor :

root@OpenWrt:~# airmon-ng start wifi0

Interface       Chipset         Driver

wifi0           Atheros         madwifi-ng
ath0            Atheros         madwifi-ng VAP (parent: wifi0) (monitor mode enabled)

Et lançons airserv-ng :

root@OpenWrt:~# airserv-ng -d ath0
Opening card ath0
Setting chan 1
Opening sock port 666
Serving ath0 chan 1 on port 666

Par défaut, le port utilisé est le 666 et la carte wifi est positionnée sur le channel 1. Ces paramètres peuvent respectivement être changés par les options -p et -c.

3 – Sur la station (le client)

L’utilisation des outils sur le PC ne change que par le nom de l’interface wifi à utiliser. Il suffit tout simplement de préciser l’adresse IP du serveur, suivi du numéro de port TCP à la place du nom de l’interface :

192.168.1.1:666

Par exemple pour airodump-ng :

# airodump-ng 192.168.1.1:666
CH  4 ][ Elapsed: 32 s ][ 2009-02-06 06:30

BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:18:84:A0:FC:ED   45       40        0    0  11  54e. WPA2 CCMP   PSK  wjopa2
 00:18:84:24:1E:7D   43       81        0    0   1  54e. OPN              FON_LINET
 00:18:84:24:1E:7E   41       96        0    0   1  54e. WPA  TKIP   PSK  LINET_PRIV
 00:1E:37:96:F8:27   14       57        0    0  10  54e  WPA  TKIP   PSK  Livebox-461a

 BSSID              STATION            PWR   Rate   Lost  Packets  Probe

4 – En conclusion…

L’intérêt d’un tel montage est, bien sûr, l’utilisation du matériel wifi dont est doté la Fonera, par une station qui en est dépourvu mais dispose d’un processeur bien plus performant. Outre c’est avantage, il n’est pas déplaisant de pouvoir transformer notre Fonera en sonde wifi, que nous pourrons connecter au plus près de notre point d’accès. Nous réaliserons ainsi nos tests, tranquillement, sans sortir du bureau et surtout, sans devoir répondre aux collègues qui se demandent pourquoi nous travaillons dans la cage d’escalier, un labtop sur les genoux… – Hum… Ils sont vraiment bizarres ces gars de l’info…-

En terminant cet article, j’imagine, qu’en bidouillant un minimum, nous pourrions nous affranchir du transformateur secteur de la Fonera en l’alimentant grâce à une batterie, de l’usb ou pourquoi pas,  depuis un switch POE.  Décidément, c’est vraiment un beau jouet cette Fonera !!!

Pour cela, je dispose d’une Fonera 2.0 flashée sous Openwrt kamikaze (8.09 RC1) sur laquelle est connecté un disque usb formaté en ext3. Le réseau est correctement configuré et opérationnel.

Commençons par installer quelques paquets indispensables :

• kmod-usb2 : gestion de l’ USB,
• kmod-usb-storage : gestion des périphériques de stockages USB,
• kmod-fs-ext3 : prise en charge des systèmes de fichiers ext3,
• nfs-kernel-server : serveur nfs,
• nfs-kernet-server-utils : utilitaires optionnels (tels que nfstat),
• portmap : indispensable pour le serveur nfs et pourtant oublié dans les dépendances.

# opkg update
# opkg install kmod-usb2
# opkg install kmod-usb-storage
# opkg install kmod-fs-ext3
# opkg install nfs-kernel-server
# opkg install nfs-kernel-server-utils
# opkg install portmap

Une fois les paquets installés, le disque devrait être reconnu et automatiquement monté dans /mnt/usbdrive.

Le suite consiste à configurer l’export nfs.

Pour cela, il faut éditer le fichier /etc/exports.

/mnt/usbdrive    192.168.7.0/24 (rw,no_root_squash,async)

• export de /mnt/usbdrive,
• pour toutes les machines du réseau 192.168.7.0,
• en lecture et écriture,
• autoriser root à accéder aux fichiers,
• en asynchrone.

Il ne reste plus qu’à démarrer le serveur nfs :

# /etc/init.d/portmap start
# /etc/init.d/nfsd start

Pour activer le lancement automatique des démons au démarrage d’openwrt :

# /etc/init.d/portmap enable
# /etc/init.d/nfsd enable

Côté client nfs, le montage se fait classiquement :

# mount -t nfs adresse_ip_fonera:/mnt/usbdrive /mnt/owrt

Le point d’accès configuré précédemment, avec une Fonera  (sous OpenWRT Kamikaze 7.09), fonctionne à merveille ! Le signal wifi est juste un peu trop faible à l’autre bout de la maison et sur la terrasse (non… pourtant je n’habite pas un château…).  J’ai donc cherché à configurer une deuxième Fonera en relai wifi et heureuse surprise:  la puce atheros et Kamikaze vont encore une fois me simplifier la tâche.

(image : souce wikipedia )

Je vais pour cela configurer un système WDS (Wireless Distribution System) pour que les données reçus par le relais soient tout simplement répétées vers le point d’accès maître et étendre ainsi la zone de couverture de mon réseau.

La configuration suivante est possible sur les dernières versions d’OpenWrt (testé sur le build du 15/10/2008). Elle présente l’avantage d’authentifier les point relais au même titre qu’un client wifi classique. L’ajout de répéteurs supplémentaires peut donc se faire sans aucune intervention sur le maître.
Dans une configuration plus classique (présentée en deuxième partie), le maître est connecté à chaque répéteur par une liaison wds spécifique, ce lien étant affecté à une interface wifi spécifique, il faudra configurer sur le maître autant d’interfaces virtuelles que de répéteurs présents (plus une pour l’ap).

Avec la version dev

Côté maître

La configuration du point d’accès est tout à fait classique.  Il suffit juste de préciser qu’il accepte des connexions WDS en ajoutant la ligne « option wds 1 » à sa configuration. Et hop ! Openwrt se charge du reste ; )

/etc/config/wireless

config wifi-device        wifi0
option type               atheros
option disabled           0
option channel            11
option diversity          0
option txantenna          1
option rxantenna          1
option distance           3000
 
config wifi-iface
option device             wifi0
option network            lan
option mode               ap
# OPTION WDS
option wds                1
option ssid               wjopa
option encryption         psk2
option key                maclefsecrete

La configuration des interfaces réseau ne change pas… Je la remets juste pour mémoire…

config interface loopback
    option ifname   lo
    option proto    static
    option ipaddr   127.0.0.1
    option netmask  255.0.0.0
 
config interface lan
    option ifname      eth0
    option type        bridge
    option proto       static
    option ipaddr      192.168.1.253
    option netmask     255.255.255.0
    option gateway     192.168.1.254
    option dns         192.168.1.254

Côté client (répéteur)

Côté répéteur, rien de bien compliqué non plus… Nous allons configurer deux interfaces wifi.

• La première pour communiquer avec le point d’accès principal,
• La deuxième pour accueillir les connexion clientes de la zone.

Il est indispensable d’utiliser le même canal (channel), le même SSID et la même clef que le point d’accès principal.

/etc/config/wireless

config wifi-device            wifi0
    option type               atheros
    option disabled           0
    option channel            11
    option diversity          0
    option txantenna          1
    option rxantenna          1
    option distance           3000
 
config wifi-iface
    option device             wifi0
    option network            lan
    option mode               sta
    # OPTION WDS
    option wds                 1
    option ssid               wjopa
    option encryption         psk2
    option key                maclefsecrete
 
config wifi-iface
    option device             wifi0
    option network            lan
    option mode               ap
    option ssid               wjopa
    option encryption         psk2
    option key                maclefsecrete

La configuration de l’interface « filaire » n’est pas obligatoire ici, mais reste bien pratique pour pouvoir prendre la main à distance (ssh). Un autre avantage est la possibilité d’y connecter une ou plusieurs machines (via un switch), notre liaison WDS faisant office de pont wifi. Dans tous les cas, les interfaces wifi doivent être regroupées au sein d’un même bridge.

/etc/config/network

config interface loopback
    option ifname   lo
    option proto    static
    option ipaddr   127.0.0.1
    option netmask  255.0.0.0
 
config interface lan
    option ifname      eth0
    option type        bridge
    option proto       static
    option ipaddr      192.168.1.252
    option netmask     255.255.255.0
    option gateway     192.168.1.254
    option dns         192.168.1.254

Avec la version 7.09

Dans une configuration plus classique, nous devons configurer manuellement la liaison wds entre le maître et le relais. La configuration wifi est identique qu’il s’agisse de l’un ou l’autre.

/etc/config/wireless

config wifi-device            wifi0
    option type               atheros
    option disabled           0
    option channel            11
    option diversity          0
    option txantenna          1
    option rxantenna          1
    option distance           3000
 
config wifi-iface
    option device             wifi0
    option network            lan
    option mode               ap
    option ssid               wjopa
    option encryption         psk
    option key                maclefsecrete
 
# WDS
config wifi-iface
    option device             wifi0
    option network            lan
    option mode               wds
    option ssid               wds
    option encryption         psk
    option key                maclefsecrete2

Il est possible ici d’utiliser une clef différente pour les points d’accès et la liaison wds.

A la manière de « top« , qui affiche en pseudo temps réel l’utilisation des ressources systèmes par les processus, iftop permet de visualiser l’utilisation de la bande passante d’une interface réseau (d’où le prefixe « if »). D’un seul coup d’oeil, vous pourrez visualiser les machines connectées à votre serveur et la bande passante qu’elles consomment.

iftop est disponible en paquet dans la majeure partie des distributions. Si ce n’est pas votre cas, vous pouvez toujours télécharger les sources sur freshmeat, sa compilation ne pose aucune difficulté.