principe de fonctionnement du VPN

On Wed, 6 Sep 2006 19:45:58 +0200, thierry <titi@laposte.net> wrote:

Avez vous de plus amples informations?
Ben surtout un VPN c'est un tunnel...

Et un tunnel ça a deux extrémités. Donc si votre client ne trouve rien
à l'autre bout qui soit configuré pour l'accueillir après paramétrage
de mots de passe, ça va beaucoup moins bien fonctionner...
--
Nina

Salut,

je viens d'installer un client VPN en suivant le mode d'emploi et donc
en ne comprenant pas ce qui va se passer. Pour moi, un VPN "encapsule"
les données dans un format de trame spécial et surtout en cryptant les
données.

Oui, à ceci près que selon les chapelles, un VPN n'implique pas
forcément du cryptage, ou plutôt du chiffrement.

Par contre, je ne voie pas comment cela fonctionne au niveau de
l'OS (je suis sous XP Pro). J'ai créer un raccouci Internet explorer en
indiquant une adresse Ip et un numéro de port (remarque cela ne marche
pas). J'ai donc l'impression que le client VPN "intercepte" les trames
sur le réseau pour voir si elles vont sur la "cible". Dans ce cas il
modifie la trame pour en faire du "VPN".

Est ce que j'ai bon?

Ça dépend comment fonctionne le client. Pour moi il y a la manière
"propre" et la manière "sale". Ce que tu décris est la manière "sale" :
les paquets sont interceptés et court-circuitent le routage normal de la
pile TCP/IP. D'après ce que j'ai pu observer, Wingate VPN semble
fonctionner ainsi.

La manière "propre" consiste à créer une interface réseau virtuelle pour
le VPN, lui attributer une adresse et des routes vers les destinations
joignables via le VPN, en utilisant le routage normal de la pile TCP/IP.
Le pilote de l'interface VPN reçoit les paquets à émettre comme
n'importe quel pilote de carte réseau, les encapsule dans des paquets au
format du VPN et les envoie à l'autre bout du VPN via le routage normal.
L'autre bout du VPN reçoit le paquet encapsulé et réalise les opérations
inverses. OpenVPN fonctionne de cette façon.

"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> wrote in message
news:ednnub$koq$1@biggoron.nerim.net

je viens d'installer un client VPN en suivant le mode d'emploi et donc
en ne comprenant pas ce qui va se passer. Pour moi, un VPN "encapsule"
les données dans un format de trame spécial et surtout en cryptant les
données.

Oui, à ceci près que selon les chapelles, un VPN n'implique pas
forcément du cryptage, ou plutôt du chiffrement.

Tu veux sûrement parler des chapelles commerciales ;-) Prêtes à tout
pour flouer le premier client venu.
Les gens serieux ;-) associent la sécurité au VPN, sinon quelle
différence avec un tunnel ? et que devient le mot "private" ?
Bon, ok, je suis un peu militant.

Ça dépend comment fonctionne le client. Pour moi il y a la manière
"propre" et la manière "sale". Ce que tu décris est la manière "sale" :
les paquets sont interceptés et court-circuitent le routage normal de la
pile TCP/IP. D'après ce que j'ai pu observer, Wingate VPN semble
fonctionner ainsi.

Attention quand même au fonctionnement d'IPsec qui est quand même
relativement propre, mais se permet d'intercepter les
paquets au niveau de la SPD avant tout autre traitement (En même temps
IPsec intervient à la couche 3, alors avant ou après le routage, c'est
une question annexe tant qu'il rend la main à la pile IP après)

La manière "propre" consiste à créer une interface réseau virtuelle pour
le VPN, lui attributer une adresse et des routes vers les destinations
joignables via le VPN, en utilisant le routage normal de la pile TCP/IP.
Le pilote de l'interface VPN reçoit les paquets à émettre comme
n'importe quel pilote de carte réseau, les encapsule dans des paquets au
format du VPN et les envoie à l'autre bout du VPN via le routage normal.
L'autre bout du VPN reçoit le paquet encapsulé et réalise les opérations
inverses. OpenVPN fonctionne de cette façon.

Et OpenVPN c'est bien !
Il ont eu la chance d'arriver 10 ans après que les autres aient essuyé
les plâtres. Mais ils ont eu le bon goût de ne pas perpetuer les mêmes
erreurs, et même de rajouter du mieux dans les fonctionnalités.



--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

selon les chapelles, un VPN n'implique pas
forcément du cryptage, ou plutôt du chiffrement.

Les gens serieux ;-) associent la sécurité au VPN, sinon quelle
différence avec un tunnel ? et que devient le mot "private" ?

Justement, l'interprétation du sens de "private" est sujette à
discussion. Pour les uns, il est à rapprocher de "privacy", ce qui
implique protection des communications et donc chiffrement. Pour les
autres, il signifie juste l'interconnexion transparente de réseaux
privées à travers un réseau public. C'est un peu comme le courrier qui
est privé par nature même s'il n'est pas chiffré. Je reconnais que la
différence entre cette dernière interprétation et la notion de tunnel
est floue.

Personnellement, je n'ai pas d'avis sur la question. Je constate juste
que dans l'esprit de beaucoup VPN est devenu plus ou moins synonyme de
PPTP, peut-être sous l'influence d'un certain OS répandu. Ainsi je lis
nombre de messages concernant des problèmes de VPN sans préciser qu'il
s'agit de PPTP, comme si c'était évident. Je note également que PPTP
n'impose pas de chiffrement.

Ça dépend comment fonctionne le client. Pour moi il y a la manière
"propre" et la manière "sale". Ce que tu décris est la manière "sale" :
les paquets sont interceptés et court-circuitent le routage normal de la
pile TCP/IP. D'après ce que j'ai pu observer, Wingate VPN semble
fonctionner ainsi.

Attention quand même au fonctionnement d'IPsec qui est quand même
relativement propre, mais se permet d'intercepter les
paquets au niveau de la SPD avant tout autre traitement (En même temps
IPsec intervient à la couche 3, alors avant ou après le routage, c'est
une question annexe tant qu'il rend la main à la pile IP après)

Je n'ai jamais bien compris comment fonctionne IPSec. Je sais par contre
qu'avec un noyau Linux 2.4 l'utilisation d'IPSec passait par la création
d'une interface réseau virtuelle distincte des interfaces réseau
"normales", alors que ce n'est plus le cas avec un noyau 2.6.

Il me semble quand même qu'IPSec a deux modes de fonctionnement :
transport et tunnel. Si j'ai bien compris le mode transport sert à la
communication entre deux hôtes et seule la charge utile des paquets est
chiffrée ; l'en-tête IP d'origine reste lisible et sert pour le routage
des paquets. Je ne qualifierais pas ce mode de VPN car je ne vois pas de
réseau virtuel là-dedans. Pour moi c'est juste du chiffrement sur le
réseau normal, Il n'y a pas besoin d'interface spéciale IPSec.

Quant au mode tunnel, il sert à la communication entre deux réseaux ou
entre un réseau et un hôte. Les paquets sont entièrement encapsulés et
chiffrés, en-tête comprise, dans d'autres paquets. C'est donc un tunnel
chiffré, à l'instar d'OpenVPN. Et logiquement le mode tunnel devrait
utiliser des interfaces spécifiques pour router le trafic dans le
tunnel. Mais je n'ai peut-être (sûrement) pas tout compris.

Et OpenVPN c'est bien !

Il faudra vraiment que je l'essaie un jour (bis repetita). En fait j'ai
envisagé d'utiliser OpenVPN une fois, mais je ne l'ai pas retenu car
j'avais besoin d'un tunnel sous Windows qui permette d'attribuer une
adresse unique sans sous-réseau, ce qui est apparemment impossible sous
Windows même en mode Tun alors que ça ne pose aucun problème sous Linux.
Je me suis donc tourné vers... PPTP ! ;-)

Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> writes:

'Lut,

Il me semble quand même qu'IPSec a deux modes de fonctionnement :
transport et tunnel.

Exact.

Si j'ai bien compris le mode transport sert à la communication entre
deux hôtes et seule la charge utile des paquets est chiffrée ;

Pas obligatoire, cela dépend de la SP définie pour le lien (on peut par
exemple demander uniquement l'extension AH et non ESP) :
http://www.die.net/doc/linux/man/man8/setkey.8.html

Je ne qualifierais pas ce mode de VPN car je ne vois pas de
réseau virtuel là-dedans. Pour moi c'est juste du chiffrement sur le
réseau normal, Il n'y a pas besoin d'interface spéciale IPSec.

Tu peux l'utiliser comme transport pour un tunnel ipip :
http://www.ietf.org/rfc/rfc3884.txt

Quant au mode tunnel, il sert à la communication entre deux réseaux ou
entre un réseau et un hôte. Les paquets sont entièrement encapsulés et
chiffrés, en-tête comprise, dans d'autres paquets. C'est donc un tunnel
chiffré, à l'instar d'OpenVPN. Et logiquement le mode tunnel devrait
utiliser des interfaces spécifiques pour router le trafic dans le
tunnel.

Le mode tunnel bypasse allègrement la table de routage de l'hote si un
paquet matche une SP définie, c'est justement un des problèmes si tu
veux utiliser un protocole de routage dynamique... D'ou la rfc3884 citée
plus haut.

--
J2M> l'usurpation est décelable par le plus neuneu des neuneus...
Pour le plus neuneus de neuneus, sans doute.
Pour le contributeur moyen de fr.rec.humour, non.
-+- GS in <http://www.le-gnu.net> : Soyons précis -+-

Dans le message <news:edq377$1ot5$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.r.ip :

Salut Pascal,

Et OpenVPN c'est bien !

Il faudra vraiment que je l'essaie un jour (bis repetita).

Oui, tu devrais, depuis le temps ! :-)

Tiens, une « feature » qui devrait t'intéresser d'un point de vue technique
: la possibilité de monter un VPN entre deux machines avec adressage privé,
toutes les deux situées derrière un routeur relié à Internet et faisant du
NAT, et ceci sans la moindre redirection de port ou de protocole au niveau
des deux routeurs. Indices : UDP et suivi de connexion.

--
Sébastien Monbrun aka TiChou

*Pascal Hambourg* tapota sur f.c.r.ip :

Et OpenVPN c'est bien !

Il faudra vraiment que je l'essaie un jour (bis repetita).

Oui, tu devrais, depuis le temps ! :-)

Oui, mais pour *quoi* faire ? J'ai beau me creuser la tête, je n'en ai
pas l'utilité pour le moment.

<HS>
Et puis c'est sûrement pas OpenVPN qui va m'aider à me coltiner tous les
bugs que je rencontre suite à la mise à jour en sarge - contrainte et
forcée, plus de suivi de sécurité - de ma vieille Debian woody qui
marchait si bien depuis si longtemps. Ah, je le savais ! "If it ain't
broken, don't fix it". Et j'ai été servi : j'ai fix it, et ça broken.
:-( Après on dira que je suis pessimiste... D'abord la mise à jour m'a
pourri le boot de lilo sans rien dire. Je me demande encore comment elle
a réussi ce coup fumant, alors que ni les noyaux ni lilo.conf n'ont
changé. Ensuite elle m'a laissé me démerder avec un bug de version de
fichiers de base de donnée pas mis à jour dans exim. Maintenant je
découvre et tente de comprendre - et éventuellement résoudre - un
problème de blocage de la socket UDP IPv6 de bind9 suite à la réception
d'un paquet IPv4-mapped, qui ne s'était jamais produit avec l'ancienne
version. D'ailleurs il me gonfle, bind9, à vouloir absolument ouvrir une
socket par adresse IPv4 au lieu d'écouter sur 0.0.0.0 comme tout le
monde. C'est vachement pratique avec les interfaces dynamiques, hein. Et
puis après, il faudra encore que je cherche pourquoi les vieilles
instances de pptp ne veulent pas mourir après la fin de leur connexion.
Quel sera le bug suivant ? Marre !
Désolé, c'est les nerfs. Faut que j'y retourne, là.
</HS>

Tiens, une « feature » qui devrait t'intéresser d'un point de vue
technique : la possibilité de monter un VPN entre deux machines avec
adressage privé, toutes les deux situées derrière un routeur relié à
Internet et faisant du NAT, et ceci sans la moindre redirection de port
ou de protocole au niveau des deux routeurs. Indices : UDP et suivi de
connexion.

Hum, comment OpenVPN arrive-t-il à accomplir un tel prodige ? Si un
routeur a le malheur de trafiquer le port source en faisant son NAT,
j'imagine que ça doit être plutôt sportif.

Dans le message <news:eds47v$2k7k$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.r.ip :

Oui, mais pour *quoi* faire ? J'ai beau me creuser la tête, je n'en ai pas
l'utilité pour le moment.

Ta soif d'apprendre et d'approfondir tes connaissances. :-)

Tiens, une « feature » qui devrait t'intéresser d'un point de vue
technique : la possibilité de monter un VPN entre deux machines avec
adressage privé, toutes les deux situées derrière un routeur relié à
Internet et faisant du NAT, et ceci sans la moindre redirection de port
ou de protocole au niveau des deux routeurs. Indices : UDP et suivi de
connexion.

Hum, comment OpenVPN arrive-t-il à accomplir un tel prodige ?

Un extrait (en anglais, sorry) de la documentation d'OpenVPN :

OpenVPN also works well on stateful firewalls. In some cases, you may
not need to add any static rules to the firewall list if you are using a
stateful firewall that knows how to track UDP connections. If you
specify --ping n, OpenVPN will be guaranteed to send a packet to its peer at
least once every n seconds. If n is less than the stateful firewall
connection timeout, you can maintain an OpenVPN connection indefinitely
without explicit firewall rules.

--
Sébastien Monbrun aka TiChou

*Pascal Hambourg* tapota sur f.c.r.ip :

Oui, mais pour *quoi* faire ? J'ai beau me creuser la tête, je n'en ai
pas l'utilité pour le moment.

Ta soif d'apprendre et d'approfondir tes connaissances. :-)

Désolé, mais je n'ai pas trop la tête à ça en ce moment. Je me prends
déjà assez la tête pour que ma passerelle remarche à peu près comme
avant après sa mise à jour. Ça me gave tellement que je n'ai plus soif !

Hum, comment OpenVPN arrive-t-il à accomplir un tel prodige ?

Un extrait (en anglais, sorry) de la documentation d'OpenVPN :

In some cases, you may not need to add any static rules [...]

Ah ouais, donc c'est pas garanti à tous les coups. Je préfère ça. :-)
(Si ça marche comme je crois que ça marche.)