Outils pour utilisateurs

Outils du site


admin:services:wififederez

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
admin:services:wifi-federez [2015/05/21 00:43] – ancienne révision (2015/05/21 00:39) restaurée chiracadmin:services:wififederez [2020/11/11 22:47] (Version actuelle) – [How To] david
Ligne 8: Ligne 8:
  
  
-L'implantation actuelle consiste à rediriger les requêtes qui ne concerne pas le campus hôte (ex : .crans.org à iresam metz) vers le serveur radius centrale de federez, baldrick.+L'implantation actuelle consiste à rediriger les requêtes qui ne concerne pas le campus hôte (ex : .crans.org à iresam metz) vers le serveur radius centrale de federez, dodecagon et parangon.
  
 Celui-ci reconnait la bonne destination, et renvoi la requête vers le bon serveur radius. Celui-ci reconnait la bonne destination, et renvoi la requête vers le bon serveur radius.
  
  
-Coté technique, il est nécessaire d'ajouter chaque radius du projet dans le proxy.conf du baldrick, et de mettre baldrick dans le client.conf de chaque radius des assos.+Coté technique, il est nécessaire d'ajouter chaque radius du projet dans le proxy.conf de dodecagon et parangon, et de mettre ceux-ci dans le client.conf de chaque radius des assos.
  
 Enfin, dans le sites available pertinent, il faut rajouter une règle qui choisi ou non la proxification sur chaque radius, suivant la tête de l'identifiant anonyme (if .crans... etc) Enfin, dans le sites available pertinent, il faut rajouter une règle qui choisi ou non la proxification sur chaque radius, suivant la tête de l'identifiant anonyme (if .crans... etc)
Ligne 19: Ligne 19:
 ===== Identifiants, mots de passe ===== ===== Identifiants, mots de passe =====
  
-Les identifiants sont ceux que vous utilisez sur le wifi de vos asso, auxquels on rajoute un @federez.votreasso+Au départ, les identifiants étaient ceux que vous utilisez sur le wifi de vos asso, auxquels on rajoute un suffixe. 
 + 
 +Les suffixe à adosser au login sont les suivants :  
 + 
 +CRANS -> @crans.org 
 +Rezometz -> @rezometz.org 
 +ViaRezo -> @viarezo.fr ou @larez.fr 
 +Rezorennes -> @rez-rennes.fr 
 +Resel -> @resel.fr 
 +Aurore -> @auro.re 
 +Rezoleo -> @rezoleo.fr
  
-Ex : @federez.crans, @federez.iresam, @federez.resometz 
  
 Les mots de passe sont inchangés Les mots de passe sont inchangés
Ligne 27: Ligne 36:
 ==== How To ==== ==== How To ====
 === Coté client === === Coté client ===
 +=== Dans le sens Client -> Federez ===
  
 Si vous voulez vous aussi faire partie du projet, ce n'est pas très compliqué. Si vous voulez vous aussi faire partie du projet, ce n'est pas très compliqué.
Ligne 62: Ligne 72:
 home_server_pool federez_radius_servers { home_server_pool federez_radius_servers {
       type = fail-over       type = fail-over
-      home_server = baldrick+      home_server = dodecagon 
 +      home_server = parangon
 } }
  
