Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Lancement Projet] VPN Distribué - decentVPN
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index French
View previous topic :: View next topic  
Author Message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Tue Aug 08, 2006 11:28 am    Post subject: Reply with quote

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.
_________________
Mangez du poulet !
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Tue Aug 08, 2006 11:49 am    Post subject: Reply with quote

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 !
Back to top
View user's profile Send private message
-KuRGaN-
Veteran
Veteran


Joined: 05 Dec 2004
Posts: 1142
Location: Besançon (25) [FRANCE]

PostPosted: Tue Aug 08, 2006 1:05 pm    Post subject: Reply with quote

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 !!!!
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Tue Aug 08, 2006 2:38 pm    Post subject: Reply with quote

-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

_________________
Mangez du poulet !
Back to top
View user's profile Send private message
El_Goretto
Moderator
Moderator


Joined: 29 May 2004
Posts: 3001
Location: Paris

PostPosted: Tue Aug 08, 2006 6:21 pm    Post subject: Reply with quote

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

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....
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" ;)
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 ;)
_________________
-Gentoo hardened: µ-serv Gen8 G1610T, 8Go ECC ; NF9D-2700, 4Go
-FreeBSD 11/Vimage/Jails: DS61, i3 2100T, 16Go ; FreeNAS: µ-serv N40L, 8Go ECC
-Réseau: ERL-3 + ESL-24 + GS108Tv2
-NAS: RN312
Back to top
View user's profile Send private message
Ey
l33t
l33t


Joined: 07 Apr 2005
Posts: 863
Location: Paris

PostPosted: Tue Aug 08, 2006 7:39 pm    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Tue Aug 08, 2006 8:01 pm    Post subject: Reply with quote

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é
*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.

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
_________________
Mangez du poulet !
Back to top
View user's profile Send private message
Oupsman
Veteran
Veteran


Joined: 19 Jul 2004
Posts: 1038

PostPosted: Wed Aug 09, 2006 5:28 am    Post subject: Reply with quote

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."
Back to top
View user's profile Send private message
El_Goretto
Moderator
Moderator


Joined: 29 May 2004
Posts: 3001
Location: Paris

PostPosted: Wed Aug 09, 2006 4:50 pm    Post subject: Reply with quote

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 :)
_________________
-Gentoo hardened: µ-serv Gen8 G1610T, 8Go ECC ; NF9D-2700, 4Go
-FreeBSD 11/Vimage/Jails: DS61, i3 2100T, 16Go ; FreeNAS: µ-serv N40L, 8Go ECC
-Réseau: ERL-3 + ESL-24 + GS108Tv2
-NAS: RN312
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Wed Aug 09, 2006 8:00 pm    Post subject: Reply with quote

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


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


Last edited by PabOu on Wed Aug 09, 2006 9:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
El_Goretto
Moderator
Moderator


Joined: 29 May 2004
Posts: 3001
Location: Paris

PostPosted: Wed Aug 09, 2006 8:45 pm    Post subject: Reply with quote

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

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.
_________________
-Gentoo hardened: µ-serv Gen8 G1610T, 8Go ECC ; NF9D-2700, 4Go
-FreeBSD 11/Vimage/Jails: DS61, i3 2100T, 16Go ; FreeNAS: µ-serv N40L, 8Go ECC
-Réseau: ERL-3 + ESL-24 + GS108Tv2
-NAS: RN312
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Wed Aug 09, 2006 10:14 pm    Post subject: Reply with quote

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...
_________________
Mangez du poulet !
Back to top
View user's profile Send private message
CryoGen
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1426
Location: Bamako - Mali - Afrique

PostPosted: Wed Aug 09, 2006 11:58 pm    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message
El_Goretto
Moderator
Moderator


Joined: 29 May 2004
Posts: 3001
Location: Paris

