Bonjour,

Je sais que mon poste n'est pas relatif a debian, mais en desespoir de
cause....

J'ai aquit un WRT54GL et l'ai flashé en dd'wrt, donc en linux.
Iptables tourne dessus.

Plan reseau:
WWW ----- WRT54GL ---- LAN

Sur mon reseau LAN, j'ai installé un serveur DNS pour mon reseau local, ca
fonctionne bien. Ce dns gerre aussi mon domaine sur internet.
Il me faut donc rediriger toutes les requette qui viennent d'internet sur le
port 53 vers mon serveur DNS interne, et que ce dns interne renvois la
reponse à son expediteur sur le net.

J'ai donc placé une regle PREROUTING qui DNAT mon port:

$IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT
$IPTABLES -t nat -A PREROUTING -p udp -d $IP_WAN --dport 53 -j DNAT
--to-destination $MOE:53

Ca ne marche pas. J'ai fait pareil avec le port 80 tcp pour ecarter une
erreur de mon dns.
J'ai donc essayé ca (53 et 80):
$IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT
$IPTABLES -t nat -A PREROUTING -p udp -i $IP_WAN --dport 53 -j DNAT
--to-destination $MOE:53

Idem, aucun resultat.
Je precise que par defaut, j'ai INPUT OUTPUT FORWARD a ACCEPT

Du coup, je vois pas trop comment faire pour que mon serveur MOE soit
accessible depuis internet sur ses port 53 et 80.
J'ai essayé d'autres solutions trouvées sur le net, et aucuns resultats.. En
bref, je suis en train de m'arracher les cheuveux depuis 3 jours...

merci d'avance pour toute piste ou solution.

Le poulpe qui bloppe ! a écrit :
> Bonjour,
>
> Je sais que mon poste n'est pas relatif a debian, mais en desespoir de
> cause....
>
> J'ai aquit un WRT54GL et l'ai flashé en dd'wrt, donc en linux.
> Iptables tourne dessus.
>
> Plan reseau:
> WWW ----- WRT54GL ---- LAN
>
> Sur mon reseau LAN, j'ai installé un serveur DNS pour mon reseau local,
> ca fonctionne bien. Ce dns gerre aussi mon domaine sur internet.
> Il me faut donc rediriger toutes les requette qui viennent d'internet
> sur le port 53 vers mon serveur DNS interne, et que ce dns interne
> renvois la reponse à son expediteur sur le net.
>
> J'ai donc placé une regle PREROUTING qui DNAT mon port:
>
> $IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT
> $IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT
> $IPTABLES -t nat -A PREROUTING -p udp -d $IP_WAN --dport 53 -j DNAT
> --to-destination $MOE:53

ne serais-ce pas plutôt:
(avec WEB_IF=eth0 & LAN_IF=192.168.1.0/24 par ex.)

$IPTABLES -t nat -A FORWARD -i $WEB_IF -p UDP -d $DNS_HOST \
--dport 53 -j ACCEPT

$IPTABLES -t nat -A PREROUTING -i $WEB_IF -p UDP --dport 53 \
-j DNAT --to-dest $DNS_HOST

$IPTABLES -t nat -A POSTROUTING -o $LAN_IF -p UDP -d $DNS_HOST \
--dport 53 -j ACCEPT


Par principe, je n'aime pas les règles qui ne font pas explicitement
référence aux I/Fs concernées, ça peut toujours donner des effetsnon-
désirés.

> Idem, aucun resultat.
> Je precise que par defaut, j'ai INPUT OUTPUT FORWARD a ACCEPT

Y'a pas pire comme policy!

Commence par remettre tout à DENY, puis ouvre les "trous" voulus.

En matière de sécurité il est plus que logique de commencer par
tout interdire, puis d'ouvrir les portes une par une; sinon ne
t'étonne pas s'il t'arrive des misères.

JY
--
Breeding rabbits is a hare raising experience.

