Différences

Ci-dessous, les différences entre deux révisions de la page.

--- transmission:wifi [2019/12/14 11:27]
bikepunk [Le wifi]
+++ transmission:wifi [2020/08/19 13:59] (Version actuelle)
bikepunk [outils cartographiques]
@@ Ligne 116: / Ligne 116: @@
 multiprise, et des EdgeSwitchXP8 quand on veut configurer des VLAN.
-Antennes en IP statique 10.X.Y.Z, avec gateway par le routeur central de
+Antennes et switch en IP statique 10.X.Y.Z, avec gateway par le routeur central de
-la branche, mais on route/NAT surtout pas vers Internet pour éviter les
+la branche. Ça permet d'accéder à tous les équipements depuis n'importe quel point
+du réseau, par contre on ne route/NAT surtout pas vers Internet pour éviter les
 remontées d'info à Ubiquiti.
@@ Ligne 136: / Ligne 137: @@
 route des IP publiques dessus avec OSPF.  Wireguard sur les APU monte à
 Mbit/s, y a de la marge :)
+Depuis peu on commence à avoir des fibres noires entre le datacenter où on est présent et des points du réseau radio : dans ce cas, même plus besoin de tunnel !
 Pour la distribution des IP publiques aux abonnés on fait ça en DHCP avec
-backend Radius, mais honnêtement c'est un peu compliqué à utiliser.  Pour
+backend Radius, mais honnêtement c'est un peu bricolé et compliqué à utiliser.  Pour
 un petit déploiement avec un seul routeur central, du DHCP avec une base
 statique IP/MAC ça peut suffire.  Mais si tu veux partir sur la solution
-compliquée, on a des paquets Debian.  Zorun a un projet d'écrire un relais
+compliquée, on a des paquets Debian de notre version patchée de Kea.  Zorun a un projet d'écrire un relais
 DHCP propre qui correspond mieux à nos besoins, mais c'est pas pour tout de
 suite. Il a commencé à mettre des idées ici :
 https://code.ffdn.org/zorun/flexible-dhcpd
+Pour les routeurs abonnés, on a un petit script maison de génération d'image OpenWrt basé sur [[https://openwrt.org/docs/guide-user/additional-software/imagebuilder|ImageBuilder]] et [[https://openwrt.org/docs/guide-developer/uci-defaults|uci-defaults]]
+Ça génère une image avec un mot de passe root connu et un wifi pré-configuré. L'abonné peut bien sûr tout modifier, mais il suffit de faire un "reset" du routeur pour retrouver la configuration Rézine standard.
+Il y a plein d'outils qui existent pour générer des images OpenWrt, il y a une liste ici : https://openwrt.org/docs/guide-developer/imagebuilder_frontends
 Suivi des équipements (débit, signal radio, uptime, nb de stations) : mix
@@ Ligne 151: / Ligne 158: @@
 rien de le faire pour toutes les antennes.
-**
+Quelques liens de notre doc qui peuvent être utile :
-Les avantages à faire du DHCP :**
+  * Explications sur le réseau pour les abonnés : https://www.rezine.org/acc%C3%A8s_Internet_local/radio/
+  * Carte du réseau, mise à jour en permanence mais parfois cassée : https://www.rezine.org/documentation/plan_reseau_radio/
+  * Un peu de doc sur OpenWrt : https://www.rezine.org/documentation/routeur-openwrt/
+**Les avantages à faire du DHCP :**
 ) Les routeurs abonnés ont tous la même configuration. On peut faire une grosse séance de flashage de routeurs et on a une pile de 20 routeurs complètement interchangables prêts à être distribués à des abonnés, en attribuant les IP au fur et à mesure.
-) C'est plus facile de gérer les conflits d'IP, tout l'info est stockée à un seul endroit (serveur DHCP ou Radius).  En mettant les IP en dur dans les routeurs y a moyen de se mélanger les pinceaux et mettre plusieurs fois la même IP à plusieurs routeurs...
+) C'est plus facile de gérer les conflits d'IP, tout l'info est stockée à un seul endroit (serveur DHCP ou Radius).  En mettant les IP en dur dans les routeurs abonnés y a moyen de se mélanger les pinceaux et mettre plusieurs fois la même IP à plusieurs routeurs...
 ) Ça fait aussi qu'un abonné peut brancher à peu près n'importe quel routeur ou PC : à partir du moment où il nous donne sa MAC il obtient son IP publique en DHCP.
