Freelan : un nouveau venu dans le monde des VPN peer-to-peer

Posté par (page perso) . Édité par Nÿco et Florent Zara. Modéré par Florent Zara. Licence CC by-sa
55
23
avr.
2012
Sécurité

Un nouveau venu fait son apparition dans le monde des VPN peer-to-peer sur Internet : Freelan. Ce logiciel libre licencié sous GPL permet d'établir un réseau VPN entre différents hôtes selon, au choix, un modèle peer-to-peer, client-serveur ou hybride. N'importe quelle topologie réseau est possible.

Plus de détails dans la suite de la dépêche

Le réseau privé virtuel peut être créé sur IPv4 et/ou IPv6 et peut être sécurisé, au choix, par une ou deux paires de clé privée-certificat. Il est possible de choisir sa propre méthode de validation de certificats ou d'utiliser la méthode classique et habituelle avec des certificats faisant autorité.

Le protocole de communication (« Freelan Secure Channel Protocol ») a été défini et rédigé avant implémentation, et on peut en trouver la spécification ici. Le protocole réseau utilisé permet également la mise en place de « relais » qui ne participent pas directement au réseau mais qui fournissent des points de connexion distribués, à l'instar d'un commutateur réseau distribué.

Le logiciel fonctionne sous Linux, Unix, Windows et Mac OS X. Un dépôt Debian est également disponible pour faciliter l'installation sur les systèmes Debian, Ubuntu et leurs dérivés. Le programme a été développé en C++ (même code source pour tous les systèmes) et les bibliothèques le composant sont elles aussi packagées et installables pour une éventuelle intégration au sein d'autres logiciels.

  • # pourquoi ?

    Posté par . Évalué à 4.

    Je ne vois pas bien ce que ça apporte par rapport à un vpn 'classique' ? Pourquoi avoir redéfini tout un protocol plutôt que d'utiliser ce qui existe déjà (Ike et Ipsec par exemple) ?

    • [^] # Re: pourquoi ?

      Posté par (page perso) . Évalué à 10. Dernière modification le 23/04/12 à 21:18.

      IPSec est en effet une solution intéressante et souvent parfaitement intégrée, mais qui ne répond pas exactement aux mêmes problématiques.

      On critique parfois IPSec pour sa difficulté d'intégration avec des réseaux NATés; Freelan s'affranchit de ce problème en étant basé sur UDP. Il est en ce sens, plus près d'OpenVPN (qui défini d'ailleurs lui aussi son propre protocole, mais qui impose une relation client(s)-serveur). De plus il a été conçu afin de pouvoir être intégrable à une application (le protocole peut servir de canal de transmission sécurisé sans être nécessairement associé à une interface réseau virtuelle).

      Freelan ne se pose donc pas en concurrent d'IPSec (ce serait d'ailleurs prétentieux et vain) mais bel et bien en complément, si on le souhaite.

      Son principal argument est selon moi sa capacité de modéliser la topologie réseau que l'on souhaite et de pouvoir décentraliser l'administration au besoin. Je ne connais aujourd'hui pas d'alternative libre à Hamachi qui permette une connexion directe entre les pairs et ce, sur plusieurs plateformes et/ou en IPv6. Évidemment, Hamachi propose en plus une interface qui simplifie grandement la configuration, et il n'est pas exclu que ce genre d'outil arrive dans un futur proche.

      Le fait de rédiger un nouveau protocole est toujours un risque, c'est vrai. Mais cela permet aussi d'avoir un meilleur contrôle sur ce qu'on l'on souhaite, et grâce à ça, freelan offre par exemple la possibilité de définir deux paires de certificat-clé privée séparées pour l'authentification et le chiffrement, pour une sécurité accrue.

      Je ne sais pas si je t'ai convaincu mais j'espère au moins avoir répondu à tes questions. Merci d'avoir pris le temps de regarder en tout cas !

      • [^] # Re: pourquoi ?

        Posté par . Évalué à 3.

        Je ne connais aujourd'hui pas d'alternative libre à Hamachi qui permette une connexion directe entre les pairs et ce, sur plusieurs plateformes et/ou en IPv6.

        Je pense a n2n qui a presque les mêmes fonctionnalité.

        • [^] # Re: pourquoi ?

          Posté par (page perso) . Évalué à 8.

          Pour être franc je ne connaissais pas du tout n2n, c'est très intéressant et assez proche je pense en effet.

          Les différences que je crois percevoir :

          • Deux notions séparées pour les "supernodes" et les "edge". J'ai cru comprendre que ces premiers étaient nécessaires pour la mise en relation des noeuds (à l'instar d'un tracker pour bittorrent). Nous avons fait le choix pour freelan de ne pas obligatoirement reposer sur une entité centrale pour plus de robustesse (même si dans le cas de n2n j'imagine qu'on peut l'héberger chez soi si on le souhaite).
          • J'ai vu qu'il se basait sur un secret partagé entre les noeuds : se pose donc à mon sens la problématique de transfert sécurisé de ce secret. Bon en revanche c'est clairement plus simple et accessible que de générer des certificats, il faut bien l'admettre.

          Je n'ai en revanche pas trouvé de description pour leur protocole : j'aurais assez aimé savoir quelle méthode(s) de chiffrement est/sont utilisée(s) et comment les clés sont échangées et renouvellées.

          En tout cas, merci pour le lien, c'est toujours bien de voir ce que font les autres.

          • [^] # Re: pourquoi ?

            Posté par . Évalué à 4.

            Pour l'avoir utilisé quelque fois, je trouve que son mode de fonctionnement est très proche de celui de hamachi mais il a l'avantage d’être libre, donc on peut avoir "confiance" au supernode.

            Vu de loin, je trouve que freelan est plus fourni en fonctionnalités par contre n2n est TRÈS simple à mettre en œuvre.

            Pour le "secret partagé", c'est simplement un mot de passe.
            La seul façon sécurisée de transmettre la clef est de personne à personne ou par un simple sms.
            On est loin de openvpn qui permet de fournir un certif à chaque personnes.

            • [^] # Re: pourquoi ?

              Posté par (page perso) . Évalué à 6.

              Je partage ton avis sur le manque de confiance qu'on peut raisonnablement accorder à Hamachi. Je ne compte plus le nombre de fois où le serveur central est passé en maintenance me privant de tout service et ce, sans préavis.

              C'est en partie ce qui m'a motivé à commencer ce projet.

              Pour l'aspect simplicité, j'ai retourné la question dans tous les sens et il semblerait qu'on ait toujours un choix cornélien à faire pour un VPN peer-to-peer:

              • Soit la mise en oeuvre est simple mais ça nuit à la sécurité.
              • Soit on se focalise sur la sécurité mais la mise en oeuvre s'en trouve grandement impactée. La faute principalement à la lourdeur qu'imposent les PKI. OpenVPN souffre de la même situation d'ailleurs.

              J'espère tout de même pouvoir simplifier un peu les choses à l'avenir. Je vois mal un utilisateur lambda de Windows générer ses propres certificats pour mettre en place son VPN. On ne peut hélas pas dire à l'heure actuelle qu'on vise exactement le même public que Hamachi. Mais nous n'en sommes finalement qu'au début. Et toutes les idées à ce sujet sont les bienvenues !

              • [^] # Re: pourquoi ?

                Posté par (page perso) . Évalué à 10.

                J'ai bien regardé les caractéristiques de n2n, et voici les remarques que j'ai à son sujet:

                Nous trouvons sur la page du site n2n, dit très loyalement :

                n2n 1.x has been designed to be simple and used in private n2n networks. We’re aware that it has some security limitations such as
                Keys on the command line are a problem.

                Sous FreeLAN les clefs symétriques, de chiffrement [AES256-CBC] et de scellement [HMAC-SHA256-128], sont générées aléatoirement (tant que faire se peut) puis échangées avec les clefs asymétriques, de chiffrement [RSAES-OAEP] et de signature [RSASSA-PSS], des utilisateurs.

                Lack of nonces in encryption makes it relatively easy to perform replay attacks.

                FreeLAN utilise le mode d’opération CBC, avec un vecteur d’initialisation imprédictible [NIST SP 800-38A]. Plus que le rejeu, cela prévient surtout de décryptages parfois spectaculaires.

                Lack of HMAC makes man in the middle relatively easy. (I don’t think this is a valid criticism as n2n is not trying to attach trust to a connection, just opacity).

                Comme dit, avoir une conversion privée c’est bien, mais avec la bonne personne c’est encore mieux, FreeLAN chiffre ET scelle les données transmises. Cette « signature symétrique » permet par ailleurs d’éliminer au plus tôt les cryptogrammes invalides, avant même leur déchiffrement, améliorant notablement la résistance aux attaques par déni de service, par canal auxiliaire, par exploitation de bogue etc.

                Difficulty in rolling keys and integrating secure key exchange protocols.

                Les clefs symétriques de FreeLAN sont automatiquement renouvelées bien avant que leur usure cryptographique théorique soit atteinte.

                Tout ceci a un prix, c'est une plus grande complexité de la configuration. Mais c'est bien d'avoir le choix non ?! :)

      • [^] # Re: pourquoi ?

        Posté par . Évalué à 8.

        freelan offre par exemple la possibilité de définir deux paires de certificat-clé privée séparées pour l'authentification et le chiffrement

        Est-ce que freelan fait de l´authentification mutuelle ? Par authentification mutuelle, je veux dire que chaque extrémité du tunnel authentifie l´autre ?

        Je pense à un truc du style :

        1. Je passe chez toi avec ma clé publique et mon certificat auto-signé
        2. Tu me files ta clé publique avec ton certificat auto-signé, puis tu ajoutes ma clé publique et mon certificat à ta liste d'autorisations
        3. Je rentre chez mois, et j'ajoute ta clé publique et ton certificat à ma liste d'autorisations
        4. Maintenant, on est capable de faire un VPN entre chez toi et chez moi

        Dans ce cas, comment fais-tu ? Est-ce pris en charge de base dans SSL et/ou TLS (je suis un total-noob dans ce domaine) ?

        Hop,
        Moi.

        PS. Peut-être d'autres patches dans le futur… Peut-être ! ;-)

        • [^] # Re: pourquoi ?

          Posté par (page perso) . Évalué à 7.

          Le scénario que tu as décrit est tout à fait possible avec freelan, oui. C'est même un des cas les plus probables en fait.

          Une nuance cependant : le certificat (autosigné dans ton exemple) contient en fait la clé publique. Il n'y a donc que cet élément à transmettre ;)

          De chaque côté, on peut définir les certificats qui font autorité. Le fait de placer un certificat autosigné comme certificat autorité permet effectivement d'autoriser une connexion avec quelqu'un qui présente ce certificat.

          Les deux parties s'authentifient donc mutuellement. Si une des parties refuse, il ne peut y avoir d'échange de clé et donc aucun canal de communication sécurisé et authentifié n'est possible.

          Une alternative à cette solution qui risque de se retrouver davantage dans une société par exemple, est d'avoir un certificat racine (une CA) qui signe les certificats de chaque pair. Exactement comme ça se fait pour les sites en HTTPS.

          On peut par ailleurs mélanger ces deux configurations et autoriser, d'une part tous les certificats émis par une ou plusieurs autorités, et d'autre part accepter (ou refuser) des certificats en particulier.

      • [^] # Re: pourquoi ?

        Posté par . Évalué à 9.

        La possibilité de faire des connexions en direct c'est pour moi la fonctionnalité qui manque à OpenVPN.

        Typiquement, avec un serveur OpenVPN derrière une ligne ADSL et une dizaine de clients, les communications entre clients passent toutes par le serveur et peuvent saturer sa connexion.

        Merci pour cette dépêche, j'ai enfin la solution de VPN qui conviendra pour faire, par exemple, des parties d'abandonware en réseau :)

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: pourquoi ?

          Posté par (page perso) . Évalué à 4. Dernière modification le 24/04/12 à 11:12.

          Merci à toi pour ton intérêt !

          Et n'hésite pas à me contacter si tu rencontres des difficultés lors de la configuration :)

      • [^] # Re: pourquoi ?

        Posté par . Évalué à 7.

        pour sa difficulté d'intégration avec des réseaux NATés; Freelan s'affranchit de ce problème en étant basé sur UDP.

        Je suis sans doute un peu bête, mais je ne vois pas bien le rapport entre ce que j’ai mis en gras.

        • [^] # Re: pourquoi ?

          Posté par . Évalué à 6.

          À priori, je dirais que la majorité des machinbox qui font du NAT sont plus tolérantes sur les flux UDP en P2P, car UDP est souvent utilisé pour des trafics en P2P justement (audio, vidéo).

          Autrement dit, le modem-routeur Netgear "compatible Skype et MSN" a des chances de laisser passer Freelan.

          Ceci dit, si y'a une raison technique plus précise au fait qu'il est plus facile avec UDP, qu'avec TCP, d'établir un lien direct entre deux machines qui sont derrière un NAT, je veux bien la connaître :)

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: pourquoi ?

            Posté par (page perso) . Évalué à 4.

            Les raisons que tu as énoncé sont effectivement les bonnes. De nombreux routeurs permettent en effet de configurer une redirection de port UDP (ou TCP mais ici ça ne nous intéresse pas).

            Après, le caractère stateless de UDP le rend plus facile à faire passer au travers d'un NAT (hors NAT symmétriques hélas). Il existe des techniques propres à UDP : je pense notamment au UDP hole punching.

            Par ailleurs, un ami à moi travaille actuellement sur l'intégration de ICE au sein de freelan pour faciliter d'autant plus le passage des NAT.

            • [^] # Re: pourquoi ?

              Posté par . Évalué à 3.

              Par ailleurs, un ami à moi travaille actuellement sur l'intégration de ICE au sein de freelan pour faciliter d'autant plus le passage des NAT.

              Pourquoi ne pas implémenter NAT-PMP ou la fonction "Internet Gateway Device" de l'UPnP. Qui permet d'activer le passage de NAT, les clients Bittorrent l'utilisent beaucoup ça fonctionne sur pas mal de "truckbox".

              ICE rend dépendant d'un serveur tiers (STUN), si mes souvenirs sont corrects, utiles dans les réseaux d'entreprise donc où il est impossible de faire de passage de NAT.

              • [^] # Re: pourquoi ?

                Posté par (page perso) . Évalué à 5.

                Très bonne idée en effet. On m'en a déjà fait part effectivement.

                Pour la première release, j'ai voulu vraiment me concentrer sur les performances et surtout la sécurité. Mais ce genre de fonctionnalité ça va etre indispensable aussi donc je compte bien le rajouter.

                J'avais déjà à l'époque un prototype fonctionnel d'ouverture de port en UPnP : ce n'est pas compliqué à implémenter, mais un peu long. Mais ça va se faire, j'y tiens également !

                Dans tous les cas ICE ne sera pas obligatoire, mais simplement possible.

                • [^] # Re: pourquoi ?

                  Posté par . Évalué à 3.

                  UPnP est une technique de passage de NAT mais elle peut être intégrée facilement dans ICE (le projet ice4j, qui est entre autre utilisé par le softphone Jitsi, permet de se servir des adresses découvert par UPnP dans les "connectivity checks" d'ICE).

                  L'utilisation d'ICE permet de maximiser les chances d'obtenir une connexion directe entre deux pairs avec les adresses de la machine (IPv4 ou IPv6), les adresses découvertes par STUN (je suis d'accord que si le FW d'une entreprise bloque le trafic UDP vers le port 3478, nous ne les aurons pas), les adresses allouées sur un serveur TURN (serveur relai) et enfin les adresses UPnP. Tous les mécanismes permettant de découvrir des adresses peuvent être utilisé par ICE. Par exemple avec XMPP on peut utiliser les relais JingleNodes (implémenté également dans Jitsi).

      • [^] # Re: pourquoi ?

        Posté par . Évalué à 3.

        Il est en ce sens, plus près d'OpenVPN (qui défini d'ailleurs lui aussi son propre protocole, mais qui impose une relation client(s)-serveur)

        Question naïve (j'imagine que tu te l'es posée) : il n'était pas possible de reprendre / étendre le protocole d'OpenVPN et de modifier ce dernier plutôt que de repartir from scratch avec un projet différent et incompatible ?

        • [^] # Re: pourquoi ?

          Posté par (page perso) . Évalué à 8.

          Nous souhaitions ne pas être tributaires des décisions du créateur d'OpenVPN concernant la conception du protocole : nous avions un objectif de sécurité assez précis et, même si on peut faire confiance à OpenVPN, le protocole que nous avons choisi d'implémenter diffère sur quelques aspects.

          De plus, si OpenVPN change son protocole sans nous avertir (ce qui est probable), nous risquons de nous retrouver avec un projet incompatible de toute façon. ;)

  • # Versus Tinc

    Posté par . Évalué à 3.

    J'utilise déjà tinc dans mon entreprise http://www.tinc-vpn.org/

    Je testerais ce petit bien ce petit nouveau ! :)

    (enfin je veux voir les perfs, facilité de déploiement, paquet openwrt, stabilité, etc)

    • [^] # Re: Versus Tinc

      Posté par (page perso) . Évalué à 10.

      Les pages sur le site ne sont pas encore écrites (j'y travaille) mais le fichier de configuration est très documenté et devrait déjà aider pas mal. N'hésite pas à me contacter au besoin pour la configuration si jamais.

      Concernant les performances, j'ai réalisé plusieurs avec des amis sur plusieurs semaines avec des montées en charge, de la voix sur IP, etc. et j'ai obtenu en moyenne un temps de traitement (latence additionnelle) de 200 microsecondes (0.2 ms) en moyenne pour chaque paquet. Il va de soi que comparé à la gigue qu'on peut observer sur l'Internet, cette latence est imperceptible.

      Dans le pire cas (transfert de fichier en FTP au maximum du débit), le processeur est monté à 10% d'occupation au maximum, sur une machine relativement modeste (Debian Squeeze sur un Athlon Dual-Core à 2.5 GHz). Je travaille déjà sur une version où les séquences de chiffrement peuvent-être précalculées (quand le processeur est moins utilisé) et dans laquelle le temps de chiffrement temps-réel se ferait alors en temps constant (un simple XOR), quelle que soit la séquence d'algorithmes de chiffrement utilisés.

      En ce qui concerne la stabilité, le démon tourne chez mois depuis plusieurs mois sans interruption ni expansion mémoire notable. Lors du développement, je teste régulièrement chaque composant sous valgrind et gdb pour m'assurer qu'il n'y ait aucune fuite mémoire.

      Enfin, concernant le packaging (et openwrt notamment), ça viendra, même s'il est vrai que je manque de temps pour faire tout ce que je souhaiterais. Le packaging Mac OS X est en cours de réalisation et j'ai déjà commencé à m'attaquer au packaging Red-Hat également. Si on me témoigne une forte demande pour d'autres plateformes, il va de soi que je les ferai passer en priorité.

      Dans tous les cas, merci pour ton intérêt, et si tu le testes, n'hésite pas à me faire un retour ! (qu'il soit positif ou non)

  • # merci

    Posté par (page perso) . Évalué à 9.

    Déjà merci d'avoir fait un service en C++ et pas une bouse en java comme on en voit souvent. Et grand merci pour avoir pensé à ce que ton logiciel soit embarquable dans un soft, c'est exactement ce que je cherchais. Sinon quel sont les limites de machines reliées en P2P, plusieurs millions c'est faisable ? plus ?

    • [^] # Re: merci

      Posté par (page perso) . Évalué à 5. Dernière modification le 24/04/12 à 13:27.

      Mais de rien. Je tenais à le faire avec un langage que j'aime et que je maîtrise.

      Concernant les limites du nombre de machine, je vais être franc : je n'ai eu l'occasion de tester avec plus de 20 machines.

      Maintenant, maintenir une "connexion" (si on peut appeler ça ainsi) avec un autre hôte au sein de freelan est très peu couteux en mémoire et n'a une incidence sur l'occupation processeur que si des données y transitent. J'imagine qu'avec une infrastructure adéquate, on peut donc créer d'assez gros réseaux.

      Le projet utilise une boucle d'événements asynchrone ce qui devrait le rendre plutôt "scalable". Il n'y aucune limite codée "en dur" donc j'imagine que la seule limite, c'est celle des performances de la machine et de ses resources (nombre de sockets, etc.).

      • [^] # Re: merci

        Posté par (page perso) . Évalué à 4.

        c'est celle des performances de la machine et de ses resources (nombre de sockets, etc.).

        Si je monte un VPN P2P ça ne change rien pour une machine en terme de ressources socket, que l'ensemble du VPN soit composé de millions de machine ou de 4, non ?
        A moins que chaque machine soit obligatoirement connecté à chacune des autres ? d'ou la fonction hybrid pour éviter ça ?

        • [^] # Re: merci

          Posté par (page perso) . Évalué à 5.

          Tout à fait : le réseau peut prendre la forme que l'on souhaite et chaque noeud décide avec qui il se connecte et avec qui il ne le fait pas. Les dénominations "client-serveur, pair-à-pair et hybride sont juste des cas particuliers exemple, mais on est vraiment libre à 100%).

          Je parlais d'un cas où une même machine devrait se connecter avec beaucoup d'autres hôtes directement.

          On peut tout à fait imaginer un gros réseau en "mesh": il faut bien veiller à ce que les noeuds intermédiaires soient en mode "relai" et ça roule :)

  • # J’ai du mal

    Posté par . Évalué à 4. Dernière modification le 25/04/12 à 19:58.

    Bon, je vois bien l’intérêt d’un VPN, mais je ne vois pas le P2P la dedans. Pourrais-tu, s’il te plais, développer un peu certains aspects ?

    • Quelle est la plus value par rapport a un VPN classique ou je monte un tunnel entre chez moi et mes parents, chez moi et ma sœur, enfin ma sœur et mes parents ?
    • Dans le premier cas du site (peer-to-peer) comment, si tu as tes 3 clients derrière du NAT, fais-tu pour initier la connexion sans faire de redirection de port sur ton routeur ?
    • [^] # Re: J’ai du mal

      Posté par (page perso) . Évalué à 7. Dernière modification le 25/04/12 à 20:02.

      Quelle est la plus value par rapport a un VPN classique ou je monte un tunnel entre chez moi et mes parents, chez moi et ma sœur, enfin ma sœur et mes parents ?

      J'ai déployé 2 VPN distincts dans une entreprise comprenant 60 sites. Je l'ai fait avec OpenVPN (très bon logiciel, mais désormais la documentation est limitée car l'éditeur favorise la vente de service). Donc un noeud central qui gère la totalité des connexions.
      Si le noeud central lâche, c'est fichu. Si les transferts sont volumineux, le noeud central est surchargé.
      Et puis il faut un noeud central tout court.

      Par contre pour le NAT, je suis curieux.
      Justement, OpenVPN n'a pas de problème avec le NAT. Il suffit que le noeud central soit accessible et c'est tout. Les connexions se font des clients vers le serveur.

      • [^] # Re: J’ai du mal

        Posté par (page perso) . Évalué à 8. Dernière modification le 24/04/12 à 13:44.

        C'est tout à fait ça.

        Dans une infrastructure client-serveur classique, le point critique c'est évidemment le serveur, sans quoi rien n'est possible.

        À noter que cette architecture a tout de même l'avantage de faciliter l'administration (on peut mettre en place un mécanisme d'authentification centralisé par exemple).

        Si on veut un VPN décentralisé, il faut évidemment accepter qu'on doive configurer indépendament chaque noeud : tout se paye :D

        Dans l'exemple cité : si je souhaite mettre en place un réseau entre ma mère, ma soeur et chez moi, j'ai tout l'intérêt de le faire en peer-to-peer :
        - Si ma mère, ma soeur ou moi-même coupons notre ordinateur, les deux autres peuvent continuer à communiquer : personne n'a plus d'importance qu'un autre.
        - Les transferts réseaux sont directs : surtout dans le cas de connexions entre particuliers, les débits sont souvent faibles, et devoir passer par un point C pour aller de A à B peut-être très couteux, en termes de débit ou de latence.

        Justement, OpenVPN n'a pas de problème avec le NAT. Il suffit que le noeud central soit accessible et c'est tout. Les connexions se font des clients vers le serveur.

        Disons que si le serveur OpenVPN est situé derrière un NAT, il faudra aussi faire une redirection de port. Mais effectivement, une fois cette redirection faite (si il est bien derrière un NAT), les clients, quelle que soit leur origine peuvent se connecter sans problème. Puisqu'ils ne se connectent jamais directement entre eux donc il n'ont pas ce problème à résoudre.

        À noter que Freelan permet aussi d'adopter, si on le souhaite, une architecture clients-serveur(s). On perd un peu d'intérêt (sa spécificité c'est tout de même d'être peer-to-peer ;)) mais c'est parfaitement possible :)

  • # Empaqueté dans AUR pour Arch Linux

    Posté par . Évalué à 8.

    J'ai posé des paquets pour freelan-buildtools 1.0, libcryptoplus 1.3, libiconvplus 1.0, libfscp 1.0, libasiotap 1.0, libfreelan 1.0, freelan 1.0 sur https://aur.archlinux.org/

    Je te fais signe si je démarre un dépôt binaire :)

  • # Ports des contacts ?

    Posté par . Évalué à 3.

    Comment spécifie-t-on le port d'écoute des contacts ?
    Doivent-ils être configurés obligatoirement sur le même port d'écoute que le serveur local ?

    • [^] # Re: Ports des contacts ?

      Posté par (page perso) . Évalué à 5. Dernière modification le 24/04/12 à 16:39.

      Le port d'écoute du service est spécifié grace à l'option listen_on:

      # The endpoint to listen on.
      #
      # The endpoint can be in both numeric and hostname format, and must always
      # contain a port specification.
      #
      # Hostnames are resolved using the method specified by
      # network.hostname_resolution_protocol.
      #
      # Using a numeric value is recommended.
      #
      # Example values: 0.0.0.0:12000, [::]:12000, localhost:12000, 10.0.0.1:12000
      # Default: 0.0.0.0:12000
      listen_on=0.0.0.0:12000
      
      

      Le choix des ports est libre sur chaque noeud, il faut simplement contacter un noeud sur le port (public dans le cas d'un NAT) sur lequel il écoute.

      Pour les contacts, on peut spécifier autant d'option contact qu'il y a de contacts:

      # The contact list.
      #
      # The list of hosts to connect to.
      #
      # You may repeat the contact option to add several hosts.
      #
      # Default: <none>
      contact=alice.example.org:12345
      contact=bob.example.org:4545
      
      

      J'espère avoir bien répondu à tes questions ?

      • [^] # Re: Ports des contacts ?

        Posté par . Évalué à 2.

        Super, merci, ce n'était pas hyper explicite dans le /etc/freelan/freelan.conf

        Il faudrait peut-être changer les lignes:

        # Default: <none>
        #contact=127.0.0.1
        
        

        en quelque chose comme:

        # Default: <none>
        #contact=127.0.0.1
        # The default port for contact is 12000
        #contact=alice.example.org:12345
        #contact=bob.example.org:4545
        
        
  • # paquet Fedora (ou tar.gz agnostique)

    Posté par . Évalué à 3.

    Hello, ça serait cool pour les gens qui ne sont pas sur Debian d'avoir un moyen pas trop dur de l'installer au moins pour tester.
    Perso je suis sur Fedora, et en plus j'arrive pas à compiler à partir du dépôt git.

    [freelan-all]$ cd libfreelan/
    [libfreelan]$ scons
    scons: Reading SConscript files …
    ImportError: No module named freelan.build_tools:
    File "/…/freelan-all/libfreelan/SConstruct", line 12:
    from freelan.build_tools import LibraryProject, Environment
    [libfreelan]$ cd ../freelan
    [freelan]$ scons
    scons: Reading SConscript files …
    ImportError: No module named freelan.build_tools:
    File "/…/freelan-all/freelan/SConstruct", line 13:
    from freelan.build_tools import ProgramProject, Environment

    Sinon ton soft fait très envie, je suis utilisateur d'OpenVPN en niveau 2 donc forcément FreeLAN m'intéresse aussi…
    Merci.

    • [^] # Re: paquet Fedora (ou tar.gz agnostique)

      Posté par (page perso) . Évalué à 3.

      Merci :)

      D'après ton erreur, tu n'as pas installé les "build tools" sur ton système (il ne trouve donc pas le module Python).

      Si tu vas dans le sous-répertoire build-tools, le README devrait expliquer comment procéder.

      En gros, il faut, dans l'ordre :

      1. Installer les build tools
      2. Compiler et installer la libcryptoplus ("scons && scons install")
      3. Compiler et installer la libasiotap ("scons && scons install")
      4. Compiler et installer la libfscp ("scons && scons install")
      5. Compiler et installer la libfreelan ("scons && scons install")
      6. Compiler et installer freelan ("scons && scons install")

      N'hésite pas à contacter la mailing list des développeurs si tu rencontres d'autres soucis. Les informations pour s'y inscrire sont là : http://www.freelan.org/page/contact

      • [^] # Re: paquet Fedora (ou tar.gz agnostique)

        Posté par . Évalué à 2.

        Merci.

        Cela dit j'aime pas trop l'idée d'installer globalement sur le système dans /usr/local des scripts utiles spécifiquement à compiler un programme, j'imagine que c'est pythonic (faut taper setup.py donc c'est pythonic, ça serait setup.exe ce serait grave pas bien) mais c'est pas du tout dans ma conception de la gestion de ce que j'installe ou pas sur mon OS et de comment.

        Je ferai avec parce que j'ai envie de jouer avec ton truc :-)

        • [^] # Re: paquet Fedora (ou tar.gz agnostique)

          Posté par (page perso) . Évalué à 2. Dernière modification le 25/04/12 à 08:07.

          Je dois admettre que je suis assez partagé moi aussi sur le fait d'installer directement des choses dans /usr/local.

          Note par contre que tu souhaites isoles les fichiers de développement de freelan (pour pouvoir par exemple tout virer d'un coup au besoin ;)), tu peux :

          1. Installer les build-tools ailleurs et simplement régler ton PYTHONPATH pour qu'il pointe vers cet "ailleurs"
          2. Valoriser les différentes variables d'environnement décrites ici pour que les installations des bibliothèques freelan se fassent où tu le souhaites :)
          3. Tu n'as plus après qu'à régler ton LIBRARY_PATH et ton LD_LIBRARY_PATH pour que ça fonctionne.

          N'hésite pas à t'inscrire sur la mailing list des développeurs si tu rencontres des soucis ou a des questions à propos des bibliothèques !

  • # Samba

    Posté par . Évalué à 3.

    As-tu fait des tests avec un partage samba entre plusieurs pc via freelan en mode peer-to-peer?

    Est-ce que c'est utilisable?

    • [^] # Re: Samba

      Posté par (page perso) . Évalué à 3.

      Oui, tout à fait.

      C'était même un des premiers tests ;)

      Le réseau virtuel créé ne peut quasiment pas être distingué d'un réseau réel donc tout ce que tu pourrais faire en "vrai", tu peux le faire au travers d'un réseau freelan.

  • # table DHT

    Posté par (page perso) . Évalué à 6.

    Est-ce envisageable d'utiliser une table DHT pour l'auto-connexion de peers ?
    Par exemple je souhaite intégrer ta lib dans mon projet. Ainsi s'il a un certain succès les users pourraient communiquer de la data entre eux de manière sécurisés via leur VPN. La faille est qu'il faut indiquer les IP de chaque peers dans la conf….
    Si freelan intégrait une table DHT il pourrait automatiquement ajouter l'ip d'un peers dans une table DHT globale à mon projet. Ensuite dans mon app si j'intègre un système de gestion des contacts à partir de clé GPG, façon retroshare, je pourrais associer à l'ip du peer sa clé public GPG dans la table DHT, voir mettre à jour l'ip (et je fuck ainsi les DNS …).

    Ainsi les peers de confiance qui se sont signé leur clé pourraient s'auto-connecter, une lib C++ comme http://bitdht.sourceforge.net/ pourrait peut être le faire ? Que penses-tu de cette idée ?

    • [^] # Re: table DHT

      Posté par (page perso) . Évalué à 3.

      C'est une excellente idée je trouve.

      Ce serait une bonne chose qu'on en discute aussi avec les autres développeurs (genre sur la mailing-list) afin qu'on tire partie de "l'intelligence collective" et qu'on voit comment on peut intégrer ça. N'hésite pas à t'y inscrire (tu peux t'en désinscrire très facilement au besoin, donc pas de craintes d'être spammé à ce niveau là )

      En tout cas le fait de ne pas avoir d'alternative à la saisie manuelle des contacts m'a toujours dérangé, et ta solution me semble très intéressante.

      • [^] # Re: table DHT

        Posté par (page perso) . Évalué à 3.

        En tout cas le fait de ne pas avoir d'alternative à la saisie manuelle des contacts m'a toujours dérangé, et ta solution me semble très intéressante.

        Super, merci d'être si ouvert. Je crois qu'il y a un truc énorme à faire à pouvoir créer un VPN par application. Ca pourrait être la base d'un cloud libre en P2P qui permettrait le développement de services libres décentralisés et DNS free.

        • [^] # Re: table DHT

          Posté par (page perso) . Évalué à 3.

          J'aime assez ton idée ;)

          Pour avoir un VPN par application, il faut juste avoir à l'esprit que ça va impliquer que les applications :

          1. Tournent avec les droits administrateurs (indispensable pour créer une interface virtuelle)
          2. Aient chacune une interface virtuelle (là ça risque d'être un peu plus chaud, parce que je ne suis pas sûr qu'un utilisateur accepte de se retrouver avec plus de dix cartes réseaux (surtout sous Windows), même virtuelles).

          Par contre, on peut tout à fait utiliser le protocole freelan sans le lier à une interface virtuelle (comme un simple canal de communication authentifié et chiffré) et ça ce n'est pas sujet aux deux points bloquants que j'ai énoncé plus haut !

          • [^] # Re: table DHT

            Posté par (page perso) . Évalué à 3.

            Ok en effet ca peut etre lourd. Par contre on peut imaginer un client freelan par machine, client qui proposerait via une socket TCP et une lib, la possibilité à une application d'avoir sa propre DHT via freelan. Exemple à la con, l'éditeur de texte Gedit se connecte via une lib (lib_dht_freelan.so/.dll) au client freelan, et pourrait ainsi se connecter via Internet à d'autres peers qui ont lancé gedit. Ca permettrait d'ajouter des features de chat ou de travail collaboratif un peu comme gobby.

            Le truc c'est que la lib fournirait via freelan l'abstraction pour la gestion de la DHT, le code de gedit n'aurait qu'à dire que son UUID est 45468789 pour créer et identifier une DHT associée à Gedit, freelan s'occupant de la comm entre toutes les apps. C'est crédible ?

            • [^] # Re: table DHT

              Posté par (page perso) . Évalué à 3.

              C'est tout à fait crédible je pense.

              Ça mérite évidemment une discussion plus poussée pour spécifier la chose mais c'est une très bonne idée je trouve.

              Je vais me renseigner sur les DHT et les bibliothèques utilisables dès que j'en aurai fini avec les tutoriaux de configuration que tout le monde me demande ;)

    • [^] # Re: table DHT

      Posté par (page perso) . Évalué à 1.

      Ça fait un bout de temps que je réfléchit à un projet de ce genre. En effet le problème commun à tous les réseaux P2P / auto hébergement / réseaux sociaux dé(a)centralisé c'est l'identification des personnes et des machines associées.

      Je me tâtait plus ou moins à lancer le projet pour de bon et commencer à coder et réaliser des specs.
      L'idée que j'ai en tête :
      - utiliserait les clés GPG comme identifiant.
      - identifierait des personnes et y associerait des machines
      - permettrait d'avoir plusieurs machines associées à un utilisateurs et avoir plusieurs utilisateurs sur une machine.
      - serait dépendant des appli construites au dessus. (il serait possible de porter des clients xmpp, serveurs mail et web sans que ça soit trop douloureux)

      En fait se serait une sorte de DNS pour des personnes (et non des machines) et entièrement acentré (DHT). Ça permettrait d'avoir un «identifiant personnel universel» pour toutes sorte d'appli et ce sans contrôle central.

      Si vous êtes intéressé, on pourrait lancé une discussion et voir ce qu'on peut faire.

      Matthieu Gautier|irc:starmad

      • [^] # Re: table DHT

        Posté par (page perso) . Évalué à 2.

        En effet il y a quelque chose à faire. Perso mon projet est de fournir un backend générique qui permette de développer tout type d'application, web, desktop, smartphone. Je souhaite que ce backend puisse fonctionner en P2P, d'ou mon intérêt sur freelan pour que je puisse m'appuyer dessus. Par contre moi comme Freelan c'est du C++, mais tout aide est bienvenue.

        • [^] # Re: table DHT

          Posté par (page perso) . Évalué à 1.

          Bon je vais me lancer dans l'écriture d'un doc.

          Par contre moi comme Freelan c'est du C++, mais tout aide est bienvenue.

          T'inquiète pas, je risque pas de l'écrire en java. Je pense même que le C est plus adapté que le C++ si je veux faire des lib utilisables par un max de soft (et donc différents langages).

          Matthieu Gautier|irc:starmad

    • [^] # Re: table DHT

      Posté par . Évalué à 2.

      Si freelan intégrait une table DHT il pourrait automatiquement ajouter l'ip d'un peers dans une table DHT globale à mon projet.

      Attention à la privacy… Si tu mets les IP telles qu'elle, n'importe qui ayant accès à la DHT peut voir tous les membres du réseau. Le mieux est de faire comme oneswarm (retroshare doit utiliser la même chose): ajouter une entrée de DHT signée, puis chiffrée, pour chacun des couples de peers.

      • [^] # Re: table DHT

        Posté par (page perso) . Évalué à 2.

        Oui bien sur, j'avoue que DHT et ce qui gravite autour dépasse mes compétences, c'est bien pour ça que si freelan intègre cette feature ca m'intéresse et surement d'autres dev.

  • # Canal sécurisé.. "robuste" ?

    Posté par . Évalué à 2.

    Question : freelan peut-il être utilisé pour maintenir un canal sécurisé entre deux nœuds ?
    Je veux dire un truc capable de se reconnecter automatiquement en cas de déconnexion, quelque chose de fiable (pas de zombies qui traînent suite à la déconnexion, ou de consommation RAM inflationniste).

    SSH peut théoriquement servir à ça, mais j'ai rien vu de moins fiable qu'un tunnel SSH !

    Sinon merci pour cet outil, OpenVPN devient gâteux.. il y a un vrai besoin pour un VPN open, pas en Java (tm), et suffisamment sophistiqué (fonctionnalités) sans être une galère à configurer.

    • [^] # Re: Canal sécurisé.. "robuste" ?

      Posté par (page perso) . Évalué à 3.

      Tant que le démon (ou le service) Freelan tourne, il essaye périodiquement de se connecter à tous les hôtes qui figurent dans sa configuration. Si le canal tombe (coupure wifi par exemple, ou autre) et que la coupure dure, la session est invalidée et un ré-établissement se fera automatiquement après un court délai.

      Une micro-coupure n'entraîne pas de perte de session (le protocole est tolérant aux pertes).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.