Dans une infrastructure client-serveur classique, le point critique c'est évidemment le serveur, sans quoi rien n'est possible.
À noter que cette architecture a tout de même l'avantage de faciliter l'administration (on peut mettre en place un mécanisme d'authentification centralisé par exemple).
Si on veut un VPN décentralisé, il faut évidemment accepter qu'on doive configurer indépendament chaque noeud : tout se paye :D
Dans l'exemple cité : si je souhaite mettre en place un réseau entre ma mère, ma soeur et chez moi, j'ai tout l'intérêt de le faire en peer-to-peer :
- Si ma mère, ma soeur ou moi-même coupons notre ordinateur, les deux autres peuvent continuer à communiquer : personne n'a plus d'importance qu'un autre.
- Les transferts réseaux sont directs : surtout dans le cas de connexions entre particuliers, les débits sont souvent faibles, et devoir passer par un point C pour aller de A à B peut-être très couteux, en termes de débit ou de latence.
Justement, OpenVPN n'a pas de problème avec le NAT. Il suffit que le noeud central soit accessible et c'est tout. Les connexions se font des clients vers le serveur.
Disons que si le serveur OpenVPN est situé derrière un NAT, il faudra aussi faire une redirection de port. Mais effectivement, une fois cette redirection faite (si il est bien derrière un NAT), les clients, quelle que soit leur origine peuvent se connecter sans problème. Puisqu'ils ne se connectent jamais directement entre eux donc il n'ont pas ce problème à résoudre.
À noter que Freelan permet aussi d'adopter, si on le souhaite, une architecture clients-serveur(s). On perd un peu d'intérêt (sa spécificité c'est tout de même d'être peer-to-peer ;)) mais c'est parfaitement possible :)
[^] # Re: J’ai du mal
Posté par ereOn . En réponse à la dépêche Freelan : un nouveau venu dans le monde des VPN peer-to-peer. Évalué à 8. Dernière modification le 24 avril 2012 à 13:44.
C'est tout à fait ça.
Dans une infrastructure client-serveur classique, le point critique c'est évidemment le serveur, sans quoi rien n'est possible.
À noter que cette architecture a tout de même l'avantage de faciliter l'administration (on peut mettre en place un mécanisme d'authentification centralisé par exemple).
Si on veut un VPN décentralisé, il faut évidemment accepter qu'on doive configurer indépendament chaque noeud : tout se paye :D
Dans l'exemple cité : si je souhaite mettre en place un réseau entre ma mère, ma soeur et chez moi, j'ai tout l'intérêt de le faire en peer-to-peer :
- Si ma mère, ma soeur ou moi-même coupons notre ordinateur, les deux autres peuvent continuer à communiquer : personne n'a plus d'importance qu'un autre.
- Les transferts réseaux sont directs : surtout dans le cas de connexions entre particuliers, les débits sont souvent faibles, et devoir passer par un point C pour aller de A à B peut-être très couteux, en termes de débit ou de latence.
Disons que si le serveur OpenVPN est situé derrière un NAT, il faudra aussi faire une redirection de port. Mais effectivement, une fois cette redirection faite (si il est bien derrière un NAT), les clients, quelle que soit leur origine peuvent se connecter sans problème. Puisqu'ils ne se connectent jamais directement entre eux donc il n'ont pas ce problème à résoudre.
À noter que Freelan permet aussi d'adopter, si on le souhaite, une architecture clients-serveur(s). On perd un peu d'intérêt (sa spécificité c'est tout de même d'être peer-to-peer ;)) mais c'est parfaitement possible :)