-) Dans notre setup, ça automatise complètement le routage : le serveur DHCP rajoute lui-même une route vers l'IP de l'abonné.
+) Dans notre setup, ça automatise complètement le routage : le serveur DHCP rajoute lui-même une route vers l'IP publique de l'abonné, et cette route est propagée dans tout le réseau grâce à OSPF.
 Mais selon tes besoins, en statique ça marche aussi...
 ======= Chez tetaneutral.net (décembre 2019) =======
+**Aspects techniques**
 On fait du routage statique avec les IPs publiques en dur dans les routeurs.
-C'est bien documenté dans la documentation de [[https://julien.vaubourg.com/files/cr_justiniac.pdf|l'installation au château Justiniac]].
+C'est bien expliqué dans la documentation de [[https://julien.vaubourg.com/files/cr_justiniac.pdf|l'installation au château Justiniac]].
 Et aussi (mais peut être pas très à jour)
@@ Ligne 177: / Ligne 192: @@
 Le script pour compiler les firmwares en openWRT : https://chiliproject.tetaneutral.net/projects/git-tetaneutral-net/repository/openwrt-tools
-=====ARN, à la recherche du premier lien [en cours]=====
+**Aspect sociaux :**
-Jusqu'à présent ARN a uniquement mis en place des partages de connexion entre deux membres (en passant par du wifi). Les gens intéressés s'inscrivent sur une carte (en indiquant leur orientation). A partir de cette carte on cherche les lignes de vue possible.
+//Comment susciter de l'intérêt ?//
+L'intérêt est très grand "naturellement" en zone blanche ou grise.
+En ville, la décision de tetaneutral.net de fournir gratuitement l'accès aux squats a fait naître un grand intérêt par les squatteur·e·s. Une bonne partie des abonné·e·s sont des ancien·ne·s squatteur·e·s et une partie des bénévoles aussi.
+Les aspects "pas cher" (prix libre) et "alternatif" séduisent une partie de la population.
+//Comment répartir les connaissances ?//
+On a fait beaucoup de sessions de formation de nouveaux et nouvelles bénévoles. Ça touche très peu de monde, mais ça fonctionne.
+Il y a maintenant des réunions de bénévoles ouvertes plus ou moins mensuelles et un wiki privé pour les bénévoles.
+Les installations sont aussi un moment chez les abonné·e·s où l'on a un peu de temps pour transmettre des connaissances.
+//Comment faire pour que les adhérent·e·s se sentent impliqué·e·s ?//
+Pas facile :-/
+//Comment répondre aux préoccupations pour les ondes ?//
+On a [[https://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/OndesSante|une page de liens]] sur la question il y a aussi [[transmission:ondes|une page sur ce wiki]].
+======= Chez ARN (décembre 2019) =======
+==== Aspects techniques ====
+Notre fonctionnement technique est décrit sur cette documentation: https://wiki.arn-fai.net/technique:natta
+En résumé, pour l'instant, nous créons des réseaux de quartiers arborescents avec des ip locales à l'aide de NanoStation Loco AC (et AirOS). L'ip publique est apportée par un VPN la plupart du temps via une NeutriBox (Brique Internet avec un orange pi pc plus). Cette Neutribox est posée chez la personne abonnée. Une règle firewall dans l'antenne qui fait routeur et passerelle (au début de la structure arborescente) empêche de se connecter à autre chose que le VPN d'ARN.
+L'idée de ce montage est que le réseau peut être quasiment ouvert, on peut faire bricoler facilement des bénévoles dessus, car il n'y a pas de problèmes de confiance puisque les personnes abonnées sont protégés par la crypto du VPN.
+L'objectif du setup technique est qu'il soit de plus en plus facile à mettre en place, avec 2 type d'antennes (AP et station) qu'on enchaîne comme des légos. L'idéal ce serait ça https://www.ffdn.org/wiki/doku.php?id=travaux:yunoisp .
+Le coût d'un lien (avec 2 antennes) est de 180€.
+On envisage wireguard pour offrir une meilleure connectivité.
+==== Aspects sociaux ====
+//Comment susciter de l'intérêt ?//
+L'intérêt naît principalement des stands, ateliers et conférences que nous organisons. Une parution dans les Dernière Nouvelles d'Alsace nous a permit de nous faire connaître un peu.
+Certaines personnes ont un besoin d'alternatives, d'autres cherchent une solution à leur problème de connectivité local (certains quartiers de Strasbourg). Le hic c'est qu'on a du mal à les relier car notre backbone n'est pas assez déployé.
+Pour nous le projet Natta (le petit nom du projet wifi) s'inscrit dans un tout. En général si une personne demande pourquoi on fait ce projet spécifiquement, les arguments sont:
+  * Il faut des FAI issus de la société civile qui puissent savoir comment marche internet et avoir une position politique sur le sujet
+  * Ce genre de réseau permet de se réapproprier la technique
+  * A l'avenir nous aimerions que le setup soit suffisamment simple pour qu'une personne lambda puisse régler ses problèmes de connexions avec un autre logement aux alentours mieux connectés. En somme un système reproductible qui permettent d'envisager de se fournir internet plutôt que de dépendre totalement de politique économique et publique du gouvernement et de quelques entreprises.
+//Comment répartir les connaissances ?//
+A chaque installation nous faisons un appel pour venir découvrir comment déployer.
+Notre objectif est aussi de réduire les connaissances pour créer le setup technique nécessaire.
+En fait on a plus de mal à répartir des connaissance sur le reste de notre infra que sur ce sujet spécifiquement.
+//Comment faire pour que les adhérent·e·s se sentent impliqué·e·s ?//
+Les personnes abonnées se sentent impliquées pour leur connexion, souvent c'est elles qui vont affiner l'orientation de leur antennes. Les personnes qui hébergent des antennes relai se sentent également impliquées. Pour le reste toutes les personnes n'adhèrent pas chez ARN pour ce projet spécifiquement.
+//Comment répondre aux préoccupations pour les ondes ?//
+Nous on avance que la puissance de nos antennes est de 0,5W, là où un téléphone fait du 2W et une antenne relais de téléphonie 300W. Quand on dit que c'est la même chose qu'une box sauf que c'est directionnel, en général les gens acceptent, surtout que la plupart ont des smartphones dans la poche.
+======= Chez SCANI (décembre 2019) =======
+==== Côté infra backbone ====
+Nous avons un fonctionnement par plaques géographiques qui sont de purs
+L2 sur lesquelles on trimballe généralement 5 VLANs :
+* Un d'admin, avec des IP RFC1918 dans des bouts de 192.168.x.0/24, un
+(ou plusieurs, pour les grosses) par plaque. On y colle toutes les
+antennes, switchs, routeurs, ...
+* Un de livraison enduser, avec des /27 routables (quand on en a un
+plein, pouf, on en rajoute un)
+* Un second d'admin qui sers de support aux antennes wifi public. On
+utilise que de l'unifi ubiquiti sur ce segment là, avec un contrôleur
+centralisé qui est passé en option 43 de ce DHCP .. du coup, aucune
+galère de config sur le terrain. On plug une antenne sur un port avec
+nos deux VLANs wifi public, pouf, 1mn après elle est sur le contrôleur,
+on l'adopte, elle se met à jour, elle se configure et pendant ce temps
+là on prend le café.
+* Un de livraison wifi public, avec des IPs RFC1918 dans 172.16.0.0/16
+globalisé sur une plaque géographique avec un petit routeur quelque part
+qui fait du NAT (et qui se charge également du DHCP pour le vlan d'admin
+ci dessus et son option 43 pour passer le contrôleur). On a pas (encore)
+réussi à faire tomber IPv6 en marche là dessus, le contrôleur ubnt est
+clairement pas sec de ce côté.
+* Un d'interco OSPF entre les routeurs L3 de la plaque
+Chaque plaque géographique a un ou plusieurs uplinks, possiblement à des
+endroits physiques différent, toujours avec un routeur L3 aux endroits
+des uplinks. Ils sont tous interco via le VLAN ci dessus sur des /31
+IPv4 et des /64 IPv6
+On fait le DHCP sur le vlan de livraison enduser sur l'un des routeurs
+qui fait uplink. On a un chantier pour en mettre plusieurs par plaque
+avec du VRRP entre, mais on n'a jamais pris le temps de terminer ça.
+L'IPv6 est pour l'instant 100% en static, n'ayant pas trouvé de méthode
+propre et nette pour faire du prefix-delegation sans tout péter dans nos
+routeurs. Il y a un projet dans un carton de faire du DHCPv6 sur
+d'autres machines que les routeurs de bordure de plaque mais c'est
+toujours ... en carton.
+Les uplinks des plaques sont, au choix :
+* Une autre plaque
+* Une collecte CELAN (6 en tout)
+* Un VPN over xDSL ou LTE
+Le tout aboutissant sur 3 routeurs à Paris (dans trois endroits
+différents) :
+* Un des routeurs reçoit les VPN
+* Les deux autres reçoivent chacun un VLAN sur chaque CELAN (ce sont
+ceux là qui ont les uplinks BGP vers internet)
+==== Côté matos ====
+Le coeur de réseau tourne sur des Edgemax Infinity XG8 avec un CRS317
+mikrotik en dessous en mode "multiprise 10G"
+La tête VPN est un Mikrotik CCR1009
+Les stations VPN sont des Mikrotik RB750 (pour les lignes avec < 30Mbps
+de capa) et dernièrement des RB760iGS (avec la crypto en hard)
+Le switching est majoritairement outdoor avec des Edgepoint R6 (on a
+jamais eu besoin de plus de 5 ports, sauf une fois ou on a mis 2
+edgepoint du coup)
+Dans les rares immeubles ou groupements de bâtiments ou on est présents,
+on switch avec du Mikrotik CRS326
+On a quelques brins de fibre alarache.com parci parlà mais 99.xx% du
+réseau est fait en radio ubiquiti 5Ghz sauf un lien en mikrotik 60Ghz
+(qui fait un pont 1Gbps symétrique entre un CELAN et notre bout de
+réseau fibre le plus développé)
+Côté "dans la maison", on a une grosse majorité de tplink WR841N et
+quelques [[https://www.eurodk.com/en/products/mikrotik-hap/routerboard-hap-ac-lite-tower|mikrotik hAP]].
+{{ :transmission:oknbehilggkglcdj.png?200|}}
+Le câblage est  fait en outdoor isolé UV cat.5
+Alors l'oxydation sur les prises, c'est ultra rare mais ça arrive. Contre intuitivement, le plus souvent qu'on l'a eu, c'était sur la prise *dans* la maison à cause de la gaine du câble un peu entamée quelque part dehors et l'eau qui descendait dans le câble par capillarité.
+Pour les câbles, on a déjà eu trois types de dégradation :
+* Les bestioles qui grignotent
+* Les frottements divers et variés (passage dans un trou dans du placo, au raz du rail en métal, câble pas fixé "vous inquiétez pas je mettrais une goulotte plus tard", ça bringuebale et ça fini par entamer le câble)
+* La température, spécifiquement quand on pose les câbles devant ou derrière du bardage métallique exposé au soleil.
+==== Côté config ====
+Les radios sont toutes cousues mains lors des installations (ou
+préparées à l'avance quand on sait sur quel AP on tape). Chaque AP a un
+SSID différent pour éviter les blagues de boucles L2.
+On ne configure rien sur les CPE chez les membres. Ceux qui veulent le
+faire, on leur montre et on leur explique. On a eu trop de galère de
+gens qui appuient pour un oui ou un non sur le bouton reset donc on
+s'arrange pour que ça marche "out of the box" sans rien faire.
+==== Côté supervision ====
+Un zabbix se charge de la collecte de l'ensemble des infos, en
+autoprovisionning depuis le SI maison. On n'y touche quasi jamais.
+Les alertes zabbix sont remontées à un script maison qui va questionner
+le même SI pour savoir quoi faire. En fonction de l'équipement, le
+script envoi (ou pas) une notification telegram sur un ou plusieurs
+groupes de discussion à travers un bot. On a un groupe général pour le
+backbone et quelques groupes locaux avec des membres volontaires
+inscrits qui vont intervenir localement en cas de soucis. Le tout est
+configurable à la volée sur le clicodrôme du SI.
+==== Aspects sociaux ====
+// Pour éveiller des vocations //
+Les groupes Telegram sont une bonne méthode. Sans forcément devenir des
+geeks, les membres voient la corrélation directe entre une panne
+constatée et un message de la supervision, ils peuvent interagir les uns
+avec les autres, ça fonctionne vraiment très bien.
+(oui, Telegram, on sait ... Mais on voulait une solution de messagerie
+instantanée 100% indépendante techniquement *et* humainement de nous et
+qui soit easy à installer pour Mme Michu)
+On s'en sers également pour l'accueil de nouveaux qui ont des questions
+à poser. Il y a un bridge avec une paire de groupes telegram qui est
+accessible en mode web quand on s'est crée un compte sur notre SI.
+Ah et pis, ça, c'était pour la partie "technique". L'éveil principal de
+vocation a lieu quand on se promène et qu'on explique, notamment lors de
+réunions publiques ou on met tout de suite les gens à l'ouvrage en leur
+expliquant que l'étude topographique de leur coin et l'organisation des
+plannings de déploiement et de maintenance, c'est eux qui devront s'en
+charger, sinon, il ne se passera rien.
+Il y en a globalement assez peu qui se prennent de passion pour la
+technique, le wifi, la config, le bgp, etc ... Par contre, beaucoup ont
+une idée assez claire du principe général et des gestes de premiers
+secours quand un bout du réseau tombe en rideau. Ils savent aussi fort
+bien comment manger et picoler mais ça on a pas eu besoin de leur
+montrer :))
+// Pour la documentation //
+On a pas mal de chose dans https://doc.scani.fr/ mais comme c'est
+compliqué de concilier la protection des données perso, la sécurité du
+réseau et la transparence documentaire, une grande partie de la doc
+n'est accessible que pour les membres et sur cooptation. Il y a des
+améliorations à apporter là dessus en rendant la doc 100% anonyme et
+générique puis en la publiant.
+// Pour les préoccupations sur les ondes //
-Notre objectif est de pouvoir mettre en place une antenne sur un immeuble haut (que nous avons choisi pour sa taille et sa situation dans la ville) afin de pouvoir couvrir une grande zone de Strasbourg et pouvoir ainsi acheminer les connexions jusqu'au Data Center qui héberge nos serveurs.
+On a depuis fort longtemps pris le parti de dire qu'on n'avait aucune
+certitude si ce n'est que les ondes qu'on génère nous sont globalement
+fortement inférieures à celles générées par la téléphonie mobile mais
+que si ça en gêne certains, on était tout prêts à sortir pelles, pioches
+et tourets de fibres pour supprimer nos ondes.
-Du coup deux points :
+Pour ceux qui ne veulent pas d'onde sur le CPE, on explique au choix
-  * Convaincre le DC de nous laisser installer une antenne sur son toit,
+comment désactiver le wifi du tplink ou, dans les cas ou le membre
-  * Convaincre des habitants de l'immeuble de nous laisser installer une antenne chez eux.
+demande, on met des mikrotik ou des edgemax sans wifi onboard. On a très
+marginalement des endroits ou l'antenne de réception est configurée en
+mode routeur et fait donc en même temps office de CPE.
-L'approche des habitants se fait grâce à du porte à porte et la distribution de flyers.
-{{ transmission:arn_flyer_wifi_draft.pdf |}}
-====== outils cartographiques ======
+====== outils ======
   * [[https://code.ffdn.org/FFDN/celutz|celutz]] pour exploiter des photos panoramiques, pour prévoir des liens wifi ou des raccordements d'abonnés
   * [[https://code.ffdn.org/ffdn/wifi-with-me|wifi-with-me]] Formulaire & carte pour recenser les aspirant-e-s connecté-e-s à un réseau radio.
   * [[http://heywhatsthat.com/]] un outil qui calcule la vue théorique et les profils topo !
-  * [[https://observatoire.francethd.fr/]] Pour voir où on peut facilement aller chercher le débit
+  * [[https://maconnexioninternet.arcep.fr/]] Pour voir où on peut facilement aller chercher le débit
   * [[http://francetopo.fr/]] carte topo libre
   * [[https://www.geoportail.gouv.fr/carte|Géoportail de l'IGN]] permettant d'élaborer un profil altimétrique entre 2 points
+  * [[http://hugin.sourceforge.net/| Hugin]] outil libre d'assemblage de panoramiques. Tutos vidéos en français [[https://invidious.fdn.fr/watch?v=jWOU5ZFdK0M|ici]] et [[https://invidious.snopyta.org/playlist?list=PLZOdZMT41b7VTcfKwKCdmZULSPj8lhjaN&autoplay=1|là]] (parce que la doc officielle n'est pas claire ni à jour).