Auriez vous des pistes de documentations sp=E9cifiques sur de la=20
translations d'adresse une pour une avec iptable sous linux ?
par exemple : toutes les adresses sources 192.168.0.x/24 doivent =EAtre=20
translat=E9s en 172.16.0.x/24 avec correspondance avec le dernier digit de=
=20
l'adresse avant d'=EAtre rout=E9es.=20
Bein Debian permet de bien vivre avec leurs packages de noyaux binaires, que veux-tu dire par là ?
Qu'un gars qui utilise une debian *sait* recompiler un noyau ;o))
C'est bien ce qui me semblait. Et je pense que tu te trompes. A mes débuts d'utilisation de Debian, je ne savais pas comment recompiler mon noyau, et Debian est tout à fait adaptée aux débutants. Quand on a appris, ensuite, on devient un utilisateur de Debian qui recompile et patche ses noyaux.
Mais pour moi, m'assertion "Debian implique non débutant" (ou en tout cas, débutant assez avancé pour recompiler son noyau) est fausse. Et j'en ai été un contre exemple il y a finalement assez peu de temps.
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Bein Debian permet de bien vivre avec leurs packages de noyaux binaires,
que veux-tu dire par là ?
Qu'un gars qui utilise une debian *sait* recompiler un noyau ;o))
C'est bien ce qui me semblait. Et je pense que tu te trompes. A mes
débuts d'utilisation de Debian, je ne savais pas comment recompiler mon
noyau, et Debian est tout à fait adaptée aux débutants. Quand on a
appris, ensuite, on devient un utilisateur de Debian qui recompile et
patche ses noyaux.
Mais pour moi, m'assertion "Debian implique non débutant" (ou en tout
cas, débutant assez avancé pour recompiler son noyau) est fausse. Et
j'en ai été un contre exemple il y a finalement assez peu de temps.
pierre
--
Pierre LALET
http://pierre.droids-corp.org/
Droids Corporation & Team rstack
French Honeynet Project
Bein Debian permet de bien vivre avec leurs packages de noyaux binaires, que veux-tu dire par là ?
Qu'un gars qui utilise une debian *sait* recompiler un noyau ;o))
C'est bien ce qui me semblait. Et je pense que tu te trompes. A mes débuts d'utilisation de Debian, je ne savais pas comment recompiler mon noyau, et Debian est tout à fait adaptée aux débutants. Quand on a appris, ensuite, on devient un utilisateur de Debian qui recompile et patche ses noyaux.
Mais pour moi, m'assertion "Debian implique non débutant" (ou en tout cas, débutant assez avancé pour recompiler son noyau) est fausse. Et j'en ai été un contre exemple il y a finalement assez peu de temps.
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Pierre LALET
Qu'il est très facile avec la "méthode Debian" de préparer un noyau sous forme de paquetage installable (qu'on peut ensuite installer tout aussi facilement sur une autre machine sous Debian). Même moi j'y suis arrivé du premier coup alors que je n'avais jamais compilé d'application "normale" :)
Alors j'avais mal compris. Et je suis d'accord avec toi ;-)
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Qu'il est très facile avec la "méthode Debian" de préparer un noyau sous
forme de paquetage installable (qu'on peut ensuite installer tout aussi
facilement sur une autre machine sous Debian). Même moi j'y suis arrivé
du premier coup alors que je n'avais jamais compilé d'application
"normale" :)
Alors j'avais mal compris. Et je suis d'accord avec toi ;-)
pierre
--
Pierre LALET
http://pierre.droids-corp.org/
Droids Corporation & Team rstack
French Honeynet Project
Qu'il est très facile avec la "méthode Debian" de préparer un noyau sous forme de paquetage installable (qu'on peut ensuite installer tout aussi facilement sur une autre machine sous Debian). Même moi j'y suis arrivé du premier coup alors que je n'avais jamais compilé d'application "normale" :)
Alors j'avais mal compris. Et je suis d'accord avec toi ;-)
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Cedric Blancher
Le Wed, 20 Oct 2004 00:19:51 +0200, Pierre LALET a écrit :
Non. C'est ce que j'expliquais, il n'y a pas une règle pour le sens aller et une règle retour (toujours de mémoire, mes tests en la matière sont lointains). Les deux règles sont différentes *aussi* sémantiquement, et elles sont toutes deux nécessaires.
Je pense que tu devrais rejeter un coup d'oeil au routage de Linux. Oui, une rule (gestion de policy routing) est différent d'un route (routage bête et méchant), c'est clair. Mais ces deux types de règles interviennent à chaque routage de paquet. Simplement, la bête commande route ne te montre pas les rules, même si elle existent.
root:~# ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default
Rien que de base, tu as 3 rules qui vont être examinées pour chaque routage de paquet, envoyant le paquet successivement vers 3 tables de routage, la principale et visible étant la table main. La table local, sert elle à placer la bonne IP source quand on envoie un paquet.
Bref, chaque routage fait intervenir une (ou plusieurs) rule et une route. Si je me souviens bien (grrr, j'ai plus de 2.2 ou 2.4 sous la main pour tester), il est n'est effectivement pas possible d'utiliser une règle seule de type :
ip rule add from 192.168.0.0/24 nat 172.16.0.0
Par contre, si tu veux mettre en place un NAT de destination seul et unidirectionnel, tu peux faire (afaik) un simple :
ip route add nat 172.16.0.0/24 via 192.168.0.0
Ce qui a pour effet de nater toutes les connexions entrantes allant vers 172.16.0.0/24 sur le bloc 192.168.0.0/24. Par contre, si le bloc 192.168.0.0/24 veut initier des connexions vers l'extérieur, il ne peut pas, et là, par contre, il a besoin d'une rule pour le faire, parce qu'on va travailler sur l'IP source, et qu'une route ne sait pas faire ça... D'où le :
ip rule add from 192.168.0.0/24 nat 172.16.0.0
Alors par contre, il est vrai que ce que j'ai dit était faux dans sa formulation. Il n'est pas exact de dire que chacune sert à modifier les paquets dans un sens ou dans l'autre. En fait, c'est au niveau des connexions (enfin des flux IP pour être précis) que ça se passe. Ce serait en fait exactement comme dire que si on considère ces deux règles :
chacune traite un sens de paquets. C'est évidemment faux. Elle traitent les initiations de flux, l'une dans un sens et l'autre dans l'autre, mais juste les initiations. Une seule suffit pour gérer des connexions établies dans un seul sens...
Pour en revenir à nos moutons, la route sert à faire le dumb NAT en destination et se suffit à elle-même. Si par contre on veut faire en plus un NAT source (donc un NAT 1-1 bidirectionnel), on doit ajouter une rule, qui ne peut pas exister seule : l'adresse pointée par le switch "nat" doit faire l'objet d'une route en nat (d'où le non fonctionnement constaté par Pascal). Pourquoi ? Parce que le routage sait s'en sortir pour les paquets de retour grâce à son cache. Par contre, la gestion des rules n'a pas de cache, donc si on place un telle rule, sans route ad-hoc, les paquets de retour ne seront pas remis en forme (c'est du moins ce que j'avais compris à l'époque). D'où la nécessité d'un ip route add nat dès qu'on veut placer un ip rule pour du NAT.
J'ai la flemme de chercher (il est trop tôt), mais il doit y avoir un chapitre là-dessus sur le site de Mark Lamb dédié au réseau pour Linux 2.2 :
http://snafu.freedom.org/linux2.2/
Donc si on remet le tout à plat, la route sert à nater les flux initiés dans le sens PUBLIC vers PRIVÉ, alors que la rule sert à nater les flux dans l'autre sens. c'est aussi simple que ça. La différence "sémantique" provient du fait que dans le process de routage de Linux, on ne peut pas faire ça au même endroit (c'est d'ailleurs très proche du PREROUTING/POSTROUTING des 2.4 et supérieurs).
-- Je suis en train de me tater (pas devant tout le monde bien sur) sur la passage a testing au lieu de stable. -+- WM sur debian-french: "masturbation mentale d'une queue de cerise" -+-
Le Wed, 20 Oct 2004 00:19:51 +0200, Pierre LALET a écrit :
Non. C'est ce que j'expliquais, il n'y a pas une règle pour le sens
aller et une règle retour (toujours de mémoire, mes tests en la matière
sont lointains). Les deux règles sont différentes *aussi*
sémantiquement, et elles sont toutes deux nécessaires.
Je pense que tu devrais rejeter un coup d'oeil au routage de Linux. Oui,
une rule (gestion de policy routing) est différent d'un route (routage
bête et méchant), c'est clair. Mais ces deux types de règles
interviennent à chaque routage de paquet. Simplement, la bête commande
route ne te montre pas les rules, même si elle existent.
root:~# ip rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Rien que de base, tu as 3 rules qui vont être examinées pour chaque
routage de paquet, envoyant le paquet successivement vers 3 tables de
routage, la principale et visible étant la table main. La table local,
sert elle à placer la bonne IP source quand on envoie un paquet.
Bref, chaque routage fait intervenir une (ou plusieurs) rule et une route.
Si je me souviens bien (grrr, j'ai plus de 2.2 ou 2.4 sous la main pour
tester), il est n'est effectivement pas possible d'utiliser une règle
seule de type :
ip rule add from 192.168.0.0/24 nat 172.16.0.0
Par contre, si tu veux mettre en place un NAT de destination seul et
unidirectionnel, tu peux faire (afaik) un simple :
ip route add nat 172.16.0.0/24 via 192.168.0.0
Ce qui a pour effet de nater toutes les connexions entrantes allant vers
172.16.0.0/24 sur le bloc 192.168.0.0/24. Par contre, si le bloc
192.168.0.0/24 veut initier des connexions vers l'extérieur, il ne peut
pas, et là, par contre, il a besoin d'une rule pour le faire, parce qu'on
va travailler sur l'IP source, et qu'une route ne sait pas faire ça...
D'où le :
ip rule add from 192.168.0.0/24 nat 172.16.0.0
Alors par contre, il est vrai que ce que j'ai dit était faux dans sa
formulation. Il n'est pas exact de dire que chacune sert à modifier les
paquets dans un sens ou dans l'autre. En fait, c'est au niveau des
connexions (enfin des flux IP pour être précis) que ça se passe. Ce
serait en fait exactement comme dire que si on considère ces deux règles :
chacune traite un sens de paquets. C'est évidemment faux. Elle traitent
les initiations de flux, l'une dans un sens et l'autre dans l'autre, mais
juste les initiations. Une seule suffit pour gérer des connexions
établies dans un seul sens...
Pour en revenir à nos moutons, la route sert à faire le dumb NAT en
destination et se suffit à elle-même. Si par contre on veut faire en
plus un NAT source (donc un NAT 1-1 bidirectionnel), on doit ajouter une
rule, qui ne peut pas exister seule : l'adresse pointée par le switch
"nat" doit faire l'objet d'une route en nat (d'où le non fonctionnement
constaté par Pascal). Pourquoi ? Parce que le routage sait s'en sortir
pour les paquets de retour grâce à son cache. Par contre, la gestion des
rules n'a pas de cache, donc si on place un telle rule, sans route ad-hoc,
les paquets de retour ne seront pas remis en forme (c'est du moins ce que
j'avais compris à l'époque). D'où la nécessité d'un ip route add nat
dès qu'on veut placer un ip rule pour du NAT.
J'ai la flemme de chercher (il est trop tôt), mais il doit y avoir un
chapitre là-dessus sur le site de Mark Lamb dédié au réseau pour Linux
2.2 :
http://snafu.freedom.org/linux2.2/
Donc si on remet le tout à plat, la route sert à nater les flux initiés
dans le sens PUBLIC vers PRIVÉ, alors que la rule sert à nater les flux
dans l'autre sens. c'est aussi simple que ça. La différence
"sémantique" provient du fait que dans le process de routage de Linux, on
ne peut pas faire ça au même endroit (c'est d'ailleurs très proche du
PREROUTING/POSTROUTING des 2.4 et supérieurs).
--
Je suis en train de me tater (pas devant tout le monde bien sur) sur la
passage a testing au lieu de stable.
-+- WM sur debian-french: "masturbation mentale d'une queue de
cerise" -+-
Le Wed, 20 Oct 2004 00:19:51 +0200, Pierre LALET a écrit :
Non. C'est ce que j'expliquais, il n'y a pas une règle pour le sens aller et une règle retour (toujours de mémoire, mes tests en la matière sont lointains). Les deux règles sont différentes *aussi* sémantiquement, et elles sont toutes deux nécessaires.
Je pense que tu devrais rejeter un coup d'oeil au routage de Linux. Oui, une rule (gestion de policy routing) est différent d'un route (routage bête et méchant), c'est clair. Mais ces deux types de règles interviennent à chaque routage de paquet. Simplement, la bête commande route ne te montre pas les rules, même si elle existent.
root:~# ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default
Rien que de base, tu as 3 rules qui vont être examinées pour chaque routage de paquet, envoyant le paquet successivement vers 3 tables de routage, la principale et visible étant la table main. La table local, sert elle à placer la bonne IP source quand on envoie un paquet.
Bref, chaque routage fait intervenir une (ou plusieurs) rule et une route. Si je me souviens bien (grrr, j'ai plus de 2.2 ou 2.4 sous la main pour tester), il est n'est effectivement pas possible d'utiliser une règle seule de type :
ip rule add from 192.168.0.0/24 nat 172.16.0.0
Par contre, si tu veux mettre en place un NAT de destination seul et unidirectionnel, tu peux faire (afaik) un simple :
ip route add nat 172.16.0.0/24 via 192.168.0.0
Ce qui a pour effet de nater toutes les connexions entrantes allant vers 172.16.0.0/24 sur le bloc 192.168.0.0/24. Par contre, si le bloc 192.168.0.0/24 veut initier des connexions vers l'extérieur, il ne peut pas, et là, par contre, il a besoin d'une rule pour le faire, parce qu'on va travailler sur l'IP source, et qu'une route ne sait pas faire ça... D'où le :
ip rule add from 192.168.0.0/24 nat 172.16.0.0
Alors par contre, il est vrai que ce que j'ai dit était faux dans sa formulation. Il n'est pas exact de dire que chacune sert à modifier les paquets dans un sens ou dans l'autre. En fait, c'est au niveau des connexions (enfin des flux IP pour être précis) que ça se passe. Ce serait en fait exactement comme dire que si on considère ces deux règles :
chacune traite un sens de paquets. C'est évidemment faux. Elle traitent les initiations de flux, l'une dans un sens et l'autre dans l'autre, mais juste les initiations. Une seule suffit pour gérer des connexions établies dans un seul sens...
Pour en revenir à nos moutons, la route sert à faire le dumb NAT en destination et se suffit à elle-même. Si par contre on veut faire en plus un NAT source (donc un NAT 1-1 bidirectionnel), on doit ajouter une rule, qui ne peut pas exister seule : l'adresse pointée par le switch "nat" doit faire l'objet d'une route en nat (d'où le non fonctionnement constaté par Pascal). Pourquoi ? Parce que le routage sait s'en sortir pour les paquets de retour grâce à son cache. Par contre, la gestion des rules n'a pas de cache, donc si on place un telle rule, sans route ad-hoc, les paquets de retour ne seront pas remis en forme (c'est du moins ce que j'avais compris à l'époque). D'où la nécessité d'un ip route add nat dès qu'on veut placer un ip rule pour du NAT.
J'ai la flemme de chercher (il est trop tôt), mais il doit y avoir un chapitre là-dessus sur le site de Mark Lamb dédié au réseau pour Linux 2.2 :
http://snafu.freedom.org/linux2.2/
Donc si on remet le tout à plat, la route sert à nater les flux initiés dans le sens PUBLIC vers PRIVÉ, alors que la rule sert à nater les flux dans l'autre sens. c'est aussi simple que ça. La différence "sémantique" provient du fait que dans le process de routage de Linux, on ne peut pas faire ça au même endroit (c'est d'ailleurs très proche du PREROUTING/POSTROUTING des 2.4 et supérieurs).
-- Je suis en train de me tater (pas devant tout le monde bien sur) sur la passage a testing au lieu de stable. -+- WM sur debian-french: "masturbation mentale d'une queue de cerise" -+-
Laurent
Dans l'article <cl40tv$1n7t$, disait...
# ip rule add from 192.168.0.0/24 nat 172.16.0.0 # ip route add nat 172.16.0.0/24 via 192.168.0.0 Eh bien ça marche super ! (mais je n'en doutais pas ;)
Et sans recompiler !! ;o))
merci encore à tout le monde. -- Laurent.
Dans l'article <cl40tv$1n7t$1@biggoron.nerim.net>, pascal@plouf.invalid
disait...
# ip rule add from 192.168.0.0/24 nat 172.16.0.0
# ip route add nat 172.16.0.0/24 via 192.168.0.0
Eh bien ça marche super ! (mais je n'en doutais pas ;)
# ip rule add from 192.168.0.0/24 nat 172.16.0.0 # ip route add nat 172.16.0.0/24 via 192.168.0.0 Eh bien ça marche super ! (mais je n'en doutais pas ;)
