École polytechnique de l'université de Nantes Département INFORMATIQUE Quatrième Année PROJET TRANSVERSAL En collaboration avec :

Transcription

1 École polytechnique de l'université de Nantes Département INFORMATIQUE Quatrième Année PROJET TRANSVERSAL En collaboration avec : L association Nantes-Wireless ANNEE UNIVERSITAIRE 2007/2008 AUTO-CONFIGURATION DE BORNES POUR RESEAU METROPOLITAIN SANS FIL Dossier de Conception Présenté par Florian DUPONT & Benoît FARRE Le : 15 février 2008 Jury : José MARTINEZ Rémi LEHN Fabien POULARD

2 Sommaire Introduction Présentation du sujet La première problématique La deuxième problématique Le réseau pour notre étude Les étapes de la réalisation L existant du projet Le chargement d un Firmware Enrichir le Firmware La configuration pour recevoir Internet La configuration des interfaces réseaux La configuration du Wifi Le routage OLSR Les règles Iptables Network Address Translation Communication entre les sous-réseaux La configuration de DnsMasq Domain Name Server Dynamic Host Control Protocol Remarques générales La conception des solutions Solution au problème du WDS Idées de solution pour la configuration automatique des interfaces Utilisation d un serveur DHCP Utilisation d un tirage aléatoire + test de disponibilité Aspects techniques de la réalisation Flashage du routeur avec le Firmware Kamikaze Installation des paquetages manquants sur le système Configuration initiale Tirage aléatoire et utilisation de WifiDog Configuration finale du routeur Tests & Evaluations de notre solution

3 5.1 Les contraintes Mesure de la bande passante Efficacité du tirage aléatoire Conclusion

4 Introduction Ce dossier présente la partie conception de notre projet transversal. Nous commencerons par faire un rappel de notre sujet, puis nous présenterons l existant du projet. Nous présenterons ensuite les solutions que nous allons apporter aux différents problèmes que nous auront présentés. Nous terminerons enfin par la présentation des différents tests que nous réaliserons à la fin du projet et qui nous permettront de tester la qualité de notre réalisation. Etant donné le caractère particulier de notre projet, nous n avons pas suivi les étapes classiques de développement. En effet, notre sujet («Auto-configuration de bornes pour un réseau sans fil») ne nous permet pas de réaliser les parties «Conception» et «Réalisation» indépendamment. Par conséquent ces deux parties se retrouvent entremêlées. Nous avons donc suivi une méthode de développement qui s apparente plus aux méthodes agiles qu à une méthode classique dans le sens où pour réaliser la phase de conception, nous avons été obligés de réaliser des tests en parallèle qui nous ont permit de vérifier la faisabilité de la solution que nous proposons. La partie réalisation a donc été largement entamée durant cette phase. Nous présenterons donc dans ce dossier la conception de la première partie de notre projet (qui en constitue la plus grosse partie) et un bon nombre d éléments qui se rapportent directement à la réalisation. La deuxième partie du sujet ne sera présentée que lors de la dernière phase du projet, en même temps que la réalisation définitive des deux solutions, et ne sera que brièvement abordée dans ce dossier. 4

5 1. Présentation du sujet Notre sujet de Projet Transversal nommé «Auto-configuration de bornes pour un réseau métropolitain sans fil» est redéfini dans cette partie. Nous abordons les différentes problématiques que nous devons résoudre et les contraintes auxquelles nous sommes confrontés. 1.1 La première problématique L association Nantes-Wireless désire mettre en place une solution pour faciliter la configuration des routeurs Wifi qu elle déploie sur l agglomération Nantaise. Dans l idéal, nous devrons apporter une solution d auto-configuration qui permettra de libérer les administrateurs des phases d installation et de configuration. Les avantages d une telle solution sont, par exemple, le déploiement rapide d un réseau pour un événement exceptionnel ou encore la facilité d utilisation qui permettrait à tout individu de réaliser cette installation. 1.2 La deuxième problématique Nous devons apporter une solution au problème de l accès des clients du réseau Wifi à Internet. En effet, lorsqu Internet est disponible sur le réseau, un client qui se connecte peut y avoir accès mais le client qui était connecté au réseau avant que l accès apparaisse, n en bénéficie pas. La solution actuelle à ce problème est, pour l hôte, d attendre la fin de son bail DHCP ou bien une déconnexion temporaire au réseau pour ensuite devenir un nouveau membre du réseau et récupérer les nouvelles configurations. Une solution est donc à apporter pour que les clients connectés avant l arrivée d une connexion Internet soient mis à jour et puissent en disposer pleinement. 1.3 Le réseau pour notre étude La figure 1 présente le réseau que nous utiliserons pour mettre au point des solutions pour résoudre les problèmes de l association et pouvoir les tester. 5

6 Figure 1: Plan du réseau Wifi de Nantes-Wireless Nous utiliserons 3 routeurs Wifi Linksys WRT54GL v1.1 : NW31, NW32, NW34. Chacun d entre eux fonctionne en mode Point d accès pour les clients qui veulent se connecter au réseau et en mode WDS avec les autres points d accès Wifi. Le protocole de routage OLSR est utilisé sur les interfaces communiquant en WDS. Tout d abord, le point d accès Linksys WRT54GL est constitué physiquement de 4 ports Ethernet, 1 port Internet et d une carte réseau Wifi. La figure 2 décrit le point d accès. Figure 2: Image d'un routeur Wifi Linksys WRT54GL 6

7 Un vlan «0» est créé entre les 4 ports Ethernet du point d accès et un second, vlan «1» avec le port WAN seul (Port Internet). Une interface Wifi «wl0» est configurée pour communiquer en Wifi. La figure 3 présente l architecture de fonctionnement du routeur Wifi. Figure 3: Schéma de l architecture d un routeur WRT54G Les étapes de la réalisation La figure 4 présente les grandes étapes de configuration et d installation des routeurs Wifi de l association. Le travail à réaliser est décomposé en 5 étapes que nous détaillons dans la partie suivante. L étude de ces étapes nous a amené à comprendre les problèmes auxquels l association fait face et à développer des solutions. Une partie plus technique sera présentée plus loin dans le dossier pour donner les directives et les conditions de développement de ces solutions. 1 Source : 7

8 Figure 4: Les différentes étapes de mise en fonctionnement des routeurs 8

9 2. L existant du projet Cette partie présente les configurations actuelles qu utilise l association et que nous avons mises en place avec les trois routeurs wifi Linksys WRT54GL v1.1 que l association nous a prêtés. Nous avons donc réalisé un mini-réseau (uniquement trois points d accès) semblable à celui actuellement déployé. Dans ce chapitre, nous allons présenter les différents modules qui composent la mise en place de ce dernier ainsi que les problèmes que rencontre l association et que nous devons résoudre. 2.1 Le chargement d un Firmware La première étape fut de mettre à jour chacun des points d accès avec le même Firmware, pour une question de simplicité de mise en œuvre de nouveaux changements. Le Firmware utilisé sera la version en cours de développement d OpenWRT : Kamikaze. Kamikaze est un Firmware récent et adapté aux périphériques que nous utilisons. Il a la particularité de permettre la configuration d un point d accès en mode AP (Access Point) et client (Station) en même temps. Kamikaze ne dispose pas d une interface graphique pour la configuration par un navigateur Web ; ce point peut être un inconvénient pour les non-initiés. Au-delà de ce problème, le Firmware propose pour la première fois, un système de configuration contenu dans des fichiers qui sont situés sur le disque dur et non plus dans la NVRAM. Notre problème dans le projet est que Kamikaze est long à installer en termes de configuration des interfaces, des protocoles, de téléchargement de paquetages Notre première idée est de concevoir un script ou un programme permettant en un minimum de commandes d installer le Firmware et de mettre à jour celui-ci. L idée est donc de faciliter l installation en ne laissant à l utilisateur que quelques paramètres à entrer. Figure 5: Envoi du Firmware par TFTP 9