Le poulpe qui bloppe ! a écrit :
> Bonjour,
>
> Je sais que mon poste n'est pas relatif a debian, mais en desespoir de
> cause....
>
> J'ai aquit un WRT54GL et l'ai flashé en dd'wrt, donc en linux.
> Iptables tourne dessus.
>
> Plan reseau:
> WWW ----- WRT54GL ---- LAN
>
> Sur mon reseau LAN, j'ai installé un serveur DNS pour mon reseau local,
> ca fonctionne bien. Ce dns gerre aussi mon domaine sur internet.
> Il me faut donc rediriger toutes les requette qui viennent d'internet
> sur le port 53 vers mon serveur DNS interne, et que ce dns interne
> renvois la reponse à son expediteur sur le net.
>
> J'ai donc placé une regle PREROUTING qui DNAT mon port:
>
> $IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT
> $IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT
> $IPTABLES -t nat -A PREROUTING -p udp -d $IP_WAN --dport 53 -j DNAT
> --to-destination $MOE:53

ne serais-ce pas plutôt:
(avec WEB_IF=eth0 & LAN_IF=192.168.1.0/24 par ex.)

$IPTABLES -t nat -A FORWARD -i $WEB_IF -p UDP -d $DNS_HOST \
--dport 53 -j ACCEPT

$IPTABLES -t nat -A PREROUTING -i $WEB_IF -p UDP --dport 53 \
-j DNAT --to-dest $DNS_HOST

$IPTABLES -t nat -A POSTROUTING -o $LAN_IF -p UDP -d $DNS_HOST \
--dport 53 -j ACCEPT


Par principe, je n'aime pas les règles qui ne font pas explicitement
référence aux I/Fs concernées, ça peut toujours donner des effetsnon-
désirés.

> Idem, aucun resultat.
> Je precise que par defaut, j'ai INPUT OUTPUT FORWARD a ACCEPT

Y'a pas pire comme policy!

Commence par remettre tout à DENY, puis ouvre les "trous" voulus.

En matière de sécurité il est plus que logique de commencer par
tout interdire, puis d'ouvrir les portes une par une; sinon ne
t'étonne pas s'il t'arrive des misères.

JY
--
Breeding rabbits is a hare raising experience.

Scribit Le poulpe qui bloppe ! dies 02/04/2007 hora 16:17:
> J'ai donc placé une regle PREROUTING qui DNAT mon port:
>
> $IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT
> $IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT

Tu dis que la politique par défaut est ACCEPT, alors pourquoi ces
lignesÂ?

> $IPTABLES -t nat -A PREROUTING -p udp -d $IP_WAN --dport 53 -j DNAT
> --to-destination $MOE:53
>
> Ca ne marche pas.

Question bêteÂ: qu'est-ce qui te fait dire que ça ne marche pasÂ? En
d'autres termes, comment testes-tu et quels sont les symptômes�

Il m'est déjà arrivé, par exemple, qu'un problème de routage fasse que
tester l'IP externe ne marche pas depuis l'intérieur, mais fort bien de
l'extérieur...

Brièvement,
Pierre
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGERfQxe13INnVDYoRArnvAKCTeP31J9U7k0JaB0aajS dG4A9gsgCg1F87
3H6gfqytLPOtgfrtw29bX9k=
=eG59
-----END PGP SIGNATURE-----

Scribit Le poulpe qui bloppe ! dies 02/04/2007 hora 16:17:
> J'ai donc placé une regle PREROUTING qui DNAT mon port:
>
> $IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT
> $IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT

Tu dis que la politique par défaut est ACCEPT, alors pourquoi ces
lignesÂ?

> $IPTABLES -t nat -A PREROUTING -p udp -d $IP_WAN --dport 53 -j DNAT
> --to-destination $MOE:53
>
> Ca ne marche pas.

Question bêteÂ: qu'est-ce qui te fait dire que ça ne marche pasÂ? En
d'autres termes, comment testes-tu et quels sont les symptômes�

Il m'est déjà arrivé, par exemple, qu'un problème de routage fasse que
tester l'IP externe ne marche pas depuis l'intérieur, mais fort bien de
l'extérieur...

Brièvement,
Pierre
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGERfQxe13INnVDYoRArnvAKCTeP31J9U7k0JaB0aajS dG4A9gsgCg1F87
3H6gfqytLPOtgfrtw29bX9k=
=eG59
-----END PGP SIGNATURE-----

OOPS: LAN_IF=eth1

--
BOFH excuse #401:

Sales staff sold a product we don't offer.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

OOPS: LAN_IF=eth1

--
BOFH excuse #401:

Sales staff sold a product we don't offer.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

>Question bête: qu'est-ce qui te fait dire que ça ne marche pas? En
>d'autres termes, comment testes-tu et quels sont les symptômes?

Ce qui me fait dire que ca ne marche pas, c'est que dnsstuff.com me dit que
mon serveur ne reponds pas, que mes secondaires ne syncronisent pas.
Pour tester, afin d'eviter les erreurs interne/externe, je me conecte en ssh
sur la machine d'un collegue, et je teste dpuis sa machine. Il ne peux pas
afficher mon site web, ni attrapper le dns, je ne peux meme pas me telnet
sur les ports 53 et 80.
Les symptomes sonts simples, rien reponds, j'eteindrait ma connexion, ca
reviendrais au meme.


>En matière de sécurité il est plus que logique de commencer par
>tout interdire, puis d'ouvrir les portes une par une; sinon ne
>t'étonne pas s'il t'arrive des misères.

Je suis habituellement sur DROP partout, mais vu que rien ne marche, je
prefere tester avec tout ouvert, et quand ca marchera, je remettrait a drop
et verifierais que ca fonctionne a drop.

Vos regles m'ont l'air tout a fait correct mais ca ne marche pas.

Voici mon script à l'heure actuelle: http://fyxx.free.fr/001iptables.txt

>Question bête: qu'est-ce qui te fait dire que ça ne marche pas? En
>d'autres termes, comment testes-tu et quels sont les symptômes?

Ce qui me fait dire que ca ne marche pas, c'est que dnsstuff.com me dit que
mon serveur ne reponds pas, que mes secondaires ne syncronisent pas.
Pour tester, afin d'eviter les erreurs interne/externe, je me conecte en ssh
sur la machine d'un collegue, et je teste dpuis sa machine. Il ne peux pas
afficher mon site web, ni attrapper le dns, je ne peux meme pas me telnet
sur les ports 53 et 80.
Les symptomes sonts simples, rien reponds, j'eteindrait ma connexion, ca
reviendrais au meme.


>En matière de sécurité il est plus que logique de commencer par
>tout interdire, puis d'ouvrir les portes une par une; sinon ne
>t'étonne pas s'il t'arrive des misères.

Je suis habituellement sur DROP partout, mais vu que rien ne marche, je
prefere tester avec tout ouvert, et quand ca marchera, je remettrait a drop
et verifierais que ca fonctionne a drop.

Vos regles m'ont l'air tout a fait correct mais ca ne marche pas.

Voici mon script à l'heure actuelle: http://fyxx.free.fr/001iptables.txt

Bonjour,

Le Lundi 02 Avril 2007 17:17, Le poulpe qui bloppe ! a écrit:
> Voici mon script à l'heure actuelle: http://fyxx.free.fr/001iptables.txt

Au vu du script, il me semble que la réponse de votre dns est détournée par
la règle de masquerading
$IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE

Généralement, l'emploi de la cible LOG avec des --log-prefix avec un préfixe
différent pour chaque chaine/table est pratique (à mon avis) pour définir
ou ça coince.

mes 0,02¤
--
Serge

Bonjour,

Le Lundi 02 Avril 2007 17:17, Le poulpe qui bloppe ! a écrit:
> Voici mon script à l'heure actuelle: http://fyxx.free.fr/001iptables.txt

Au vu du script, il me semble que la réponse de votre dns est détournée par
la règle de masquerading
$IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE

Généralement, l'emploi de la cible LOG avec des --log-prefix avec un préfixe
différent pour chaque chaine/table est pratique (à mon avis) pour définir
ou ça coince.

mes 0,02¤
--
Serge

Scribit Le poulpe qui bloppe ! dies 02/04/2007 hora 18:10:
> Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc
> mais un routeur avec micronoyau linux.

Nota beneÂ:

- un PC peut être un tout petit engin avec très peu de place, ce qui
fait que c'est un PC ou non est son architecture matérielle
- il n'existe pas de micronoyau linux

> Et la seule memoire est une microflash et il ne me reste que tres tres
> peu de place.

Tu auras quand même intérêt à logger un certain nombre de choses, donc
tu n'as qu'à utiliser syslog en réseauÂ: tous les logs sont directement
envoyés à un démon syslog sur une autre machine.

C'est même une contre-mesure classique contre le camouflage d'un
piratage, parce que le pirate, même s'il a pris le contrôle de la
machine, ne peut pas effacer les traces de ce qui s'est passé pendant le
piratage. C'est ainsi qu'un piratage avait été détecté sur des serveurs
du projet Debian, il y a quelques temps...

Brièvement,
Pierre
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGESyExe13INnVDYoRAiNeAJoC8wyIrk+REC4plwXy2E y7wDktAgCg/vP2
QUsIQzt08P2nWjEjFBqMAWQ=
=/+Eg
-----END PGP SIGNATURE-----

Scribit Le poulpe qui bloppe ! dies 02/04/2007 hora 18:10:
> Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc
> mais un routeur avec micronoyau linux.

Nota beneÂ:

- un PC peut être un tout petit engin avec très peu de place, ce qui
fait que c'est un PC ou non est son architecture matérielle
- il n'existe pas de micronoyau linux

> Et la seule memoire est une microflash et il ne me reste que tres tres
> peu de place.

Tu auras quand même intérêt à logger un certain nombre de choses, donc
tu n'as qu'à utiliser syslog en réseauÂ: tous les logs sont directement
envoyés à un démon syslog sur une autre machine.

C'est même une contre-mesure classique contre le camouflage d'un
piratage, parce que le pirate, même s'il a pris le contrôle de la
machine, ne peut pas effacer les traces de ce qui s'est passé pendant le
piratage. C'est ainsi qu'un piratage avait été détecté sur des serveurs
du projet Debian, il y a quelques temps...

Brièvement,
Pierre
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGESyExe13INnVDYoRAiNeAJoC8wyIrk+REC4plwXy2E y7wDktAgCg/vP2
QUsIQzt08P2nWjEjFBqMAWQ=
=/+Eg
-----END PGP SIGNATURE-----

>
>
> Généralement, l'emploi de la cible LOG avec des --log-prefix avec un
> préfixe
> différent pour chaque chaine/table est pratique (à mon avis) pour définir
> ou ça coince.
>

Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc mais
un routeur avec micronoyau linux. Et la seule memoire est une microflash et
il ne me reste que tres tres peu de place.

Mais j'ai trouvé le probleme.
Mon script commence par #!/bin/bash, et apparemment, le linux embarqué nele
supporte pas.
En mettant #!/bin/sh à la place, le script est bien pris en compte, et il
marche bien, donc je vous remercie beaucoup de votre aide.

>
>
> Généralement, l'emploi de la cible LOG avec des --log-prefix avec un
> préfixe
> différent pour chaque chaine/table est pratique (à mon avis) pour définir
> ou ça coince.
>

Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc mais
un routeur avec micronoyau linux. Et la seule memoire est une microflash et
il ne me reste que tres tres peu de place.

Mais j'ai trouvé le probleme.
Mon script commence par #!/bin/bash, et apparemment, le linux embarqué nele
supporte pas.
En mettant #!/bin/sh à la place, le script est bien pris en compte, et il
marche bien, donc je vous remercie beaucoup de votre aide.

Salut,

Serge Cavailles a écrit :
>
> Au vu du script, il me semble que la réponse de votre dns est détournée par
> la règle de masquerading
> $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE

Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les
chaînes de la table 'nat'. Ils sont traités implicitement en fonction
des opérations de NAT appliquées au premier paquet de la connexion.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Salut,

Serge Cavailles a écrit :
>
> Au vu du script, il me semble que la réponse de votre dns est détournée par
> la règle de masquerading
> $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE

Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les
chaînes de la table 'nat'. Ils sont traités implicitement en fonction
des opérations de NAT appliquées au premier paquet de la connexion.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le poulpe qui bloppe ! a écrit :
>
> Voici mon script à l'heure actuelle: http://fyxx.free.fr/001iptables.txt

> $IPTABLES -t nat -A FORWARD -i $IF_LAN -p tcp -d $MOE --dport 53 -j ACCEPT

1) Il n'y a pas de chaîne FORWARD dans la table 'nat'. Une coquille, je
suppose.

2) Si je lis bien, cette règle est censée accepter les paquets entrant
par l'interface LAN destinés au serveur local. Autant dire qu'elle ne
doit pas accepter grand chose venant de l'extérieur.

> $IPTABLES -t nat -A PREROUTING -i $IF_WAN -p tcp --dport 53 -j DNAT --to-dest $MOE
> $IPTABLES -t nat -A POSTROUTING -o $IF_LAN -p tcp -d $MOE --dport 53 -j ACCEPT

2) C'est quoi le but de la règle ACCEPT dans la chaîne nat/POSTROUTING,
sachant que la politique par défaut des chaînes de la table 'nat' est
normalement déjà ACCEPT ?

> #################### Masquerading ####################
> ################################################## ###################
> ##### Seul les PC de confience
> $IPTABLES -t nat -A POSTROUTING -s $SMITHERS -o $IF_WAN -j MASQUERADE
> $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
[...]

On ne fait pas de filtrage avec la table 'nat'. Si on veut empêcher des
postes de sortir, on bloque avec DROP ou REJECT dans la chaîne
filter/FORWARD. Tel quel, ça pollue internet en laissant sortir des
paquets avec leurs adresses source privées originales.


Accessoirement, où est le traitement des paquets retour ? Pas étonnant
que plus rien ne marche avec les politiques par défaut à DROP.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le poulpe qui bloppe ! a écrit :
>
> Voici mon script à l'heure actuelle: http://fyxx.free.fr/001iptables.txt

> $IPTABLES -t nat -A FORWARD -i $IF_LAN -p tcp -d $MOE --dport 53 -j ACCEPT

1) Il n'y a pas de chaîne FORWARD dans la table 'nat'. Une coquille, je
suppose.

2) Si je lis bien, cette règle est censée accepter les paquets entrant
par l'interface LAN destinés au serveur local. Autant dire qu'elle ne
doit pas accepter grand chose venant de l'extérieur.

> $IPTABLES -t nat -A PREROUTING -i $IF_WAN -p tcp --dport 53 -j DNAT --to-dest $MOE
> $IPTABLES -t nat -A POSTROUTING -o $IF_LAN -p tcp -d $MOE --dport 53 -j ACCEPT

2) C'est quoi le but de la règle ACCEPT dans la chaîne nat/POSTROUTING,
sachant que la politique par défaut des chaînes de la table 'nat' est
normalement déjà ACCEPT ?

> #################### Masquerading ####################
> ################################################## ###################
> ##### Seul les PC de confience
> $IPTABLES -t nat -A POSTROUTING -s $SMITHERS -o $IF_WAN -j MASQUERADE
> $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
[...]

On ne fait pas de filtrage avec la table 'nat'. Si on veut empêcher des
postes de sortir, on bloque avec DROP ou REJECT dans la chaîne
filter/FORWARD. Tel quel, ça pollue internet en laissant sortir des
paquets avec leurs adresses source privées originales.


Accessoirement, où est le traitement des paquets retour ? Pas étonnant
que plus rien ne marche avec les politiques par défaut à DROP.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le Lundi 02 Avril 2007 19:16, Pascal Hambourg a écrit:
> Salut,
Bonjour,

> Serge Cavailles a écrit :
> > Au vu du script, il me semble que la réponse de votre dns est détournée
> > par la règle de masquerading
> > $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
>
> Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les
> chaînes de la table 'nat'. Ils sont traités implicitement en fonction
> des opérations de NAT appliquées au premier paquet de la connexion.

Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne
pense pas qu'il puisse y avoir de paquets ESTABLISHED.

Mais je peux me tromper, je l'ai déjà prouvé

--
Serge

Le Lundi 02 Avril 2007 19:16, Pascal Hambourg a écrit:
> Salut,
Bonjour,

> Serge Cavailles a écrit :
> > Au vu du script, il me semble que la réponse de votre dns est détournée
> > par la règle de masquerading
> > $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
>
> Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les
> chaînes de la table 'nat'. Ils sont traités implicitement en fonction
> des opérations de NAT appliquées au premier paquet de la connexion.

Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne
pense pas qu'il puisse y avoir de paquets ESTABLISHED.

Mais je peux me tromper, je l'ai déjà prouvé

--
Serge

