Forum Linux.noyau Intégration de Klips au noyau 2.6

Posté par  .
Étiquettes : aucune
0
19
mai
2005
Bonjour a tous,

Je passe actuellement d'un noyau 2.2 à un noyau 2.6.
Parmi les changements apportés par le 2.6, il y a le support natif de l'IPSec, plus connu sous le nom de 26sec.

Or, ce dernier gère l'IPSec différemment, notamment en ce qui concerne les interfaces ipsecX, qui disparaissent complètement :-(. J'ai vu qu'il y avait peut-etre un patch noyau de klips pour remedier à cela et faire reapparaitre ces interfaces.

Y'en a-t-il parmi vous qui pourraient m'éclairer sur le sujet?

Pour info, mon kernel est un 2.6.8.1, et pour l'IPSec, je compte utiliser freeswan.

D'avance merci!

  • # aidez-moi silvouplé

    Posté par  . Évalué à -1.

    personne n'est en mesure de m'aider????

    • [^] # Re: aidez-moi silvouplé

      Posté par  . Évalué à 3.

      pour quel probleme exactement ?
      sur le site
      http://www.freeswan.org/(...)
      je peut lire
      The FreeS/WAN team is proud to announce the arrival of 2.06, the project's final release of its freely redistributable IPsec for Linux. Here are a few of its notable features, as documented in the CHANGES file:

      * KLIPS has been ported to Linux 2.6; please see the INSTALL file for more details.
      * FreeS/WAN's kernel configuration option, CONFIG_IPSEC, has been changed to CONFIG_KLIPS, due to a name conflict with 2.6 IPsec. This breaks "make oldgo" on any kernel version, unless a corresponding change is made by hand to the kernel's .config file.
      * KLIPS modules generated for 2.4 kernels via "make module" are now created in the modobj subdirectory, instead of linux/net/ipsec. The "make minstall" target has been updated, but users accustomed to a manual install take note.
      * KLIPS now permits DNS packets out on UDP and TCP port 53.
      * All support for transport mode has been removed.

      donc quel est ton soucis ?

      • [^] # Re: aidez-moi silvouplé

        Posté par  . Évalué à -1.

        Voici exactement mon problème :

        Avec la nouvelle implémentation d'IPSec(26sec), il n'y a plus d'interface réseau(comme ipsec0, ipsec1, etc). Or, moi j'aimerais avoir la possibilté d'utiliser ces interfaces avec mon noyau 2.6. Pour ce faire, il faut que j'integre klips (une autre implementation IPSec) dans mon noyau.

        J'ai trouvé des patches prévus à cet effet mais seulement pour noyaux 2.2 et 2.4.

        Je souterais donc savoir s'il y a quelqu'un qui sait où je peux trouver le ou les patche(s) pour le noyau 2.6.

        • [^] # Re: aidez-moi silvouplé

          Posté par  . Évalué à 2.

          mais klips est deja dans le kernel 2.6, il suffit de le selectionner a la place de ipsec26 lorsque que tu compile le kernel.
          que te manque t-il ?

          • [^] # Re: aidez-moi silvouplé

            Posté par  . Évalué à -1.

            pourrais-tu me dire quelles sont les options a activer dans mon .config pour avoir klips a la place de 26sec car je ne les ai pas trouvés?

            • [^] # Re: aidez-moi silvouplé

              Posté par  . Évalué à 2.

              lors de l'installation de freeswan 2.06 les source de klips sont inclus dans le kernel ensuite tu recompile le kernel en selectionnant klip en lieu est place d'ipsec.
              tu peut suivre ce tutoriel pour arriver a cela
              source :
              http://www.wlug.org.nz/IPSecInstallation(...)

              • [^] # Re: aidez-moi silvouplé

                Posté par  . Évalué à 0.

                Cette doc a l'air un peu plus consistante et claire que celle fournie sur le site de freeswan.

                C'est juste que mon cas est un peu particulier car je fais un rpm avec mon kernel mais sinon je pense que ca devrait aller.

                je te remercie.

    • [^] # Re: aidez-moi silvouplé

      Posté par  . Évalué à 1.

      - Quelle est ta configuration actuelle sur le 2.2 ?
      - klips et 26sec sont 2 implémentations d'IPSec pour le 2.6. Un patch de klips ne peut pas résoudre un problème de 26sec
      - Freeswan est un peu mort, je te conseille plutôt openswan (http://www.openswan.org)(...) qui est la référence aujourd'hui.

      Si tu fais une transition aussi importante (2.2 vers 2.6), tu as intérêt à faire une machine de test pour voir les impacts.

      IPSec n'a rien de trivial, tu as intérêt à comprendre toi même l'utilisation, et venir quand tu aura des problèmes spécifiques (pour ton problème d'interface, c'est bien l'implémentation klips qui conserve les interfaces ipsecX, mais elle remplace alors 26sec).

      --
      Thomas

      • [^] # Re: aidez-moi silvouplé

        Posté par  . Évalué à -1.

        actuellement en 2.2 j'ai freeswan-1.7-3, et tout fonctionne tres bien.

        En fait, je ne souhaite pas regler un probleme de 26sec mais utiliser klips a la place de 26sec.

        Quant a openswan, je suis tout à fait ouvert a l'utilisation de ce dernier, du moment que je me sers de klips.

        J'ai trouvé des patches prévus pour integer klips au noyau mais seulement pour noyaux 2.2 et 2.4. Je souhaiterais donc savoir s'il y a quelqu'un qui sait où je peux trouver le ou les patche(s) pour le noyau 2.6.

  • # la reponse (en tout cas j'espere)

    Posté par  . Évalué à 2.

    Il faut utiliser opeswan, le projet freeswan a été abandonné et a été repris par openswan.

    Les modules KLIPS sont inclus dans les sources d'openswan. Mais par défaut ils ne sont pas installés si l'on a un noyau 2.6 afin de laisser le champ libre à l'implementation du noyau. Pour les utiliser il suffit de le dire lors de la compilation de openswan :

    make KERNELSRC=/lib/modules/`uname -r`/build module minstall

    Et c est tout, les modules KLIPS prendront le pas sur les modules du noyau automatiquement. En revanche je ne connais pas le résultat si l'implementation du noyau a été compilé en "dur" dans le noyau.

    Bref, c'est tout ce qu'il y a faire.

    tty

    PS : Cette info est présente dans le fichier openswan-2.3./INSTALL ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.