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.
Aller plus loin
- Site officiel de Freelan (3042 clics)
- Spécification du protocole Freelan (620 clics)
- Dépôt principal (281 clics)
- Téléchargements (594 clics)
# pourquoi ?
Posté par Volnai . É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 ereOn (site web personnel) . Évalué à 10. Dernière modification le 23 avril 2012 à 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 paipai62 . Évalué à 3.
Je pense a n2n qui a presque les mêmes fonctionnalité.
[^] # Re: pourquoi ?
Posté par ereOn (site web personnel) . É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 :
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 paipai62 . É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 ereOn (site web personnel) . É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:
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 ereOn (site web personnel) . É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 :
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.
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.
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.
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 ymorin . Évalué à 8.
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 :
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 ereOn (site web personnel) . É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 Grunt . É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 ereOn (site web personnel) . Évalué à 4. Dernière modification le 24 avril 2012 à 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 Anthony Jaguenaud . Évalué à 7.
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 Grunt . É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 ereOn (site web personnel) . É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 paipai62 . Évalué à 3.
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 ereOn (site web personnel) . É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 ping6 . É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 karteum59 . Évalué à 3.
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 ereOn (site web personnel) . É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 guilhem.lettron . É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 ereOn (site web personnel) . É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 fredix . É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 ereOn (site web personnel) . Évalué à 5. Dernière modification le 24 avril 2012 à 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 fredix . Évalué à 4.
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 ereOn (site web personnel) . É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 Anthony Jaguenaud . Évalué à 4. Dernière modification le 25 avril 2012 à 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 ?
[^] # Re: J’ai du mal
Posté par Kerro . Évalué à 7. Dernière modification le 25 avril 2012 à 20:02.
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 ereOn (site web personnel) . Évalué à 8. Dernière modification le 24 avril 2012 à 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.
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 Pierre Carrier . É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 :)
[^] # Re: Empaqueté dans AUR pour Arch Linux
Posté par ereOn (site web personnel) . Évalué à 2.
Super ! Merci beaucoup ! :D
[^] # Re: Empaqueté dans AUR pour Arch Linux
Posté par Pierre Carrier . Évalué à 3.
Pour les décideurs pressés (qui utilisent x86_64 pour le moment, j'ai la flemme de construire un environnement de build i686), les paquets sont disponibles en ajoutant dans /etc/pacman.conf :
[^] # Re: Empaqueté dans AUR pour Arch Linux
Posté par Faya . Évalué à 1.
La description de freelan et libfreelan dit :
C'est normal ?
# Ports des contacts ?
Posté par zyphos . É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 ereOn (site web personnel) . Évalué à 5. Dernière modification le 24 avril 2012 à 16:39.
Le port d'écoute du service est spécifié grace à l'option listen_on:
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:
J'espère avoir bien répondu à tes questions ?
[^] # Re: Ports des contacts ?
Posté par zyphos . Évalué à 2.
Super, merci, ce n'était pas hyper explicite dans le /etc/freelan/freelan.conf
Il faudrait peut-être changer les lignes:
en quelque chose comme:
[^] # Re: Ports des contacts ?
Posté par ereOn (site web personnel) . Évalué à 1. Dernière modification le 25 avril 2012 à 14:22.
Tu as parfaitement raison.
C'est mis à jour :)
Merci !
# paquet Fedora (ou tar.gz agnostique)
Posté par DerekSagan . É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.
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 ereOn (site web personnel) . É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 :
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 DerekSagan . É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 ereOn (site web personnel) . Évalué à 2. Dernière modification le 25 avril 2012 à 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 :
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 Donk . É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 ereOn (site web personnel) . É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 fredix . É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 ereOn (site web personnel) . É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 fredix . Évalué à 3.
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 ereOn (site web personnel) . É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 :
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 fredix . É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 ereOn (site web personnel) . É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 GaMa (site web personnel) . É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 fredix . É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 GaMa (site web personnel) . Évalué à 1.
Bon je vais me lancer dans l'écriture d'un doc.
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 fredix . Évalué à 2.
Il faudra de toute manière des libs dans un maximum de langage comme le fait redis http://redis.io/clients
[^] # Re: table DHT
Posté par geb . Évalué à 2.
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 fredix . É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 Salim . É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 ereOn (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.