Serge Cavailles a écrit :
> Le Lundi 02 Avril 2007 19:16, Pascal Hambourg a écrit :
>> Salut,
> Bonjour,
>
>> Serge Cavailles a écrit :
>>> Au vu du script, il me semble que la réponse de votre dns est détournée
>>> par la règle de masquerading
>>> $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
>> Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pasles
>> chaînes de la table 'nat'. Ils sont traités implicitement en fonction
>> des opérations de NAT appliquées au premier paquet de la connexion.
>
> Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne
> pense pas qu'il puisse y avoir de paquets ESTABLISHED.
>
> Mais je peux me tromper, je l'ai déjà prouvé

Vi, tu te trompes: si la réponse à la requête dépasse 512 byte, la
réponse sera systématiquement en TCP et pas en UDP:

http://www.secuobs.com/plugs/18356.shtml


--
You can see that there are 25 unread articles in `news.announce.newusers'.
There are no unread articles, but some ticked articles, in
`alt.fan.andrea-dworkin' (see that little asterisk at the beginning of the
line?)
You can fuck that up to your heart's delight by fiddling with the
`gnus-group-line-format' variable.
-- From the (ding) Gnus 5 documentation, by Lars Magne Ingebrigtsen

Serge Cavailles a écrit :
> Le Lundi 02 Avril 2007 19:16, Pascal Hambourg a écrit :
>> Salut,
> Bonjour,
>
>> Serge Cavailles a écrit :
>>> Au vu du script, il me semble que la réponse de votre dns est détournée
>>> par la règle de masquerading
>>> $IPTABLES -t nat -A POSTROUTING -s $MOE -o $IF_WAN -j MASQUERADE
>> Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pasles
>> chaînes de la table 'nat'. Ils sont traités implicitement en fonction
>> des opérations de NAT appliquées au premier paquet de la connexion.
>
> Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne
> pense pas qu'il puisse y avoir de paquets ESTABLISHED.
>
> Mais je peux me tromper, je l'ai déjà prouvé

Vi, tu te trompes: si la réponse à la requête dépasse 512 byte, la
réponse sera systématiquement en TCP et pas en UDP:

http://www.secuobs.com/plugs/18356.shtml


--
You can see that there are 25 unread articles in `news.announce.newusers'.
There are no unread articles, but some ticked articles, in
`alt.fan.andrea-dworkin' (see that little asterisk at the beginning of the
line?)
You can fuck that up to your heart's delight by fiddling with the
`gnus-group-line-format' variable.
-- From the (ding) Gnus 5 documentation, by Lars Magne Ingebrigtsen

Serge Cavailles a écrit :
>>
>>Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les
>>chaînes de la table 'nat'. Ils sont traités implicitement en fonction
>>des opérations de NAT appliquées au premier paquet de la connexion.
>
> Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne
> pense pas qu'il puisse y avoir de paquets ESTABLISHED.

C'est pareil en UDP et n'importe quel autre protocole IP du moment que
le suivi de connexion peut identifier un paquet comme une réponse à un
autre paquet qu'il a déjà vu passer. La notion de "connexion" de
Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par
ses adresses source et destination, protocole, ports source et
destination (si applicables)... Exemples en dehors de TCP :
- ICMP echo request et l'echo reply correspondant
- requête DNS en UDP et la réponse correspondante
- tunnel GRE, IPIP ou autre


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Serge Cavailles a écrit :
>>
>>Aucune chance, les paquets dans l'état ESTABLISHED ne traversent pas les
>>chaînes de la table 'nat'. Ils sont traités implicitement en fonction
>>des opérations de NAT appliquées au premier paquet de la connexion.
>
> Bien sûr, pour du TCP, mais dans le cas du dns, vu qu'on est en UDP, je ne
> pense pas qu'il puisse y avoir de paquets ESTABLISHED.

C'est pareil en UDP et n'importe quel autre protocole IP du moment que
le suivi de connexion peut identifier un paquet comme une réponse à un
autre paquet qu'il a déjà vu passer. La notion de "connexion" de
Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par
ses adresses source et destination, protocole, ports source et
destination (si applicables)... Exemples en dehors de TCP :
- ICMP echo request et l'echo reply correspondant
- requête DNS en UDP et la réponse correspondante
- tunnel GRE, IPIP ou autre


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org