-home_server baldrick {+ 
 +home_server dodecagon {
       type = auth       type = auth
-      ipaddr = 138.231.142.239+      ipaddr = 195.154.165.76 
 +      port = 1812 
 +      secret = un_secret_a_convenir_avec_federez_admin 
 +      require_message_authenticator = yes 
 +      response_window = 20 
 +      zombie_period = 40 
 +      revive_interval = 120 
 +      status_check = status-server 
 +      check_interval = 30 
 +      num_answers_to_alive = 3 
 +
 + 
 +home_server parangon { 
 +      type = auth 
 +      ipaddr = 185.230.78.47
       port = 1812       port = 1812
       secret = un_secret_a_convenir_avec_federez_admin       secret = un_secret_a_convenir_avec_federez_admin
Ligne 82: Ligne 108:
  Maintenant, votre serveur est prêt à envoyer des requêtes d'authentification radius à Federez. Il ne peut pas encore en recevoir de federez. Il y a un autre problème ; il faut définir la règle qui va activer ou non la transmission de la requète à federez.  Maintenant, votre serveur est prêt à envoyer des requêtes d'authentification radius à Federez. Il ne peut pas encore en recevoir de federez. Il y a un autre problème ; il faut définir la règle qui va activer ou non la transmission de la requète à federez.
  
- * Cela se passe dans /etc/freeradius/sites-available/defaut , il faut rajouter une petit règle : + * Cela se passe dans /etc/freeradius/sites-available/defaut , il faut rajouter une petit règle (remplacer crans par votre asso évidemment) 
  
 <code> <code>
-        if ("%{User-Name}" !~ /moncampus$/) { +        if (User-Name !~ /@(.*)crans(.*)$/) {
-            update control { +
-                Proxy-To-Realm := 'FEDEREZ' +
-            } +
-        } +
-</code> +
- +
-Si jamais les identifiants de votre campus ne sont pas en @moncampus.org, on peut ruser, par ex: +
- +
-<code> +
-        if (User-Name !~ /crans$/) {+
              if (User-Name =~ /^(.*)@(.*)/) {              if (User-Name =~ /^(.*)@(.*)/) {
                  update control {                  update control {
Ligne 103: Ligne 119:
         }         }
 </code> </code>
 +
 +Explication : dans cet exemple, on se situe au avec un login toto@federez.asso, la requête sera envoyée à FedeRez, pour toto différent de Crans. En effet, si il y a crans, on créerait alors une boucle entre le serveur FedeRez et le serveur local, chacun renvoyant la règle à l'autre...
  
 Avec ça, tous les identifiants qui ne correspondent à @moncampus.org seront envoyés se faire authentifier vers federez-wifi. Avec ça, tous les identifiants qui ne correspondent à @moncampus.org seront envoyés se faire authentifier vers federez-wifi.
  
- Enfin, il faut que le serveur puisse recevoir les requètes venant de federez.+=== Dans le sens Federez->client === 
 + 
 + Il faut que le serveur puisse recevoir les requètes venant de federez.
  
 Pour cela, il suffit d'ajouter baldrick dans le /etc/freeradius/client.conf : Pour cela, il suffit d'ajouter baldrick dans le /etc/freeradius/client.conf :
  
 <code> <code>
-Baldrick (radius de federez) +Parangon (radius de federez) 
-client 138.231.142.239 {+client parangon { 
 +        ipaddr = 185.230.78.47 
 +        secret          = secret_convenu_avec_federez_admin 
 +        } 
 +         
 +# Dodecagon (radius de federez) 
 +client dodecagon { 
 +        ipaddr = 195.154.165.76
         secret          = secret_convenu_avec_federez_admin         secret          = secret_convenu_avec_federez_admin
         }         }
 </code> </code>
  
-=== Monitoring ===+ * Mais la client reçoit des requêtes du type toto@federez.iresam, il faut retirer le @federez.iresam. Il faut modifier l'authentification ldap/sql, pour qu'elle n'utilise pas le User-Name, mais une autre variable, le stripped-username. 
  
-Il est évidemment nécessaire de savoir si les serveurs freeradius du projet sont up ou down.+Pourquoi ne pas modifier le username directement ? Le protocole mschapv2 ne supporte pas cela, car il utilise le username comme sel au moment du chiffrement du mot de passe...
  
-C'est par ici : [[admin:services:wifi-federez:monitoring]]+On ruse donc, on peuple une variable stripped username (voir ci dessous) qu'on utilise alors au moment de la recherche ldap/postgresql.
  
-Un script, status.sh situé dans le /root/federezwifi de baldrick est exécuté par un cron toutes les 5 min. Il parse la liste des serveurs présents dans le /etc/freeradius/proxy.conf.+<code> 
 +Ex pour ldap : 
 +filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" 
 +</code>
  
-Pour chaque serveur radiusil extrait l'ip, le secret et le nom.+ * Il faut ensuite peupler ce stripped usernameca se passe dans le site défaut(comme pour les realms)
  
-Puis il lance une commande radtest, si le serveurs répond, il considère que le serveur est up, sinon c'est qu'il est dead.+<code> 
 +        if ("%{request:User-Name}" =~ /^(.*)@(.*)crans(.*)/) { 
 +            update request { 
 +                Stripped-User-Name := "%{1}" 
 +                } 
 +        }
  
-Ensuite, il construit un template à partir de ces données, qui est la page wiki telle qu'affichée à la section monitoring.+</code>
  
-Pour finir, il copie via scp ce template d'abord dans /home/wififederez de hexagon, puis en tant que www-data (pour faire les choses proprement), il met la page dans le data du wiki.+ * Enfin, il peut être nécessaire de transmettre cette variable à l'intérieur du tunnel : 
  
 +<code>
 +copy_request_to_tunnel = yes
 +</code>
  
-Projet encore en développement, contacter detraz@crans.org.+=== Monitoring ===
  
-=== Bug ===+Il est évidemment nécessaire de savoir si les serveurs freeradius du projet sont up ou down. 
 + 
 +Un script, situé dans ''/root/federez-wifi/eapol_test.py'' sur parangon est exécuté par un cron toutes les 5 min. Il parse la liste des serveurs présents dans le ''/etc/freeradius/proxy.conf''
 + 
 +Pour chaque serveur radius, il extrait l'ip, le secret et le nom. 
 + 
 +Puis il lance une commande ''eapoltest'' avec les bons arguments, login et mot de passe, si le serveurs répond ok, il considère que le serveur est up, sinon c'est qu'il est dead. 
 + 
 +Enfin, il poste les informations via un script over ssh sur le présent wiki situé sur dodecagon. 
 + 
 + 
 +=== Etat actuel ===
  
 Ce qui marche bien : Ce qui marche bien :
  
-iresam -> exterieur +8 associations où FedeRez wifi est en production et fonctionnel : 
-crans -> exterieur +Cr@ns, Supélec Rezo Rennes, AURORE, Rezo Metz, ViaRézo, Rézoléo, Resel. 
-exterieur -> crans +
-rezometz -> extérieur+
  
-Ce qui marche moins bien : 
-exterieur -> iresam : je n'ai pas trouvé le moyen de faire un update de l'id, enlever le suffixe dans le inner tunnel 
-update : d'après cysi ca serait trivial, je vais tester 
-exterieur -> rezometz : problème avec le suffixe 
  
-<olmap id="olMap" width="600px" height="400px" lat="52.0" lon="5.1" zoom="12" statusbar="1" toolbar="1" controls="1" poihoverstyle="1" baselyr="OpenStreetMap" gpxfile=":playground:hardlopen_gpx.gpx" geojsonfile=":playground:test.gsojson" kmlfile=":playground:mtb.kml" summary="This map shows a gpx trace, a kml trace and a dot"> +--  
-52.1,5.1,60,.8,marker-green.png,Just a spot +Pour toute question sur le projetcontacter detraz@crans.org.
-</olmap>+
admin/services/wififederez.1432161820.txt.gz · Dernière modification : 2015/05/21 00:43 de chirac

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki