# [Lancement Projet] VPN Distribué - decentVPN

## El_Goretto

Bonjour tout le monde  :Smile: 

Ce thread est la suite de celui intitulé: [Réseau] VPN distribué.

Apparemment, certains d'entre nous vont tenter de passer du côté obscur de la GPL, et s'essayer à la création de projet  :Smile: 

Pour ceux qui ont déjà fait, c'est douloureux?  :Smile: 

Bref, le concept est simple: il s'agit d'avoir un VPN dont les flux ne soient pas obligés de passer par le serveur comment c'est la cas d'une colution classique. Chaque client doit pouvoir s'adresser directement à un autre.

Pour ceux qui connaissent, on va en fait s'attaquer à un segment occupé pour l'instant uniquement par hamachi  qui est proprio, mais fait fureur (qq millions d'utilisateur, parait). J'ai abslomument pas confiance en cette bestiole, donc... "Vas-y gaillard, on te regarde".

La description initiale plus complète en anglais du projet.

EDIT: Cette page de présentation est en cours de MAJ.

Dans ce premier thread, il s'agit juste de présenter à la communauté gentoo francophone le soft que l'on veut obtenir et "l'équipe", et faire appel à leur créativité et leur dynamisme  :Smile: .

[edit: snipé la partie sur le nom, pour + de clarté]

Participants (par ordre d'arrivée):

El_Goretto  - admin, codeur amateur et initiateur du projet

CryoGen  -  admin, codeur et client du projet

-KuRGaN-  -  testeur & gestion peri-projet (wiki, serveur de test à disposition)

PabOu  -  boîte à idée & gestion peri-projet (wiki, TRAC, etc.)

kaworu  -  testeur

Oupsman  -  testeur + serveur de test à disposition

Poischack  -  testeur +OpenBSD

truc  -  joker

----------

## antoine_

Concernant le nom : je ne sais pas ce qui se fait dans le domaine des logiciels libres.

Si tu veux déposer un nom, en France cela se fait auprès de l'INPI. Un nom se dépose dans des catégories. Une catégorie correspond à un type d'activité (j'invente des exemples : une catégorie pour l'organisation de salons, une catégorie pour le tourisme et les agences de voyages, une catégorie pour les logiciels...). Il y en a un peu plus d'une quarantaine je crois. Donc tu peux déposer un nom qui existe déjà, mais pas dans les même catégories.

Déposer un nom pour 10 ans dans une, deux, ou trois catégories coûte 225. Au delà c'est 40 de plus par catégorie. A priori 3 catégories devraient vous suffire.

Maintenant votre logiciel ne va pas être utilisé uniquement en France, et je ne sais pas si vous avez intêret à déposer le nom dans d'autres pays (surtout que ça va vous coûter drôlement cher à force).

Bon à savoir : si vous utilisez un nom sans l'avoir déposé, qu'une société le dépose plus tard, vous pourrez le récupérer en prouvant que vous l'avez utilisé avant. Ceci dit ça imposera de faire un procès (ce qui coûte très très cher).

A mon avis, tant que vous n'avez pas un projet un petit peu solide, ne vous embêtez pas à savoir si il faut déposer le nom.

----------

## nykos

le nom c'est vite changé par la suite  :Wink: 

je trouve l'idée géniale, je connaissais vaguement hamachi et je trouvais l'idée très bonne

par contre es-tu sûr qu'avec la nouvelle loi tu risques rien ?

----------

## CryoGen

Je pense pas.... sinon une connexion via un ordi en ssh te permet d'échanger des fichiers donc ssh illégal ! De toutes facons avec cette lois tout est illégal   :Rolling Eyes:  Et ce n'est pas un logiciel insitant au partage de fichiers  :Wink: 

----------

## El_Goretto

 *nykos wrote:*   

> par contre es-tu sûr qu'avec la nouvelle loi tu risques rien ?

 

Concernant le risque dû à la phobie anti-p2p, je ne pense pas. Il n'y a aucun dispositif d'échange de fichier, et on ne le facilite pas. Par contre, utiliser des systèmes de camouflage pour télécharger des fichiers illégaux est considéré comme circonstance aggravante (je l'ai lu).

C'est un VPN, rien d'autre. Toutes les entreprises en utilisent. Si çà devenait hors la loi...

Maintenant, je n'ai pas assez étudié la sale bête DADVSI pour être catégorique.

@antoine_: Merci pour les infos  :Smile: 

Concernant le projet, je reviens sur Sourceforge. Je vais l'y inscrire. Ca permet d'avoir plein de services utiles sans se casser le f...on: espace pour un site de 100Mo, CVS/SVN, Forum, bugtracking etc.

Autre chose, je l'ai déclaré LGPL. Ca pose problème? J'ai lu l'article sur les différences avec la GPL sur wikipedia, je pense que c'est le plus sage. Sinon, en attendant vos suggestions de noms, et pour me faire la main, j'ai enregistré un projet au nom de decentVPN. A vos critiques et suggestions  :Smile: 

Je finis la page de description du projet, et je poste le lien temporaire (en attendant l'acceptation par SourceForge).

--

edit: Effectivement, comme l'a dit Kurgan, le nom du démon peut se contracter... Ca marche aussi avec mon dvpnd  :Smile: 

Sinon, pour le nom "non pro" (à destination des non linuxiens) j'avais pensé à Kodachi, mais un projet sur sourceforge l'occupe déjà, ggrrr. Sinon j'ai pensé à Nodachi (jeu de mot avec Node, cf la description, et référence au concurrent proprio  :Smile: ). A vous de voir, c'est tout à fait subjectif  :Smile: 

----------

## -KuRGaN-

Au niveau du nom je pensai à DVPN comme DistributedVPN avec un petit nom pour le daemon comme dvnpd    :Rolling Eyes: 

Ou histoire de ne pas trop déranger au niveau de DADVSI, un petit p2pvpn   :Laughing: 

----------

## -KuRGaN-

Et une fois le nom trouvé, il faudrait qu'un graphiste nous fasse un petit logo sympa, déjà histoire de le mettre sur le wiki.

En parlant du wiki, je pensai à mediawiki, simple et efficace.

Tu en penses quoi Pabou?

----------

## truc

Bonjour, je ne suis pas (pour l'instant en tout cas..) capable de coder quoique ce soit, cependant, ce projet m'interesse grandement, aussi, je vous serai très reconnaissant, de nous faire partager vos anvancées, discutions, etc.. (cette thread là, est déjà un bon début, (et une bonne suite à la précédente que je suivais également))

Donc, voila, je ne prétends pas vouloir faire parti de l'équipe, mais si toute fois, [un jour] je pouvais vous être utile, alors, je serai, à priori, disponible,  et ravi de pouvoir faire avancer un tel projet (  :Evil or Very Mad:  oui je sais j'ai une soutenance et un rapport à présenter en septembre mais bon...   :Evil or Very Mad:  )

J'ai, par contre une petite question. Vous avez l'air de dire qu'un tel 'logiciel' (qu'une telle solution) pourrait interesser les joueurs, ça me surprend, étant donné qu'on parle souvent de la lenteur des VPN? Je suis d'accord qu'en ne passant pas par un seul serveur 'central' cela améliorera forcément la latence, mais je me demande, quand même ce qu'on peut réellement espérer  :Question: 

----------

## Nattfodd

Trouver un nom, c'est certes utile, mais pas primordial et il y a beaucoup de choses à penser avant d'en arriver là. Définir clairement ce que vous voulez, quelles features vous allez supporter tout de suite et lesquelles vous ajouterez par la suite, quel langage, quelles librairies, quelles plateformes, etc...

Trouver un noyau dur de devs, des gens sur lesquels vous savez pouvoir compter.

Mettre en place les outils dont vous allez avoir besoin. Les sites de gestion de projet à la sourceforge.net proposent tout ce qu'il faut. Personnellement, je préfère gna! (www.gna.org) à SF.net, ils sont français en plus. 

Vous ouvrez une ou deux ML pour discuter design et commencez à utiliser subversion.

L'important est ensuite d'arriver à avoir suffisamment rapidement quelque chose de fonctionnel. Sinon, le risque est que le "soufflé retombe" et  de ne plus avancer faut de motivation. L'idéal est de réussir à avoir quelque chose d'utilisable avec l'impulsion de départ et de gagner suffisamment d'utilisateurs suffisamment vite pour redonner un second souffle (rien ne motive tant que d'avoir du feedback).

----------

## PabOu

 *-KuRGaN- wrote:*   

> Et une fois le nom trouvé, il faudrait qu'un graphiste nous fasse un petit logo sympa, déjà histoire de le mettre sur le wiki.
> 
> En parlant du wiki, je pensai à mediawiki, simple et efficace.
> 
> Tu en penses quoi Pabou?

 

Tout d'abord, je suis d'accord avec le message du grand développeur nattfodd ;) le nom et le logo, c'est vraiment secondaire. Si le programme se montre à la hauteur de nos attentes et qu'il comble plein de gens, c'est plus important que le goût des personnes en matière de nom de programme...

Pour le wiki, je dois dire que je ne connais que mediawiki, je n'ai pas touché à d'autres.

Ne risque-t-on pas de tomber dans le même piège que phpbb ? tellement utilisé et lourd que des failles sont fréquemment découvertes et exploitées ? mais cela inclut souvent une bonne réactivité de correction des bogues, que d'autres plateformes n'égalent pas... l'un dans l'autre, je ne sais pas lequel est le mieux.

Personnellement, j'aimerais bien essayer TRAC qui est vraiment orienté pour le développement de projets/applications... Peut-être que les services qu'il propose seront redondants avec ce qui est offert par SF.net

Mais la premiere idée que j'avais en tête, c'était d'utiliser un wiki pour faire un liste des features du programme (comme la page de Goretto), et puis d'aller un peu plus loin dans l'explication de ces features (comment l'intégrer, ...) pour que les devs puissent mettre leurs idées à plat, de bien définir ce qui doit être fait, et de quelle façon.. Pour débattre de tout ça, une mailing list serait le plus approprié, tout en se référant au wiki.

Demain, à tête reposée, je lirai la page d'introduction au projet de mister El_Goretto

----------

## El_Goretto

 *truc wrote:*   

> J'ai, par contre une petite question. Vous avez l'air de dire qu'un tel 'logiciel' (qu'une telle solution) pourrait interesser les joueurs, ça me surprend, étant donné qu'on parle souvent de la lenteur des VPN? Je suis d'accord qu'en ne passant pas par un seul serveur 'central' cela améliorera forcément la latence, mais je me demande, quand même ce qu'on peut réellement espérer 

 

En fait, on peut espérer une augmentation de latence minimale sinon négligeable, étant donné que sans chiffrement, on se contentera de faire du routage de paquet. Donc changer une @IP d'un paquet déjà forgé et l'envoyer, c'est super rapide, mon serveur/fw/routeur gentoo fait çà tous les jours sur tout ce qui lui passe sous la main  :Smile: 

L'intérêt est une interface réseau virtuelle (celle du VPN) que les jeux verront comme appartenant à un "LAN".

----------

## kaworu

Salut !

Je n'ai surement pas le "profil requis" pour être programmeur (seulement 1 ans de prog dans les pattes - Java/ Bash / Python), mais si vous avez besoin d'un betâ testeur ou qqch comme ça, je suis là ^_______^

----------

## Oupsman

J'ai éventuellement mon serveur perso à disposition, et je peux administrer les serveurs éventuels.

----------

## El_Goretto

@truc &Oupsman: On pourra avoir besoin de vous pour les tests. En devenant un node du VPN  en installant le client, ça serait déjà un aide précieuse. Pour le serveur, Oupsman, KuRGaN a déjà repondu présent, mais 2 c'est toujours mieux que 1  :Smile: 

@kaworu: pareil, et dépêche toi d'apprendre  :Wink: 

@Nattfodd: merci pour tes conseils... Tu voudrais pas devenir notre "consultant" en projet, des fois?  :Smile:  De précieux conseils pour des apprentis lanceurs de projets, çà serait fantastique. Genre on t'intègre à l'équipe, tu passes qd tu veux et tu nous dis ce que tu penses de la conduite du projet (pas forcément besoin de mettre le nez dans le code, enfin sauf si tu as le temps pour çà naturellement  :Smile: ).

@PabOu & KuRGaN: Si un système permet la rédaction de docs en collaboratif à la façon wiki, mais que ce n'est pas du wiki, çà devrait aller tout autant... Pour TRAC, à vous de voir, j'ai lu cette critique. Pour la gestion des tickets etc, je ne sais pas si il vaut mieux compter sur SourceForge qui est un outil plus standard et auquel les "spectateurs" du projet pourraient être plus habitués. Si on peut installer un wiki ou équivalent sur l'espace web fourni pas SourceForge, alors on peut s'organiser un "match" TRAC (ou autre) contre SF+Wiki et lister les points sur lesquels l'un ou l'autre l'emporte. Le but du jeu, c'est quand même que les outils ne soient pas un obstacle, après si Pabou nous assure un truc du tonnerre avec un outils un peu exotique mais stable...  :Smile: 

----------

## CryoGen

Et bien ca bouge ici ^^

J'ai lu la page de presentation et j'aimerai poser immediatement une question sur la partie "NAT" : dans les versions futur tu comptes tarverser le NAT sans configuration particuliere mais en attendant cette version pourrat-on tout de meme passer le nat ? Je dis ca car beaucoup de personne utilise des routeurs maintenant, les connexions directes se "rarifient" (surtout chez mes clients XD)

----------

## El_Goretto

 *CryoGen wrote:*   

> Et bien ca bouge ici ^^

 

Ya bon  :Smile: 

 *CryoGen wrote:*   

> J'ai lu la page de presentation et j'aimerai poser immediatement une question sur la partie "NAT" : dans les versions futur tu comptes tarverser le NAT sans configuration particuliere mais en attendant cette version pourrat-on tout de meme passer le nat ? Je dis ca car beaucoup de personne utilise des routeurs maintenant, les connexions directes se "rarifient" (surtout chez mes clients XD)

 

Euh, clairement il faut qu'on puisse franchir un NAT, mais le tout est de savoir de quelle façon. Si le NAT est configuré pour forwarder un port (au hasard celui que le client utilise en mode écoute), aucun problème mais je pense que ce n'était pas ta question, si?

Parce que pour le franchissement de NAT sans forwarding de port spécifique, j'ai pas encore réfléchi. Il parait qu'il y a des techniques, mais là on touche au réseau "avancé", il faudrait que je me renseigne.

Si c'était ta question, tu as des idées?

Et pour le nom, ça te va ou tu as une proposition?  :Smile: 

----------

## PabOu

 *CryoGen wrote:*   

> j'aimerai poser immediatement une question

 

D'où l'utilité d'une Mailing List entre nous.

 *CryoGen wrote:*   

> dans les versions futur tu comptes tarverser le NAT sans configuration particuliere mais en attendant cette version pourrat-on tout de meme passer le nat ? Je dis ca car beaucoup de personne utilise des routeurs maintenant, les connexions directes se "rarifient" (surtout chez mes clients XD)

 

Si tout est encapsulé dans un paquet IP (comme OpenVPN), il suffira d'une simple redirection de port... au contraire d'IPsec ou il fait des modifications directement sur le paquet qui sera routé (et donc ca passe pas très bien les NAT).

----------

## CryoGen

Oki donc si une redirection de port suffit ca peut s'arranger  :Smile: 

Et si j'ai bien compris il nous faut un "serveur" par "point de connexion" au VPN ? En gros sur chaque routeur-machine linux on balance notre soft et apres un coup de bageutte magique (et de nombreux litres de sueur) ca marche ? Je demande ca histoire de pouvoir degrossir l'idée  :Smile: 

Pour le nom je propose: ngVPN => Next-Gen VPN (un brin pretentieux non   :Laughing:  )

----------

## truc

Bon j'y vais de mon commentaire, pour trac, j'ai fait joujou, en tant que simple utilisateur avec celui de initng et c'est pas spécialement repoussant.

Ce que j'apprécie, c'est le tout en un, le fait de pouvoir faire des rapport de bug lisible (syntaxe wiki) etc. c'est un gros point fort à mon gout.

----------

## El_Goretto

 *CryoGen wrote:*   

> Oki donc si une redirection de port suffit ca peut s'arranger 
> 
> Et si j'ai bien compris il nous faut un "serveur" par "point de connexion" au VPN ? En gros sur chaque routeur-machine linux on balance notre soft et apres un coup de bageutte magique (et de nombreux litres de sueur) ca marche ? Je demande ca histoire de pouvoir degrossir l'idée 

 

Il n'y aurait qu'un seul serveur pour tout le VPN (sauf si on implémente la délégation d'authent' mais c'est loiiiin dans le plan d'avancement). Le coup du forwarding du port se fait au niveau de l'équipement routeur. Par contre, je pense que cette astuce ne marche que si un seul client est derrière le routeur. 

Sinon au choix:

1- implémenter de laisser le choix du port découte sur le client, et le routeur devra avoir autant de ports forwardés que de clients potentiels (un peu gore). 

2- implémenter un support UPnP (pas super standard, et très bof côté sécurité)

3- développer un 3e type de module logiciel, un hybride (ce à quoi tu devais penser, CryoGen), qui ferait moitié client, moitié routeur intraVPN (il écoute sur l'interface WAN et LAN). Celui-ci serait vu comme un client classique par tous le reste du VPN, sauf pour les clients "derrière" côté LAN qui ne le verront pas (en bref il intercepte leur communication et les NATe). C'est la solution "massue"  :Smile:  EDIT: j'avais les fils qui se touchent: du côté des clients WAN aussi, le module hybride serait invisible.

4- Une solution élégante... à trouver.  :Rolling Eyes:  Appel aux neurones volontaires, je décroche pour ce soir.

 *CryoGen wrote:*   

> Pour le nom je propose: ngVPN => Next-Gen VPN (un brin pretentieux non   )

 

 :Smile:  Note, si le résultat déboite vraiment, c'est clairement une option  :Smile:  Pour la version 2.0?  :Wink:  Enfin moi ça me plait, mais je suis d'un naturel prudent ...

----------

## Enlight

si je peux me permettre, le nom tu t'en balance pour l'instant, le logo c'est pareil, c'est le genre de trucs sur lesquels tu vas révasser des heures au lieu de coder, pour paralyser un projet y'a pas mieux. En plus choisir le nom a posteriori je trouve ça carément mieux car c'est bien plus à même de refléter le soft.

----------

## PabOu

 *El_Goretto wrote:*   

> 4- Une solution élégante... à trouver. :roll: Appel aux neurones volontaires, je décroche pour ce soir.

 

Faire d'un des clients VPN un "maître de LAN" qui recevrait des connexions des machines de son LAN (donc un petit client à développer en plus, ou alors un mode spécial à ajouter au client que l'on va faire) et qui se chargerait de "publier" les IP du réseau VPN appartenant aux machines sur son LAN... Les vrais clients VPN distants ajouteraient alors des routes en conséquence... et puis de laisser faire le routage des paquets à l'OS...

Je ne sais pas si je me suis fait assez clair ?

----------

## CryoGen

S'il y a un serveur unique ce n'est pas decentralisé pour moi. Si ce noeud est injoignable ont fait comment ?

A mon avis il faudrait un serveur par site qui connait les IP_public des autres serveurs. Au lancement les serveurs récuperent les IP_lan que les autres serveurs "hébérgent" afin de creer les routes. Ainsi si un site tombe, le VPN n'est pas affecté puiqu'il n'y a pas de site avec serveur maitre unique... 

Bon c'est un peu basique mais c'est mon idée générale... à 2h45 du mat   :Razz: 

----------

## El_Goretto

 *PabOu wrote:*   

> Faire d'un des clients VPN un "maître de LAN" qui recevrait des connexions des machines de son LAN (donc un petit client à développer en plus, ou alors un mode spécial à ajouter au client que l'on va faire) et qui se chargerait de "publier" les IP du réseau VPN appartenant aux machines sur son LAN... Les vrais clients VPN distants ajouteraient alors des routes en conséquence... et puis de laisser faire le routage des paquets à l'OS...
> 
> Je ne sais pas si je me suis fait assez clair ?

 

Si si, mais c'est le mode de fonctionnement de mon point 3  :Smile: 

Sauf qu'on l'intégrerait au client au lieu d'avoir un soft indépendant.

 *CryoGen wrote:*   

> S'il y a un serveur unique ce n'est pas decentralisé pour moi. Si ce noeud est injoignable ont fait comment ?

  Sur ce point, le décentralisé fait référence au fonctionnement des flux clients entre eux. Mais la remarque est clairement intéressante, la fonctionnalité de redondance des serveurs est plus qu'à creuser. On peut prévoir un groupe de serveurs partageant la même configuration (bases clients&co, il faut prévoir un système de réplication des confs, c'est pas tout à fait trivial). Les clients en auraient la liste (liste peut être aussi distribuée par les serveurs façon fichiers .pac des proxy), et changeraient de serveurs lorsque celui qui est paramétré par défaut chez eux ne répondrait pas à une de leur requête.

 *CryoGen wrote:*   

> A mon avis il faudrait un serveur par site qui connait les IP_public des autres serveurs. Au lancement les serveurs récuperent les IP_lan que les autres serveurs "hébérgent" afin de creer les routes. Ainsi si un site tombe, le VPN n'est pas affecté puiqu'il n'y a pas de site avec serveur maitre unique... 
> 
> Bon c'est un peu basique mais c'est mon idée générale... à 2h45 du mat  

 

Ton point de vue développe le même fonctionnement que ce que propose Pabou (et moi) pour un des nodes qui serait spécialisé dans le routage IntraVPN côté LAN, à la différence que tu l'attribues à un serveur.

Ce dernier point me gêne car normalement, aucun flux ne transite par lui (Je suis plutot partisan de ne pas coller trop de fonction au serveur, plus c'est simple, plus c'est clair et sûr), et de plus je voudrais laisser la possibilité de n'utiliser qu'un seul serveur pour tout un VPN (ceux de taille restreinte).

Donc on est tous d'accord pour la solution de dernière extrémité, sauf pour savoir qui héberge la fonction.

Ceci dit, ce genre de solution de routage intraVPN qui peut nous prendre un bon moment à mettre en place et complexifie l'installation et l'administration de la solulion, est à envisager en dernier recours. Car si on trouve comment faire autrement, tout le boulot fait serait rendu caduc.

J'ai une idée à ce propos, je la muris, et je vous en parle. 

La question est: comment gruger un firewall statefull. Je ramasse les copies à la fin de la journée.  :Smile: 

----------

## Oupsman

 *El_Goretto wrote:*   

> 
> 
> 1- implémenter de laisser le choix du port découte sur le client, et le routeur devra avoir autant de ports forwardés que de clients potentiels (un peu gore). 
> 
> 

 

Et tout faire passer par le même port ? Ca évite de mettre des limites. Beaucoup de soft de P2P travaillent comme çà, et OpenVPN travaille comme çà aussi. Après, tu limites de façon soft le nombre de clients que tu veux avoir en simultané, en fonction de ta bécane et de la charge maximale acceptable. 

Ensuite, je trouve qu'avoir un serveur centralisé pour l'authentification est une mauvaise idée. On pourrait plutot imaginer N serveurs LDAP disséminés sur des clients spéciaux, donc le responsable choisi de gérer l'authentification pour le réseau. Ca évite d'avoir un SPF  :Wink:  et permettrait de réduire la surface d'attaque du réseau. Sachant que le LDAP permet de gérer la réplication automatique, je pense que ce serait pas mal. L'autre solution serait des serveurs Radius, mais là je connais pas du tout.

----------

## PabOu

 *El_Goretto wrote:*   

> 
> 
> Ce dernier point me gêne car normalement, aucun flux ne transite par lui (Je suis plutot partisan de ne pas coller trop de fonction au serveur, plus c'est simple, plus c'est clair et sûr), et de plus je voudrais laisser la possibilité de n'utiliser qu'un seul serveur pour tout un VPN (ceux de taille restreinte).
> 
> Donc on est tous d'accord pour la solution de dernière extrémité, sauf pour savoir qui héberge la fonction.

 

Je ne suis pas d'accord sur tes termes "solution de dernière extrémité". Déjà ca voudrait dire qu'on a pas réussi à faire autrement --> echec. Et puis, la solution me semble très valide à moi, c'est pas une roue de secours.

Par contre je suis d'accord que ce n'est pas à implémenter tout de suite.

Pour commencer, contentons nous d'un simple réseau VPN avec des clients qui ne font QUE la fonction de client. Quand ca fonctionnera, on avisera de la prochaine étape.

----------

## PabOu

pour la décentralisation du serveur.

On pourrait simplement faire un seul client qui fait la fonction de client et de serveur en même temps, avec réplication automatique des données (qui seraient conservées sur disque dur et pas en ram).

On mettrait en place un serveur, on ne lui met rien de spécial dans sa configuration (à part le port sur lequel écouter).

Avec le même binaire, on mettrait en place un client, et on lui spécifie l'ip du serveur dans son fichier de config.

Le client va se connecter et le serveur ajouterait l'ip du client (+port) à sa liste non-officielle (pas dans la config qu'on a établit).

Un met en place un deuxième et un troisième et un... client, tous avec uniquement l'ip du serveur dans le fichier de config.

Lorsque ces clients se connectent, le serveur ajoute leurs ip(+ports) à sa liste non-officielle, et distribue la liste (réplication) aux clients pour qu'ils puissent se connecter entre eux.

Les clients gardent cette liste non-officielle.

À partir de ce moment, il n'y a plus de vrai serveur central, sauf quand on veut ajouter un nouveau client. Seul le "Serveur" peut ajouter de nouveaux clients à la liste (éventuellement penser à une option "priorité" dans le fichier de config pour bien définir qui est le serveur en tout moment quand l'un est down, etc..)

Quand les clients se déconnectent et puis se reconnectent, ils utilisent la liste "non-officielle" pour se connecter --> ca veut dire que même si le "serveur" est down, le réseau VPN peut s'établir, et la liste se dupliquer à partir des clients et non pas du serveur (utilité de la priorité pour savoir qui a raison en cas de conflit de liste)

des questions ?

----------

## -KuRGaN-

Ouai j'aime bien l'idée de Pabou dans l'histoire de rajoutée des clients avec la liste non-officielle.

Mais si on veut décentraliser un max, plusieurs clients/serveurs doivent être habilité à rajouté des clients à cette liste alors.

----------

## PabOu

 *-KuRGaN- wrote:*   

> Mais si on veut décentraliser un max, plusieurs clients/serveurs doivent être habilité à rajouté des clients à cette liste alors.

 

Mais imagine ce cas :

J'ai 50 peers dans mon réseau VPN..

Du jour au lendemain, je décide de retirer un client. Je vais donc l'enlever de la liste "non-officielle" sur un client (un seul pour pas devoir le  faire manuellement sur les 49 restants), et normalement, ce client devrait pouvoir distribuer la nouvelle liste aux autres peers...

Mais que se passe-t-il si un autre client essaye de propager une nouvelle liste différente, au même moment (ou le client qu'on veut enlever est toujours présent) ? quelle liste va devenir la nouvelle ? Je vois deux façons de résoudre ce problème :

un seul serveur qui se charge de la distribution des listes (il n'a pas besoin d'être UP quand il n'y a aucun changement à la liste)un système de priorités comme j'ai parlé précédemment.. mais c'est une solution qui a encore besoin de réfléxion.ce n'est pas un vrai problème

----------

## El_Goretto

Note: j'ai mis des titres aux §, parce que rendu en bas, j'ai relu mon pavé, et ça m'a fait peur...   :Shocked: 

En réponse à Pabou, sur ses dernières reflexions.

(attention, je le précise une fois pour toute, il s'agit bien sûr de critiques à but constructif, rien de personnel. Ca me fait même super plaisir de voir quelqu'un qui mobilise autant sa matière grise et en fait profiter les autres  :Smile: )

1- Décentralisation complète du VPN - laisser le choix

J'avais déjà réfléchi à la possiblité de "décentraliser" une partie des tâches attribuées au serveur. Il m'est apparu que si l'on tient à maintenir un niveau de sécurité correct (cad dire maximal  :Smile: ), on ne peut pas se passer de serveur dédié (un ou plusieurs, mais là n'est pas la question). Je suis donc parti du principe qu'on aurait bien une archi serveur/clients dans un premier temps, et qu'on se laissait le temps de réfléchir à une archi plus pair à pair, car c'est un mode bien plus complexe, et n'offrant pas les mêmes possibilités de sécurisation à l'accès au VPN.Par contre, c'est un des objectifs que j'avais listés à long terme (le mode sans serveur de la page de description).

Pour moi, on doit laisser le choix aux utilisateurs entre sécurité maximale (avec serveur dédié) et simplicité (sans, donc configuration simplissime). Sachant que la redondance de la fonction "serveur"/authentification/accès au VPN est à prendre en compte dans les deux cas, on est d'accord (euh, mais j'y avais pas pensé au début  :Wink: ).

2- Pourquoi proposer une version avec serveur dédié

J'explique: D'un point de vue sécu, il est inconcevable que les données servant à l'authentification soient confiées aux clients. La machine peut être corrompue et controlée par un tiers (pensez qu'on aura des clients sous Windows, hein, c'est tout de suite plus clair). Je ne crois pas que ce soit la peine de vanter les mérites d'un serveur sous linux (si en plus il est hardened, niark niark).Ensuite, on ne peut pas se permettre de faire circuler sur le réseau le contenu des "bases de données" des utilisateurs (ce que tu appelles "réplication automatique des données" si j'ai bien compris).Même si celles-ci sont protégées déjà sur le disque (données pas en clair), et qu'elles sont transférées via le VPN chiffré, c'est prendre un risque pour rien.

C'est une idée à creuser, mais pour le mode sans serveur ultérieur avec que des clients "évolués", dont encore une fois, les utilisateurs auront été averti de la sécurisation moindre.

3- A propos du mode sans serveur dédié

Pour ta description de "la décentralisation du serveur", çà concerne un VPN sans contrôle d'accès? Car tu ne parles pas de la configuration des comptes sur le serveur. Et on ne peut pas compter que sur l'uplet @IP/port pour identifier un membre du VPN (les @IP peuvent êter dynamiques). Il faut à mon avis forcément une notion d'Identifiant (qui ne peut pas être non plus l'@IP dans le VPN). L'idée que les clients réacceptent un client qui serait parti n'est valable que si les clients gardent en mémoires les clés de chiffrement qu'ils ont entre eux. Sinon, comment savoir que le véritable client ne s'est pas fait "descendre" et est spoofé par un tiers?

A mon avis (à discuter), il faut forcément que les clients se reconnectant repartent de zero et se réauthentifient, si besoin auprès d'un client qui aura été "élu" comme "client/serveur" suppléant au précédent qui est devenu indisponible entre temps (ce qui avait l'air d'être le point de départ de ta réflexion).

4- Divers

A ce propos, effectivement la façon d'attribuer les priorités et donc d'élire le prochain "client/serveur" est fichtrement pas évident  :Smile:  C'est à ranger dans la dossier de réflexion sur la redondance des fonctions de serveur.

Pour ton post des "J'ai 50 peers dans mon réseau VPN.. ", et dont on en retire un. C'est clairement le choix 1 pour moi, pour des raisons de simplicité et de rapidité de réaction.En plus, on est assuré qu'il y a une unique serveur à un instant t, grâce à la redondance.

5- La suite

Pour des raisons de clarté, il faudrait qu'à l'avenir on sépare nos axes de réflexions en précisant sur quoi elles portent:

*le mode client-serveur dédié

*le mode "pair à pair" complètement décentralisé, cad "sans serveur dédié"

*le système de redondance serveur (cad priorités/election), qui s'applique aux 2 points précédents.

Par contre, je pense qu'il ne faut pas aller trop loin (cad descendre de façon trop détaillée sur les algorithmes, etc) sur le 2e point, dans un premier temps. Enfin sauf si çà en inspire grandement certains  :Wink: 

Et maintenant, on finit par....

 *Oupsman wrote:*   

> Et tout faire passer par le même port ? Ca évite de mettre des limites. Beaucoup de soft de P2P travaillent comme çà, et OpenVPN travaille comme çà aussi. Après, tu limites de façon soft le nombre de clients que tu veux avoir en simultané, en fonction de ta bécane et de la charge maximale acceptable.

  La discussion parle du cas où on a plusieurs clients NATés derrière le même équipement, et que le serveur est externe. OpenVPN fontionne avec un seul port NATé, car c'est le serveur qui est NATé, et que les clients viennent se connecter dessus. Pour les solutions non légales (youpi) d'échange de fichiers en p2p (au hasard la mule), c'est le même problème que nous. Tu ne peux pas avoir plusieurs clients NATés avec les mêmes ports d'écoute sur le même LAN. (ou alors j'ai les fils qui se touchent)

 *Oupsman wrote:*   

> Ensuite, je trouve qu'avoir un serveur centralisé pour l'authentification est une mauvaise idée. On pourrait plutot imaginer N serveurs LDAP disséminés sur des clients spéciaux, donc le responsable choisi de gérer l'authentification pour le réseau. Ca évite d'avoir un SPF  et permettrait de réduire la surface d'attaque du réseau. Sachant que le LDAP permet de gérer la réplication automatique, je pense que ce serait pas mal. L'autre solution serait des serveurs Radius, mais là je connais pas du tout.

 

Tu confonds le serveur VPN qui va recevoir les demandes d'accès au VPN, avec le processus d'authentification lui même (cela dépendra des modules d'authent' qu'on implémentera). Ce dernier peut très bien avoir lieu ailleurs que sur le serveur VPN (le cas de LDAP et RADIUS justement). Je garde par contre ta très bonne idée pour les "features in later releases"  :Wink: 

Cf plus haut pour la discussion sur l'unique serveur d'authentification, et les "réplications". Idem pour la redondance du "serveur VPN" qui est maintenant dans le scope du projet.

*BAM!*

Voilà, c'est fini. Ouais, fallait pas me chercher aussi, à être aussi actifs alors que je ne pouvais pas répondre depuis le boulot  :Wink: 

----------

## Ey

Bon allez, je vais faire semblant d'aider.

La solution décentralisée n'est pas forcément moins "secure" que la version centralisée. Tout ce qui compte c'est de faire la sécu correctement. En décentralisé à priori la façon la plus seine de faire c'est d'utiliser des certificats. Comme ça vous mettez juste un certificat racine plus le certificat de la bécane sur chacune des machines et à priori vous avez tout ce qu'il faut pour authentifier vos serveurs entre eux. A priori faire du SSLv3 (ou du TLS) sera la solution la plus simple pour mettre ça en place.

Oui ça demande d'avoir une authorité de certification, mais bon c'est pas très grave, elle n'a pas besoin d'être on-line et si vous voulez vraiment faire sérieux, vous pouvez toujours diffusé les CRLs par votre réseau overlay.

Bon sinon pour reprendre un peu votre foutoire, vous vous posez des questions qui ont soit un rapport avec les réseaux overlay soit n'ont rien à voir avec votre problème.

Pour la partie réseau overlay : comment distribuer la liste des addresses (j'ai pas dit IP hein, cf 2e point) ? DHT. Après y a plusieurs solutions pour implémenter cette DHT, mais bon à priori le plus simple est d'aller faire un tour du côté de Chord.

Pour le hors sujet : le routage IP et autre questions sur IP blah blah blah. Vous voulez pouvoir supporter autre chose que de l'IP non ? J'avais vu des mentions sur les anciens jeux et co... bref votre interface réseau (virtuelle) à priori sera une interface ethernet et non une point-to-point. Donc les IPs elles seront gérées comme sur une interface réseau normale. Si vous voulez partager la connexion, il faut soit faire du routage IP et indiquer la route qvb sur les autres PCs de votre LAN, soit bridger l'interface virtuelle avec l'interface LAN. De toute façon tout ça n'a rien à voir avec votre projet, donc les disgression c'est cool mais pour l'instant il faudrait peut-être ce concentrer un peu plus sur le sujet. (Ah oui au passage l'addresse de tout à l'heure à priori c'est une addresse MAC. Après vous pouvez vous servir des addresses MAC comme identifiant du client virtuel, rien n'empêche une addresse MAC d'être sur plusieurs LANs - cf VLANs et co)

EDIT : dsl si je suis un peu brut de fonderie là mais en fait votre truc est en train de me prendre la tete big time. Donc en gros j'ai le choix :

- soit je vous donne un coup de main pour concevoir et implémenter le bidule et je suis pas sorti de l'auberge parce que bon mine de rien vous avez pas l'air d'avoir beaucoup d'experience en la matiere

- soit j'essai de plus y penser et ca va finir par me demenger tellement qu'il faudra de toute facon que j'ailles coder ce truc pour que ca arrete de m'obséder...

----------

## PabOu

 *El_Goretto wrote:*   

> En réponse à Pabou, sur ses dernières reflexions.

 

Tout d'abord, je tiens à dire que tu penses au projet de façon beaucoup plus large que moi, et tu sembles avoir une idée du projet qui est très bien imbriquée/intégrée. Tes réponses parlent de certaines notions que j'ai du mal à comprendre, et quand je me dis que c'est en réponse à une de mes interventions, ca me laisse penser que 1) soit j'ai pas le niveau; 2) soit tu parles d'un truc qui pour moi n'a vraiment rien à voir, et je pense que je me suis mal fait comprendre.. Et c'est frustrant dans un sens. Mais dans un autre, je suis content qu'il ne reste pas de grosses bétises suite à mon passage...

 *El_Goretto wrote:*   

> 1- Décentralisation complète du VPN - laisser le choix
> 
> Je suis donc parti du principe qu'on aurait bien une archi serveur/clients dans un premier temps, et qu'on se laissait le temps de réfléchir à une archi plus pair à pair

 

Là, je viens faire la remarque que notre idée de base était de faire un réseau VPN du genre d'hamachi. Donc, durant le développement (les premières versions bêta), on va commencer par une archi serveur/clients, mais il me semble quand même primordial d'avoir le pair-à-pair tres rapidement (avant la premiere release officielle).

Bien sûr, je crois qu'on est tout de même parti pour avoir une architecture pair-à-pair AVEC un serveur pour centraliser la configuration et tout ca...

 *El_Goretto wrote:*   

> 2- Pourquoi proposer une version avec serveur dédié
> 
> J'explique: D'un point de vue sécu, il est inconcevable que les données servant à l'authentification soient confiées aux clients. La machine peut être corrompue et controlée par un tiers (pensez qu'on aura des clients sous Windows, hein, c'est tout de suite plus clair).
> 
> Ensuite, on ne peut pas se permettre de faire circuler sur le réseau le contenu des "bases de données" des utilisateurs (ce que tu appelles "réplication automatique des données" si j'ai bien compris).Même si celles-ci sont protégées déjà sur le disque (données pas en clair), et qu'elles sont transférées via le VPN chiffré, c'est prendre un risque pour rien.

 

J'aimerais que tu développes un peu ce point. Car il me semble que les seules données dont le serveur et les clients ont besoin, ce sont une liste de clients autorisés avec une liste de clé publique qui leur est associé (et selon la méthode que l'on va développer, une liste d'ip/ports). Donc pour moi, rien de très très secret.. Je me trompe ?

 *El_Goretto wrote:*   

> 3- A propos du mode sans serveur dédié
> 
> Pour ta description de "la décentralisation du serveur", çà concerne un VPN sans contrôle d'accès? Car tu ne parles pas de la configuration des comptes sur le serveur. Et on ne peut pas compter que sur l'uplet @IP/port pour identifier un membre du VPN (les @IP peuvent êter dynamiques). Il faut à mon avis forcément une notion d'Identifiant (qui ne peut pas être non plus l'@IP dans le VPN). L'idée que les clients réacceptent un client qui serait parti n'est valable que si les clients gardent en mémoires les clés de chiffrement qu'ils ont entre eux. Sinon, comment savoir que le véritable client ne s'est pas fait "descendre" et est spoofé par un tiers?
> 
> A mon avis (à discuter), il faut forcément que les clients se reconnectant repartent de zero et se réauthentifient, si besoin auprès d'un client qui aura été "élu" comme "client/serveur" suppléant au précédent qui est devenu indisponible entre temps (ce qui avait l'air d'être le point de départ de ta réflexion).

 

Tu marques un point, j'avais totallement oublié ce coté là de la chose. Par contre, je vais reposer la question une fois de plus.. quelle est l'utilité de ces clés de chiffrement ? Si on travaille avec SSL, cette clé sera regénérée à chaque nouvelle connexion, donc pas besoin de garder l'ancienne... et (je pense) que ce sera transparant pour nous, ca ne doit pas être un point sur lequel il faut s'attarder.

Et le SSL garantit également l'identité de la personne avec laquelle tu parles --> spoof impossible, sauf si le pirate à un accès au disque dur de la machine (et dans ce cas, il pourra très bien pirater la configuration d'identification avec le serveur, donc un serveur dédié n'aide pas).

 *El_Goretto wrote:*   

> 4- Divers
> 
> A ce propos, effectivement la façon d'attribuer les priorités et donc d'élire le prochain "client/serveur" est fichtrement pas évident :) C'est à ranger dans la dossier de réflexion sur la redondance des fonctions de serveur.

 

Je pense également que la redondance du serveur est une option future.

 *El_Goretto wrote:*   

> 5- La suite
> 
> Pour des raisons de clarté, il faudrait qu'à l'avenir on sépare nos axes de réflexions en précisant sur quoi elles portent:
> 
> *le mode client-serveur dédié
> ...

 

Comme je l'ai dit plus haut, je pense qu'on est en train de partir sur un mode hybride de ces deux premières options, puisque le serveur dédié semble irremplacable pour la gestion de la liste de clients, et que le pair-à-pair est notre but.

 *El_Goretto wrote:*   

> *BAM!*
> 
> Voilà, c'est fini. Ouais, fallait pas me chercher aussi, à être aussi actifs alors que je ne pouvais pas répondre depuis le boulot ;)

 

Bah :P

----------

## Oupsman

J'vais p'tet dire une connerie concernant l'accès en mode décentralisé mais il m'est venu une idée cette nuit pendant une période d'insomnie.

Je serais d'avis de se passer complètement de serveur, et d'avoir donc un réseau VPN entièrement P2P. Un peu comme Skype par exemple. Tous les paquets vont donc transiter de peer en peer, avec l'inconvénient d'un temps de latence assez fort, mais qui va diminuer avec le grossissement du projet. 

Comment gérer la sécurité ? Par une paire de clé ?

Non, elle est pas bonne mon idée ? Bon ben je la remballe.

----------

## El_Goretto

Concernant le mode sans serveur dédié: en effet, quand on passe par un système d'authentification par clés publiques accompagnées d'une liste de clients autorisés, il n'y a rien de secret... Excusez moi, j'avais "oublié" ce "détail". Pour ces méthodes d'authentification, ça colle nickel avec une décentralisation complète. Par contre, les authentifications comme SRP (mot de passe) n'iront pas (j'étais focalisé sur çà, car c'est une méthode que je tiens à avoir de dispo, parce qu'elle est simple... pour un utilisateur lambda). Bien vu, tous.  :Smile: 

@Oupsman: tu as saisi l'idée  :Smile:  Mais on va être moins radical, car on ne va pas se passer d'un serveur (même si dans le mode "sans serveur", c'est un des client qui reprend les tâches qui sont associées). En fait, quand tu cites Skype, je sais que les flux sont "p2p-risés"... Mais quand tu lances le soft, tu te "connectes" au réseau... Je pense qu'il y a quand même un serveur.

Pour ce point là, je t'invites à relire nos discussions précédentes, et les justes remarques de Pabou.

@Ey: je n'ai volontairement pas répondu hier soir pour éviter un incident. Ca tombe bien, car tu as édité ton post après coup. Mettons.

Indépendamment de ce que nous sommes, de notre bonne volonté, et de nos compétences supposées, il y a un point à ne pas oublier: on ne peut pas aider les gens malgré eux. Le ton de ton post est vraiment déplaisant. Peut être (sûrement même pour ce que j'ai pris la peine de comprendre) pertinent techniquement. Mais si tu n'expliques rien, si tu "balances", çà nous sert à quoi, nous? Que tu sois dev' à plein temps dans la vie, c'est bien, pas nous. Je ne pas en quoi çà implique un jugement qualitatif sur nos personnes. Un travail propre et bien fait, c'est ce qui compte, pas que le gars qui l'a fait soit un amateur ou un prix nobel.

Maintenant le contenu que j'ai compris: 

-Pour les certifs SSL & co, oui, j'ai zoné.Cf 1er § de ce post.

-Pour le protocole IP et le routage: on est parti sur çà car ça nous permet de réfléchir sur un cas concret. Etant donné qu'on aura une interface TUN/TAP, on est libre de faire ce qu'on en veut de toute façon. En quelque sorte, merci de nous avoir rappellé ce point là, qu'on ne doit pas s'enfermer dans le support IP uniquement.

Pour le fatras d'abréviations entre les 2, merci de nous expliquer ce que tu veux dire. En particuliers qu'est ce que c'est pour toi un overlay, dans le domaine du réseau.

Une remarque de ma part: On en est à la définition des fonctions du projet, et pour savoir si certaines sont faisables, on explique un peu comment on croit que ça peut marcher. On aura encore une phase de réflexion sur le "comment faire au mieux" une fois qu'on se sera assuré que chaque point est faisable. On est loin du code réel, puisqu'on est sur un produit à priori innovant technologiquement (mmmmm  :Wink: ).

Concernant le passage à travers un firewall statefull, j'ai besoin des lumières des calés en réseau, pour voir si mon scénario "colle". Si en plus certains connaissent le fonctionnement détaillé de certains firewall d'entreprise et passent dans le coin...  :Smile: 

Soit A un client qui veut parler à B et monter le tunnel entre eux, et S le serveur. 

Hypothèses: 

Mettons qu'on ne fasse que du TCP entre clients, pour le moment (pour UDP, je ne sais pas si on peut faire qq chose d'analogue, car l'UDP et le statefull...). 

Mettons aussi que le firewall laisse sortir librement les paquets depuis le LAN (c'est raisonnable comme hypothèse, non? sinon, faudrait jouer avec le proxy... je note çà dans ma liste de description du projet). 

Mettons aussi que les clients et le serveur aient toujours un moyen de communiquer (comment? A réfléchir. Keep alive solution par défaut)

Séquence:

A constuit son SYN (demande de d'établissement de connexion TCP), l'envoit à B et simultanément, le client VPN A encapsule ce SYN et envoi un paquet le contenant au serveur S.

B ne recoit bien sûr pas le SYN

S recoit le duplicata du paquet destiné à B.

S envoit à B (par son lien VPN permanent, cf hypothèses) le paquet censé être reçu par B. B calcule la réponse SYN/ACK qu'il doit normalement transmettre à A (euh, les trucs avec le numéro de séquence dans la trame TCP, etc). Il envoit ce paquet à A.

A reçoit la réponse attendue, car il est derrière un firewall statefull intelligent pour qui la séquence est valide.

A compose le dernier message ACK, pour finaliser la connexion TCP. Il l'envoit à B.

B qui ne le recoit pas non plus, mais on s'en fiche. A transmet encore un diplicata à S, qui le transmet à B pour qu'il soit au courant de l'avancement (et je crois qu'il faut aussi qu'il puisse avoir çà pour le numéro de séquence, sinon dasn ea suite, ça merdouille. Merci de confirmer)

Résultat: le firewall est "ouvert" côté A. B peut prendre alors initier un tunnel avec A.

Ouf.

J'ai peut être tout faux. Mais çà serait fichtrement intéressant qu'on me dise pourquoi, histoire que je me couche moins bête ce soir  :Smile: 

----------

## PabOu

 *El_Goretto wrote:*   

> Concernant le passage à travers un firewall statefull, j'ai besoin des lumières des calés en réseau, pour voir si mon scénario "colle". Si en plus certains connaissent le fonctionnement détaillé de certains firewall d'entreprise et passent dans le coin... :)
> 
> Soit A un client qui veut parler à B et monter le tunnel entre eux, et S le serveur. 
> 
> Hypothèses: 
> ...

 

Ton modèle ne me semble pas viable pour deux raisons :

B va recevoir le ACK encapsulé. Une fois décapsulé, il va devoir attribuer le ACK à une interface d'entrée (le tunnel VPN). Le paquet aura une ip source (l'ip publique de A)qui ne peut PAS provenir de cette interface. Le spoof peut utiliser cette technique (afin de faire flooder la vraie personne qui détient cette ip) et il me semble que pour des raisons de sécurité, c'est bloqué par défaut par /proc/sys/net/ipv4/conf/*/rp_filter

B étant derrière un firewall, il est probable que le firewall filtre le SYN/ACK que B essaye d'envoyer directement à A.. Moi ca me parait bizarre de voir un SYN/ACK sortir sans qu'il y ait eu un SYN qui soit passé dans l'autre sens avant... et c'est pour ca que je pense cela pourrait être filtré par certains firewalls

Admettons que le SYN/ACK de B arrive à sortir et à atteindre A. Dans ce cas, le firewall de B *devrait* forwarder la réponse entrante ACK vers B.. faire l'association ip/port du paquet avec B.. Si il ne le fait pas à ce moment là, il ne le fera pas plus tard, et ca veut simplement dire qu'aucun message ne pourra arriver directement de A vers B.

----------

## El_Goretto

Excuse moi Pabou, je suis perdu... Il y a une faute de typo ou bien tu parles d'une séquence autre que celle au dessus?

c'est bien A qui initie la connexion TCP?

Avec:

A       --SYN->     B

A  <-SYN/ACK-- B

A       --ACK->     B

Je vais essayer de répondre indépendament de qui est A ou B.

En fait, on gère "l'encapsulage" des paquets "duplicatas" au niveau utilisateur, dans notre client VPN, donc on fait ce qu'on veut avec. A priori un SYN ne passe pas par les controles que tu cites quand il arrive via VPN sur B depuis S. Le paquet suivant SYN/ACK généré par B est forgé de toute pièce au niveau utilisateur aussi (libnet), donc je ne pense pas qu'on soit embêté de ce côté.

Mais ta remarque est juste: A devra effectivement communiquer son adresse IP publique en accompagnement de son SYN lors de l'envoi à S (ou alors un paquet SYN encapsulé tel qu'il doit sortir sur le WAN, et non celui qu'émet A véritablement sur son interface LAN).

Pour le filtrage qui serait statefull plus ou moins aussi en sortie, c'est tout à fait possible. C'est pour çà que je posais l'hypothèse qu'il n'y avait pas de filtre dans le sens sortant. Sinon, dans ce cas on peut tenter de faire en sorte que S "spoofe" l'IP de B et réponde à sa place. Tu (les autres aussi) en penses quoi?

 *PabOu wrote:*   

> Admettons que le ACK de B arrive à sortir et à atteindre A. Dans ce cas, le firewall de B *devrait* forwarder la réponse entrante SYN/ACK vers B.. faire l'association ip/port du paquet avec B.. Si il ne le fait pas à ce moment là, il ne le fera pas plus tard, et ca veut simplement dire qu'aucun message ne pourra arriver directement de A vers B.

 

Je ne comprends pas, désolé  :Smile: 

Par contre, en réfléchissant, si on a bien A "ouvert" en fin de séquence, ce n'est pas si simple pour que B (pour qui la connexion n'existe pas niveau système) vienne taper sur A juste après. Car pour B, la connexion n'existe pas niveau système. Il faudra faire une séquence similaire pour "ouvrir" aussi B, et là, ça pose pas mal de questions sur ce qui se passe quand on joue un établissement de connexion de B vers A sur les mêmes ports, alors que pour A et son FW, elle existe déjà.

La solution est simple si on peut faire en sorte qu'une partie des messages soit spoofée par le serveur S.

----------

## PabOu

 *El_Goretto wrote:*   

> Excuse moi Pabou, je suis perdu... Il y a une faute de typo ou bien tu parles d'une séquence autre que celle au dessus?

 

Toutes mes excuses.. c'est ma faute !! j'avoue ! que je sois forcé d'éditer mon message pour réparer mon erreur ! Ah, mais c'est déjà fait :) J'avais inversé tous les ACK et SYN/ACK.

 *El_Goretto wrote:*   

> Pour le filtrage qui serait statefull plus ou moins aussi en sortie, c'est tout à fait possible. C'est pour çà que je posais l'hypothèse qu'il n'y avait pas de filtre dans le sens sortant. Sinon, dans ce cas on peut tenter de faire en sorte que S "spoofe" l'IP de B et réponde à sa place. Tu (les autres aussi) en penses quoi?

 

Tout d'abord, j'ai pensé à ton hypothèse mais dans le sens "je laisse sortir uniquement les NOUVELLES connexions (SYN uniquement)+ les connexions qui figurent déjà dans ma mémoire (grâce à un SYN précédent)". Ensuite, il est un peu facile d'assumer que le firewall fonctionnera d'une façon donnée à tous les coups. On devrait prévoir tous les cas possibles dès le début, sinon ca risque de poser problème par la suite quand se sera basé sur des hypothèses pas toujours vérifiées.

A part ca, j'en pense que de cette façon, S servirait d'intérmédiaire dans les deux sens de la communication, et donc aucun firewall (ni du coté de A, ni du coté de B) ne verrait la connexion passer et ils ne sauraient donc pas crééer le tunnel directement entre eux.

 *El_Goretto wrote:*   

>  *PabOu wrote:*   Admettons que le ACK de B arrive à sortir et à atteindre A. Dans ce cas, le firewall de B *devrait* forwarder la réponse entrante SYN/ACK vers B.. faire l'association ip/port du paquet avec B.. Si il ne le fait pas à ce moment là, il ne le fera pas plus tard, et ca veut simplement dire qu'aucun message ne pourra arriver directement de A vers B. 
> 
> Je ne comprends pas, désolé :)

 

ACK <--> SYN/ACK (ma faute voir premier §). 

En fait je dis que si B envoie le SYN/ACK, le firewall devrait ajouter une entrée dans sa table, pour dire que B à une connexion avec A, sur tels ports (et éventuellement natté vers telle ip). Dès lors, lorsque A va envoyer le ACK final, B devra pouvoir le recevoir. Si le firewall ne créée pas l'entrée dans sa table, il ne pourra pas dire que le paquet ACK final destiné à B est légitime et qu'il à l'autorisation de passer. Si c'est effectivement le cas et que le firewall ne créée pas cette entrée à ce moment, alors on peut se dire que le firewall n'ajoutera JAMAIS l'entrée dans sa table et que donc toutes les communications après la négociation SYN/SYN-ACK/ACK (en gros, le tunnel VPN) ne pourront pas passer vers B... Donc c'est inutile de faire passer la réponse ACK par S. Elle doit directement arriver à B sans intermédiaire. Tu comprends mieux ?

 *El_Goretto wrote:*   

> ça pose pas mal de questions sur ce qui se passe quand on joue un établissement de connexion de B vers A sur les mêmes ports, alors que pour A et son FW, elle existe déjà.

 

Je ne sais pas si ca pourrait être utile, mais il existe le flag RST (au même niveau que SYN et ACK dans le header IP) qui sert à resetter une connexion...

----------

## CryoGen

Un petit post pour vous dire que je suis toujours là mais là ca depasse mes compétances ^^ je vais apprendre normément avec ce projet je le sens  :Smile: 

Une fois que le schéma sera plus clair pour vous, il devra l'etre pour moi aussi   :Laughing:  , heuresement, je comprend vite...

----------

## El_Goretto

 *PabOu wrote:*   

> 
> 
>  *El_Goretto wrote:*   Pour le filtrage qui serait statefull plus ou moins aussi en sortie, c'est tout à fait possible. C'est pour çà que je posais l'hypothèse qu'il n'y avait pas de filtre dans le sens sortant. Sinon, dans ce cas on peut tenter de faire en sorte que S "spoofe" l'IP de B et réponde à sa place. Tu (les autres aussi) en penses quoi? 
> 
> Tout d'abord, j'ai pensé à ton hypothèse mais dans le sens "je laisse sortir uniquement les NOUVELLES connexions (SYN uniquement)+ les connexions qui figurent déjà dans ma mémoire (grâce à un SYN précédent)". Ensuite, il est un peu facile d'assumer que le firewall fonctionnera d'une façon donnée à tous les coups. On devrait prévoir tous les cas possibles dès le début, sinon ca risque de poser problème par la suite quand se sera basé sur des hypothèses pas toujours vérifiées.

 

+1.

 *PabOu wrote:*   

> A part ca, j'en pense que de cette façon, S servirait d'intérmédiaire dans les deux sens de la communication, et donc aucun firewall (ni du coté de A, ni du coté de B) ne verrait la connexion passer et ils ne sauraient donc pas crééer le tunnel directement entre eux.

 

Dans le cas où c'est S qui répond à la place de B en spoofant son IP, tu penses qu'on ne pourrait pas "ouvrir" A par cette séquence? Pourquoi? Pour A et son FW, tout se passe normalement, non?

 *PabOu wrote:*   

> Admettons que le ACK de B arrive à sortir et à atteindre A. Dans ce cas, le firewall de 
> 
> En fait je dis que si B envoie le SYN/ACK, le firewall devrait ajouter une entrée dans sa table, pour dire que B à une connexion avec A, sur tels ports (et éventuellement natté vers telle ip). Dès lors, lorsque A va envoyer le ACK final, B devra pouvoir le recevoir. Si le firewall ne créée pas l'entrée dans sa table, il ne pourra pas dire que le paquet ACK final destiné à B est légitime et qu'il à l'autorisation de passer. Si c'est effectivement le cas et que le firewall ne créée pas cette entrée à ce moment, alors on peut se dire que le firewall n'ajoutera JAMAIS l'entrée dans sa table et que donc toutes les communications après la négociation SYN/SYN-ACK/ACK (en gros, le tunnel VPN) ne pourront pas passer vers B... Donc c'est inutile de faire passer la réponse ACK par S. Elle doit directement arriver à B sans intermédiaire. Tu comprends mieux ?

 

Si l'entrée n'est pas ajoutée sur le FW de B pendant qu'on "ouvre" celui de A, on devrait penser à un scénario similaire dans l'autre sens à jouer pour "ouvrir" B après l'ouverture de A.

Pour l'utilité du ACK final, çà dépend, car on devra peut être jouer avec les numero de séquence pour synchroniser A et B, surtout si on ouvre l'un après l'autres par une technique comme çà. De toute façon, A envoie systématiquement pour de vrai ses paquets. Donc qu'il arrive ou pas en plus par le client VPN (je précise que ce n'est pas sous la forme d'un vrai paquet! Il serait encapsulé ou alors on ne transmettrait que certaines infos nécessaires à le reconstituer).

 *PabOu wrote:*   

>  *El_Goretto wrote:*   ça pose pas mal de questions sur ce qui se passe quand on joue un établissement de connexion de B vers A sur les mêmes ports, alors que pour A et son FW, elle existe déjà. 
> 
> Je ne sais pas si ca pourrait être utile, mais il existe le flag RST (au même niveau que SYN et ACK dans le header IP) qui sert à resetter une connexion...

 

Oui, il est employé entre autre pour répondre à une demande de connexion sur un port qui n'est pas en mode écoute. Si quelqu'un sait, j'ai besoin d'un coup de main pour savoir ce qui ce passe dans le cas précis présenté.

----------

## Oupsman

 *El_Goretto wrote:*   

> @Oupsman: tu as saisi l'idée  Mais on va être moins radical, car on ne va pas se passer d'un serveur (même si dans le mode "sans serveur", c'est un des client qui reprend les tâches qui sont associées). En fait, quand tu cites Skype, je sais que les flux sont "p2p-risés"... Mais quand tu lances le soft, tu te "connectes" au réseau... Je pense qu'il y a quand même un serveur.
> 
> Pour ce point là, je t'invites à relire nos discussions précédentes, et les justes remarques de Pabou.
> 
> 

 

Hum ... Il doit y avoir un certain nombres de serveurs chez Skype pour gérer l'authentification et ensuite les différents clients se démerdent (à moins que le(s) serveur(s) en fasse un préroutage des flux pour accélerer un peu le transit des paquets). 

Le point qui me gène dans l'histoire d'avoir un serveur pour gérer des accès VPN, c'est qu'il nous met devant un Single Point of Failure assez génant : en fait, un attaquant qui veut écrouler notre réseau (au sens générique du terme) n'a à attaquer qu'un seul serveur pour compromettre toutes les authentifications au réseau. Je parle ici de SPF au sens large, si les serveurs d'authentification sont bien déterminés, on est fichus. 

Donc de mon humble avis, soit on déporte l'authentification sur des clients spécifiques, soit on s'en passe totalement et on se base sur une paire de clés. Ce qui n'empeche pas l'utilisateur lambda d'avoir à saisir un mot de passe, si tu protèges la clé par mot de passe  :Very Happy:  . 

Comment on définit qu'on veut partager des données avec telle ou telle personne ? Tout simplement en faisant un échange de clés publiques. Non  :Question:  C'est con mon idée  :Question: 

Dans le même domaine, regarde un réseau comme Kademilia : même sans serveur, il est capable de s'initialiser tout seul. Il y'a moyen de l'aider en lui donnant une adresse IP, mais si on ne fait rien, l'initialisation est un peu plus longue, c'est tout. Mais le développement des adresses IP fixes chez les particuliers étant ce qu'il est, je pense que la première initialisation pourrait se faire via une IP fixe*, et les suivantes, au relancement du logiciel se faire via le test des clients connus précédement. Ensuite, une fois l'initialisation faite, le client contacte ceux qu'il connait pour leur demander : "Eh les mecs (où les filles, comme vous voulez) , qui gère l'authentification aujourd'hui  :Question:  " Et le client recoit une liste d'adresses IP à contacter pour s'authentifier. 

Qui plus es, j'aurais tendance à penser que pour l'instant il ne faudrait pas trop partir dans des considérations de passage à travers de firewall, mais plutot s'attacher sur le design général du réseau. Même si certaines considérations techniques découleront de la traversée où non de firewalls .... 

* Après relecture : ou alors sur le site WEB du projet, on maintient un script permettant de récupérer une liste d'adresses IP de clients. Ou alors sur le serveur tourne un applicatif permettant juste d'avoir les adresses IP des clients connus et identifiés comme sûrs. Si on ajoute une roue de secours permettant la découverte des clients via une liste d'adresses IP connues, on diminue de beaucoup les risques de DoS sur notre réseau. 

----------

## PabOu

 *El_Goretto wrote:*   

>  *PabOu wrote:*   A part ca, j'en pense que de cette façon, S servirait d'intérmédiaire dans les deux sens de la communication, et donc aucun firewall (ni du coté de A, ni du coté de B) ne verrait la connexion passer et ils ne sauraient donc pas crééer le tunnel directement entre eux. 
> 
> Dans le cas où c'est S qui répond à la place de B en spoofant son IP, tu penses qu'on ne pourrait pas "ouvrir" A par cette séquence? Pourquoi? Pour A et son FW, tout se passe normalement, non?

 

Ah, tu veux dire un vrai spoof, et pas le "j'encapsule et j'envoie à S pour qu'il transmette le paquet"..

Le vrai spoof est vraiment déconseillé selon moi. C'est mal vu par les FAI, et même peut-être (surement) bloqué.

Mais dans la pratique, pour A et son FW, tout se passe correctement, oui.

 *El_Goretto wrote:*   

> Si l'entrée n'est pas ajoutée sur le FW de B pendant qu'on "ouvre" celui de A, on devrait penser à un scénario similaire dans l'autre sens à jouer pour "ouvrir" B après l'ouverture de A.

 

Ce sont des techniques très avancées qu'on ne devrait pas penser à mettre en place maintenant.

C'est vrai que ca enleverai une épine au pied de l'admin réseau qui va mettre le système en place (un port en moins à forwarder statiquement), mais le projet n'a pas encore commencé. On devrait laisser cette idée sur le coté pour le moment.

----------

## Ey

 *El_Goretto wrote:*   

> @Ey: je n'ai volontairement pas répondu hier soir pour éviter un incident. Ca tombe bien, car tu as édité ton post après coup. Mettons.
> 
> Indépendamment de ce que nous sommes, de notre bonne volonté, et de nos compétences supposées, il y a un point à ne pas oublier: on ne peut pas aider les gens malgré eux. Le ton de ton post est vraiment déplaisant. Peut être (sûrement même pour ce que j'ai pris la peine de comprendre) pertinent techniquement. Mais si tu n'expliques rien, si tu "balances", çà nous sert à quoi, nous? Que tu sois dev' à plein temps dans la vie, c'est bien, pas nous. Je ne pas en quoi çà implique un jugement qualitatif sur nos personnes. Un travail propre et bien fait, c'est ce qui compte, pas que le gars qui l'a fait soit un amateur ou un prix nobel.
> 
> Maintenant le contenu que j'ai compris: 
> ...

 

Bon alors je vais répondre dans le désordre  :Very Happy: 

Commençons par la fin : qu'est ce qu'un réseau overlay ?

Les réseaux overlay c'est une notion assez proche mais légèrement plus générale que les réseaux p2p, pour faire simple c'est un réseau que tu mets par dessus un réseau existant. Après il y a pas mal de constructions assez sympas si tu veux faire un réseau overlay efficace, notament chord et ses dérivés. L'avantage de résonner avec un modèle comme chord c'est qu'il ne fait aucune hypothèse sur ce que tu fais avec le réseau overlay. Donc pour reprendre l'une des idée avancées : faire du routage et ne pas se contenter de faire des connexions point à point directe, chord pourra être utilisé pour faire ça aussi.

Ensuite dans les catégories sigles obscures, DHT : distributed hash table, cf google

Ensuite si je vous ai choqué, c'est bien c'était aussi mon but. A priori ce que vous devrier faire en premier lieux c'est vous faire un peu de culture générale sur les réseaux overlays et la sécu parce que c'est quand même le coeur de ce que vous voulez faire. Ensuite si certains d'entre vous ne savent pas coder, c'est pas grave, il y a des choses beaucoup plus importantes à faire pour le moment que de s'occuper de trouver un logo sexy, et à priori se documenter sur des concepts théoriques ne demande pas de connaissance en programmation.

Sinon pour ce qui est de l'experience en devel (je parles pas juste de chier le code la, mais aussi de la facon d'organiser les choses et ainsi de suite), je tiens quand même à vous rappeler qu'à priori on parle d'un outil de sécu là... (Oui bon je bosses dans la sécu -même si j'ai un profil de devel-, donc je suis peut-etre trop exigent aussi...)

Sinon pour finir, essayez de changer le nom de votre projet, parce qu'en gros ca ressemble a "bon les vpns actuels c'est de la merde, nous on a enfin fait quelque chose de décent..."

----------

## Ey

 *El_Goretto wrote:*   

> Mettons aussi que le firewall laisse sortir librement les paquets depuis le LAN (c'est raisonnable comme hypothèse, non? sinon, faudrait jouer avec le proxy... je note çà dans ma liste de description du projet). 

 

Bof, ça dépend vraiment des entreprises. Par contre le proxy c'est pas vraiment une bonne idée pour bypasser le méchant firewall sur un réseau d'entreprise... enfin sauf si tu comptes faire un VPN sans respecter la politique de sécu de la boite...

De toute façon si le vpn est monté par l'entreprise le/les serveurs qui serviront de gateway VPN auront les accès qui conviennent sur l'extérieur.

Sinon je n'ai pas franchement compris ce que tu voulais faire avec ton A et ton B... Si tu as fait les choses proprement, (même sur un réseau IP) pas besoin d'aller chercher dans la séquence TCP. Le flux est encapsulé entre la gateway VPN et l'extérieur, donc du point de vue d'un firewall, il s'agit d'un flux tout ce qu'il y a de plus normal. Ensuite le reste c'est juste du routage IP. En gros tu as un routeur à un endroit qui au lieu de router vers une interface physique route vers l'interface virtuelle.

PS : et si le client distant n'a pas connaissance du shéma de routage interne, il suffit de faire du NAT (avec l'IP de l'interface virtuelle) sur la gateway, mais encore une fois ce n'est pas vraiment propre à votre projet.

----------

## El_Goretto

@Oupsman: Je vais faire clair. L'objectif premier du projet est de  permettre la communication directe entre clients. Point barre. Si le projet propose par la suite un mode décentralisé poussé (certaines réflexions on porté dessus, et sont dans le domaine du faisable rapidement), c'est pour offrir le choix aux utilisateurs d'éviter la maintenance d'un serveur dédié.

Enfin, il n'y aura pas de SPF (merci pour l'explication  :Smile: ) si le client choisit d'exploiter la redondance que le projet va lui proposer (on a bien rajouté ce point dans les objectifs du projet).

Pour le cas précis des clés assym en mode décentralisé complet (authentification entre les clients directement, mais listing des clients et clés autorisées sur un seul endroit à un instant t), on a déjà dit que c'était a priori une idée intelligente. Sujet clos pour le moment sur l'authentification dans ce mode, puisqu'on a au moins une méthode correcte a priori.

Autre sujet à clore sur le mode décentralisé complet, il y aura forcément un point fixe au départ. Comme pour Kademlia que tu cites, et qui l'appelle le bootstrap. Tes considérations sur le sujet sont justes, mais sortent du cadre d'un VPN. Tu es en train de nous parler d'un projet clone de freenet et son successeur... On est pas là pour faire un réseau p2p crypté à la base (enfin, si tout va bien ici, un fork et hop, demerden sie sich  :Smile: ).

Pour conclure ce passage: c'est un VPN. L'archi n'est pas un seul énorme VPN style communauté/réseau p2p, mais plein de VPNs, des réseaux privés maîtrisés. C'est pour çà que les explications de Ey (merci pour le coup de pied dans les fesses et les explications  :Smile: ) me font un peu peur. Ca fait très freenet totu çà...

A vous de voir, mais ce n'est pas ce que j'avais en tête, et un clone de freenet ne m'interesse pas.

@Ey: Ta double compétence dev/secu est plus qu'alléchante...  :Smile:  Surtout parce que les développements "sécurisés" sont ultra particuliers, comme OpenSSH et sa gestion des droits des processus qui est terrible (lacher les droits root dès que possible). Par contre, là je n'ai aucune idée de comment çà se fait concrètement. Et je serais ravi de recevoir de tes conseils surtout dès la conception de l'archi logicielle. Quand à être exigeant, tant qu'on n'a pas des envies au dessus de ses moyens  :Smile: . Bref, si tu pouvais éclaircir tes intentions quant au projet (si tu comptes faires des apparitions, avoir quelques dispos ou bien intégrer complètement l'équipe)...

Pour le coup du gruge-le-nat et @Pabou, si j'ai poussé la réflexion, c'est que si on est capable de faire çà, on s'évite de développer la partie logicielle qui est censée faire interface entre le WAN et les clients WAN (cf discussions passées). C'est pour çà que si on pouvait être fixé très vite là dessus, çà serait bien  :Smile: 

Sinon, est-ce que l'on a progressé sur le wiki, ou TRAC? Par défaut, si on veut se rabattre sur SourceForge, ils ont validé le projet. Monter un wiki sur 100Mo, c'est faisable?

Note: je serais absent ce WE.

----------

## PabOu

 *El_Goretto wrote:*   

> Sinon, est-ce que l'on a progressé sur le wiki, ou TRAC? Par défaut, si on veut se rabattre sur SourceForge, ils ont validé le projet. Monter un wiki sur 100Mo, c'est faisable?
> 
> Note: je serais absent ce WE.

 

Tout d'abord, il faudrait voir les services proposés par SF et par TRAC. Essayer de voir si ya pas redondance, et si TRAC serait utile.

Le wiki sur 100Mo, c'est largement faisable, il faut juste une base de données derrière.

J'essayerai de voir ca un peu plus en profondeur ce soir et ce week-end.

----------

## Ey

 *El_Goretto wrote:*   

> Ca fait très freenet totu çà...
> 
> A vous de voir, mais ce n'est pas ce que j'avais en tête, et un clone de freenet ne m'interesse pas.

 

Non ça n'a rien à voir avec freenet. 

- Freenet, te garantit l'anonymat, là tu as une addresse visible par tous sur chaque requete que tu fais.

- Ce serait extremement dangeureux de se servir de ce vpn distribué avec des gens que tu ne connais pas/auxquelles tu ne fais pas confiance car ton PC est accessible par toutes les nodes du VPN sur tous les ports => dans ce genre de cas il faut mettre un FW a la sortie du VPN pour se protéger.

----------

## El_Goretto

Juste pour dire que je vais refaire une passe sur le thread sous peu, et faire un résumé de nos discussions sur une page html secondaire du projet. Ah, et je nettoierai le 1er post du thread pour faire plus style "page d'accueil".

(Ouais, le WE était génial mais la reprise affreuse, du coup j'ai encore les neurones tout froissés  :Smile: )

J'attends impatiemment des nouvelles de nos GOs péri-projets  :Wink: 

----------

## PabOu

 *El_Goretto wrote:*   

> J'attends impatiemment des nouvelles de nos GOs péri-projets ;)

 

Euh, j'ai eu un week-end et une semaine très chargée, et puis c'est pas encore près de s'arrêter... je passe mon temps "libre" à venir sur ce forum.

À part ça, qui est encore vivant ?

Et puis, où est-ce qu'on peut mettre en place le wiki/trac ?

----------

## El_Goretto

Crée-toi un compte utilisateur sur sourceforge, et je te donnerai les accès pour le site web.

----------

## PabOu

mon compte créé est da_pabou !

----------

## El_Goretto

Juste un petit Up, pour précisé que le projet n'est pas mort (pour moi en tout cas  :Smile: ) et que je me suis enfin mis à synthétiser les discussions, et à mettre à jour la doc (aucune modif visible pour le moment, c'est en local). 

Oui, plein de schémas, déjà. A ce propos, j'utilise Dia, si à un moment vous voulez récupérer et modifier un fichier original.

----------

## truc

j'y pensais justement, j'l'ai pas refait remonté moi même pour l'instant car galère inside, mais j'suis content de voir que ça avance, j'essaierai de suivre ça au mieux.

----------

## -KuRGaN-

Je n'ai pas trop suivi car du coup, je ne suis pas au chômage , donc j'ai pas trop le temps de m'en occuper en ce moment, désolé.

----------

## PabOu

Ouaip ben moi aussi j'y pense encore assez souvent, car ca m'intéresse toujours ;-)