10 2.2 Enrichir le Firmware Il est nécessaire de mettre à jour le Firmware, une fois l installation terminée. L opération consiste donc à télécharger les paquets manquants sur la version. Ces paquets sont relatifs à des commandes ou des services utilisables sous Kamikaze. Les paquets manquants pour notre projet sont les suivants : - OLSR (pour la mise en œuvre du routage OLSR entre les points d accès) - IP (la commande IP permet une plus grande souplesse pour la configuration ou la consultation des interfaces réseaux) - WL ou WLC (pour la configuration du Wifi et du WDS) - WifiDog (C est le portail d authentification sur le réseau qu utilise l association actuellement) Ces téléchargements se font grâce à la commande «ipkg» qui permet d indiquer vers quels sites web nous allons pouvoir trouver les paquets compatibles avec Kamikaze. Nous pouvons voir ici un des problèmes qui pourrait se poser : si le routeur ne dispose pas d un accès Internet, alors il est impossible d utiliser la commande ipkg. Il faut donc trouver une alternative, comme par exemple charger «manuellement» les paquets. Pour faciliter ces installations longues et répétitives, nous allons créer un script ou un programme rassemblant l ensemble des étapes à effectuer séquentiellement pour obtenir ces paquets et les installer proprement sans difficulté pour l administrateur. Cette solution constitue une étape de l auto-configuration ; en effet ce script ou ce programme sera lancé une seule fois : lors du premier démarrage du routeur avec le nouveau Firmware chargé. Figure 6: Etapes de Flashage et d'installation des paquets manquants 2.3 La configuration pour recevoir Internet La mise à jour et le téléchargement des paquets nécessitent une connexion à Internet. Cette connexion se fait automatiquement à l aide du port Internet situé au dos du routeur. Ce port a la particularité d être en demande permanente d adresse IP, il est client d un service d adressage dynamique (DHCP). Lorsque l on branche un câble sur ce port, il est nécessaire qu un serveur DHCP 10

11 soit démarré pour adresser le routeur wifi dynamiquement. Une fois cette étape réalisée, le routeur ajoute les nouvelles données dans sa table de routage et permet l envoie de paquets par défaut vers une passerelle Internet. La connexion vers Internet est automatisée et prévue dans les configurations générales du Firmware. Le problème pour l administrateur du point d accès est la nécessité d avoir à portée de main une connexion Internet distribuée par un serveur DHCP. Pour palier ce problème, la création d un script ou programme permettant de rentrer manuellement et statiquement les renseignements utiles pour se connecter à Internet pourra être développé. Ce script (ou programme) sera situé dans le dossier de l utilisateur «root» et pourra être exécuté par l administrateur. Celui-ci n aura qu à compléter les renseignements affichés. Il pourra être exécuté à n importe quel moment mais ne sera pas un script inclut au démarrage. 2.4 La configuration des interfaces réseaux A la suite du flashage, le routeur redémarre en activant les ports LAN et en s attribuant l adresse IP /24. Cette configuration par défaut permet de se connecter tout d abord en Telnet pour attribuer un mot de passe «root» à l aide de la commande «passwd root». Un redémarrage est ensuite nécessaire. Durant ce redémarrage, le serveur Dropbear (serveur SSH) est lancé. Ce serveur permet une administration du point d accès par une connexion SSH (Secure Shell) et désactive automatiquement l accès en Telnet. Une fois connecté en mode SSH, la première étape est de donner un nom au point d accès en modifiant le fichier /etc/config/system. La seconde étape est la configuration des interfaces du routeur contenues dans le fichier /etc/config/network. Cette étape nécessite une modification du contenu avec l éditeur de texte «Vi». On peut ainsi attribuer les adresses IP et les masques que l on souhaite. Le problème dans ces configurations est le risque d entrer de mauvaises adresses entrainant un dysfonctionnement du point d accès. La redondance des configurations peut être automatisée, pour éviter à l administrateur d effectuer pour chaque routeur ces manipulations et limiter le risque de mauvais paramétrage. La création d un script ou d un programme est envisagée pour résoudre ce problème. Il s appuiera sur le fait que la seule différence dans cette étape entre chaque routeur est le numéro du point d accès. En effet, à partir de ce numéro, nous allons pouvoir déterminer l adressage de toutes ses interfaces. L avantage sera une diminution du temps de configuration (par l exécution du script) et une simplicité de mise en œuvre. 11

12 Figure 7: Plan d'adressage de l'association Comme nous pouvons le constater, la plage d adresse /26 n est pour l instant pas utilisée. Elle nous permettra par la suite de configurer une interface Wifi virtuelle en mode client qui nous permettra de scanner le réseau sans avoir à déconnecter les clients du point d accès. Ce point sera vu plus loin dans le dossier. 2.5 La configuration du Wifi Cette étape permet d activer et de configurer les interfaces Wifi. A la suite du flashage, aucune interface Wifi n est activée sur le point d accès. Le fichier à configurer pour résoudre ce problème est /etc/config/wireless. Dans ce fichier, on règle différents paramètres pour chaque interface et on peut créer des interfaces virtuelles (notamment pour faire du WDS et pour simuler le mode client). Chaque interface est décrite par son nom, le périphérique auquel elle est rattachée, son mode de fonctionnement (Client, Point d accès, Adhoc, WDS) et différentes options liées au mode de fonctionnement. Cette étape est redondante dans la configuration du matériel pour l association et ne dépend que de l utilisation que l on veut faire du routeur. Pour notre projet, chaque point d accès est configuré en mode «AP» (point d accès) pour les clients, doit pouvoir communiquer avec les autres points d accès du réseau par l intermédiaire d interfaces WDS et doit pouvoir scanner le réseau via une interface client virtuelle (le scan du réseau ne peut être effectué qu en mode client). 12

13 La configuration du Wifi est donc divisée en trois étapes : la première est la configuration en mode point d accès, la deuxième en mode client et la dernière en mode WDS. Les deux premières étapes peuvent être automatisées par un script permettant la mise en place du routeur en mode AP pour les clients et en mode client virtuel. La dernière est par contre plus difficilement réalisable. En effet, la configuration d une interface WDS nécessite de connaître l adresse MAC du routeur avec lequel nous souhaitons créer la liaison. Pour créer une interface WDS avec chacun des routeurs situés dans sa zone de couverture, nous allons donc devoir récupérer chacune de leur adresse MAC. L enregistrement des adresses MAC des points d accès dans le réseau est réalisable par un script qui scannera le réseau et retiendra les adresses MAC des voisins. La modification du fichier /etc/config/wireless se fera en conséquence. Le principe est de créer des interfaces virtuelles avec chacun des routeurs voisins au moment du scan. Pour trouver les routeurs voisins, un scan du réseau via l interface client virtuelle que nous venons de créer sera fait périodiquement et sera lancé au démarrage. 2.6 Le routage OLSR Le protocole de routage utilisé par l association est OLSR (Optimized Link State Routing). Il n est pas préinstallé sur Kamikaze mais il peut être téléchargé avec la commande «ipkg install olsrd». Le paquet s installe sans problème et met en place une configuration «de base». Pour l association, il est nécessaire de modifier quelques paramètres notamment les interfaces sur lesquelles OLSR doit fonctionner. La configuration du protocole est similaire sur tous les routeurs de l association et ne dépend que du numéro du routeur qui permet de retrouver les adresses de toutes les interfaces. Cette configuration unique peut être faite au premier lancement du routeur Wifi et modifiée par différents scripts si nécessaire accédant au fichier de configuration /etc/olsrd.conf. 2.7 Les règles Iptables Iptables est la commande qui permet aux administrateurs réseaux de configurer Netfilter. Netfilter est un module qui fournit à Linux des fonctions de pare-feu, de traduction d adresse et de journalisation du trafic réseau. Il intercepte les paquets IP et procède avant et après au routage. Dans notre cas, Iptables doit être installé par la commande «ipkg install iptables» car le module n est pas présent dans la configuration d origine de Kamikaze. Ce module doit ensuite être paramétré pour faire de la translation d adresse, faire suivre les paquets entre les différents sous-réseaux (LAN, WLAN, WDS) et sécuriser le réseau global Network Address Translation Pour l accès Internet, il est nécessaire d ajouter une règle précisant que tous les paquets à destination de l interface eth0.1 (interface de sortie vers Internet) soient translatés par le principe du Network Address Translation (NAT). Un routeur fait du NAT (en Français de la «Translation d Adresse Réseau») lorsqu'il fait correspondre les adresses IP internes non-uniques et souvent non routables 13

14 d'un intranet à un ensemble d'adresses externes uniques et routables. Ce mécanisme permet de faire correspondre une seule adresse externe publique visible sur Internet (ici, l adresse IP de l interface eth0.1) à toutes les adresses d'un réseau privé (les sous-réseaux LAN, WLAN, WDS). La configuration de Netfilter s effectue donc en modifiant le fichier de configuration /etc/firewall.user. Dans ce fichier, il est possible d ajouter de nouvelles règles de filtrage et de NAT Communication entre les sous-réseaux Le second problème est le fait que les sous-réseaux soient à l origine bloqués pour communiquer entre eux. Il est donc nécessaire d ajouter des règles de FORWARD («de retransmission») des paquets sur les autres interfaces du routeur. Celles-ci sont aussi généralisables pour tous les routeurs de l association. Un script ou un programme sera réalisé pour généraliser les configurations du firewall Netfilter. 2.8 La configuration de DnsMasq DnsMasq est un serveur de cache DNS (Domain Name Server) intégrant un serveur DHCP (Dynamic Host Control Protocol). Il est spécialement adapté aux petits réseaux locaux Domain Name Server Le serveur cache DNS est conçu pour répondre aux requêtes DNS (requête de résolution de nom de domaine) des ordinateurs du réseau local (WLAN et LAN dans notre réseau). Son principal avantage est de réduire significativement le temps de latence car il interroge le moins possible les serveurs DNS du FAI (Fournisseur d Accès Internet) et enregistre les requêtes déjà effectuées. Il ne transmet donc la requête aux serveurs du FAI que si la réponse n est pas présente dans le cache Dynamic Host Control Protocol Le serveur DHCP permet de transmettre aux ordinateurs du réseau local la configuration de ce réseau. Il suffit de définir dans la configuration de DnsMasq les plages d adresses IP disponibles sur chaque interface pour les clients. Ceci s effectue en modifiant le fichier /etc/config/dhcp. Le problème présenté peut être résolu de manière automatique en une seule fois lors de l installation. Un script ou un programme configurera le fichier /etc/config/dhcp lors de l installation du Firmware. Les plages d adresse IP respecterons le plan d adressage proposé par l association. La configuration du serveur DNS s effectue en modifiant le fichier /etc/dnsmasq.conf. 14

15 2.9 Remarques générales La configuration d un routeur Linksys WRT54GL v1.1 utilisant Kamikaze peut se schématiser par la figure 8 qui modélise l ensemble des fichiers de configuration qui devront être modifiés pour faire fonctionner le réseau de l association. Figure 8: Arbre des dépendances des fichiers de configuration L ensemble des fichiers et processus à configurer ne dépend que de deux choses : - Le numéro du point d accès - Le nombre de point d accès voisins ainsi que leurs adresses MAC. Le numéro du point d accès permet de configurer l ensemble des interfaces en attribuant des plages d adresses IP et le nom du routeur automatiquement de la même manière sur chaque machine. C est un paramètre clé dans la configuration du routeur. En revanche, il est difficile de créer les interfaces WDS pour communiquer avec les autres points d accès du réseau de l association. Il est nécessaire de connaître l adresse MAC des voisins pour ensuite créer une interface virtuelle et la configurer pour communiquer avec eux. Cette étape doit être automatisée. L ensemble des solutions que nous proposons tiennent compte de ces remarques et répondent au problème en substituant ces deux paramètres. 15

16 3. La conception des solutions Cette partie justifie l utilisation du Firmware Kamikaze dans notre projet et met en avant les solutions que nous avons exploitées pour résoudre les problèmes de l association Nantes-Wireless. 3.1 Solution au problème du WDS La figure 9 modélise le fonctionnement d un point d accès incluant le principe automatique de scan du réseau en mode Client pour trouver les routeurs voisins. Des explications du fonctionnement sont fournies à la suite du schéma. Figure 9: Principe de fonctionnement d'un Routeur Le démarrage s effectue selon 3 points : - Présence ou non de Kamikaze sur le point d accès - Nécessité d installer des paquets manquants - Démarrage en mode opératoire (mode normal) Dans le premier cas, le point d accès n est pas du tout configuré pour fonctionner sur le réseau de l association ; il est donc nécessaire de le flasher et de le configurer. Dans le second cas, le routeur utilise déjà Kamikaze mais n est pas configuré pour communiquer comme les autres ; il faut donc le 16

17 mettre à jour et installer les paquets nécessaires à la configuration. Dans le dernier cas, le routeur fonctionne de manière autonome s il démarre en mode normal ; sinon il est reconfiguré. A la suite de chacune de ces trois parties, nous pouvons enfin commencer la configuration générale du point d accès (de tous les services) et le chargement des configurations pour le mode normal. Le routeur est donc autonome et peut fonctionner normalement avec son WLAN (Wireless Local Area Network) et son LAN (Local Area Network). Une nouvelle phase est ici rajoutée : l automatisation du WDS. Cette phase permet de scanner le réseau Wifi périodiquement (la période est à définir) en utilisant l interface virtuelle client que nous avons créée précédemment. Suivant les résultats du scan, on détecte ou non la présence d un ou plusieurs routeurs de l association et on récupère leurs adresses MAC. La récupération de ces informations permet ensuite de créer un nombre nécessaire d interfaces virtuelles WDS (au maximum 3) pour communiquer avec les routeurs voisins. Une reconfiguration et un redémarrage du routeur est nécessaire. Celui-ci redémarre en mode normal et retrouve son autonomie et se lance dans une nouvelle phase d attente. Avantage L avantage principal de cette première phase de résolution du problème est que l administrateur du point d accès est soulagé du travail de configuration des interfaces WDS. Celui-ci n a plus à intervenir dans la configuration de chaque routeur pour les faire communiquer ensemble. Inconvénient Le principal inconvénient est que les étapes de configuration dépendent encore d un paramètre qui n est pas auto-configuré : le numéro du routeur. Cette solution ne propose pas de système permettant d attribuer un numéro automatiquement au routeur lors de sa configuration ainsi il est encore nécessaire de le passer en paramètre au premier démarrage du point d accès. La partie suivante propose une solution à ce problème. 17

18 3.2 Idées de solution pour la configuration automatique des interfaces Utilisation d un serveur DHCP La première solution à laquelle nous avions pensé était basée sur l utilisation d un serveur DHCP central. Cette solution consistait à mettre le premier point d accès démarré en mode serveur DHCP pour l ensemble des autres points d accès sur les différents liens WDS créés. Cette solution aurait alors permis une simplification de l adressage de chaque point d accès puisque chacun d entre eux aurait donc été capable de déterminer les plages d adresses pour ses sous-réseaux Wifi et LAN d après l adresse qu il aurait reçue par le serveur DHCP (adresse qui contient notamment le numéro affecté au routeur et qui est la base de l adressage de toutes les interfaces). Après étude de cette solution, nous nous sommes rendu compte que malgré son apparente simplicité de mise en œuvre, cette-dernière était beaucoup plus compliquée qu il n y paraissait. Le premier problème est le fait que si le routeur possédant le serveur DHCP tombe en panne, alors c est l ensemble du réseau qui s effondre. Nous avons alors cherché une solution qui pourrait résoudre ce problème, et donc telle que le réseau ne soit pas centralisé autour d un serveur. Le deuxième problème est le fait que le serveur DHCP doit être joignable par tous les points d accès arrivant sur le réseau ; hors cela n est pas possible. En effet, un serveur DHCP ne peut attribuer des configurations dynamiques qu à des clients DHCP se situant sur son sous-réseau car les trames ARP et BOOTP ne traversent pas les routeurs. Ce problème pourrait néanmoins être résolu en utilisant des agents de relais DHCP. Comme son nom l indique, un agent de relais DHCP relaie les messages DHCP échangés entre un client et un serveur DHCP situés sur deux sous-réseaux différents séparés par ce-dernier. Ainsi chaque point d accès serait client DHCP du serveur central et à la fois serait agent de relais DHCP pour les autres points d accès arrivant dans le réseau. Un autre problème se pose, un serveur et un agent de relais DHCP doivent avoir des adresses IP statiques. Ainsi cette solution paraît trop difficile à mettre en œuvre et serait dangereuse de part sa stratégie de centralisation. De plus le fait de devoir spécifier des adresses statiques rentre en conflit avec notre sujet puisqu il va à l encontre d une autoconfiguration Utilisation d un tirage aléatoire et test de disponibilité La deuxième solution que nous proposons est un système de tirage aléatoire d un numéro au démarrage du routeur, présenté sur la figure

19 Figure 10: Principe de fonctionnement de la solution par tirage aléatoire Pour résoudre le problème de l auto-configuration des interfaces, il faut d abord affecter un numéro au routeur. C est ensuite à partir de ce numéro que seront configurées les adresses de chacune des interfaces du routeur. Présentation de la solution Tout d abord, le routeur va configurer ses interfaces avec une adresse que l on spécifie réservée : x. Le routeur va donc maintenant pouvoir communiquer avec les autres points d accès et notamment disposer d une connexion Internet si elle existe. Le routeur va ensuite se connecter au serveur d authentification WifiDog pour récupérer la liste des numéros des points d accès qui sont déjà en service. Une fois la liste récupérée, le routeur va tirer au hasard un nombre entre 1 et 253 et vérifier si ce numéro n est pas déjà utilisé. S il est libre, le routeur va alors reconfigurer toutes ses interfaces puis va s enregistrer auprès du service d authentification pour réserver le numéro sinon il va recommencer l opération jusqu à obtenir un numéro libre. Si le routeur ne dispose pas d une 19

20 connexion internet, il sera alors demandé à l opérateur de rentrer manuellement le numéro du routeur. Avantage Cette solution offre l avantage, si le routeur possède une connexion internet, de limiter le risque d erreur, notamment en évitant que deux routeurs possèdent le même numéro. Cette solution est intéressante dans la mesure où la plupart des routeurs disposeront d un accès Internet. Inconvénient Un inconvénient est lié au fait que le routeur «réserve» le sous-réseau X durant sa phase de lancement. Rien n empêche cependant deux routeurs de démarrer en même temps et de prendre cette même adresse. Pire encore, imaginons une coupure de courant qui toucherait plusieurs points d accès, ces-derniers redémarreraient alors tous au même moment. Une solution pour palier à ce problème pourrait être de demander à l opérateur si la configuration doit être faite au démarrage du routeur. Dans ce cas, l opérateur indiquerait au routeur de ne pas se reconfigurer s il s agit d un redémarrage intempestif. 20

21 4. Aspects techniques de la réalisation Nous faisons dans cette partie référence au travail qui sera produit pour mettre en œuvre les solutions expliquées dans la partie précédente. Nous expliquons, dans l ordre, les étapes partant du flashage des routeurs à la mise en œuvre de l auto-configuration. La chronologie n est plus respectée dans la solution proposée. Figure 11: Chronologie actuelle des modifications dans les différents fichiers par l administrateur 4.1 Flashage du routeur avec le Firmware Kamikaze Il existe différentes manières de flasher un routeur Linksys WRT54GL. Il est préférable de flasher le routeur par TFTP, notamment dans le cas où le flash ne fonctionnerait pas il serait alors toujours possible de transférer l image du Firmware précédant. La procédure de base en utilisant un client TFTP pour charger un nouveau Firmware sur le routeur est : - Mettre le routeur hors-tension - Lancer le client TFTP o Donner l adresse du routeur (TFTP ) o Mettre en mode octet/binary (binary) o Mettre le client en réception jusqu à la fin de la transmission (rexmt 1) o Envoyer le fichier (put openwrt-version-du-firmware.bin) - Allumer le routeur - Le client TFTP reçoit un accusé de réception et commence l envoi Cette procédure peut être réalisée en une seule ligne : echo e "binary\nrexmt 1\ntimeout 60\ntrace\nput openwrt-wrt54g-2.4- squashfs.bin" tftp Remplacer «openwrt-wrt54g-2.4-squashfs.bin» par le fichier correspondant si la version utilisée est différente. 21