PostPosted: Thu Aug 10, 2006 5:22 am    Post subject: Reply with quote

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é.
_________________
-Gentoo hardened: µ-serv Gen8 G1610T, 8Go ECC ; NF9D-2700, 4Go
-FreeBSD 11/Vimage/Jails: DS61, i3 2100T, 16Go ; FreeNAS: µ-serv N40L, 8Go ECC
-Réseau: ERL-3 + ESL-24 + GS108Tv2
-NAS: RN312


Last edited by El_Goretto on Thu Aug 10, 2006 6:45 pm; edited 1 time in total
Back to top
View user's profile Send private message
Oupsman
Veteran
Veteran


Joined: 19 Jul 2004
Posts: 1038

PostPosted: Thu Aug 10, 2006 5:57 am    Post subject: Reply with quote

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

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 :?: C'est con mon idée :?:

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 :?: " 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.
_________________
--
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."
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Thu Aug 10, 2006 9:43 am    Post subject: Reply with quote

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.
_________________
Mangez du poulet !
Back to top
View user's profile Send private message
Ey
l33t
l33t


Joined: 07 Apr 2005
Posts: 863
Location: Paris

PostPosted: Thu Aug 10, 2006 6:36 pm    Post subject: Reply with quote

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


Bon alors je vais répondre dans le désordre :D
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..."
Back to top
View user's profile Send private message
Ey
l33t
l33t


Joined: 07 Apr 2005
Posts: 863
Location: Paris

PostPosted: Thu Aug 10, 2006 6:50 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
El_Goretto
Moderator
Moderator


Joined: 29 May 2004
Posts: 3001
Location: Paris

PostPosted: Thu Aug 10, 2006 7:22 pm    Post subject: Reply with quote

@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.
_________________
-Gentoo hardened: µ-serv Gen8 G1610T, 8Go ECC ; NF9D-2700, 4Go
-FreeBSD 11/Vimage/Jails: DS61, i3 2100T, 16Go ; FreeNAS: µ-serv N40L, 8Go ECC
-Réseau: ERL-3 + ESL-24 + GS108Tv2
-NAS: RN312
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Fri Aug 11, 2006 4:37 pm    Post subject: Reply with quote

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.
_________________
Mangez du poulet !
Back to top
View user's profile Send private message
Ey
l33t
l33t


Joined: 07 Apr 2005
Posts: 863
Location: Paris

PostPosted: Fri Aug 11, 2006 5:08 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
El_Goretto
Moderator
Moderator


Joined: 29 May 2004
Posts: 3001
Location: Paris

PostPosted: Wed Aug 16, 2006 8:49 pm    Post subject: Reply with quote

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 ;)
_________________
-Gentoo hardened: µ-serv Gen8 G1610T, 8Go ECC ; NF9D-2700, 4Go
-FreeBSD 11/Vimage/Jails: DS61, i3 2100T, 16Go ; FreeNAS: µ-serv N40L, 8Go ECC
-Réseau: ERL-3 + ESL-24 + GS108Tv2
-NAS: RN312
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Fri Aug 18, 2006 4:51 pm    Post subject: Reply with quote

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 ?
_________________
Mangez du poulet !
Back to top
View user's profile Send private message
El_Goretto
Moderator
Moderator


Joined: 29 May 2004
Posts: 3001
Location: Paris

PostPosted: Fri Aug 18, 2006 8:11 pm    Post subject: Reply with quote

Crée-toi un compte utilisateur sur sourceforge, et je te donnerai les accès pour le site web.
_________________
-Gentoo hardened: µ-serv Gen8 G1610T, 8Go ECC ; NF9D-2700, 4Go
-FreeBSD 11/Vimage/Jails: DS61, i3 2100T, 16Go ; FreeNAS: µ-serv N40L, 8Go ECC
-Réseau: ERL-3 + ESL-24 + GS108Tv2
-NAS: RN312
Back to top
View user's profile Send private message
PabOu
Veteran
Veteran


Joined: 11 Feb 2004
Posts: 1084
Location: Hélécine - Belgium

PostPosted: Sun Aug 20, 2006 12:13 pm    Post subject: Reply with quote

mon compte créé est da_pabou !
_________________
Mangez du poulet !
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index French All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum