Je me permets cette question ici, vu votre niveau general ;-)
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode
"user"
D'une facon generale (si on peut generaliser), quel(s) avantages et
soucis cela peut procurer d'avoir une application userland a la place
de kernel-land?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
manu
Maximus wrote:
D'une facon generale (si on peut generaliser), quel(s) avantages et soucis cela peut procurer d'avoir une application userland a la place de kernel-land?
Pour userland: plus facile à developper, séparation des privileges donc plus de sécurité. Pour kernel: potentiellement gains en performances car on evite des changements de contexte. -- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Maximus <uwo-8e@iximail.com> wrote:
D'une facon generale (si on peut generaliser), quel(s) avantages et
soucis cela peut procurer d'avoir une application userland a la place
de kernel-land?
Pour userland: plus facile à developper, séparation des privileges donc
plus de sécurité.
Pour kernel: potentiellement gains en performances car on evite des
changements de contexte.
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
D'une facon generale (si on peut generaliser), quel(s) avantages et soucis cela peut procurer d'avoir une application userland a la place de kernel-land?
Pour userland: plus facile à developper, séparation des privileges donc plus de sécurité. Pour kernel: potentiellement gains en performances car on evite des changements de contexte. -- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Benjamin Pineau
Le 14 Apr 2004 05:01:50 -0700, Maximus écrivais:
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode "user"
D'une facon generale (si on peut generaliser), quel(s) avantages et soucis cela peut procurer d'avoir une application userland a la place de kernel-land?
Je reviens au thème des VPNs pour discuter à partir de ta question, étant entendu qu' E. Dreyfuss y a déjà répondu de façon précise.
Dans ce domaine le choix n'est pas seulement une question de performances. Et il ne se résoud pas totalement dans la problématique opposant « d'une facon generale » kerneland et userland ; je regrette que la formulation de mon précédent message ai pu favoriser ce léger contresens.
En fait il fallait entendre: « le choix de certaines technologies impliquant de fait une forte solicitation et de larges spécifités noyau » (kerneland), et « le choix d'autres technologies moins dépendantes des fonctionalités disponibles ou non dans le noyau ». Sachant que les premières nécessitent généralement un complément userland pour être vraiment fonctionnelles (comme racoon, isakmpd, ipsecadm etc.) et que les secondes peuvent recquerir certaines fonctionnalités kernel relativement spécifiques (au hasard, le driver tun(4)).
Je profite de l'occasion pour préciser mon propos (et peut être anticiper une de tes questions ?).
Ce qui me semble plus déterminant dans le choix d'une technologie VPN (userland ou kerneland) c'est le protocole qu'elle implémente (la qualité de l'implémentation est certainement très importante aussi, mais il n'est jamais aisé d'en juger).
Or il se trouve qu'il n'existe pas (à ma connaissance) d'implémentation purement userland d'IPsec sous *BSD, et que ce protocole est néanmoins assez important dans le domaine des VPN parcequ'il est l'un des rares ouvertement normalisé et implémenté par un très grand nombre d'acteurs (les 3 BSD libres, GNU/linux, windows2k/xp, certains IOS Cisco, Checkpoint VPN-1, les HP-UX et Solaris récents ...).
Pour donner mon avis à deux centimes (et très discutable), le choix oppose essentiellement un protocole - théoriquement - très interopérable (mais complexe à deployer) à une foultitude de protocoles ou logiciels (pptp, htun, amrita, cipe, slan, nets, openvpn, ...) peut ou pas interopérables mais souvent très simple à mettre en place (surtout si l'on doit traverser une couche de NAT) ; que celà fonctionne ou non « dans » le kernel est assez secondaire en somme.
Comme l'a justement fait remarquer Thomas Pornin, la complexité dans ce cas n'est pas liée au fait de devoir parfois modifier légèrement le noyau (sauf quand on veut avoir FreeS/Wan avec X.509 et simple DES avec un noyau linux 2.4.* ;-). Elle serait plutôt conséquence de l'architecture des protocoles respectifs et de leur implémentation (notament l'implémentation des interfaces de paramétrage).
Au niveau de la securite?
Je continue de répondre sur le cas précis des VPNs (donc pas exactement à ta question sur une éventuelle dimension générale).
On se trouve dans une situation opposant une technologie (IPsec) conçue par de nombreux experts en sécurité et validée sur le long terme par un grand nombre d'acteurs face à une série de technologies souvent moins auditées, et pouvant par conséquent réveler sur le moyen terme d'importantes erreurs de conceptions impactant sur la sécurité (cf. par exemple le cas d'école Vtun).
Un autre avantage d'IPsec ayant trait à la sécurité est qu'il est fournis avec l'OS (du moins pour les *BSDs libres, qu'il soit activé par défaut ou non); il est par conséquent maintenu avec l'OS, et les mises à jour s'en trouvent facilités.
Bref, qu'IPsec soit généralement implementé au niveau du noyau de l'OS alors que d'autres protocoles fonctionnent en userland (ou pas) ne devrait pas, en soi, avoir de conséquences immédiate sur la sécurité.
Je crois que cette remarque est à peu près généralisable : le niveau d'execution d'un logiciel (kernel ou pas) n'est pas en soi un critère décisif concernant la sécurité.
-- Benjamin
Le 14 Apr 2004 05:01:50 -0700,
Maximus <uwo-8e@iximail.com> écrivais:
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode
"user"
D'une facon generale (si on peut generaliser), quel(s) avantages et
soucis cela peut procurer d'avoir une application userland a la place
de kernel-land?
Je reviens au thème des VPNs pour discuter à partir de ta question,
étant entendu qu' E. Dreyfuss y a déjà répondu de façon précise.
Dans ce domaine le choix n'est pas seulement une question de performances.
Et il ne se résoud pas totalement dans la problématique opposant
« d'une facon generale » kerneland et userland ; je regrette que la
formulation de mon précédent message ai pu favoriser ce léger contresens.
En fait il fallait entendre: « le choix de certaines technologies
impliquant de fait une forte solicitation et de larges spécifités noyau »
(kerneland), et « le choix d'autres technologies moins dépendantes des
fonctionalités disponibles ou non dans le noyau ». Sachant que les
premières nécessitent généralement un complément userland pour être vraiment
fonctionnelles (comme racoon, isakmpd, ipsecadm etc.) et que les secondes
peuvent recquerir certaines fonctionnalités kernel relativement spécifiques
(au hasard, le driver tun(4)).
Je profite de l'occasion pour préciser mon propos (et peut être
anticiper une de tes questions ?).
Ce qui me semble plus déterminant dans le choix d'une technologie VPN
(userland ou kerneland) c'est le protocole qu'elle implémente (la
qualité de l'implémentation est certainement très importante aussi, mais
il n'est jamais aisé d'en juger).
Or il se trouve qu'il n'existe pas (à ma connaissance) d'implémentation
purement userland d'IPsec sous *BSD, et que ce protocole est néanmoins
assez important dans le domaine des VPN parcequ'il est l'un des rares
ouvertement normalisé et implémenté par un très grand nombre d'acteurs
(les 3 BSD libres, GNU/linux, windows2k/xp, certains IOS Cisco, Checkpoint
VPN-1, les HP-UX et Solaris récents ...).
Pour donner mon avis à deux centimes (et très discutable), le choix oppose
essentiellement un protocole - théoriquement - très interopérable (mais
complexe à deployer) à une foultitude de protocoles ou logiciels (pptp,
htun, amrita, cipe, slan, nets, openvpn, ...) peut ou pas interopérables mais
souvent très simple à mettre en place (surtout si l'on doit traverser une
couche de NAT) ; que celà fonctionne ou non « dans » le kernel est assez
secondaire en somme.
Comme l'a justement fait remarquer Thomas Pornin, la complexité dans ce cas
n'est pas liée au fait de devoir parfois modifier légèrement le noyau (sauf
quand on veut avoir FreeS/Wan avec X.509 et simple DES avec un noyau linux
2.4.* ;-). Elle serait plutôt conséquence de l'architecture des protocoles
respectifs et de leur implémentation (notament l'implémentation des
interfaces de paramétrage).
Au niveau de la securite?
Je continue de répondre sur le cas précis des VPNs (donc pas exactement
à ta question sur une éventuelle dimension générale).
On se trouve dans une situation opposant une technologie (IPsec) conçue
par de nombreux experts en sécurité et validée sur le long terme par un
grand nombre d'acteurs face à une série de technologies souvent moins
auditées, et pouvant par conséquent réveler sur le moyen terme d'importantes
erreurs de conceptions impactant sur la sécurité (cf. par exemple le cas
d'école Vtun).
Un autre avantage d'IPsec ayant trait à la sécurité est qu'il est fournis
avec l'OS (du moins pour les *BSDs libres, qu'il soit activé par défaut ou
non); il est par conséquent maintenu avec l'OS, et les mises à jour s'en
trouvent facilités.
Bref, qu'IPsec soit généralement implementé au niveau du noyau de l'OS
alors que d'autres protocoles fonctionnent en userland (ou pas) ne devrait
pas, en soi, avoir de conséquences immédiate sur la sécurité.
Je crois que cette remarque est à peu près généralisable : le niveau
d'execution d'un logiciel (kernel ou pas) n'est pas en soi un critère
décisif concernant la sécurité.
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode "user"
D'une facon generale (si on peut generaliser), quel(s) avantages et soucis cela peut procurer d'avoir une application userland a la place de kernel-land?
Je reviens au thème des VPNs pour discuter à partir de ta question, étant entendu qu' E. Dreyfuss y a déjà répondu de façon précise.
Dans ce domaine le choix n'est pas seulement une question de performances. Et il ne se résoud pas totalement dans la problématique opposant « d'une facon generale » kerneland et userland ; je regrette que la formulation de mon précédent message ai pu favoriser ce léger contresens.
En fait il fallait entendre: « le choix de certaines technologies impliquant de fait une forte solicitation et de larges spécifités noyau » (kerneland), et « le choix d'autres technologies moins dépendantes des fonctionalités disponibles ou non dans le noyau ». Sachant que les premières nécessitent généralement un complément userland pour être vraiment fonctionnelles (comme racoon, isakmpd, ipsecadm etc.) et que les secondes peuvent recquerir certaines fonctionnalités kernel relativement spécifiques (au hasard, le driver tun(4)).
Je profite de l'occasion pour préciser mon propos (et peut être anticiper une de tes questions ?).
Ce qui me semble plus déterminant dans le choix d'une technologie VPN (userland ou kerneland) c'est le protocole qu'elle implémente (la qualité de l'implémentation est certainement très importante aussi, mais il n'est jamais aisé d'en juger).
Or il se trouve qu'il n'existe pas (à ma connaissance) d'implémentation purement userland d'IPsec sous *BSD, et que ce protocole est néanmoins assez important dans le domaine des VPN parcequ'il est l'un des rares ouvertement normalisé et implémenté par un très grand nombre d'acteurs (les 3 BSD libres, GNU/linux, windows2k/xp, certains IOS Cisco, Checkpoint VPN-1, les HP-UX et Solaris récents ...).
Pour donner mon avis à deux centimes (et très discutable), le choix oppose essentiellement un protocole - théoriquement - très interopérable (mais complexe à deployer) à une foultitude de protocoles ou logiciels (pptp, htun, amrita, cipe, slan, nets, openvpn, ...) peut ou pas interopérables mais souvent très simple à mettre en place (surtout si l'on doit traverser une couche de NAT) ; que celà fonctionne ou non « dans » le kernel est assez secondaire en somme.
Comme l'a justement fait remarquer Thomas Pornin, la complexité dans ce cas n'est pas liée au fait de devoir parfois modifier légèrement le noyau (sauf quand on veut avoir FreeS/Wan avec X.509 et simple DES avec un noyau linux 2.4.* ;-). Elle serait plutôt conséquence de l'architecture des protocoles respectifs et de leur implémentation (notament l'implémentation des interfaces de paramétrage).
Au niveau de la securite?
Je continue de répondre sur le cas précis des VPNs (donc pas exactement à ta question sur une éventuelle dimension générale).
On se trouve dans une situation opposant une technologie (IPsec) conçue par de nombreux experts en sécurité et validée sur le long terme par un grand nombre d'acteurs face à une série de technologies souvent moins auditées, et pouvant par conséquent réveler sur le moyen terme d'importantes erreurs de conceptions impactant sur la sécurité (cf. par exemple le cas d'école Vtun).
Un autre avantage d'IPsec ayant trait à la sécurité est qu'il est fournis avec l'OS (du moins pour les *BSDs libres, qu'il soit activé par défaut ou non); il est par conséquent maintenu avec l'OS, et les mises à jour s'en trouvent facilités.
Bref, qu'IPsec soit généralement implementé au niveau du noyau de l'OS alors que d'autres protocoles fonctionnent en userland (ou pas) ne devrait pas, en soi, avoir de conséquences immédiate sur la sécurité.
Je crois que cette remarque est à peu près généralisable : le niveau d'execution d'un logiciel (kernel ou pas) n'est pas en soi un critère décisif concernant la sécurité.
-- Benjamin
voodoo child
"Maximus" a écrit dans le message de news:
Hello,
Je me permets cette question ici, vu votre niveau general ;-)
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode "user"
D'une facon generale (si on peut generaliser), quel(s) avantages et soucis cela peut procurer d'avoir une application userland a la place de kernel-land?
Au niveau de la securite?
Merci
Max
J'ai une petite question à propos du vpn
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la hauteur de freeswan????
"Maximus" <uwo-8e@iximail.com> a écrit dans le message de
news:c1b00b11.0404140401.26e3461d@posting.google.com...
Hello,
Je me permets cette question ici, vu votre niveau general ;-)
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode
"user"
D'une facon generale (si on peut generaliser), quel(s) avantages et
soucis cela peut procurer d'avoir une application userland a la place
de kernel-land?
Au niveau de la securite?
Merci
Max
J'ai une petite question à propos du vpn
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la
hauteur de freeswan????
Je me permets cette question ici, vu votre niveau general ;-)
Dans un message plus bas, on parle de VPN en mode "kernel" ou en mode "user"
D'une facon generale (si on peut generaliser), quel(s) avantages et soucis cela peut procurer d'avoir une application userland a la place de kernel-land?
Au niveau de la securite?
Merci
Max
J'ai une petite question à propos du vpn
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la hauteur de freeswan????
Vincent Bernat
OoO En ce début d'après-midi nuageux du lundi 19 avril 2004, vers 14:35, "voodoo child" disait:
J'ai une petite question à propos du vpn
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la hauteur de freeswan????
Les BSD utilisent l'implémentation KAME, de même que Linux 2.6. Freeswan n'est plus développé. -- SUBSTITUTE TEACHERS ARE NOT SCABS SUBSTITUTE TEACHERS ARE NOT SCABS SUBSTITUTE TEACHERS ARE NOT SCABS -+- Bart Simpson on chalkboard in episode BABF09
OoO En ce début d'après-midi nuageux du lundi 19 avril 2004, vers
14:35, "voodoo child" <voodoo.child@laposte.net> disait:
J'ai une petite question à propos du vpn
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la
hauteur de freeswan????
Les BSD utilisent l'implémentation KAME, de même que Linux
2.6. Freeswan n'est plus développé.
--
SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS
-+- Bart Simpson on chalkboard in episode BABF09
OoO En ce début d'après-midi nuageux du lundi 19 avril 2004, vers 14:35, "voodoo child" disait:
J'ai une petite question à propos du vpn
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la hauteur de freeswan????
Les BSD utilisent l'implémentation KAME, de même que Linux 2.6. Freeswan n'est plus développé. -- SUBSTITUTE TEACHERS ARE NOT SCABS SUBSTITUTE TEACHERS ARE NOT SCABS SUBSTITUTE TEACHERS ARE NOT SCABS -+- Bart Simpson on chalkboard in episode BABF09
Eric Masson
"voodoo" == voodoo child writes:
'Lut,
voodoo> sur linux la rèf c'est freeswan. D'une manière générale, c'est voodoo> la référence.
On a les références que l'on peut, mais celle ci était tout de même particulièrement pourrie, le code de Kame a fini par être intégré dans la série 2.6.
voodoo> Mais quel est l'équivalent dans le monde bsd.
Les implémentations ipsec de chacun des bsd (toutes dérivées de Kame, même si Free et Open ont chacun ajouté le support de la crypto via hardware, iirc, Net doit avoir en projet d'intégrer le support hardware des deux autres)
voodoo> Est-ce que vtun arrive à la hauteur de freeswan????
Euh, ça ne fait pas la même chose à la base, cela reviendrait à comparer des choux et des carottes.
IPsec est normalisé et d'usage général, là ou vtun est un outil ne sachant interopérer qu'avec lui même et dont la fonction est le tunnelling.
Eric Masson
-- Et manque de bol, ça accélère énormément cette nouvelle version (à croire que l'ancienne était codée en 68k et utilisait ApplScript). -+- SC in Guide du Macounet Pervers : Jobs, stakhanoviste ? Nooon ! -+-
voodoo> sur linux la rèf c'est freeswan. D'une manière générale, c'est
voodoo> la référence.
On a les références que l'on peut, mais celle ci était tout de même
particulièrement pourrie, le code de Kame a fini par être intégré dans
la série 2.6.
voodoo> Mais quel est l'équivalent dans le monde bsd.
Les implémentations ipsec de chacun des bsd (toutes dérivées de Kame,
même si Free et Open ont chacun ajouté le support de la crypto via
hardware, iirc, Net doit avoir en projet d'intégrer le support hardware
des deux autres)
voodoo> Est-ce que vtun arrive à la hauteur de freeswan????
Euh, ça ne fait pas la même chose à la base, cela reviendrait à comparer
des choux et des carottes.
IPsec est normalisé et d'usage général, là ou vtun est un outil ne
sachant interopérer qu'avec lui même et dont la fonction est le
tunnelling.
Eric Masson
--
Et manque de bol, ça accélère énormément cette nouvelle version (à
croire que l'ancienne était codée en 68k et utilisait ApplScript).
-+- SC in Guide du Macounet Pervers : Jobs, stakhanoviste ? Nooon ! -+-
voodoo> sur linux la rèf c'est freeswan. D'une manière générale, c'est voodoo> la référence.
On a les références que l'on peut, mais celle ci était tout de même particulièrement pourrie, le code de Kame a fini par être intégré dans la série 2.6.
voodoo> Mais quel est l'équivalent dans le monde bsd.
Les implémentations ipsec de chacun des bsd (toutes dérivées de Kame, même si Free et Open ont chacun ajouté le support de la crypto via hardware, iirc, Net doit avoir en projet d'intégrer le support hardware des deux autres)
voodoo> Est-ce que vtun arrive à la hauteur de freeswan????
Euh, ça ne fait pas la même chose à la base, cela reviendrait à comparer des choux et des carottes.
IPsec est normalisé et d'usage général, là ou vtun est un outil ne sachant interopérer qu'avec lui même et dont la fonction est le tunnelling.
Eric Masson
-- Et manque de bol, ça accélère énormément cette nouvelle version (à croire que l'ancienne était codée en 68k et utilisait ApplScript). -+- SC in Guide du Macounet Pervers : Jobs, stakhanoviste ? Nooon ! -+-
Benjamin Pineau
Le Mon, 19 Apr 2004 14:35:32 +0200, voodoo child écrivais:
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
On peut difficilement dire que FreeS/Wan soit « la référence générale ». D'une part parcequ'il ne fonctionne qu'avec linux (et seulement pour les noyaux < 2.6 pour la partie klips), d'autre part parceque l'implem est particulièrement moche (pas de support X.509 sans repatcher sur le patch, pas de simple DES, pas d'IPv6, empilements d'affreux shells scripts ...) et pour finir, parceque même les devs du noyau linux l'ont désavoué, lui préférant l'implémentation d'USAGI (le jumeau de kame) pour la nouvelle génération de noyau ; à vrai dire, ils n'ont jamais accepté d'intégrer FreeS/Wan dans les sources du noyau standard, non sans raisons, c'est dire sa qualité de « référence ».
Bref, comme d'autres l'ont dit, le stack USAGI/KAME (et les serveurs de clefs isakmpd et racoon) mériterai le qualificatif de « références » dans le monde des OS libres bien avant FreeS/Wan. Reste à attendre que les linuxiens cessent de polluer les réseaux avec ce machin (d'ici 25 ans, quand debian aura intégré le noyau 2.6 en std ? ;).
J'ai bon espoir tout de même : http://www.freeswan.org/ending_letter.html
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la hauteur de freeswan????
D'un certaine manière, oui. Le design de vtun est unaniment reconnu comme une abération en matière de sécurité (p. ex. http://off.net/~jme/vtun_secu.html). Il offre en outre tout les charmes d'un protocole maison et non-interropérable. Et il reste néanmoins très populaire dans le monde linux. À la hauteur de fs.
L'équivalent (si l'on peut dire) dans le monde BSD est Kame, le stack IPv6 & IPsec BSD. Il est intégré out of the box sur les 3 BSD (et activé par défault seulement sous open). Coté serveur de clefs, en plus de l'implem de kame (racoon) on peut utiliser isakmpd qui fait des merveilles (et photurisd aussi).
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
On peut difficilement dire que FreeS/Wan soit « la référence générale ».
D'une part parcequ'il ne fonctionne qu'avec linux (et seulement pour les
noyaux < 2.6 pour la partie klips), d'autre part parceque l'implem est
particulièrement moche (pas de support X.509 sans repatcher sur le patch,
pas de simple DES, pas d'IPv6, empilements d'affreux shells scripts ...) et
pour finir, parceque même les devs du noyau linux l'ont désavoué, lui
préférant l'implémentation d'USAGI (le jumeau de kame) pour la nouvelle
génération de noyau ; à vrai dire, ils n'ont jamais accepté d'intégrer
FreeS/Wan dans les sources du noyau standard, non sans raisons, c'est
dire sa qualité de « référence ».
Bref, comme d'autres l'ont dit, le stack USAGI/KAME (et les serveurs de
clefs isakmpd et racoon) mériterai le qualificatif de « références »
dans le monde des OS libres bien avant FreeS/Wan. Reste à attendre que
les linuxiens cessent de polluer les réseaux avec ce machin (d'ici 25
ans, quand debian aura intégré le noyau 2.6 en std ? ;).
J'ai bon espoir tout de même : http://www.freeswan.org/ending_letter.html
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la
hauteur de freeswan????
D'un certaine manière, oui. Le design de vtun est unaniment reconnu comme une
abération en matière de sécurité (p. ex. http://off.net/~jme/vtun_secu.html).
Il offre en outre tout les charmes d'un protocole maison et non-interropérable.
Et il reste néanmoins très populaire dans le monde linux. À la hauteur de fs.
L'équivalent (si l'on peut dire) dans le monde BSD est Kame, le stack
IPv6 & IPsec BSD. Il est intégré out of the box sur les 3 BSD (et activé
par défault seulement sous open). Coté serveur de clefs, en plus de
l'implem de kame (racoon) on peut utiliser isakmpd qui fait des merveilles
(et photurisd aussi).
Le Mon, 19 Apr 2004 14:35:32 +0200, voodoo child écrivais:
sur linux la rèf c'est freeswan. D'une manière générale, c'est la référence.
On peut difficilement dire que FreeS/Wan soit « la référence générale ». D'une part parcequ'il ne fonctionne qu'avec linux (et seulement pour les noyaux < 2.6 pour la partie klips), d'autre part parceque l'implem est particulièrement moche (pas de support X.509 sans repatcher sur le patch, pas de simple DES, pas d'IPv6, empilements d'affreux shells scripts ...) et pour finir, parceque même les devs du noyau linux l'ont désavoué, lui préférant l'implémentation d'USAGI (le jumeau de kame) pour la nouvelle génération de noyau ; à vrai dire, ils n'ont jamais accepté d'intégrer FreeS/Wan dans les sources du noyau standard, non sans raisons, c'est dire sa qualité de « référence ».
Bref, comme d'autres l'ont dit, le stack USAGI/KAME (et les serveurs de clefs isakmpd et racoon) mériterai le qualificatif de « références » dans le monde des OS libres bien avant FreeS/Wan. Reste à attendre que les linuxiens cessent de polluer les réseaux avec ce machin (d'ici 25 ans, quand debian aura intégré le noyau 2.6 en std ? ;).
J'ai bon espoir tout de même : http://www.freeswan.org/ending_letter.html
Mais quel est l'équivalent dans le monde bsd. Est-ce que vtun arrive à la hauteur de freeswan????
D'un certaine manière, oui. Le design de vtun est unaniment reconnu comme une abération en matière de sécurité (p. ex. http://off.net/~jme/vtun_secu.html). Il offre en outre tout les charmes d'un protocole maison et non-interropérable. Et il reste néanmoins très populaire dans le monde linux. À la hauteur de fs.
L'équivalent (si l'on peut dire) dans le monde BSD est Kame, le stack IPv6 & IPsec BSD. Il est intégré out of the box sur les 3 BSD (et activé par défault seulement sous open). Coté serveur de clefs, en plus de l'implem de kame (racoon) on peut utiliser isakmpd qui fait des merveilles (et photurisd aussi).
voodoo child
voodoo> Est-ce que vtun arrive à la hauteur de freeswan????
Euh, ça ne fait pas la même chose à la base, cela reviendrait à comparer des choux et des carottes.
IPsec est normalisé et d'usage général, là ou vtun est un outil ne sachant interopérer qu'avec lui même et dont la fonction est le tunnelling.
Tu as raison à propos de vtun, il est interopérable uniquement avec lui même. Mais d'une manière génréle vtun permet de faire du vpn mais s'il n'utilise pas ipsec
voodoo> Est-ce que vtun arrive à la hauteur de freeswan????
Euh, ça ne fait pas la même chose à la base, cela reviendrait à comparer
des choux et des carottes.
IPsec est normalisé et d'usage général, là ou vtun est un outil ne
sachant interopérer qu'avec lui même et dont la fonction est le
tunnelling.
Tu as raison à propos de vtun, il est interopérable uniquement avec lui
même. Mais d'une manière
génréle vtun permet de faire du vpn mais s'il n'utilise pas ipsec
voodoo> Est-ce que vtun arrive à la hauteur de freeswan????
Euh, ça ne fait pas la même chose à la base, cela reviendrait à comparer des choux et des carottes.
IPsec est normalisé et d'usage général, là ou vtun est un outil ne sachant interopérer qu'avec lui même et dont la fonction est le tunnelling.
Tu as raison à propos de vtun, il est interopérable uniquement avec lui même. Mais d'une manière génréle vtun permet de faire du vpn mais s'il n'utilise pas ipsec