Le Wed, 05 May 2004 20:56:00 +0000, Franck Pissotte a écrit :
Le projet a ete "repris" et est devenu Openswan (http://www.openswan.org/). encore un de ces projet opensource dont on ne sait pas a quoi ca sert.
rien n'est explique pour le gus qui ne fait pas parti des "inities". si qqu'un peut me dire ce qu'est ipsec.
Quand on ne sait effectivement pas ce qu'est qu'IPSEC et qu'en plus on ne veut pas chercher dans la section Documentation du site ou ne serait-ce que _lire_, on a du mal, je le reconnais.
Section about :
Openswan is an Open Source implementation of IPsec for the Linux operating system.
Tu attends quoi de plus ? Ah oui, je vois, c'est quoi IPSEC ?
Section Documentation, Wiki, OpenS/WAN documentation, introduction (http://wiki.openswan.org/index.php/Introduction)... Sinon, Google, c'est pas mal non plus, même quand on ne lit pas l'anglais dans le texte. Recherche simple du mot IPSEC, 3e lien :
http://www.securiteinfo.com/crypto/IPSec.shtml
Si maintenant, à chaque fois qu'on publie un outil, on doit non seulement à quoi il sert, mais en plus tous les concepts sous-jacent pour ne pas paraître "hermétique" aux non-initié manifestement feignant et en plus de mauvaise foi, ce n'est plus du logiciel qu'on va mettre en ligne, mais des encyclopédies... Je vois bien un vendeur de perceuses ajouter une documentation à ses produits pour expliquer à quoi ça sert de percer des trous...
-- <MuadDib> commment je fait pour qu'il évite de me de mer mettrede smessage comme ça? et à la palce une phrase que je choisit ? -+- : in http://www.petitjoueur.net/ : Aga ? -+-
Le Wed, 05 May 2004 20:56:00 +0000, Franck Pissotte a écrit :
Le projet a ete "repris" et est devenu Openswan
(http://www.openswan.org/).
encore un de ces projet opensource dont on ne sait pas a quoi ca sert.
rien n'est explique pour le gus qui ne fait pas parti des "inities".
si qqu'un peut me dire ce qu'est ipsec.
Quand on ne sait effectivement pas ce qu'est qu'IPSEC et qu'en plus on ne
veut pas chercher dans la section Documentation du site ou ne serait-ce
que _lire_, on a du mal, je le reconnais.
Section about :
Openswan is an Open Source implementation of IPsec for the Linux
operating system.
Tu attends quoi de plus ? Ah oui, je vois, c'est quoi IPSEC ?
Section Documentation, Wiki, OpenS/WAN documentation, introduction
(http://wiki.openswan.org/index.php/Introduction)... Sinon, Google, c'est
pas mal non plus, même quand on ne lit pas l'anglais dans le texte.
Recherche simple du mot IPSEC, 3e lien :
http://www.securiteinfo.com/crypto/IPSec.shtml
Si maintenant, à chaque fois qu'on publie un outil, on doit non seulement
à quoi il sert, mais en plus tous les concepts sous-jacent pour ne pas
paraître "hermétique" aux non-initié manifestement feignant et en plus
de mauvaise foi, ce n'est plus du logiciel qu'on va mettre en ligne, mais
des encyclopédies... Je vois bien un vendeur de perceuses ajouter une
documentation à ses produits pour expliquer à quoi ça sert de percer
des trous...
--
<MuadDib> commment je fait pour qu'il évite de me de mer mettrede
smessage comme ça? et à la palce une phrase que je choisit ?
-+- : in http://www.petitjoueur.net/ : Aga ? -+-
Le Wed, 05 May 2004 20:56:00 +0000, Franck Pissotte a écrit :
Le projet a ete "repris" et est devenu Openswan (http://www.openswan.org/). encore un de ces projet opensource dont on ne sait pas a quoi ca sert.
rien n'est explique pour le gus qui ne fait pas parti des "inities". si qqu'un peut me dire ce qu'est ipsec.
Quand on ne sait effectivement pas ce qu'est qu'IPSEC et qu'en plus on ne veut pas chercher dans la section Documentation du site ou ne serait-ce que _lire_, on a du mal, je le reconnais.
Section about :
Openswan is an Open Source implementation of IPsec for the Linux operating system.
Tu attends quoi de plus ? Ah oui, je vois, c'est quoi IPSEC ?
Section Documentation, Wiki, OpenS/WAN documentation, introduction (http://wiki.openswan.org/index.php/Introduction)... Sinon, Google, c'est pas mal non plus, même quand on ne lit pas l'anglais dans le texte. Recherche simple du mot IPSEC, 3e lien :
http://www.securiteinfo.com/crypto/IPSec.shtml
Si maintenant, à chaque fois qu'on publie un outil, on doit non seulement à quoi il sert, mais en plus tous les concepts sous-jacent pour ne pas paraître "hermétique" aux non-initié manifestement feignant et en plus de mauvaise foi, ce n'est plus du logiciel qu'on va mettre en ligne, mais des encyclopédies... Je vois bien un vendeur de perceuses ajouter une documentation à ses produits pour expliquer à quoi ça sert de percer des trous...
-- <MuadDib> commment je fait pour qu'il évite de me de mer mettrede smessage comme ça? et à la palce une phrase que je choisit ? -+- : in http://www.petitjoueur.net/ : Aga ? -+-
Erwan David
Cedric Blancher écrivait :
Le Wed, 05 May 2004 19:24:56 +0000, Djoume SALVETTI a écrit :
D'autre part il est également possible d'utiliser [Free|Open]S/WAN avec KAME.
Non. L'implémentation kernel-side d'IPSEC de Linux est propre à Linux, et n'a donc rien à voir avec Kame. Par contre, elle compatible avec les outils userland portés du projet Kame via son interface PFKey.
Je dirais plus que [Free|Open]S/WAN est, comme Kame, utilisable avec la couche IPSEC des noyaux 2.6.
J'avais compris "utilisable" dans le sens d'interopérable, mais heureusement que 2 implémentations d'ipsec sonr interopérables...
Le Wed, 05 May 2004 19:24:56 +0000, Djoume SALVETTI a écrit :
D'autre part il est également possible d'utiliser [Free|Open]S/WAN avec
KAME.
Non.
L'implémentation kernel-side d'IPSEC de Linux est propre à Linux, et n'a
donc rien à voir avec Kame. Par contre, elle compatible avec les outils
userland portés du projet Kame via son interface PFKey.
Je dirais plus que [Free|Open]S/WAN est, comme Kame, utilisable avec la
couche IPSEC des noyaux 2.6.
J'avais compris "utilisable" dans le sens d'interopérable, mais
heureusement que 2 implémentations d'ipsec sonr interopérables...
Le Wed, 05 May 2004 19:24:56 +0000, Djoume SALVETTI a écrit :
D'autre part il est également possible d'utiliser [Free|Open]S/WAN avec KAME.
Non. L'implémentation kernel-side d'IPSEC de Linux est propre à Linux, et n'a donc rien à voir avec Kame. Par contre, elle compatible avec les outils userland portés du projet Kame via son interface PFKey.
Je dirais plus que [Free|Open]S/WAN est, comme Kame, utilisable avec la couche IPSEC des noyaux 2.6.
J'avais compris "utilisable" dans le sens d'interopérable, mais heureusement que 2 implémentations d'ipsec sonr interopérables...
-- Real programs don't eat cache
Eric Masson
"Franck" == Franck Pissotte writes:
Franck> encore un de ces projet opensource dont on ne sait pas a quoi Franck> ca sert. rien n'est explique pour le gus qui ne fait pas parti Franck> des "inities". si qqu'un peut me dire ce qu'est ipsec.
Google et/ou chercher par toi même ne t'as pas effleuré l'esprit ?
Effectivement, dans ce cas, il est compréhensible que tu n'aimes pas l'Open Source.
Eric Masson
-- SP : De la différence entre "menacé" et "stevé".... VN : je prefere largement être menacé que stevé, au moins on peut se defendre -+- VN in Guide du Macounet Pervers : Corbeille mon amour -+-
Franck> encore un de ces projet opensource dont on ne sait pas a quoi
Franck> ca sert. rien n'est explique pour le gus qui ne fait pas parti
Franck> des "inities". si qqu'un peut me dire ce qu'est ipsec.
Google et/ou chercher par toi même ne t'as pas effleuré l'esprit ?
Effectivement, dans ce cas, il est compréhensible que tu n'aimes pas
l'Open Source.
Eric Masson
--
SP : De la différence entre "menacé" et "stevé"....
VN : je prefere largement être menacé que stevé, au moins on peut se
defendre
-+- VN in Guide du Macounet Pervers : Corbeille mon amour -+-
Franck> encore un de ces projet opensource dont on ne sait pas a quoi Franck> ca sert. rien n'est explique pour le gus qui ne fait pas parti Franck> des "inities". si qqu'un peut me dire ce qu'est ipsec.
Google et/ou chercher par toi même ne t'as pas effleuré l'esprit ?
Effectivement, dans ce cas, il est compréhensible que tu n'aimes pas l'Open Source.
Eric Masson
-- SP : De la différence entre "menacé" et "stevé".... VN : je prefere largement être menacé que stevé, au moins on peut se defendre -+- VN in Guide du Macounet Pervers : Corbeille mon amour -+-
Eric Masson
"Djoume" == Djoume SALVETTI writes:
Djoume> [Free|Open]S/WAN a quand même l'avantage (pratique) de fournir Djoume> une interface ipsec, ce qui n'est pas le cas de KAME il me Djoume> semble.
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin* de m'en servir, même au niveau filtrage.
A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
Djoume> D'autre part il est également possible d'utiliser Djoume> [Free|Open]S/WAN avec KAME.
Ah ? C'est un peu court comme argumentation.
KAME et MachinSwan sont deux projets distincts recouvrant les mêmes fonctionnalités (enfin presque, vu que le deuxième s'assoit sur une partie des rfc concernées), support kernel et isakmpd, j'ai des doutes sur le fait que l'on puisse faire coexister les supports kernel des deux simultanément.
A partir du moment ou l'on utilise une interface de type pfkeyV2 pour la communication entre l'isakmpd et l'implémentation noyau, n'importe quel isakmpd respectant cet interface pourra converser avec une implémentation kernel la supportant aussi (ex isakmpd (OpenBSD) sur un FreeBSD/NetBSD (KAME))
Quand au fait qu'une implémentation MachinSwan puisse avoir pour pair une implémentation KAME, c'est tout de même le minimum.
Eric Masson
-- C'est vrai peut t'on renconter quelqu'un sur internet? Car moi je cherche l'ame soeur -+- SR in: <http://www.le-gnu.net> - Neuneu a-t-il une âme ? -+-
Djoume> [Free|Open]S/WAN a quand même l'avantage (pratique) de fournir
Djoume> une interface ipsec, ce qui n'est pas le cas de KAME il me
Djoume> semble.
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin*
de m'en servir, même au niveau filtrage.
A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
Djoume> D'autre part il est également possible d'utiliser
Djoume> [Free|Open]S/WAN avec KAME.
Ah ? C'est un peu court comme argumentation.
KAME et MachinSwan sont deux projets distincts recouvrant les mêmes
fonctionnalités (enfin presque, vu que le deuxième s'assoit sur une
partie des rfc concernées), support kernel et isakmpd, j'ai des doutes
sur le fait que l'on puisse faire coexister les supports kernel des deux
simultanément.
A partir du moment ou l'on utilise une interface de type pfkeyV2 pour la
communication entre l'isakmpd et l'implémentation noyau, n'importe quel
isakmpd respectant cet interface pourra converser avec une
implémentation kernel la supportant aussi (ex isakmpd (OpenBSD) sur un
FreeBSD/NetBSD (KAME))
Quand au fait qu'une implémentation MachinSwan puisse avoir pour pair
une implémentation KAME, c'est tout de même le minimum.
Eric Masson
--
C'est vrai peut t'on renconter quelqu'un sur internet?
Car moi je cherche l'ame soeur
-+- SR in: <http://www.le-gnu.net> - Neuneu a-t-il une âme ? -+-
Djoume> [Free|Open]S/WAN a quand même l'avantage (pratique) de fournir Djoume> une interface ipsec, ce qui n'est pas le cas de KAME il me Djoume> semble.
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin* de m'en servir, même au niveau filtrage.
A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
Djoume> D'autre part il est également possible d'utiliser Djoume> [Free|Open]S/WAN avec KAME.
Ah ? C'est un peu court comme argumentation.
KAME et MachinSwan sont deux projets distincts recouvrant les mêmes fonctionnalités (enfin presque, vu que le deuxième s'assoit sur une partie des rfc concernées), support kernel et isakmpd, j'ai des doutes sur le fait que l'on puisse faire coexister les supports kernel des deux simultanément.
A partir du moment ou l'on utilise une interface de type pfkeyV2 pour la communication entre l'isakmpd et l'implémentation noyau, n'importe quel isakmpd respectant cet interface pourra converser avec une implémentation kernel la supportant aussi (ex isakmpd (OpenBSD) sur un FreeBSD/NetBSD (KAME))
Quand au fait qu'une implémentation MachinSwan puisse avoir pour pair une implémentation KAME, c'est tout de même le minimum.
Eric Masson
-- C'est vrai peut t'on renconter quelqu'un sur internet? Car moi je cherche l'ame soeur -+- SR in: <http://www.le-gnu.net> - Neuneu a-t-il une âme ? -+-
Cedric Blancher
Le Thu, 06 May 2004 07:48:38 +0000, Eric Masson a écrit :
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin* de m'en servir, même au niveau filtrage. A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
Elle présente un réel intérêt, en particulier si on a besoin de faire du NAT sur le flux IPSEC en entrée ou en sortie. En effet, sous Linux, le trafic en PREROUTING/POSTROUTING est encore chiffré, il est donc impossible de modifier les paquets tunnelés. C'est pas exemple utile si on veut faire du LAN/LAN avec une passerelle qui n'accepte que du host/LAN, auquel cas on doit SNATer le trafic routé via le lien IPSEC. Y'a pleins d'autre problématiques de filtrage qui se règles mieux si on a une interface IPSEC à disposition que si on ne l'a pas.
Mais la plupart de ces choses sont propres à l'architecture de filtrage de Linux. Mais il y a du travail qui est réalisé dessus, et bientôt l'usage de cette interface ne sera plus nécessaire.
Sinon, sur un plan purement conceptuel, la présence d'une interface permet de voir le lien IPSEc comme un tunnel (un vrai) et permet de réaliser un certain nombre de choses via la couche de routage qui ne sont pas aussi simples si on gère la chose avec des transformations. Par exemple, gérer de la redondance de lien IPSEC avec OSPF est trivial avec une interface, mais pas aussi simple si on en n'a pas.
My 0.02¤...
-- BB: il me dit "Unable to parse configuration file". Que dois je faire ? JM: Lire la doc BB: CA MARCHE !!!!!! -+- BB in : http://neuneu.ctw.cc - Le RTFM pour les nuls -+-
Le Thu, 06 May 2004 07:48:38 +0000, Eric Masson a écrit :
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin*
de m'en servir, même au niveau filtrage.
A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
Elle présente un réel intérêt, en particulier si on a besoin de faire
du NAT sur le flux IPSEC en entrée ou en sortie. En effet, sous Linux,
le trafic en PREROUTING/POSTROUTING est encore chiffré, il est donc
impossible de modifier les paquets tunnelés. C'est pas exemple utile
si on veut faire du LAN/LAN avec une passerelle qui n'accepte que du
host/LAN, auquel cas on doit SNATer le trafic routé via le lien IPSEC.
Y'a pleins d'autre problématiques de filtrage qui se règles mieux si on
a une interface IPSEC à disposition que si on ne l'a pas.
Mais la plupart de ces choses sont propres à l'architecture de filtrage
de Linux. Mais il y a du travail qui est réalisé dessus, et bientôt
l'usage de cette interface ne sera plus nécessaire.
Sinon, sur un plan purement conceptuel, la présence d'une interface
permet de voir le lien IPSEc comme un tunnel (un vrai) et permet de
réaliser un certain nombre de choses via la couche de routage qui ne sont
pas aussi simples si on gère la chose avec des transformations. Par
exemple, gérer de la redondance de lien IPSEC avec OSPF est trivial avec
une interface, mais pas aussi simple si on en n'a pas.
My 0.02¤...
--
BB: il me dit "Unable to parse configuration file". Que dois je faire ?
JM: Lire la doc
BB: CA MARCHE !!!!!!
-+- BB in : http://neuneu.ctw.cc - Le RTFM pour les nuls -+-
Le Thu, 06 May 2004 07:48:38 +0000, Eric Masson a écrit :
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin* de m'en servir, même au niveau filtrage. A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
Elle présente un réel intérêt, en particulier si on a besoin de faire du NAT sur le flux IPSEC en entrée ou en sortie. En effet, sous Linux, le trafic en PREROUTING/POSTROUTING est encore chiffré, il est donc impossible de modifier les paquets tunnelés. C'est pas exemple utile si on veut faire du LAN/LAN avec une passerelle qui n'accepte que du host/LAN, auquel cas on doit SNATer le trafic routé via le lien IPSEC. Y'a pleins d'autre problématiques de filtrage qui se règles mieux si on a une interface IPSEC à disposition que si on ne l'a pas.
Mais la plupart de ces choses sont propres à l'architecture de filtrage de Linux. Mais il y a du travail qui est réalisé dessus, et bientôt l'usage de cette interface ne sera plus nécessaire.
Sinon, sur un plan purement conceptuel, la présence d'une interface permet de voir le lien IPSEc comme un tunnel (un vrai) et permet de réaliser un certain nombre de choses via la couche de routage qui ne sont pas aussi simples si on gère la chose avec des transformations. Par exemple, gérer de la redondance de lien IPSEC avec OSPF est trivial avec une interface, mais pas aussi simple si on en n'a pas.
My 0.02¤...
-- BB: il me dit "Unable to parse configuration file". Que dois je faire ? JM: Lire la doc BB: CA MARCHE !!!!!! -+- BB in : http://neuneu.ctw.cc - Le RTFM pour les nuls -+-
Djoume SALVETTI
Le Wed, 05 May 2004 19:24:56 +0000, Djoume SALVETTI a écrit :
D'autre part il est également possible d'utiliser [Free|Open]S/WAN avec KAME.
Non. L'implémentation kernel-side d'IPSEC de Linux est propre à Linux, et n'a donc rien à voir avec Kame. Par contre, elle compatible avec les outils userland portés du projet Kame via son interface PFKey.
Je dirais plus que [Free|Open]S/WAN est, comme Kame, utilisable avec la couche IPSEC des noyaux 2.6.
En fait c'est cette couche (IPSec noyau 2.6) que j'appelais KAME.
-- Djoumé SALVETTI
Le Wed, 05 May 2004 19:24:56 +0000, Djoume SALVETTI a écrit :
D'autre part il est également possible d'utiliser [Free|Open]S/WAN avec
KAME.
Non.
L'implémentation kernel-side d'IPSEC de Linux est propre à Linux, et n'a
donc rien à voir avec Kame. Par contre, elle compatible avec les outils
userland portés du projet Kame via son interface PFKey.
Je dirais plus que [Free|Open]S/WAN est, comme Kame, utilisable avec la
couche IPSEC des noyaux 2.6.
En fait c'est cette couche (IPSec noyau 2.6) que j'appelais KAME.
Le Wed, 05 May 2004 19:24:56 +0000, Djoume SALVETTI a écrit :
D'autre part il est également possible d'utiliser [Free|Open]S/WAN avec KAME.
Non. L'implémentation kernel-side d'IPSEC de Linux est propre à Linux, et n'a donc rien à voir avec Kame. Par contre, elle compatible avec les outils userland portés du projet Kame via son interface PFKey.
Je dirais plus que [Free|Open]S/WAN est, comme Kame, utilisable avec la couche IPSEC des noyaux 2.6.
En fait c'est cette couche (IPSec noyau 2.6) que j'appelais KAME.
-- Djoumé SALVETTI
Cedric Blancher
Le Thu, 06 May 2004 08:18:26 +0000, Djoume SALVETTI a écrit :
En fait c'est cette couche (IPSec noyau 2.6) que j'appelais KAME.
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin* de m'en servir, même au niveau filtrage.
A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
cf réponse de Cédric Blancher.
Djoume> D'autre part il est également possible d'utiliser Djoume> [Free|Open]S/WAN avec KAME.
Ah ? C'est un peu court comme argumentation.
Si c'est uniquement l'implémentation noyau de SWAN qui te gène (pas d'utilisation de la crypto API par exemple) tu peux utiliser celle de Linux 2.6, c'est tout ce que je voulais dire.
-- Djoumé SALVETTI
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin*
de m'en servir, même au niveau filtrage.
A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
cf réponse de Cédric Blancher.
Djoume> D'autre part il est également possible d'utiliser
Djoume> [Free|Open]S/WAN avec KAME.
Ah ? C'est un peu court comme argumentation.
Si c'est uniquement l'implémentation noyau de SWAN qui te gène (pas
d'utilisation de la crypto API par exemple) tu peux utiliser celle de
Linux 2.6, c'est tout ce que je voulais dire.
Sous Open, une interface de type enc existe, je n'ai jamais eu *besoin* de m'en servir, même au niveau filtrage.
A part pouvoir dire qu'elle existe, quel est son intérêt *réel* ?
cf réponse de Cédric Blancher.
Djoume> D'autre part il est également possible d'utiliser Djoume> [Free|Open]S/WAN avec KAME.
Ah ? C'est un peu court comme argumentation.
Si c'est uniquement l'implémentation noyau de SWAN qui te gène (pas d'utilisation de la crypto API par exemple) tu peux utiliser celle de Linux 2.6, c'est tout ce que je voulais dire.
-- Djoumé SALVETTI
Eric Masson
"Cedric" == Cedric Blancher writes:
[Snip explications interface traffic crypté]
Intéressant, merci.
Cedric> Mais la plupart de ces choses sont propres à l'architecture de Cedric> filtrage de Linux. Mais il y a du travail qui est réalisé Cedric> dessus, et bientôt l'usage de cette interface ne sera plus Cedric> nécessaire.
Ok.
Cedric> Sinon, sur un plan purement conceptuel, la présence d'une Cedric> interface permet de voir le lien IPSEc comme un tunnel (un Cedric> vrai) et permet de réaliser un certain nombre de choses via la Cedric> couche de routage qui ne sont pas aussi simples si on gère la Cedric> chose avec des transformations. Par exemple, gérer de la Cedric> redondance de lien IPSEC avec OSPF est trivial avec une Cedric> interface, mais pas aussi simple si on en n'a pas.
Effectivement, je contourne ce genre de problème en utilisant des tunnels gre/gif sécurisés par un lien ipsec transport, les solutions que j'avais envisagé avec des tunnels ipsec natifs me paraissaient un poil trop compliqué pour assurer une maintenance simple à postériori.
Cedric> My 0.02¤...
Sois pas si modeste ;)
Eric Masson
-- L'idée serait bonne si seulement beaucoup de personnes ne venaient pas sur internet sans avoir auparavant lue un bouquin qui leur aurait permis d'apprendre quelques règle non écrites mais relevant du bon sans -+- JB in GNU : Bien lire les règles non écrites à sans pour sens.
Cedric> Mais la plupart de ces choses sont propres à l'architecture de
Cedric> filtrage de Linux. Mais il y a du travail qui est réalisé
Cedric> dessus, et bientôt l'usage de cette interface ne sera plus
Cedric> nécessaire.
Ok.
Cedric> Sinon, sur un plan purement conceptuel, la présence d'une
Cedric> interface permet de voir le lien IPSEc comme un tunnel (un
Cedric> vrai) et permet de réaliser un certain nombre de choses via la
Cedric> couche de routage qui ne sont pas aussi simples si on gère la
Cedric> chose avec des transformations. Par exemple, gérer de la
Cedric> redondance de lien IPSEC avec OSPF est trivial avec une
Cedric> interface, mais pas aussi simple si on en n'a pas.
Effectivement, je contourne ce genre de problème en utilisant des
tunnels gre/gif sécurisés par un lien ipsec transport, les solutions que
j'avais envisagé avec des tunnels ipsec natifs me paraissaient un poil
trop compliqué pour assurer une maintenance simple à postériori.
Cedric> My 0.02¤...
Sois pas si modeste ;)
Eric Masson
--
L'idée serait bonne si seulement beaucoup de personnes ne venaient pas
sur internet sans avoir auparavant lue un bouquin qui leur aurait
permis d'apprendre quelques règle non écrites mais relevant du bon sans
-+- JB in GNU : Bien lire les règles non écrites à sans pour sens.
Cedric> Mais la plupart de ces choses sont propres à l'architecture de Cedric> filtrage de Linux. Mais il y a du travail qui est réalisé Cedric> dessus, et bientôt l'usage de cette interface ne sera plus Cedric> nécessaire.
Ok.
Cedric> Sinon, sur un plan purement conceptuel, la présence d'une Cedric> interface permet de voir le lien IPSEc comme un tunnel (un Cedric> vrai) et permet de réaliser un certain nombre de choses via la Cedric> couche de routage qui ne sont pas aussi simples si on gère la Cedric> chose avec des transformations. Par exemple, gérer de la Cedric> redondance de lien IPSEC avec OSPF est trivial avec une Cedric> interface, mais pas aussi simple si on en n'a pas.
Effectivement, je contourne ce genre de problème en utilisant des tunnels gre/gif sécurisés par un lien ipsec transport, les solutions que j'avais envisagé avec des tunnels ipsec natifs me paraissaient un poil trop compliqué pour assurer une maintenance simple à postériori.
Cedric> My 0.02¤...
Sois pas si modeste ;)
Eric Masson
-- L'idée serait bonne si seulement beaucoup de personnes ne venaient pas sur internet sans avoir auparavant lue un bouquin qui leur aurait permis d'apprendre quelques règle non écrites mais relevant du bon sans -+- JB in GNU : Bien lire les règles non écrites à sans pour sens.
Alain Thivillon
Eric Masson wrote:
Effectivement, je contourne ce genre de problème en utilisant des tunnels gre/gif sécurisés par un lien ipsec transport, les solutions que j'avais envisagé avec des tunnels ipsec natifs me paraissaient un poil trop compliqué pour assurer une maintenance simple à postériori.
Et donc vous etes compatible avec vous même.
L'absence de moyen de filtrage des sorties des tunnels IPSEC sous FreeBSD ou NetBSD dévalue complètement par exemple l'utilisation possible de ces plateformes dans la vraie vie.
Ca montre bien aussi que "IPSEC ça pue" et que ça a été inventé par des gens qui ont pas bien compris les problemes réels. Depuis tout le monde rame, et l'abandon de l'Ipsec FreeSwan dans les kernel 2.6 est pas du tout une bonne idée amha. -- Nom d'un chat de nom d'un chat !
Eric Masson <emss@free.fr> wrote:
Effectivement, je contourne ce genre de problème en utilisant des
tunnels gre/gif sécurisés par un lien ipsec transport, les solutions que
j'avais envisagé avec des tunnels ipsec natifs me paraissaient un poil
trop compliqué pour assurer une maintenance simple à postériori.
Et donc vous etes compatible avec vous même.
L'absence de moyen de filtrage des sorties des tunnels IPSEC
sous FreeBSD ou NetBSD dévalue complètement par exemple
l'utilisation possible de ces plateformes dans la vraie vie.
Ca montre bien aussi que "IPSEC ça pue" et que ça a été
inventé par des gens qui ont pas bien compris les problemes
réels. Depuis tout le monde rame, et l'abandon de l'Ipsec
FreeSwan dans les kernel 2.6 est pas du tout une bonne idée
amha.
--
Nom d'un chat de nom d'un chat !
Effectivement, je contourne ce genre de problème en utilisant des tunnels gre/gif sécurisés par un lien ipsec transport, les solutions que j'avais envisagé avec des tunnels ipsec natifs me paraissaient un poil trop compliqué pour assurer une maintenance simple à postériori.
Et donc vous etes compatible avec vous même.
L'absence de moyen de filtrage des sorties des tunnels IPSEC sous FreeBSD ou NetBSD dévalue complètement par exemple l'utilisation possible de ces plateformes dans la vraie vie.
Ca montre bien aussi que "IPSEC ça pue" et que ça a été inventé par des gens qui ont pas bien compris les problemes réels. Depuis tout le monde rame, et l'abandon de l'Ipsec FreeSwan dans les kernel 2.6 est pas du tout une bonne idée amha. -- Nom d'un chat de nom d'un chat !
