NetVirt est une technologie de réseaux virtuels multi-contexte qui permet de créer des réseaux de type LAN par-dessus Internet. Le service www.dynvpn.com fait tourner NetVirt afin d'offrir des services VPN point à point. Pour les amateurs du Cloud et de l'Internet des objets, NetVirt permet d'interconnecter chaque nœud (machine virtuelle, serveur, PC, Raspberry Pi, etc.) au sein d'un réseau privé virtuel (ou Private Cloud Network).
le code est sous licence GPLv3 (nvagent) ou AGPLv3 (nvswitch, nvctrler, libnvcore).
- Financement Indiegogo - https://www.indiegogo.com/projects/netvirt
- DynVPN - https://www.dynvpn.com
- Code source - https://github.com/netvirt
L'intérêt de cette technologie est la facilité avec laquelle vous pouvez ajouter un nouveau nœud à votre réseau. Une nouvelle instance docker, ou bien une nouvelle VM ? Vous pouvez les ajouter à votre réseau aussitôt.
NetVirt est présentement en version bêta, et son client en est à la version 0.6.1.
Pour ceux qui sont intéressés à discuter avec les développeurs, vous pouvez nous joindre sur #netvirt irc.freenode.org.
Happy Networking !
# Côté serveur?
Posté par woopla . Évalué à 5.
J'ai l'impression que côté NetVirt, il y a aussi le serveur qui sert à initier les connexions (une version command-line du site web DynVPN, quoi). Est-ce bien le cas?
Du coup, votre business model c'est de vendre (une fois la beta passée) l'interface de config facile, mais de fournir en logiciel libre l'intégralité des outils nécessaires à la connexion entre machines, sans passer par votre site?
La documentation manque cruellement :)
[^] # Re: Côté serveur?
Posté par nib . É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 :)
# client2serveur ou client2client ?
Posté par ptit_poulet . Évalué à 0.
Bonjour,
Votre système a l'air intéressant dans le sens où il facile la mise en place d'un VPN.
Par contre la question que je me pose, est-ce que les clients peuvent communiquer ensuite entre eux directement ou sont-ils obligé de passer par un serveur central ?
[^] # Re: client2serveur ou client2client ?
Posté par nib . É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: client2serveur ou client2client ?
Posté par ptit_poulet . Évalué à 1.
Merci pour la réponse, très utile de pouvoir se passer de tout intermédiaire.
# Description technique
Posté par Vincent Bernat (site web personnel) . Évalué à 1.
Ça a l'air assez sympa. Toutefois, la solution n'est pas décrite techniquement. Il faut un peu lire les sources. Quelques questions :
[^] # Re: Description technique
Posté par nib . É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 !
# j'ai voulu contribuer
Posté par palm123 (site web personnel) . Évalué à 5.
et payer par carte bancaire, je me fais bouler car (j'habite en France)
l'Etat (AA,AE,AK,AL,AP,AR…) n'est pas bon
le format du numéro de téléphone est incorrect.
Ca énerve de penser qu'une campagne indiegogo n'est pas capable de faire payer des français, mais est conçue pour des américains…
Comment décourager les bonnes volontés en un clic…
Comme je dis toujours, le diable est dans les détails !
ウィズコロナ
[^] # Re: j'ai voulu contribuer
Posté par nib . É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: j'ai voulu contribuer
Posté par palm123 (site web personnel) . Évalué à 2.
Je ne voulais pas utiliser Paypal, donc directement par carte bancaire.
ウィズコロナ
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.