o Chaque contexte possède un CA qui signe les certificats des noeuds et celui que la virtual-switch utilise. Le noeud et la virtual-switch échangent leur certificat. Pour l'instant on assume que si les certificats sont trustés, la session SSL devrait passer. Il y a aussi une whitelist de tous les noeuds qui sont autorisés. Ce qui fait que même si tu as un certificat valide, et que tu n'es pas dans la whitelist, ta connexion ne fonctionnera pas.
o Les certificats sont poussés au moment du provisioning, le mode ADH est simplement utilisé la première fois. Une fois que le noeud a téléchargé ses certificats, il y a un step-up et la connexion se fait en utilisant les certificats et AES256-SHA. Il peut en effet avoir un MITM actif à ce moment-là. Tu peux regarder notre code de provisioning2 qui est en cours et qui utilise une méthode plus solide que celle de notre prototype, et qui utilise aussi du Ephemeral DH: https://github.com/netvirt/netvirt/tree/prov2
o La communication TCP est présentement seulement entre la virtual-switch et le controlleur.
o Les noeuds et la virtual-switch se parlent en UDP (plus précisément en utilisant UDT) voir: http://udt.sourceforge.net/
o Il faut absolument un serveur central qui fait provisionning des noeuds et la découverte des noeuds connectés. Par contre le transfert de données se fait en P2P, à moins d'avoir un réseau qui bloque le UDP hole punching.
Le noeuds se connectent directement entre eux (p2p) lors d'un transfert de données. Il se peut dans de rare cas que le (p2p) ne fonctionne pas, dans ce cas les données passent par un serveur central.
Le dashboard est entrain de se faire nettoyer et il va aussi faire partie de la brique libre. Le but est que n'importe qui puisse faire tourner NetVirt sur son propre serveur. Comme tu peux le constater, il n'y a pas de business modèle de décidé encore.
Et pour la doc, tu as parfaitement raison, c'est une tâche que l'on doit attaquer :)
Il y a un feature qui va arriver éventuellement qui se nomme "les présences" et qui va permettre de voir via la page web et le client: le status des nodes de ton réseaux et qui est en p2p avec qui (histoire de s'assurer que le p2p a bien fonctionné).
Cela va donner une bonne vue d'ensemble sur ce qui se passe sur son propre réseau.
Oui, le paquet va avoir en dépendance libcap2-bin, afin de déscendre automatiquement l'outil setcap. C'est quelque chose que nous avons oublié de faire, merci pour le rappel :)
le mécanisme n'est pas présent aujourd'hui, mais tu vas pouvoir révoquer une node dans le cas où quelqu'un volerait ton ordinateur, ce qui va rendre invalide son certificat et donc il ne pourra pas se connecter.
Merci pour vos commentaires et vos questions, cela va nous permettre de s'améliorer !
C'est vrai que le site est plutôt laconique pour le moment, et que la suite logique du comment le tout fonctionne n'est pas très clair !
Il y a des questions qui ont été soulevées par beaucoup d'entre vous, et nous allons faire en sorte que le site internet y répondent directement. C'est évident qu'un système qui dit encrypter l'information et qui n'explique pas derrière ce qui se passe, ça ne met pas les gens en confiance. Nous allons ajouter l'information technique et non technique.
Pour répondre à la question de la license, le client est sous GPLv3 et la partie disponible côté serveur est sous AGPLv3
Posté par nib .
En réponse au journal DynVPN beta.
Évalué à 1.
Bonjour Sytoka Modon,
Oui en effet un client multi-plateforme est essentiel.
Pour l'instant un version bêta Windows et linux (raspberry pi aussi) est disponible. La version OS X fonctionne, mais le packaging n'est pas encore fini.
Posté par nib .
En réponse au journal DynVPN beta.
Évalué à 2.
Bonjour fredix,
La clé est nécessaire seulement la première fois que tu lances dnc. Ça permet à ton client de se provisionner. C'est-à-dire de recevoir les certificats qui seront utilisés par la suite.
Et pour répondre à ta question, oui en effet un mode daemon pour le client console est prévu :)
Posté par nib .
En réponse au journal DynVPN beta.
Évalué à 3.
Bonjour NeoX,
Une fois un réseau virtuel créé, l'idée est d'ajouter des membres dans le réseau. Chaque membre possède une clé unique qui permet de provisionner le membre automatiquement la première fois qu'il se connecte.
Donc une clé (un membre) devrait être ajouté pour chaque ordinateur différente que tu connecte.
[^] # Re: j'ai voulu contribuer
Posté par nib . En réponse au journal NetVirt - solution de réseautique virtuel. Évalué à 0.
Bonjour !
tu as essayé de payer via paypal ?
paypal te permet de payer via un compte paypal ou bien via une carte de crédit,
quel méthode tu as utilisé ?
merci !
[^] # Re: Description technique
Posté par nib . En réponse au journal NetVirt - solution de réseautique virtuel. Évalué à 2.
Bonjour,
o Chaque contexte possède un CA qui signe les certificats des noeuds et celui que la virtual-switch utilise. Le noeud et la virtual-switch échangent leur certificat. Pour l'instant on assume que si les certificats sont trustés, la session SSL devrait passer. Il y a aussi une whitelist de tous les noeuds qui sont autorisés. Ce qui fait que même si tu as un certificat valide, et que tu n'es pas dans la whitelist, ta connexion ne fonctionnera pas.
o Les certificats sont poussés au moment du provisioning, le mode ADH est simplement utilisé la première fois. Une fois que le noeud a téléchargé ses certificats, il y a un step-up et la connexion se fait en utilisant les certificats et AES256-SHA. Il peut en effet avoir un MITM actif à ce moment-là. Tu peux regarder notre code de provisioning2 qui est en cours et qui utilise une méthode plus solide que celle de notre prototype, et qui utilise aussi du Ephemeral DH: https://github.com/netvirt/netvirt/tree/prov2
o La communication TCP est présentement seulement entre la virtual-switch et le controlleur.
o Les noeuds et la virtual-switch se parlent en UDP (plus précisément en utilisant UDT) voir: http://udt.sourceforge.net/
o Il faut absolument un serveur central qui fait provisionning des noeuds et la découverte des noeuds connectés. Par contre le transfert de données se fait en P2P, à moins d'avoir un réseau qui bloque le UDP hole punching.
j'espère que ca répond à tes questions !
[^] # Re: client2serveur ou client2client ?
Posté par nib . En réponse au journal NetVirt - solution de réseautique virtuel. Évalué à 2.
Bonjour,
Le noeuds se connectent directement entre eux (p2p) lors d'un transfert de données. Il se peut dans de rare cas que le (p2p) ne fonctionne pas, dans ce cas les données passent par un serveur central.
[^] # Re: Côté serveur?
Posté par nib . En réponse au journal NetVirt - solution de réseautique virtuel. Évalué à 3.
Bonjour,
Le dashboard est entrain de se faire nettoyer et il va aussi faire partie de la brique libre. Le but est que n'importe qui puisse faire tourner NetVirt sur son propre serveur. Comme tu peux le constater, il n'y a pas de business modèle de décidé encore.
Et pour la doc, tu as parfaitement raison, c'est une tâche que l'on doit attaquer :)
[^] # Re: Pas pu essayer, mais
Posté par nib . En réponse au journal DynVPN passe en v0.5. Évalué à 2.
Il y a un feature qui va arriver éventuellement qui se nomme "les présences" et qui va permettre de voir via la page web et le client: le status des nodes de ton réseaux et qui est en p2p avec qui (histoire de s'assurer que le p2p a bien fonctionné).
Cela va donner une bonne vue d'ensemble sur ce qui se passe sur son propre réseau.
Merci
[^] # Re: Pas pu essayer, mais
Posté par nib . En réponse au journal DynVPN passe en v0.5. Évalué à 2.
Oui, le paquet va avoir en dépendance libcap2-bin, afin de déscendre automatiquement l'outil setcap. C'est quelque chose que nous avons oublié de faire, merci pour le rappel :)
[^] # Re: Pas pu essayer, mais
Posté par nib . En réponse au journal DynVPN passe en v0.5. Évalué à 2.
Bonjour,
le mécanisme n'est pas présent aujourd'hui, mais tu vas pouvoir révoquer une node dans le cas où quelqu'un volerait ton ordinateur, ce qui va rendre invalide son certificat et donc il ne pourra pas se connecter.
# on vous lis
Posté par nib . En réponse au journal DynVPN passe en v0.5. Évalué à 2.
Salut à tous,
Merci pour vos commentaires et vos questions, cela va nous permettre de s'améliorer !
C'est vrai que le site est plutôt laconique pour le moment, et que la suite logique du comment le tout fonctionne n'est pas très clair !
Il y a des questions qui ont été soulevées par beaucoup d'entre vous, et nous allons faire en sorte que le site internet y répondent directement. C'est évident qu'un système qui dit encrypter l'information et qui n'explique pas derrière ce qui se passe, ça ne met pas les gens en confiance. Nous allons ajouter l'information technique et non technique.
Pour répondre à la question de la license, le client est sous GPLv3 et la partie disponible côté serveur est sous AGPLv3
Bonne journée :-)
[^] # Re: Freelan
Posté par nib . En réponse au journal DynVPN passe en v0.5. Évalué à -2.
Faudrait que quelqu'un essait les deux pour en faire la liste !
[^] # Re: j'ai pas bien compris le principe ?
Posté par nib . En réponse au journal DynVPN beta. Évalué à 1.
Voici un petit guide: http://www.dynvpn.com/gettingstarted/
[^] # Re: FreeLan
Posté par nib . En réponse au journal DynVPN beta. Évalué à 1.
Bonjour Sytoka Modon,
Oui en effet un client multi-plateforme est essentiel.
Pour l'instant un version bêta Windows et linux (raspberry pi aussi) est disponible. La version OS X fonctionne, mais le packaging n'est pas encore fini.
[^] # Re: daemon ?
Posté par nib . En réponse au journal DynVPN beta. Évalué à 2.
Bonjour fredix,
La clé est nécessaire seulement la première fois que tu lances dnc. Ça permet à ton client de se provisionner. C'est-à-dire de recevoir les certificats qui seront utilisés par la suite.
Et pour répondre à ta question, oui en effet un mode daemon pour le client console est prévu :)
merci pour le retour,
[^] # Re: j'ai pas bien compris le principe ?
Posté par nib . En réponse au journal DynVPN beta. Évalué à 3.
Bonjour NeoX,
Une fois un réseau virtuel créé, l'idée est d'ajouter des membres dans le réseau. Chaque membre possède une clé unique qui permet de provisionner le membre automatiquement la première fois qu'il se connecte.
Donc une clé (un membre) devrait être ajouté pour chaque ordinateur différente que tu connecte.