Pour le wiki, je veux bien m'en occuper (installation, mise à jour, backup, etc), mais j'avoue ne toujours pas avoir d'idée sur lequel choisir. Et je ne pense pas avoir une idée un jour, je ne les connais pas.. à part un tout petit peu mediawiki (celui de wikipedia).

----------

## El_Goretto

 *PabOu wrote:*   

> Pour le wiki, je veux bien m'en occuper (installation, mise à jour, backup, etc), mais j'avoue ne toujours pas avoir d'idée sur lequel choisir. Et je ne pense pas avoir une idée un jour, je ne les connais pas.. à part un tout petit peu mediawiki (celui de wikipedia).

 

Un autre poste sur le forum en avait parlé, il y a pas très longtemps, et avait donné ce lien: http://www.wikimatrix.org/

Pour les critères de selections du "wizard", ça se discute, voilà ce que à quoi je pensais:

-avec historique

-pas d'impératif wysiwyg (mais bon, avec c'est mieux  :Smile: )

-forme logicielle installable

-pas de BD pour la simplicité de gestion (sauvegardes etc), mais des fichiers

-bon, opensource, hein...

-pas de restriction sur le langage

Après çà, en regardant les possibilités, TWiki avait l'air sympa, grâce à un système de plugins (assez monstrueux, en possibilités  :Smile: ). Et il est quand même WYSIWYG...  :Smile: 

----------

## PabOu

Chouette ce wikimatrix :)

C'est quoi ton paramètre "forme logicielle installable" ?

----------

## El_Goretto

Ben euh, par opposition aux solutions hébergées, si j'ai bien compris.  :Smile: 

Note: début de MAJ de la doc, pas encore synthétisé nos discussions, mais présenté le projet. Attention, lien vers la page temporaire free modifié.

----------

## truc

salut, bon, est-ce qu'on pourrait mettre en place un système de mailing list, etc.. histoire qu'on puisse discuter  :Smile: 

Sinon, j'me documente sur pas mal de trucs en ce moment, je repense à ce que vous disiez etc.. bref, je devrais avoir un peu plus le temps, je souhaiterai pouvoir faire avancer les choses.

Je n'ai pas de connaissances particlières en prog (notamment prog réseau & sécu) mais j'ai quand même un avis:) :

Je pense que se baser sur openvpn serait une très bonne idée pour garder une compatibilité quand au différentes évolutions (un peu à l'image des noyau, quand desfois t'installe le 2.6.19, ça te télécharge le snapshot du 2.6.18, puis ça t'applique un enorme patch (qui passe...  :Twisted Evil: ), Mais aussi une compatibilité pendant le fonctionnement (ce qui serait à mon avis un ENORME avantage.

Ca nous obligerai à rester au courant de l'actualité autour d'openvpn, ce qui à mon avis est un bon point, cela devrait pouvoir permettre également aux utilisateur d'openvpn normal de pouvoir tester notre version patchée, avec le moins de modifs possible (les modifs ne concerneront probablement que les gestions des clées etc...   :Question:  )

Ensuite, vous avez discuté sécurité pas mal au début, j'vais jsute abordé un point "réseau", 

Déjà, (au moins pour débuter), comme ça a été dit avant, je serai également plus pour:

* un serveur VPN qui nous interconnecte entre nous

* un paramètre dans la config client disant: oui je souhaite profiter du mode distribué quand c'est possible, et j'ai donc pris les dispositions nécessaires(à définir...)

Quand deux clients veulent correspondre entre eux, si les deux ont activés le mode distribué et si ça marche (timeout? blahblah tenir le serveur au courant?) alors mode fonctionnement en mode distribué entre ces deux hotes sinon, fonctionnement en mode normal client-serveur

Dans le cas où nous somme en mode routé (je garde les termes d'openvpn hein..), ça veut dire que par défaut le fonctionnement est le même qu'openvpn, avec les routes vers les LAN clients etc..., mais dès qu'un connexion distribué est mise en place, certaines routes doivent être changé, ou au moins temporairement remplacées(par exemple sur le client1 le LAN-client2 était à l'origine atteignable par le serveurVPN, mais une fois la connexion réalisée entre client1 et client2, LAN-client2 doit être atteignable directement par le client2, puis une fois la connexion client1-client2 coupée (après un certain temps d'inactivité, ou une coupure brutale pour une raison x ou y) cette route doit revenir à celle propagée par le serveur VPN initialement.

De même avec le LAN-client1.

Le truc qui cloche un peu(je crois), c'est que seul LE serveur openVPN généralest censé connaitre les différents LAN clients, mais les clients ne les connaissents pas d'emblée, donc à supposé que ce soit client2 qui va faire serveur entre client1-client2, il faut trouver un moyen de lui dire d'ateindre le LAN-client1 par la nouvelle interface que la connexion vient de créer(c'est pas très bien dit, mais j'éspère que vous voyez ce que je veux dire ?)(par contre, dans cette configuration (client2 serveur) le problème d'annoncer le LAN-client2 au client un n'en n'est pas vraiment un car LAN-client2 est un 'paramètre' que client2 connait  :Smile: 

J'avais d'autres choses à dire/demander, mais j'ai oublié :/

voili-voilou, j'n'ai pas trop dit de bétise? (j'insiste sur le fait que je pense qu'une compatibilité avec openvpn serait vraiment bien..  :/ )

à vous,

----------

## El_Goretto

Je relirai ta réponse plus en détails prochainement, j'ai du mal à mobiliser mes neurones, en cette période de l'année  :Smile: 

Pour la mailing list, je peux centraliser vos coordonnées  que vous m'envoyez par MP, et on fait une mailing list à "l'ancienne". Je n'ai pas regardé les possibilités de Sourceforge, voir s'il y a un mini-système de forum (voire de mailing liste avec trace, j'ai vu que certains projets le faisaient).

----------

## Raboo

This seems like an intressting project, how is it going?

----------

## El_Goretto

For the moment, it's in standby, cause I haven't found time yet to finish the specification of the very first software architecture.

But I'm still more than motivated...  :Smile: 

I hope and think I'll be able to "steal" some time from my actual job, and go on this project.

According to how my situation will evolve in the next mounth, I'm not yet decided if I will expose my project to my boss or not, so that I would develop it in GPL in a sort of sponsored way.

----------

## Raboo

Why not, a project like this could be good publicity for a company...

Tell your boss that you are willing to put his company on the map!  :Wink: 

Just like LogMeIn's Hamachi

As long as you keep it opensourced & free  :Wink: 

----------

