On me demande de monter un tunnel ipsec entre 2 sites via Internet. J'ai
donc monté 2 machines de test à base de Debian Sarge, modifiée avec un
kernel Vanilla 2.6.18.2 avec tout ce qu'il faut pour ipsec compilé en
module, et les outils ipsec-tools et racoon 0.6.6 (backportés depuis
etch)
je fais ma popote de config pour setkey, psk et racoon.conf, et je lance
les démons racoon en foreground sur les 2 machines... et rien ne se passe
!
Bon, je relis l'IPsec-Howto (http://www.ipsec-howto.org/) et je tombe là-
dessus :
"The IKE daemon racoon does not start the tunnel negotiation immediately
when started. Rather racoon waits until the tunnel is needed. For this
notification to occur the kernel needs to know when to notify racoon. To
achieve this, the administrator needs to define security policies without
the appropiate security associations. Whenever the Linux kernel needs to
protect a packet according to the security policies and when no security
association is available, the Linux kernel calls racoon and asks for the
required security associations. Racoon will then start the IKE
negotiations and will create the SAs when finished. The Linux kernel can
then send the packets."
Pour résumer, si je comprends bien, le tunnel est monté à la demande.
Qu'à cela ne tienne, je tente un ping vers le réseau distant :
# ping 192.168.221.254
PING 192.168.221.254 (192.168.221.254) 56(84) bytes of data.
From 193.253.14.185 icmp_seq=32 Destination Net Unreachable
Et c'est le 1er routeur de bordure derrière ma passerelle par défaut qui
me répond que le paquet n'est pas routable !
Forcément, ma table de routage ne contient aucune route vers mon réseau
distant, puisque je n'ai encore aucune interface de montée !
J'en conclus que je dois louper quelque chose, mais j'ai beau lire et
relire le ipsec howto, je vois pas quoi ?
Un petit coup de pouce sera le bienvenu :)
Je ne pige pas trop le pourquoi de la présence de cette SP, mais bon.
elle est rajoutée automatiquement par setkey >= 0.5
Et un ping -S 192.168.50.254 192.168.51.254, ça donne quoi ? Si tu ne peux pas faire ce test, essaye de pinger depuis un autre hôte du lan vers une adresse située sur l'autre lan.
c'est réglé, le tunnel se monte maintenant (cf mon autre post)
La couche ipsec vérifie les paquets entrants par rapport à la SPD, si une règle est applicable alors le/les paquet(s) subi(ssen)t les transformations et il est/sont réinjecté(s) dans la pile.
merci pour toutes ces explications, merci aussi à Fred qui m'a
indirectement mis sur la voie pour résoudre mon problème ;)
-- Rico
Eric Masson <emss@free.fr> wrote in news:4rvl24-s87.ln1
@srvbsdnanssv.oursoides-associes.com:
Je ne pige pas trop le pourquoi de la présence de cette SP, mais bon.
elle est rajoutée automatiquement par setkey >= 0.5
Et un ping -S 192.168.50.254 192.168.51.254, ça donne quoi ?
Si tu ne peux pas faire ce test, essaye de pinger depuis un autre hôte
du lan vers une adresse située sur l'autre lan.
c'est réglé, le tunnel se monte maintenant (cf mon autre post)
La couche ipsec vérifie les paquets entrants par rapport à la SPD, si
une règle est applicable alors le/les paquet(s) subi(ssen)t les
transformations et il est/sont réinjecté(s) dans la pile.
merci pour toutes ces explications, merci aussi à Fred qui m'a
indirectement mis sur la voie pour résoudre mon problème ;)
Je ne pige pas trop le pourquoi de la présence de cette SP, mais bon.
elle est rajoutée automatiquement par setkey >= 0.5
Et un ping -S 192.168.50.254 192.168.51.254, ça donne quoi ? Si tu ne peux pas faire ce test, essaye de pinger depuis un autre hôte du lan vers une adresse située sur l'autre lan.
c'est réglé, le tunnel se monte maintenant (cf mon autre post)
La couche ipsec vérifie les paquets entrants par rapport à la SPD, si une règle est applicable alors le/les paquet(s) subi(ssen)t les transformations et il est/sont réinjecté(s) dans la pile.
merci pour toutes ces explications, merci aussi à Fred qui m'a
indirectement mis sur la voie pour résoudre mon problème ;)
-- Rico
Eric Masson
J1 writes:
N'ai pas parle d'incoherence, juste du cote pratique :)
Ben, tu peux prendre la méthode OpenBSD qui a modifié netstat pour que dans le cas de l'utilisation de l'option r, la SPD soit affichée elle aussi.
Je n'ai pas pousse tres loin mon utilisation d'ipsec et des politiques de securite, mais dans le cas d'un systeme linux, quelles operations sont possibles avec les selecteurs de politiques que ne permettent pas les outils netfilter + iproute2 + tunnel ?
Là, tu m'en demandes un poil trop, je suis loin d'être suffisamment pointu sous linux pour te répondre, il se trouve juste que l'implémentation ipsec des séries 2.6 est très proche de celle qui est utilisée sur les bsd, KAME.
Merci pour l'information. Avec ce type de tunnel, redevient il possible d'utiliser les outils classiques de routage et de filtrage (si j'ai bien suivi, oui)
Étant donné que tu disposes d'une interface, tous les outils s'appliquant à une interface sont disponibles.
ou faut il encore manipuler les tables de routage ET les selecteurs de politique de securite lors d'ajout de regles de routage
Tu ne manipules plus la SPD que pour ajouter un nouveau lien (mise en place de la SP esp/transport pour protéger le trafic ipip).
-- Je pense qu'un lecteur assidu se reconnaitra. James, si tu veux que je réponde à ton message, même pour te dire que je n'ai pas envie de te répondre, laisse-moi une adresse de retour ! -+-DM in : <http://www.le-gnu.net> : Je t'aime moi non plus -+-
J1 <ji1.NOJUNK@free.fr> writes:
N'ai pas parle d'incoherence, juste du cote pratique :)
Ben, tu peux prendre la méthode OpenBSD qui a modifié netstat pour que
dans le cas de l'utilisation de l'option r, la SPD soit affichée elle
aussi.
Je n'ai pas pousse tres loin mon utilisation d'ipsec et des politiques
de securite, mais dans le cas d'un systeme linux, quelles operations
sont possibles avec les selecteurs de politiques que ne permettent pas
les outils netfilter + iproute2 + tunnel ?
Là, tu m'en demandes un poil trop, je suis loin d'être suffisamment
pointu sous linux pour te répondre, il se trouve juste que
l'implémentation ipsec des séries 2.6 est très proche de celle qui est
utilisée sur les bsd, KAME.
Merci pour l'information. Avec ce type de tunnel, redevient il possible
d'utiliser les outils classiques de routage et de filtrage (si j'ai bien
suivi, oui)
Étant donné que tu disposes d'une interface, tous les outils
s'appliquant à une interface sont disponibles.
ou faut il encore manipuler les tables de routage ET les selecteurs de
politique de securite lors d'ajout de regles de routage
Tu ne manipules plus la SPD que pour ajouter un nouveau lien (mise en
place de la SP esp/transport pour protéger le trafic ipip).
--
Je pense qu'un lecteur assidu se reconnaitra. James, si tu veux que
je réponde à ton message, même pour te dire que je n'ai pas envie de te
répondre, laisse-moi une adresse de retour !
-+-DM in : <http://www.le-gnu.net> : Je t'aime moi non plus -+-
N'ai pas parle d'incoherence, juste du cote pratique :)
Ben, tu peux prendre la méthode OpenBSD qui a modifié netstat pour que dans le cas de l'utilisation de l'option r, la SPD soit affichée elle aussi.
Je n'ai pas pousse tres loin mon utilisation d'ipsec et des politiques de securite, mais dans le cas d'un systeme linux, quelles operations sont possibles avec les selecteurs de politiques que ne permettent pas les outils netfilter + iproute2 + tunnel ?
Là, tu m'en demandes un poil trop, je suis loin d'être suffisamment pointu sous linux pour te répondre, il se trouve juste que l'implémentation ipsec des séries 2.6 est très proche de celle qui est utilisée sur les bsd, KAME.
Merci pour l'information. Avec ce type de tunnel, redevient il possible d'utiliser les outils classiques de routage et de filtrage (si j'ai bien suivi, oui)
Étant donné que tu disposes d'une interface, tous les outils s'appliquant à une interface sont disponibles.
ou faut il encore manipuler les tables de routage ET les selecteurs de politique de securite lors d'ajout de regles de routage
Tu ne manipules plus la SPD que pour ajouter un nouveau lien (mise en place de la SP esp/transport pour protéger le trafic ipip).
-- Je pense qu'un lecteur assidu se reconnaitra. James, si tu veux que je réponde à ton message, même pour te dire que je n'ai pas envie de te répondre, laisse-moi une adresse de retour ! -+-DM in : <http://www.le-gnu.net> : Je t'aime moi non plus -+-
Eric Masson
Eric Belhomme <{rico}+no/ writes:
merci aussi à Fred qui m'a indirectement mis sur la voie pour résoudre mon problème ;)
Ben, un développeur/committer ipsec-tools est très souvent de bon conseil ;)
--
http://www.aixcomputers.com Jamais rien lu de plus con excepté une notice de magnétoscope.
-+- JdC in GNU : Quatres têtes hi-fi stéréo et toujours aussi con -+-
Eric Belhomme <{rico}+no/spam@ricospirit.net> writes:
merci aussi à Fred qui m'a indirectement mis sur la voie pour résoudre
mon problème ;)
Ben, un développeur/committer ipsec-tools est très souvent de bon
conseil ;)
--
http://www.aixcomputers.com
Jamais rien lu de plus con excepté une notice de magnétoscope.
-+- JdC in GNU : Quatres têtes hi-fi stéréo et toujours aussi con -+-
Eric Masson wrote in news:0a1m24-s87.ln1 @srvbsdnanssv.oursoides-associes.com:
Ben, un développeur/committer ipsec-tools est très souvent de bon conseil ;)
oups, j'avais même pas tilté ! Son nom est pourtant sur la 1ere page du projet !
-- Rico
Eric Belhomme
"F. Senault" wrote in news::
le tunnel ipsec travaille sur une interface existante.
Là est la clé de mon problème ! Dans mon esprit racoon montait une interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Je crois que je vais envoyer quelques suggestions de modifications au mainteneur de l'ipsec-howto car ce détail n'est pas du tout clair dans son document (en tout cas pour moi !)
Même là, il m'a fallu plusieurs relectures avant de percuter l'implication de cette simple assertion, et de comprendre dans la foulée mon erreur... on va dire que ma semaine démarre doucement ;)
-- Rico
"F. Senault" <fred@lacave.net> wrote in
news:epain3k3rj6k.dlg@tamnavulin.lacave.local:
le tunnel ipsec travaille sur une interface existante.
Là est la clé de mon problème ! Dans mon esprit racoon montait une
interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Je crois que je vais envoyer quelques suggestions de modifications au
mainteneur de l'ipsec-howto car ce détail n'est pas du tout clair dans son
document (en tout cas pour moi !)
Même là, il m'a fallu plusieurs relectures avant de percuter l'implication
de cette simple assertion, et de comprendre dans la foulée mon erreur... on
va dire que ma semaine démarre doucement ;)
le tunnel ipsec travaille sur une interface existante.
Là est la clé de mon problème ! Dans mon esprit racoon montait une interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Je crois que je vais envoyer quelques suggestions de modifications au mainteneur de l'ipsec-howto car ce détail n'est pas du tout clair dans son document (en tout cas pour moi !)
Même là, il m'a fallu plusieurs relectures avant de percuter l'implication de cette simple assertion, et de comprendre dans la foulée mon erreur... on va dire que ma semaine démarre doucement ;)
-- Rico
J1
Eric Masson wrote:
J1 writes:
N'ai pas parle d'incoherence, juste du cote pratique :)
Ben, tu peux prendre la méthode OpenBSD qui a modifié netstat pour que dans le cas de l'utilisation de l'option r, la SPD soit affichée elle aussi.
Ce choix semble judicieux, cela permet d'avoir une vue d'ensemble sans avoir a consulter la table de routage ET les SPD.
ou faut il encore manipuler les tables de routage ET les selecteurs de politique de securite lors d'ajout de regles de routage
Tu ne manipules plus la SPD que pour ajouter un nouveau lien (mise en place de la SP esp/transport pour protéger le trafic ipip).
Parfait!
Merci encore pour la precision de ces reponses.
Bonne journee,
-- J1
Eric Masson wrote:
J1 <ji1.NOJUNK@free.fr> writes:
N'ai pas parle d'incoherence, juste du cote pratique :)
Ben, tu peux prendre la méthode OpenBSD qui a modifié netstat pour que
dans le cas de l'utilisation de l'option r, la SPD soit affichée elle
aussi.
Ce choix semble judicieux, cela permet d'avoir une vue d'ensemble
sans avoir a consulter la table de routage ET les SPD.
ou faut il encore manipuler les tables de routage ET les selecteurs de
politique de securite lors d'ajout de regles de routage
Tu ne manipules plus la SPD que pour ajouter un nouveau lien (mise en
place de la SP esp/transport pour protéger le trafic ipip).
N'ai pas parle d'incoherence, juste du cote pratique :)
Ben, tu peux prendre la méthode OpenBSD qui a modifié netstat pour que dans le cas de l'utilisation de l'option r, la SPD soit affichée elle aussi.
Ce choix semble judicieux, cela permet d'avoir une vue d'ensemble sans avoir a consulter la table de routage ET les SPD.
ou faut il encore manipuler les tables de routage ET les selecteurs de politique de securite lors d'ajout de regles de routage
Tu ne manipules plus la SPD que pour ajouter un nouveau lien (mise en place de la SP esp/transport pour protéger le trafic ipip).
Parfait!
Merci encore pour la precision de ces reponses.
Bonne journee,
-- J1
F. Senault
"F. Senault" wrote in news::
le tunnel ipsec travaille sur une interface existante.
Là est la clé de mon problème ! Dans mon esprit racoon montait une interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Nope. Ca a déjà été discuté, mais il semblerait que ça soit compliqué, surtout de manière à peu près portable.
Fred -- Safely away from the world In a dream, timeless domain A child, dreamy eyed, Mother's mirror, father's pride (Nightwish, I wish I could come back to you Once again feel the rain Beauty of Falling inside me Cleaning all that I've become the Beast)
"F. Senault" <fred@lacave.net> wrote in
news:epain3k3rj6k.dlg@tamnavulin.lacave.local:
le tunnel ipsec travaille sur une interface existante.
Là est la clé de mon problème ! Dans mon esprit racoon montait une
interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Nope. Ca a déjà été discuté, mais il semblerait que ça soit compliqué,
surtout de manière à peu près portable.
Fred
--
Safely away from the world In a dream, timeless domain
A child, dreamy eyed, Mother's mirror, father's pride (Nightwish,
I wish I could come back to you Once again feel the rain Beauty of
Falling inside me Cleaning all that I've become the Beast)
le tunnel ipsec travaille sur une interface existante.
Là est la clé de mon problème ! Dans mon esprit racoon montait une interface virtuelle (genre tun/tap, ou même ppp) à la manière d'openvpn !!!
Nope. Ca a déjà été discuté, mais il semblerait que ça soit compliqué, surtout de manière à peu près portable.
Fred -- Safely away from the world In a dream, timeless domain A child, dreamy eyed, Mother's mirror, father's pride (Nightwish, I wish I could come back to you Once again feel the rain Beauty of Falling inside me Cleaning all that I've become the Beast)
F. Senault
Mais en lisant le document de Fred, j'ai vu qu'il rajoutait des routes dans les tables de routage de ces passerelles !
j'ai donc aliasé une adresse IP sur l'interface interne de de mes 2 passerelles :
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans mon setup, les tunnels VPNs permanents sont établis de réseau à réseau, sans passer par un adressage supplémentaire.
Et comme les end-points VPN sont situés sur les passerelles par défaut de chaque réseau, les machines clientes n'ont pas besoin de routes supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont incapables de communiquer entre eux via le VPN, alors que le reste du réseau y arrive, IIRC).
Fred -- I am wanting give me breath I am truth you can't explain I am treasure I am dust I am water I am rain I am tempted here I am the hunter I am the prey Though you're ten thousand years Every moment remains I am future I am past I am haunted I am blessed (Collide, Tempted)
Mais en lisant le document de Fred, j'ai vu qu'il rajoutait des routes
dans les tables de routage de ces passerelles !
j'ai donc aliasé une adresse IP sur l'interface interne de de mes 2
passerelles :
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans mon
setup, les tunnels VPNs permanents sont établis de réseau à réseau, sans
passer par un adressage supplémentaire.
Et comme les end-points VPN sont situés sur les passerelles par défaut
de chaque réseau, les machines clientes n'ont pas besoin de routes
supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont
incapables de communiquer entre eux via le VPN, alors que le reste du
réseau y arrive, IIRC).
Fred
--
I am wanting give me breath I am truth you can't explain I am treasure
I am dust I am water I am rain I am tempted here I am the hunter I am
the prey Though you're ten thousand years Every moment remains I am
future I am past I am haunted I am blessed (Collide, Tempted)
Mais en lisant le document de Fred, j'ai vu qu'il rajoutait des routes dans les tables de routage de ces passerelles !
j'ai donc aliasé une adresse IP sur l'interface interne de de mes 2 passerelles :
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans mon setup, les tunnels VPNs permanents sont établis de réseau à réseau, sans passer par un adressage supplémentaire.
Et comme les end-points VPN sont situés sur les passerelles par défaut de chaque réseau, les machines clientes n'ont pas besoin de routes supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont incapables de communiquer entre eux via le VPN, alors que le reste du réseau y arrive, IIRC).
Fred -- I am wanting give me breath I am truth you can't explain I am treasure I am dust I am water I am rain I am tempted here I am the hunter I am the prey Though you're ten thousand years Every moment remains I am future I am past I am haunted I am blessed (Collide, Tempted)
Eric Belhomme
"F. Senault" wrote in news:1ogftrs6xheqo$:
Nope. Ca a déjà été discuté, mais il semblerait que ça soit compliqué, surtout de manière à peu près portable.
C'est bien ce que je me suis dit, tun/tap etant linuxo-linux (bien qu'il y
ai des ports vers pas mal de plate-formes), et KAME etant à la base BSD...
Note qu'une fois ce point éclairci, ca ne me pose pas de problème, le tout étant de le savoir ! Et comme j'ai été auparavant "formaté" avec des outils qui créent des interfaces virtuelles à la volée (genre openvpn, pptp sous windows,etc..., ou dans un autre registre vmware), je m'attendais bêtement à ce qu'il en soit ainsi avec KAME/racoon
-- Rico
"F. Senault" <fred@lacave.net> wrote in
news:1ogftrs6xheqo$.dlg@tamnavulin.lacave.local:
Nope. Ca a déjà été discuté, mais il semblerait que ça soit
compliqué, surtout de manière à peu près portable.
C'est bien ce que je me suis dit, tun/tap etant linuxo-linux (bien qu'il y
ai des ports vers pas mal de plate-formes), et KAME etant à la base BSD...
Note qu'une fois ce point éclairci, ca ne me pose pas de problème, le tout
étant de le savoir !
Et comme j'ai été auparavant "formaté" avec des outils qui créent des
interfaces virtuelles à la volée (genre openvpn, pptp sous windows,etc...,
ou dans un autre registre vmware), je m'attendais bêtement à ce qu'il en
soit ainsi avec KAME/racoon
Nope. Ca a déjà été discuté, mais il semblerait que ça soit compliqué, surtout de manière à peu près portable.
C'est bien ce que je me suis dit, tun/tap etant linuxo-linux (bien qu'il y
ai des ports vers pas mal de plate-formes), et KAME etant à la base BSD...
Note qu'une fois ce point éclairci, ca ne me pose pas de problème, le tout étant de le savoir ! Et comme j'ai été auparavant "formaté" avec des outils qui créent des interfaces virtuelles à la volée (genre openvpn, pptp sous windows,etc..., ou dans un autre registre vmware), je m'attendais bêtement à ce qu'il en soit ainsi avec KAME/racoon
-- Rico
Eric Belhomme
"F. Senault" wrote in news::
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans mon setup, les tunnels VPNs permanents sont établis de réseau à réseau, sans passer par un adressage supplémentaire.
c'est ce que je me suis dit, après avoir constaté que KAME travaille
directement sur une interface réelle : mon routage à la openvpn n'a plus lieu d'être, et ne sert plus à rien... sauf dans le cas où je voudrais joindre un réseau sur le même plan d'eddressage que moi ! dans ce cas, je suppose qu'il faudrait que je mette en place un réseau "tampon" qui ferait de la translation d'adresse d'un réseau à l'autre ?
Et comme les end-points VPN sont situés sur les passerelles par défaut de chaque réseau, les machines clientes n'ont pas besoin de routes supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont incapables de communiquer entre eux via le VPN, alors que le reste du réseau y arrive, IIRC).
là par contre je suis pas sur de saisir ?
Dans mon exemple, mettons qu'une machine 192.168.50.12 veuille communiquer avec 192.168.51.13. on est d'accord que la route par défaut pour 192.168.50.12 est 192.168.50.254 ? donc tout paquet à destination de 192.168.51.13 sera routé vers 192.168.50.254 ? Donc 192.168.50.254 va avoir une décision deroutage à prendre afin de router le paquet vers 192.168.51.254 Et c'est _seulement_ à ce moment que KAME va intercepter le paquet, l'encapsuler dans ipsec et le réinjecter dans la pile IP ? Donc le routeur _doit_ connaitre le moyen de router un endpoint à un autre ? Ou j'ai faux ?
-- Rico
"F. Senault" <fred@lacave.net> wrote in
news:8exrixk74ihn.dlg@tamnavulin.lacave.local:
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans
mon setup, les tunnels VPNs permanents sont établis de réseau à
réseau, sans passer par un adressage supplémentaire.
c'est ce que je me suis dit, après avoir constaté que KAME travaille
directement sur une interface réelle : mon routage à la openvpn n'a plus
lieu d'être, et ne sert plus à rien... sauf dans le cas où je voudrais
joindre un réseau sur le même plan d'eddressage que moi ! dans ce cas,
je suppose qu'il faudrait que je mette en place un réseau "tampon" qui
ferait de la translation d'adresse d'un réseau à l'autre ?
Et comme les end-points VPN sont situés sur les passerelles par défaut
de chaque réseau, les machines clientes n'ont pas besoin de routes
supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont
incapables de communiquer entre eux via le VPN, alors que le reste du
réseau y arrive, IIRC).
là par contre je suis pas sur de saisir ?
Dans mon exemple, mettons qu'une machine 192.168.50.12 veuille
communiquer avec 192.168.51.13. on est d'accord que la route par défaut
pour 192.168.50.12 est 192.168.50.254 ? donc tout paquet à destination
de 192.168.51.13 sera routé vers 192.168.50.254 ? Donc 192.168.50.254 va
avoir une décision deroutage à prendre afin de router le paquet vers
192.168.51.254 Et c'est _seulement_ à ce moment que KAME va intercepter
le paquet, l'encapsuler dans ipsec et le réinjecter dans la pile IP ?
Donc le routeur _doit_ connaitre le moyen de router un endpoint à un
autre ? Ou j'ai faux ?
Certes. Mais note aussi que ce n'est pas du tout nécessaire. Dans mon setup, les tunnels VPNs permanents sont établis de réseau à réseau, sans passer par un adressage supplémentaire.
c'est ce que je me suis dit, après avoir constaté que KAME travaille
directement sur une interface réelle : mon routage à la openvpn n'a plus lieu d'être, et ne sert plus à rien... sauf dans le cas où je voudrais joindre un réseau sur le même plan d'eddressage que moi ! dans ce cas, je suppose qu'il faudrait que je mette en place un réseau "tampon" qui ferait de la translation d'adresse d'un réseau à l'autre ?
Et comme les end-points VPN sont situés sur les passerelles par défaut de chaque réseau, les machines clientes n'ont pas besoin de routes supplémentaires pour atteindre chaque côté du VPN.
Par contre, les routeurs eux-mêmes en ont besoin (sinon, ils sont incapables de communiquer entre eux via le VPN, alors que le reste du réseau y arrive, IIRC).
là par contre je suis pas sur de saisir ?
Dans mon exemple, mettons qu'une machine 192.168.50.12 veuille communiquer avec 192.168.51.13. on est d'accord que la route par défaut pour 192.168.50.12 est 192.168.50.254 ? donc tout paquet à destination de 192.168.51.13 sera routé vers 192.168.50.254 ? Donc 192.168.50.254 va avoir une décision deroutage à prendre afin de router le paquet vers 192.168.51.254 Et c'est _seulement_ à ce moment que KAME va intercepter le paquet, l'encapsuler dans ipsec et le réinjecter dans la pile IP ? Donc le routeur _doit_ connaitre le moyen de router un endpoint à un autre ? Ou j'ai faux ?
