Specs
Un article de Toulouse Sans Fil, un réseau wifi libre sur Toulouse.
Accueil | Technique | Spécifications
Carte de Toulouse sans Fil
Comment se connecter
Le matériel actuellement le mieux adapté pour se connecter est le LinksysWRT54g. Mais il n'est pas le seul ! Un PC sous Linux ou windows, un mac, etc + OLSR + une carte wifi quelquonque ça marche aussi bien ! Il suffit donc de s'en procurer un (via les Achats Groupés) et de suivre les spécifications ci-dessous.
Des pages spécifiques concernant des réalisations simplifiées destinées au moins aguerris apparaitront au fur et à mesure de nos travaux. Pour l'instant, nous expérimentons et proposons les solutions qui nous parraissent les plus viables dans ces specifications.
Specifications pour le réseau toulouse-sans-fil
Il s'agit d'une tentative de CR d'une réunion nocturne de membres de l'association et du CA destinée à poser clairement les bases écrites du réseau TSF.
Principe de travail : après avoir figé une partie du document, si on ajoute une note ou un § : on lui affecte un numero en l'indiçant avec une lettre. exemple : entre le §3.5 et le §3.6 on insere la note 3.5.a. On ne change pas la numérotation des §. De même si un § est supprimé, on garde juste son indice et on le note comme obsolete (ex. 3.5 obsolète). Et ce jusqu'au moment où le document est de nouveau figé. Merci.
- 05/09/2006 : Grompf. Nouvelle version figée. renumérotation des chapitres.
Vocabulaire spécifique à ce document
1.1 le réseau : Réseau citoyen sans fil sur Toulouse, aussi appellé ici "Réseau TSF".
1.2 opérateur : personne bénévole, détenant et opérant un élément fonctionnnel du réseau TSF. Personne responsable de cet élément.
Liste des pages de spécification
2.1 Specification générales (cette page)
2.2 Annexe OLSR
2.3 Annexe plugin de publication d'information technique
2.4 Annexe serveur de publication d'information technique
2.5 Annexe Etablissement d'un VPN par OpenVPN
2.6 Annexe Accès de maintenance par SSH
Grands principes
3.1 le but de l'association est de mettre en place un réseau sans fil collaboratif et citoyen ouvert à tous sur l'aglomération toulousaine au sens large. Ce type de réseau est souvent nommé "réseau communautaire" par nos amis anglosaxons qui ont une autre approche culturelle concernant la dénomination de ce type d'activité.
3.2 L'association a pour but de garder la cohérence de ce réseau et ne presume pas de l'usage qui en sera fait, des usages qui seront inventés, etc.
3.3 L'association fournit une aide technique à la construction et au bon fonctionnement du réseau , mais elle n'en est ni la propriétaire ni la responsable du matériel utilisé, des données qui y transitent, de la sécurité des machines qui y sont connectées et des usages qui en sont faits. Chaque membre et opérateur d'un élément du réseau est responsable de celui-ci. Tout opérateur d'un relais ou d'un node est responsable des transactions initiées par son node ou à sa destination.
3.4 L'association et le réseau TSF n'ont pas pour but ou pour vocation la fourniture de connexion à internet, et ne détient pas de licence pour être FAI.
3.5 le nom du réseau sera "toulouse-sans-fil.net". Il fera ainsi référence au nom de domaine publique de l'association et permettra à toute personne de trouver des informations sur notre vitrine publique sur internet. Il est à noter que le prefixe "www." n'est pas mis en avant pour éviter d'ajouter une incitation à croire de le réseau TSF n'est qu'une extension d'internet.
3.6 Les modes de fonctionnement choisis devront tendre vers un mode de fonctionnement égalitaire non centralisé et non hierarchique, axé sur la coopération, la responsabilisation et la participation de chacun.
3.7 Chaque membre devra lui meme assurer l'entretien et la fourniture en energie de son matériel. L'association n'étant pas impliquée dans l'équipement individuel de chacun.
3.8 Le devoir minimal de tout membre de l'association sera quand il sera en ligne et connecté sur le réseau TSF de relayer sans distinction les données d'autres membres ammenées à transiter par son instalation.
3.9 L'association pourra être à meme d'emetre des avis pouvant aller jusqu'à des regles strictes concernant les techniques de régulation à mettre en place afin de maintenir l'intégrité du réseau et de son contenu.
3.10 L'association pourra être à meme d'émetre des avis pouvant aller jusqu'à des règles strictes concernant les techniques et les politiques à mettre en place afin de garantir un bon fonctionnement du réseau dans les limites imposées par le législateur.
Eméteur/récepteur à radio-frequences
Technologies
4.1.1 Il est donc choisi du fait de l'activité de l'association un support physique sans fil avec une préférence pour des normes interopérables sans restriction comme les normes IEEE 802.11b ou IEEE 802.11g.
4.1.2 Aucune licence spécifique ne devra être requise pour l'utilisation et l'acquisition de matériel.
4.1.3 La bande grand public libre dite ISM (industrielle, scientifique, médicale) sera utilisé. Le matériel le plus répandu est actuellement celui supportant la norme 802.11 dans la bande radio des 2.4GHz.
4.1.4 L'association statuera au cas par cas suivant les besoins pour les autres technologies et les variantes propriétaires du 802.11 : la contrainte majeure restant la plus large interopérabilité entre les differents acteurs du réseau.
Configuration pour la norme IEEE 802.11b/g
4.2.1 Le mode d'opération ad-hoc est choisi pour son fonctionnement égalitaire. Contrairement au mode infrastructure qui est foncierement hierachique, et naturellement destiné aux FAI.
4.2.2 Le bssid sera : toulouse-sans-fil.net
4.2.3 Le canal choisi après évaluation de l'occupation de la bande des 2.4GHz sera le 5 (2432MHz).
4.2.4 Les canaux de secours reservé pour des opérations particulières ou exceptionnelles (par exemple : une ségrégation de liens dans une zone congestionnée) seront les canaux 2 (2417MHz) et 8 (2447MHz). L'usage de ces canaux sera restreint pour conserver l'interopérabilité à l'interieur du réseau.
Ségrégation des données
4.3.1 Une clef WEP 128 bits sera utilisée pour prévenir les fuites ou les intrusions par malveillance ou par maladresse sur le réseau.
4.3.2 Elle pourra être changée périodiquement à la discretion des responsables de l'association.
4.3.3 Il est entendu par l'association et tous les opérateurs membres que ce chiffrage et cette clef ne sont qu'un moyen d'assurer une fonction de séparation de données entre TSF et le reste du monde à l'instar de la gaine d'un cable sur un réseau filaire. Il ne s'agit que d'une "cloture virtuelle" facilement mais volontairement franchissable et ne presentant en aucun cas une forme de chiffrage fort assurant une quelconque sécurité.
4.3.4 L'usage simultané des canaux hertziens, de l'indicatif du réseau, et de la clef WEP associée ne peut être que volontaire de la part des membres opérateurs, ou de toute personne exterieure à l'association.
Réseau (fonctions de base)
Routage
5.1.1 Un systeme de routage égalitaire et le plus automatique possible est choisi.. Le daemon de routage dynamique OLSR est choisi car ayant fait ses preuves dans differents groupes oeuvrant à la promotion des réseaux citoyens, et durant les expérimentation locales.
5.1.2 A l'interieur même du réseau TSf les données circulent normalement en clair sans chiffrage : tout opérateur est à même de pouvoir contrôler ce qu'il relaye si il le juge bon.
5.1.3 L'usage de matériel de chiffrage reste à la discretion et sous l'entière responsabilité des opérateurs communicant entre eux d'opérateur à opérateur.
5.1.4 Les spécifications liées à l'usage du daemon olsr.org (http://www.olsr.org) en tant que service de routage pour le réseau TSF se trouve dans l'annexe routage OLSR.
Norme réseau
5.2.1 la norme de communication par réseau IPv4 est actuellement choisie pour de simples raisons pratiques.
5.2.2 le plan d'adressage se fera sous la forme d'un adressage 10.31.0.0/8.
5.2.3 les adresses seront distribuées sur le principe du premier arrivé : premier servi. Une adddresse libérée sera placée temporairement en attente pour être ensuite remise dans la liste des adresses disponibles .
5.2.4 l'attribution des adresses sera effectué par l'association ainsi que les éventuels arbitrages afférents. Les décisions de l'association seront souveraines.
Norme de routage dans un relais multi-noeud (proposition)
5.3.1 Dans le cas d'un relais constitué localement de plusieurs noeuds colocalisés, il est nécessaire pour des raisons de performance d'utiliser un routage interne au noeud. Voir OpenWRT.org (http://www.openwrt.org)" : You MUST do this if you want to use ad-hoc mode, otherwise your throughput WILL suffer! (http://wiki.openwrt.org/OpenWrtDocs/Configuration)".
5.3.2 Ce routage sera differentié des routes usuelles du réseau TSF.
5.3.3 Le plan d'adressage interne se fera sous la forme d'un adressage 192.168.254.0/24
5.3.4 Ce réseau interne sera routable via OLSR.
5.3.5 A regler : empecher la visibilité des adresses internes depuis l'exterieur et rendre le réseau interne independant de tout conflit d'adressage (faire en sorte que plusieurs relais multi-noeuds puissent utiliser les mêmes adressages). A suivre sur la page discussion
Service de publication locale d'informations techniques
5.4.1 Un serveur http devra exister sur les machines et permettant de connaître les parètres locaux de communications, ainsi que l'état de la passerelle TSF consultée.
5.4.2 Les paramètres principeaux seront la configuration OLSR de la passerelle, l'état des interfaces pour lesquelles un routage OLSR intervient dans le cadre de TSF, les routes actives sur la machines, ainsi que le dénombrement des machines voisines. La présente liste de ces informations publiables n'est pas exhaustive. 5.4.3 Le port d'accès devra être décalé vers les ports supérieurs. Proposition d'usage : 42080. (base 42000 + n°port http)
5.4.4 Le serveur http devra librement permètre les accès en lecture à ces informations.
5.4.5 Tout accès en écriture pourra se faire sous la responsabilité de l'opérateur et de façon extremement protégée de façon à ne pas mettre l'intégrigé du réseau en jeu.
5.4.6 Les machines les plus simples (par exemple les machines individuelles non affectées exclusivement à TSF) ne sont pas obligées de fournir ce service bien que sa présence soit formellement conseillée pour faciliter la surveillance du réseau et toute maintenance.
5.4.7 Les spécifications liées à la mise l'usage du plugin http info fourni avec le daemon olsr.org (http://www.olsr.org). se trouve dans l'annexe http info.
5.4.8 Les spécifications liées à la mise l'usage d'un serveur http et de scripts pour fournir un service de consulation d'information technique se trouve dans l'annexe serveur http.
Service de nommage
5.5.1 l'utilisation d'un service de nomage (DNS) reste à étudier. Point majeur remis à une prochaine réunion. Il est a noter que l'usage simultané d'internet et du réseau TSF par des personnes non ou peu averties devra être pris en compte lors de l'étude de cas.
5.5.2 L'usage du plugin OLSR nameservice permet dans sa version actuelle de mettre en place un système de DNS réparti sur le réseau demandant très peu de ressources pour être opérationel. L'adjonction d'un DNS réel (exemple dnsmasq sur machine de type UNIX) permet une diffusion et une utilisation aisée de ces informations.
5.5.3 Attention : plugin en cours de tests.
5.5.4 Un systeme d'inclusion de fichier de déclaration dans l'équivalent du fichier /etc/hosts pourra être mis à disposition à partir des informations données par les membres de l'association pour les opérateurs ne pouvant gérer de dns réparti sur OLSR. Ces fichiers à inclure seront mis à jour et mis à disposition par l'association sur son site.
Service de maintenance
5.6.1 Au minimum un service accessible en ligne de commande devra être disponible pour toute machine participant au réseau TSF et devant posseder un accès à distance.
5.6.2 SSH étant la méthode la plus courante pour effectuer des manipulations en ligne de commande de façon sécurisée : ce protocole est choisi pour remplir cette fonction.
5.6.3 Le port d'accès devra être décalé vers les ports supérieurs. Proposition d'usage : 42022. (base 42000 + n°port ssh)
5.6.4 Les spécifications liées à la mise en place d'un accès SSH sur une machine distante se trouve dans l'annexe SSH
VPNs externes
5.7.1 l'usage de VPNs externes au réseau TSF sera d'un usage reservé aux membres avertis de l'association pour le seul et unique but de désenclaver des nodes isolés.
5.7.2 les VPNs externes n'etant qu'un moyen transitoire de desenclavement l'établissement de ceux-ci est soumis a décision ou approbation de l'association.
5.7.3 Pour les membres non avertis une configuration clef en main pourra être mise en place par l'association sous réserve de la disponibilité des ressources humaines et matérielles associées. Ceci sans garantie de résultat sauf accord explicite.
5.7.4 Un VPN de type SSL sera choisi car non intrusif au niveau du noyau du système d'exploitation quel qu'il soit pour ce qui concerne les VPNs externes.
5.7.5 Ce VPN gérera ses identifications par certificats d'authentification, l'association ayant alors toute latitude pour révoquer un ou plusieurs certificats sans préavis.
5.7.6 L'association ou les personnes choisies par l'association géreront le système de création de certificat et les transmetront de mmanière fiable et sécurisée aux demandeurs pour leur permetre de réaliser leur connexions.
5.7.7 L'association ou les personnes choisies par l'association seront les seuls à détenir le certificat maître capapble de produire tous les autres certificats.
5.7.8 L'association ou les personnes choisies par l'association seront seuls responsables de la mise en oeuvre des serveurs de connexion des VPNs internes. Au minimum une machine fonctionnant 24/24 et accessible 24/24 sera strictement nécessaire.
5.7.9 Une redondance pourra être mise en place à la discretion de l'association pour assurer un meilleur fonctionnement de l'ensemble des réseau TSF et VPNs.
5.7.10 Tout VPN externe non configuré dans ces conditions ne sera pas supporté ou reconnu par l'association.
5.7.11 Les spécifications liées à la mise en place d'un VPN externe de type OpenVPN se trouve dans l'annexe OpenVPN
VPN inter régionaux
5.8.1 L'association pourra mettre en place des VPNs de pontage inter-régionaux.
5.8.2 Le choix des technologies sera fera par négociation directe entre associations régionales. Les protocoles devant être libre et les spécifications d'inter connexion ouvertes et documentées.
5.8.3 Un protocole d'accord d'inter connexion sera pris en compte au niveau politique par les associations s'interconnectant.
5.8.4 L'association ou les personnes choisies par l'association seront seuls responsables de la mise en oeuvre des serveurs de connexion des VPNs inter régionaux. Au minimum une machine fonctionnant 24/24 et accessible 24/24 sera strictement nécessaire.
5.8.5 Une redondance pourra être mise en place à la discretion des associations pour assurer un meilleur fonctionnement de l'ensemble des réseau TSF et VPNs inter régionaux.
5.8.6 La révocation des droits d'accès aux VPNs inter régionaux pourra aussi faire d'un protocole d'accord.
Charte d'inter connexion libre (proposition)
5.9.1 Le propriétaire, opérateur, ou responsable d'un réseau libre accepte de fournir un transit libre à travers son propre réseau libre. Il accepte de ne pas modifier ou d'interférer avec les données qui traversent son réseau libre, sauf quand des mesures techniques s'imposent (filtrage, gestion des débits, etc) pour maintenir la stabilité et l'intégrité du réseau.
5.9.2 Le propriétaire, opérateur, ou responsable d'un réseau libre accepte de fournir les données nécessaire à l'interconnexion ; ces données devant être fournies sous une licence libre.
5.9.3 Il n'y a aucune garantie de service. L'accès au réseau est fourni tel quel et ceci sans aucune garantie ou responsabilité contractuelle, commerciale ou légale.
5.9.4 Les facilités d'accès peuvent être réduites ou augmentées, voire annulées sans aucun préavis.
5.9.5 Le propriétaire, opérateur, ou responsable d'un réseau libre peut imposer sur son réseau libre, toute charte d'usage ne contrevenant pas aux points précédement cités.
VPN internes
5.10.1 l'usage de VPNs internes au réseau TSF sera librement autorisés. Se reporter au § 3.9.
5.10.2 L'association ne présume pas du type des VPNs qui seront utilisés de façon interne au réseau.
5.10.3 L'association ne présume pas du type de solution de chiffrage utilisée pour la réalisation de ces VPNs.
5.10.4 Les opérateurs de VPNs internes au réseau TSF sont pleinement responsables de l'usage qui en est fait, et des solutions utilisées.
Inter connexion de réseaux locaux
5.11.1 L'interconnection avec des réseaux privés via NAT sous responsabilité d'une personne morale sera possible uniquement après accord ecrit bipartite avec TSF (association, entreprise, administration, etc ).
5.11.2 Les personnes physiques sont nommément adherentes à l'association et relevent du cas général en ce qui concerne les activités d'interconnexion via NAT.
Routage TSF filaire
5.12.1 Les opérateurs pourront utiliser une interface ethernet et un système filaire spécialisé et ségrégé sur lequel un routage de type OLSR fonctionnera : ceci afin de fournir des services fonctionnant sur des machines spécifiques (serveurs divers) et sans occuper de bande passante hertzienne. Une interface hertzienne propre à l'opérateur servira alors de pont vers le réseau TSF en tant que tel et annoncera ces machines sur le réseau TSF.
5.12.2 Une interface ethernet filaire sur un routeur TSF pourra donc fonctionner en mode OLSR ou en mode NAT. Ces deux modes seront exclusifs.
Machines utilisables pour créer le réseau : le relais TSF
6.1 Il s'agit de la forme necessitant le moins d'investissements techniques et financiers, mais necessitant seulement de faire tourner olsr et d'obtenir une adresse IP auprès de l'association.
6.2 un relais ne peut avoir q'une seule interface sans fil et donc n'aura qu'une seule et unique adresse IP sur le réseau TSF (ainsi qu'un identifiant unique).
6.3 un relais n'a pas de contraintes opérationnelles, mais en contrepartie il ne peut pas offrir de services critiques au bon fonctionnement du réseau.
6.4 un opérateur de relais peut offrir les services (non critiques au fonctionnement du réseau) qu'il souhaite sur le réseau TSF.
6.5 un relais peut connecter son réseau privé au réseau TSF sous son entiere responsabilité en utilisant SA propre adresse TSF.
6.6 la seul obligation en faisant parti de TSF sera de faire tourner un service olsr ouvert aux membres du reseau. Il n'y a aucune obligation d'ouvrir un quelconque accès publique au relais en lui même.
6.7 L'opérateur du relais assurera la sécurité de son installation de la façon qui lui conviendra et en gardera la responsabilité.
6.8 exemple de matériel utilisable : un pc de bureau classique avec une carte wifi et une antenne pointée sur l'exterieur.
Machines utilisables pour créer le réseau : le node ou noeud TSF
7.1 le noeud TSF est une machine fiabilisée matériellement et logiciellement, et spécialisée dans la gestion de réseaux et des services qui y gravitent.
7.2 le noeud possede une ou plusieurs antennes.
7.3 Chaque antenne du noeud est dotée d'une interface sans fil. Tout jeu d'antennes couplées via un répartiteur et connecté à une seule interface sans fil sera considéré comme une seule et unique antenne.
7.4 Le noeud peut comporter plusieurs interfaces ethernet.
7.5 Le noeud se verra attribuer autant d'adresses IP que nécessaire pour chacune des interfaces utilisées.Cependant une seule adresse sera considérée comme l'adresse principale du noeud.
7.6 Le logiciel du noeud comporte au minimum un systeme d'exploitation , un firewall, un serveur SSH, et un routeur OLSR.
7.7 Le noeud doit pouvoir interconnecter un ou plusieurs réseaux internes privés avec le réseau TSF.
7.8 L'interconnexion de réseau privés se fera sous l'entiere et unique responsabilité de l'opérateur du noeud en utilisant sa propre adresse IP principale. L'interconnexion devra être donc faite sous couvert de NAT : aucune adresse ne sera atribuée sur le réseau TSF pour les cas d'interconnexion.
7.9 Le noeud peut permetre l'execution d'un routage OLSR sur une ou plusieurs interfaces ethernet de façon à permetre l'exploitation locale de plusieurs machines associée à TSF sans pour autant occuper de bande passante hertzienne.
7.10 Il sera attribué autant d'adresses que nécessaire pour les machines executant ce routage OLSR filaire et visibles sur le réseau TSF.
7.11 Le mode OLSR et le NAT sont exclusifs sur une interface ethernet donnée. Le basculement d'un mode à l'autre est proscrit.
7.12 Le noeud doit présenter une sécurité renforcée par un firewall et tout autre moyen que l'opérateur jugera bon afin de prevenir tout acte de malveillance mettant en jeu l'intégrité du réseau TSF.
7.13 le noeud ne doit héberger que les services nécessaires à ses fonctions.
7.14 Le noeud doit comporter des interfaces de maintenance et des dispositifs de mise à jour des parametres à distance. Point à définir remis à une prochaine réunion spécialisée.
Machines utilisables pour créer le réseau : TSFBOX, un node préconfiguré et fermé
8.1 Un noeud TSF nommé TSFBOX pourra être mise au point par l'association et proposé aux adhérents ne désirant qu'un élément matériel opérationel sans avoir plus de contrôle sur celui-ci.
8.2 Ce noeud sera préconfiguré et présentera une interface de contrôle fermée dont les réglages accessibles à l'utilisateur seront nommément identifiés.
8.3 Ces noeuds pourront être débloqués sur demande de l'utilisateur à partir du moment ou il prend à son compte toutes les responsabilitées associées au fonctionnement du noeud, et décharge l'association de la maintenance opérationnelle du noeud.
8.4 Dans tous les cas, ces noeuds appartiennent au final à l'utilisateur qui a pour charge d'en faire la maintenance physique.
8.5 Ces noeuds pourront être maintenables par l'association, ou par des personnes mandatées par l'association.
8.6 La définition complète est remise à plus tard lors d'une réunion "spécialisée".