[Lancement Projet] VPN Distribué - decentVPN

PabOu · Posted: Tue Aug 08, 2006 11:49 am Post subject:

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 ?
_________________
Mangez du poulet !

-KuRGaN- · Posted: Tue Aug 08, 2006 1:05 pm Post subject:

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.
_________________
Knight Gent00 Industries RiDeR !!!!

PabOu · Posted: Tue Aug 08, 2006 2:38 pm Post subject:

El_Goretto · Moderator Joined: 29 May 2004 Posts: 3169 Location: Paris

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

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

)

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

), 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

).

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

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

Et maintenant, on finit par....

Ey · l33t Joined: 07 Apr 2005 Posts: 863 Location: Paris

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 · Posted: Tue Aug 08, 2006 8:01 pm Post subject:

Oupsman · Veteran Joined: 19 Jul 2004 Posts: 1042

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.
_________________
--
L'idéal de nouveauté semble avoir remplacé l'idéal de progrès. C'est bien triste.

----
Unix philosophy: "Do one thing and do it well."
systemd: "Try to do everything and do it wrong."

El_Goretto · Moderator Joined: 29 May 2004 Posts: 3169 Location: Paris

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.

@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.

@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

).

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:
- 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

_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT)

PabOu · Posted: Wed Aug 09, 2006 8:00 pm Post subject:

El_Goretto · Moderator Joined: 29 May 2004 Posts: 3169 Location: Paris

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 · Posted: Wed Aug 09, 2006 10:14 pm Post subject:

CryoGen · Posted: Wed Aug 09, 2006 11:58 pm Post subject:

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

Une fois que le schéma sera plus clair pour vous, il devra l'etre pour moi aussi :lol:

, heuresement, je comprend vite...
_________________
- CryoGen` on #gentoofr@irc.freenode.net
- ~amd64 / KDE4
- I'm the bone of my sword...

El_Goretto · Moderator Joined: 29 May 2004 Posts: 3169 Location: Paris

Oupsman · Veteran Joined: 19 Jul 2004 Posts: 1042

PabOu · Posted: Thu Aug 10, 2006 9:43 am Post subject:

Ey · l33t Joined: 07 Apr 2005 Posts: 863 Location: Paris

Ey · l33t Joined: 07 Apr 2005 Posts: 863 Location: Paris

El_Goretto · Moderator Joined: 29 May 2004 Posts: 3169 Location: Paris

@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

) 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

).

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

) 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...

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

. 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

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.
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT)

PabOu · Posted: Fri Aug 11, 2006 4:37 pm Post subject:

Ey · l33t Joined: 07 Apr 2005 Posts: 863 Location: Paris

El_Goretto · Moderator Joined: 29 May 2004 Posts: 3169 Location: Paris

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

)

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

_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT)

PabOu · Posted: Fri Aug 18, 2006 4:51 pm Post subject:

El_Goretto · Moderator Joined: 29 May 2004 Posts: 3169 Location: Paris

Crée-toi un compte utilisateur sur sourceforge, et je te donnerai les accès pour le site web.
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT)

PabOu · Posted: Sun Aug 20, 2006 12:13 pm Post subject:

mon compte créé est da_pabou !
_________________
Mangez du poulet !