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
La recherche sur Google a dû être longue et difficile...
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être translatés en 172.16.0.x/24 avec correspondance avec le dernier digit de l'adresse avant d'être routées.
La recherche sur Google a dû être longue et difficile...
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être
translatés en 172.16.0.x/24 avec correspondance avec le dernier digit
de l'adresse avant d'être routées.
La recherche sur Google a dû être longue et difficile...
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être translatés en 172.16.0.x/24 avec correspondance avec le dernier digit de l'adresse avant d'être routées.
Sur les derniers kernels, la cible NETMAP est incluse de base.
RTFM/STFW :)))
-- BOFH excuse #108:
The air conditioning water supply pipe ruptured over the machine room
Laurent
Dans l'article , disait...
La recherche sur Google a dû être longue et difficile... oui, bon, désolé...
mais je cherchais à "iptables nat", et dans ce qui pouvait m'interesser je tombais que sur des exemples de port forwarding...
http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO- 4.html#ss4.4 Sur les derniers kernels, la cible NETMAP est incluse de base. Je crains de ne pas l'avoir, le dernier kernel...
en tout cas, merci ! :)
Dans l'article <pan.2004.10.19.15.26.45.423797@cartel-securite.fr>,
blancher@cartel-securite.fr disait...
La recherche sur Google a dû être longue et difficile...
oui, bon, désolé...
mais je cherchais à "iptables nat", et dans ce qui pouvait m'interesser
je tombais que sur des exemples de port forwarding...
http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO- 4.html#ss4.4
Sur les derniers kernels, la cible NETMAP est incluse de base.
Je crains de ne pas l'avoir, le dernier kernel...
La recherche sur Google a dû être longue et difficile... oui, bon, désolé...
mais je cherchais à "iptables nat", et dans ce qui pouvait m'interesser je tombais que sur des exemples de port forwarding...
http://www.netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO- 4.html#ss4.4 Sur les derniers kernels, la cible NETMAP est incluse de base. Je crains de ne pas l'avoir, le dernier kernel...
en tout cas, merci ! :)
Cedric Blancher
Le Tue, 19 Oct 2004 17:52:39 +0200, Laurent a écrit :
Sur les derniers kernels, la cible NETMAP est incluse de base. Je crains de ne pas l'avoir, le dernier kernel...
Ben alors sois tu trouves une distro qui va te filer un package kernel et une version de iptables contenant cette cible, genre Debian, soit tu recompiles un kernel dans la version que tu as en utilisant le patch-o-matic, ou alors un kernel suffisamment récent, et tu recompiles iptables derrière.
Après vérification, le noyau 2.6.5 de base possède cette cible, et la dernière version de iptables aussi. Donc voilà.
-- /* Nobody will ever see this message :-) */ panic("Cannot initialize video hardwaren"); 2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
Le Tue, 19 Oct 2004 17:52:39 +0200, Laurent a écrit :
Sur les derniers kernels, la cible NETMAP est incluse de base.
Je crains de ne pas l'avoir, le dernier kernel...
Ben alors sois tu trouves une distro qui va te filer un package kernel et
une version de iptables contenant cette cible, genre Debian, soit tu
recompiles un kernel dans la version que tu as en utilisant le
patch-o-matic, ou alors un kernel suffisamment récent, et tu recompiles
iptables derrière.
Après vérification, le noyau 2.6.5 de base possède cette cible, et la
dernière version de iptables aussi. Donc voilà.
--
/* Nobody will ever see this message :-) */
panic("Cannot initialize video hardwaren");
2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
Le Tue, 19 Oct 2004 17:52:39 +0200, Laurent a écrit :
Sur les derniers kernels, la cible NETMAP est incluse de base. Je crains de ne pas l'avoir, le dernier kernel...
Ben alors sois tu trouves une distro qui va te filer un package kernel et une version de iptables contenant cette cible, genre Debian, soit tu recompiles un kernel dans la version que tu as en utilisant le patch-o-matic, ou alors un kernel suffisamment récent, et tu recompiles iptables derrière.
Après vérification, le noyau 2.6.5 de base possède cette cible, et la dernière version de iptables aussi. Donc voilà.
-- /* Nobody will ever see this message :-) */ panic("Cannot initialize video hardwaren"); 2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
Pascal
Salut,
Cedric Blancher wrote:
Auriez vous des pistes de documentations spécifiques sur de la translations d'adresse une pour une avec iptable sous linux ?
Genre Netfilter NAT HOWTO ? Ou le Double NAT HOWTO ?
Le sujet m'ayant intéressé, j'avais déjà lu ces deux docs et n'avais rien vu dedans qui traite de NAT 1:1 par bloc. je les ai relus, et ne trouve toujours rien. Tu pourrais préciser dans quels paragraphes exactement il en est question ?
Salut,
Cedric Blancher wrote:
Auriez vous des pistes de documentations spécifiques sur de la
translations d'adresse une pour une avec iptable sous linux ?
Genre Netfilter NAT HOWTO ?
Ou le Double NAT HOWTO ?
Le sujet m'ayant intéressé, j'avais déjà lu ces deux docs et n'avais
rien vu dedans qui traite de NAT 1:1 par bloc. je les ai relus, et ne
trouve toujours rien. Tu pourrais préciser dans quels paragraphes
exactement il en est question ?
Auriez vous des pistes de documentations spécifiques sur de la translations d'adresse une pour une avec iptable sous linux ?
Genre Netfilter NAT HOWTO ? Ou le Double NAT HOWTO ?
Le sujet m'ayant intéressé, j'avais déjà lu ces deux docs et n'avais rien vu dedans qui traite de NAT 1:1 par bloc. je les ai relus, et ne trouve toujours rien. Tu pourrais préciser dans quels paragraphes exactement il en est question ?
Pierre LALET
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être translatés en 172.16.0.x/24 avec correspondance avec le dernier digit de l'adresse avant d'être routées.
Si tu n'as pas besoin de gestion d'état (ce qui est le cas dans ton exemple), je te conseille le routage avancé du noyau Linux (CONFIG_IP_ADVANCED_ROUTER), avec 'policy routing' (CONFIG_IP_MULTIPLE_TABLES) et le 'fast NAT' (CONFIG_IP_ROUTE_NAT).
Ca c'est pour le noyau, et l'outil userland qui permet de jouer avec est la commande 'ip' du package 'iproute2'.
J'ai découvert ce truc là (le routage avancé, pas juste le fast NAT) au cours de mon stage de deuxième année, et franchement, ça tue la mort ce truc.
Evidemment, tu peux utiliser en parallèle Netfilter/Iptables pour faire le filtrage (avec inspection d'état ou pas).
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être
translatés en 172.16.0.x/24 avec correspondance avec le dernier digit de
l'adresse avant d'être routées.
Si tu n'as pas besoin de gestion d'état (ce qui est le cas dans ton
exemple), je te conseille le routage avancé du noyau Linux
(CONFIG_IP_ADVANCED_ROUTER), avec 'policy routing'
(CONFIG_IP_MULTIPLE_TABLES) et le 'fast NAT' (CONFIG_IP_ROUTE_NAT).
Ca c'est pour le noyau, et l'outil userland qui permet de jouer avec est
la commande 'ip' du package 'iproute2'.
J'ai découvert ce truc là (le routage avancé, pas juste le fast NAT) au
cours de mon stage de deuxième année, et franchement, ça tue la mort ce
truc.
Evidemment, tu peux utiliser en parallèle Netfilter/Iptables pour faire
le filtrage (avec inspection d'état ou pas).
pierre
--
Pierre LALET
http://pierre.droids-corp.org/
Droids Corporation & Team rstack
French Honeynet Project
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être translatés en 172.16.0.x/24 avec correspondance avec le dernier digit de l'adresse avant d'être routées.
Si tu n'as pas besoin de gestion d'état (ce qui est le cas dans ton exemple), je te conseille le routage avancé du noyau Linux (CONFIG_IP_ADVANCED_ROUTER), avec 'policy routing' (CONFIG_IP_MULTIPLE_TABLES) et le 'fast NAT' (CONFIG_IP_ROUTE_NAT).
Ca c'est pour le noyau, et l'outil userland qui permet de jouer avec est la commande 'ip' du package 'iproute2'.
J'ai découvert ce truc là (le routage avancé, pas juste le fast NAT) au cours de mon stage de deuxième année, et franchement, ça tue la mort ce truc.
Evidemment, tu peux utiliser en parallèle Netfilter/Iptables pour faire le filtrage (avec inspection d'état ou pas).
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Pascal
Pierre LALET wrote:
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être translatés en 172.16.0.x/24 avec correspondance avec le dernier digit de l'adresse avant d'être routées.
Si tu n'as pas besoin de gestion d'état (ce qui est le cas dans ton exemple), je te conseille le routage avancé du noyau Linux (CONFIG_IP_ADVANCED_ROUTER), avec 'policy routing' (CONFIG_IP_MULTIPLE_TABLES) et le 'fast NAT' (CONFIG_IP_ROUTE_NAT).
Ca c'est pour le noyau, et l'outil userland qui permet de jouer avec est la commande 'ip' du package 'iproute2'.
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule) NAT source pour l'aller et une route NAT destination pour le retour (sans quoi la règle aller n'a pas l'air de fonctionner).
Exemple simplifié dans le cas exposé : # 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
Pierre LALET wrote:
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être
translatés en 172.16.0.x/24 avec correspondance avec le dernier digit
de l'adresse avant d'être routées.
Si tu n'as pas besoin de gestion d'état (ce qui est le cas dans ton
exemple), je te conseille le routage avancé du noyau Linux
(CONFIG_IP_ADVANCED_ROUTER), avec 'policy routing'
(CONFIG_IP_MULTIPLE_TABLES) et le 'fast NAT' (CONFIG_IP_ROUTE_NAT).
Ca c'est pour le noyau, et l'outil userland qui permet de jouer avec est
la commande 'ip' du package 'iproute2'.
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher
avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule)
NAT source pour l'aller et une route NAT destination pour le retour
(sans quoi la règle aller n'a pas l'air de fonctionner).
Exemple simplifié dans le cas exposé :
# 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
par exemple : toutes les adresses sources 192.168.0.x/24 doivent être translatés en 172.16.0.x/24 avec correspondance avec le dernier digit de l'adresse avant d'être routées.
Si tu n'as pas besoin de gestion d'état (ce qui est le cas dans ton exemple), je te conseille le routage avancé du noyau Linux (CONFIG_IP_ADVANCED_ROUTER), avec 'policy routing' (CONFIG_IP_MULTIPLE_TABLES) et le 'fast NAT' (CONFIG_IP_ROUTE_NAT).
Ca c'est pour le noyau, et l'outil userland qui permet de jouer avec est la commande 'ip' du package 'iproute2'.
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule) NAT source pour l'aller et une route NAT destination pour le retour (sans quoi la règle aller n'a pas l'air de fonctionner).
Exemple simplifié dans le cas exposé : # 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
Cedric Blancher
Le Tue, 19 Oct 2004 20:33:05 +0200, a écrit :
Genre Netfilter NAT HOWTO ? Ou le Double NAT HOWTO ? Le sujet m'ayant intéressé, j'avais déjà lu ces deux docs et n'avais
rien vu dedans qui traite de NAT 1:1 par bloc. je les ai relus, et ne trouve toujours rien. Tu pourrais préciser dans quels paragraphes exactement il en est question ?
Tu fais un concours de mauvaise foi là ? :)))
Déjà, d'une part, on ne parle pas encore de bloc. On parle de NAT 1-1, relis la citation que je fais.Mais je t'accorde que, effectivement, il est vrai qu'il ne doit pas y avoir un exemple de NAT 1-1. Mais maintenant, vous avez le droit d'utiliser votre cerveau quand vous lisez un document.
En gros, dans ces HOWTO, vous aller trouvez :
1. Comment nater une IP (ou plage d'IP) en source ou en destination 2. Quelle IP mettre à la place de la source ou de la destination
Maintenant, si les gens ne sont pas capables de faire le lien entre les deux pour faire un NAT 1-1, franchement, la lecture qu'ils ont des HOWTOs doit être bien bête et méchante. Genre "c'est pas en exemple dans les HOWTO, donc je fais pas"...
Dans les chapitres NAT de source et NAT de destination, on voit comment configurer l'adresse de remplacement :
-- [à propos de discussions de traduction] Dans ce cas, pourquoi ne pas adopter également : brouter = bouter sur la racine. -+- DC sur debian-french: "boutons le gnou anglois hors de France!" -+-
Le Tue, 19 Oct 2004 20:33:05 +0200, Pascal@plouf a écrit :
Genre Netfilter NAT HOWTO ?
Ou le Double NAT HOWTO ?
Le sujet m'ayant intéressé, j'avais déjà lu ces deux docs et n'avais
rien vu dedans qui traite de NAT 1:1 par bloc. je les ai relus, et ne
trouve toujours rien. Tu pourrais préciser dans quels paragraphes
exactement il en est question ?
Tu fais un concours de mauvaise foi là ? :)))
Déjà, d'une part, on ne parle pas encore de bloc. On parle de NAT 1-1,
relis la citation que je fais.Mais je t'accorde que, effectivement, il est
vrai qu'il ne doit pas y avoir un exemple de NAT 1-1. Mais maintenant,
vous avez le droit d'utiliser votre cerveau quand vous lisez un document.
En gros, dans ces HOWTO, vous aller trouvez :
1. Comment nater une IP (ou plage d'IP) en source ou en destination
2. Quelle IP mettre à la place de la source ou de la destination
Maintenant, si les gens ne sont pas capables de faire le lien entre les
deux pour faire un NAT 1-1, franchement, la lecture qu'ils ont des
HOWTOs doit être bien bête et méchante. Genre "c'est pas en exemple
dans les HOWTO, donc je fais pas"...
Dans les chapitres NAT de source et NAT de destination, on voit comment
configurer l'adresse de remplacement :
--
[à propos de discussions de traduction]
Dans ce cas, pourquoi ne pas adopter également :
brouter = bouter sur la racine.
-+- DC sur debian-french: "boutons le gnou anglois hors de France!" -+-
Genre Netfilter NAT HOWTO ? Ou le Double NAT HOWTO ? Le sujet m'ayant intéressé, j'avais déjà lu ces deux docs et n'avais
rien vu dedans qui traite de NAT 1:1 par bloc. je les ai relus, et ne trouve toujours rien. Tu pourrais préciser dans quels paragraphes exactement il en est question ?
Tu fais un concours de mauvaise foi là ? :)))
Déjà, d'une part, on ne parle pas encore de bloc. On parle de NAT 1-1, relis la citation que je fais.Mais je t'accorde que, effectivement, il est vrai qu'il ne doit pas y avoir un exemple de NAT 1-1. Mais maintenant, vous avez le droit d'utiliser votre cerveau quand vous lisez un document.
En gros, dans ces HOWTO, vous aller trouvez :
1. Comment nater une IP (ou plage d'IP) en source ou en destination 2. Quelle IP mettre à la place de la source ou de la destination
Maintenant, si les gens ne sont pas capables de faire le lien entre les deux pour faire un NAT 1-1, franchement, la lecture qu'ils ont des HOWTOs doit être bien bête et méchante. Genre "c'est pas en exemple dans les HOWTO, donc je fais pas"...
Dans les chapitres NAT de source et NAT de destination, on voit comment configurer l'adresse de remplacement :
-- [à propos de discussions de traduction] Dans ce cas, pourquoi ne pas adopter également : brouter = bouter sur la racine. -+- DC sur debian-french: "boutons le gnou anglois hors de France!" -+-
Pierre LALET
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule) NAT source pour l'aller et une route NAT destination pour le retour (sans quoi la règle aller n'a pas l'air de fonctionner).
Je pense que tu n'as pas vraiment compris, ce sont deux commandes *très* différentes, c'est pas une pour l'aller une pour le retour, mais une règle et une route. La doc explique assez bien ça, il me semble (c'est loin tout ça).
Exemple simplifié dans le cas exposé : # 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
Voilà. Donc inutile de sortir l'arsenal iptables/netfilter pour des trucs comme ça.
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher
avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule)
NAT source pour l'aller et une route NAT destination pour le retour
(sans quoi la règle aller n'a pas l'air de fonctionner).
Je pense que tu n'as pas vraiment compris, ce sont deux commandes *très*
différentes, c'est pas une pour l'aller une pour le retour, mais une
règle et une route. La doc explique assez bien ça, il me semble (c'est
loin tout ça).
Exemple simplifié dans le cas exposé :
# 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
Voilà. Donc inutile de sortir l'arsenal iptables/netfilter pour des
trucs comme ça.
pierre
--
Pierre LALET
http://pierre.droids-corp.org/
Droids Corporation & Team rstack
French Honeynet Project
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule) NAT source pour l'aller et une route NAT destination pour le retour (sans quoi la règle aller n'a pas l'air de fonctionner).
Je pense que tu n'as pas vraiment compris, ce sont deux commandes *très* différentes, c'est pas une pour l'aller une pour le retour, mais une règle et une route. La doc explique assez bien ça, il me semble (c'est loin tout ça).
Exemple simplifié dans le cas exposé : # 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
Voilà. Donc inutile de sortir l'arsenal iptables/netfilter pour des trucs comme ça.
pierre
-- Pierre LALET http://pierre.droids-corp.org/ Droids Corporation & Team rstack French Honeynet Project
Cedric Blancher
Le Tue, 19 Oct 2004 23:29:07 +0200, a écrit :
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule) NAT source pour l'aller et une route NAT destination pour le retour (sans quoi la règle aller n'a pas l'air de fonctionner).
Ben si elle fonctionne. Mais comme il n'y a pas de règle pour remettre les adresses en place au retour, ça ne marche pas... Ce NAT est basé sur le routage et donc agit paquet par paquet, sans aucune notion d'état. Le système n'est donc pas capable d'associer un paquet de retour à un paquet précédemment émis (ce qui n'est pas le cas avec Netfilter).
Ceci dit, est-ce que tu es bien sûr que ça fait du 1-1 par bloc ? Genre si 192.168.0.15 se connecte, est-ce qu'elle va bien avoir 172.16.0.15, et non une IP consécutive à l'IP natée précédemment ?
NB : ce type de NAT semble poser pleins de problèmes avec les 2.6 et vient d'être retiré (en 2.6.9-rc1)
-- MS> A quand une hiérachie alternative en langue française?? SP> Quand vous aurez lancé les messages de contrôle idoines. MS> Je les connais pas ? Peut-tu les publié ici même? -+- MS in GNU : Mon neuneu est un aaaaartiste -+-
Le Tue, 19 Oct 2004 23:29:07 +0200, Pascal@plouf a écrit :
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher
avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule)
NAT source pour l'aller et une route NAT destination pour le retour
(sans quoi la règle aller n'a pas l'air de fonctionner).
Ben si elle fonctionne. Mais comme il n'y a pas de règle pour remettre
les adresses en place au retour, ça ne marche pas... Ce NAT est basé sur
le routage et donc agit paquet par paquet, sans aucune notion d'état. Le
système n'est donc pas capable d'associer un paquet de retour à un
paquet précédemment émis (ce qui n'est pas le cas avec Netfilter).
Ceci dit, est-ce que tu es bien sûr que ça fait du 1-1 par bloc ? Genre
si 192.168.0.15 se connecte, est-ce qu'elle va bien avoir 172.16.0.15, et
non une IP consécutive à l'IP natée précédemment ?
NB : ce type de NAT semble poser pleins de problèmes avec les 2.6 et
vient d'être retiré (en 2.6.9-rc1)
--
MS> A quand une hiérachie alternative en langue française??
SP> Quand vous aurez lancé les messages de contrôle idoines.
MS> Je les connais pas ? Peut-tu les publié ici même?
-+- MS in GNU : Mon neuneu est un aaaaartiste -+-
Vi. Si on a déjà toutes ces options dans le noyau, ça évite de patcher avec NETMAP et de recompiler. Pour faire court, il faut une règle (rule) NAT source pour l'aller et une route NAT destination pour le retour (sans quoi la règle aller n'a pas l'air de fonctionner).
Ben si elle fonctionne. Mais comme il n'y a pas de règle pour remettre les adresses en place au retour, ça ne marche pas... Ce NAT est basé sur le routage et donc agit paquet par paquet, sans aucune notion d'état. Le système n'est donc pas capable d'associer un paquet de retour à un paquet précédemment émis (ce qui n'est pas le cas avec Netfilter).
Ceci dit, est-ce que tu es bien sûr que ça fait du 1-1 par bloc ? Genre si 192.168.0.15 se connecte, est-ce qu'elle va bien avoir 172.16.0.15, et non une IP consécutive à l'IP natée précédemment ?
NB : ce type de NAT semble poser pleins de problèmes avec les 2.6 et vient d'être retiré (en 2.6.9-rc1)
-- MS> A quand une hiérachie alternative en langue française?? SP> Quand vous aurez lancé les messages de contrôle idoines. MS> Je les connais pas ? Peut-tu les publié ici même? -+- MS in GNU : Mon neuneu est un aaaaartiste -+-
Cedric Blancher
Le Tue, 19 Oct 2004 23:49:27 +0200, Pierre LALET a écrit :
Je pense que tu n'as pas vraiment compris, ce sont deux commandes *très* différentes, c'est pas une pour l'aller une pour le retour, mais une règle et une route. La doc explique assez bien ça, il me semble (c'est loin tout ça).
Grosso modo, ça revient au même.
La première fait le NAT source, mais la seconde dit de router le réseau à travers une règle de NAT en donnant sa destination. La différence syntaxique est réelle, mais sémantiquement...
-- Actuellement des cobayes humains se font implantés des puces électroniques sous la peau,le but faire disparaître l'humain trop primitif dans une décennie... -+-M in Guide du Neunu d'Usenet: Et pour le neuneu, rien de prévu ?-+-
Le Tue, 19 Oct 2004 23:49:27 +0200, Pierre LALET a écrit :
Je pense que tu n'as pas vraiment compris, ce sont deux commandes *très*
différentes, c'est pas une pour l'aller une pour le retour, mais une
règle et une route. La doc explique assez bien ça, il me semble (c'est
loin tout ça).
Grosso modo, ça revient au même.
La première fait le NAT source, mais la seconde dit de router le réseau
à travers une règle de NAT en donnant sa destination. La différence
syntaxique est réelle, mais sémantiquement...
--
Actuellement des cobayes humains se font implantés des puces
électroniques sous la peau,le but faire disparaître l'humain trop
primitif dans une décennie...
-+-M in Guide du Neunu d'Usenet: Et pour le neuneu, rien de prévu ?-+-
Le Tue, 19 Oct 2004 23:49:27 +0200, Pierre LALET a écrit :
Je pense que tu n'as pas vraiment compris, ce sont deux commandes *très* différentes, c'est pas une pour l'aller une pour le retour, mais une règle et une route. La doc explique assez bien ça, il me semble (c'est loin tout ça).
Grosso modo, ça revient au même.
La première fait le NAT source, mais la seconde dit de router le réseau à travers une règle de NAT en donnant sa destination. La différence syntaxique est réelle, mais sémantiquement...
-- Actuellement des cobayes humains se font implantés des puces électroniques sous la peau,le but faire disparaître l'humain trop primitif dans une décennie... -+-M in Guide du Neunu d'Usenet: Et pour le neuneu, rien de prévu ?-+-
