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=E9 en dd'wrt, donc en linux.
Iptables tourne dessus.
Plan reseau:
WWW ----- WRT54GL ---- LAN
Sur mon reseau LAN, j'ai install=E9 un serveur DNS pour mon reseau local, c=
a
fonctionne bien. Ce dns gerre aussi mon domaine sur internet.
Il me faut donc rediriger toutes les requette qui viennent d'internet sur l=
e
port 53 vers mon serveur DNS interne, et que ce dns interne renvois la
reponse =E0 son expediteur sur le net.
J'ai donc plac=E9 une regle PREROUTING qui DNAT mon port:
Ca ne marche pas. J'ai fait pareil avec le port 80 tcp pour ecarter une
erreur de mon dns.
J'ai donc essay=E9 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=E9 d'autres solutions trouv=E9es sur le net, et aucuns resultats=
. En
bref, je suis en train de m'arracher les cheuveux depuis 3 jours...
Bonjour,<br><br>Je sais que mon poste n'est pas relatif a debian, mais =
en desespoir de cause....<br><br>J'ai aquit un WRT54GL et l'ai flas=
h=E9 en dd'wrt, donc en linux.<br>Iptables tourne dessus.<br><br>Plan r=
eseau:
<br>WWW ----- WRT54GL ---- LAN<br><br>Sur mon reseau LAN, j'ai install=
=E9 un serveur DNS pour mon reseau local, ca fonctionne bien. Ce dns gerre =
aussi mon domaine sur internet.<br>Il me faut donc rediriger toutes les req=
uette qui viennent d'internet sur le port 53 vers mon serveur DNS inter=
ne, et que ce dns interne renvois la reponse =E0 son expediteur sur le net.
<br><br>J'ai donc plac=E9 une regle PREROUTING qui DNAT mon port:<br><b=
r>$IPTABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT<br>$IP=
TABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT<br>$IPTABL=
ES -t nat -A PREROUTING -p udp -d $IP_WAN --dport 53 -j DNAT --to-destinati=
on $MOE:53
<br><br>Ca ne marche pas. J'ai fait pareil avec le port 80 tcp pour eca=
rter une erreur de mon dns.<br>J'ai donc essay=E9 ca (53 et 80):<br>$IP=
TABLES -t filter -A FORWARD -p udp -d $MOE --dport 53 -j ACCEPT<br>
$IPTABLES -t nat -A POSTROUTING -p udp -d $MOE --dport 53 -j ACCEPT<br>
$IPTABLES -t nat -A PREROUTING -p udp -i $IP_WAN --dport 53 -j DNAT --to-de=
stination $MOE:53<br><br>Idem, aucun resultat.<br>Je precise que par defaut=
, j'ai INPUT OUTPUT FORWARD a ACCEPT<br><br>Du coup, je vois pas trop c=
omment faire pour que mon serveur MOE soit accessible depuis internet sur s=
es port 53 et 80.
<br>J'ai essay=E9 d'autres solutions trouv=E9es sur le net, et aucu=
ns resultats. En bref, je suis en train de m'arracher les cheuveux depu=
is 3 jours...<br><br>merci d'avance pour toute piste ou solution.<br>
<br>
------=_Part_119032_15621868.1175523472860--
--
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
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 loca l, 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:
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 effets non- 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 loca l,
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:
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 effets non-
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.
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 loca l, 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:
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 effets non- 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.
-- 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 with a subject of "unsubscribe". Trouble? Contact
--
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
-- 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 with a subject of "unsubscribe". Trouble? Contact
Jean-Yves F. Barbier
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 with a subject of "unsubscribe". Trouble? Contact
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
-- 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 with a subject of "unsubscribe". Trouble? Contact
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 ss h 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<br>>d'autres termes, comment testes-tu et quels sont les sympt ômes?<br><br>Ce qui me fait dire que ca ne marche pas, c'est que <a h ref="http://dnsstuff.com"> dnsstuff.com</a> me dit que mon serveur ne reponds pas, que mes secondaires ne syncronisent pas.<br>Pour tester, afin d'eviter les erreurs interne /externe, je me conecte en ssh sur la machine d'un collegue, et je test e dpuis sa machine. Il ne peux pas afficher mon site web, ni attrapper le d ns, je ne peux meme pas me telnet sur les ports 53 et 80. <br>Les symptomes sonts simples, rien reponds, j'eteindrait ma connexio n, ca reviendrais au meme.<br><br><br>>En matière de sécurité il e st plus que logique de commencer par<br>>tout interdire, puis d'ouvr ir les portes une par une; sinon ne <br>>t'étonne pas s'il t'arrive des misères.<br><br>Je s uis 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 ver ifierais que ca fonctionne a drop. <br><br>Vos regles m'ont l'air tout a fait correct mais ca ne march e pas.<br><br>Voici mon script à l'heure actuelle: <a href="http:// fyxx.free.fr/001iptables.txt">http://fyxx.free.fr/001iptables.txt</a><br><b r> <br>
------=_Part_120421_6745967.1175527029982--
-- 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 with a subject of "unsubscribe". Trouble? Contact
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 ss h
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<br>>d'autres termes, comment testes-tu et quels sont les sympt ômes?<br><br>Ce qui me fait dire que ca ne marche pas, c'est que <a h ref="http://dnsstuff.com">
dnsstuff.com</a> me dit que mon serveur ne reponds pas, que mes secondaires ne syncronisent pas.<br>Pour tester, afin d'eviter les erreurs interne /externe, je me conecte en ssh sur la machine d'un collegue, et je test e dpuis sa machine. Il ne peux pas afficher mon site web, ni attrapper le d ns, je ne peux meme pas me telnet sur les ports 53 et 80.
<br>Les symptomes sonts simples, rien reponds, j'eteindrait ma connexio n, ca reviendrais au meme.<br><br><br>>En matière de sécurité il e st plus que logique de commencer par<br>>tout interdire, puis d'ouvr ir les portes une par une; sinon ne
<br>>t'étonne pas s'il t'arrive des misères.<br><br>Je s uis 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 ver ifierais que ca fonctionne a drop.
<br><br>Vos regles m'ont l'air tout a fait correct mais ca ne march e pas.<br><br>Voici mon script à l'heure actuelle: <a href="http:// fyxx.free.fr/001iptables.txt">http://fyxx.free.fr/001iptables.txt</a><br><b r>
<br>
------=_Part_120421_6745967.1175527029982--
--
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 ss h 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<br>>d'autres termes, comment testes-tu et quels sont les sympt ômes?<br><br>Ce qui me fait dire que ca ne marche pas, c'est que <a h ref="http://dnsstuff.com"> dnsstuff.com</a> me dit que mon serveur ne reponds pas, que mes secondaires ne syncronisent pas.<br>Pour tester, afin d'eviter les erreurs interne /externe, je me conecte en ssh sur la machine d'un collegue, et je test e dpuis sa machine. Il ne peux pas afficher mon site web, ni attrapper le d ns, je ne peux meme pas me telnet sur les ports 53 et 80. <br>Les symptomes sonts simples, rien reponds, j'eteindrait ma connexio n, ca reviendrais au meme.<br><br><br>>En matière de sécurité il e st plus que logique de commencer par<br>>tout interdire, puis d'ouvr ir les portes une par une; sinon ne <br>>t'étonne pas s'il t'arrive des misères.<br><br>Je s uis 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 ver ifierais que ca fonctionne a drop. <br><br>Vos regles m'ont l'air tout a fait correct mais ca ne march e pas.<br><br>Voici mon script à l'heure actuelle: <a href="http:// fyxx.free.fr/001iptables.txt">http://fyxx.free.fr/001iptables.txt</a><br><b r> <br>
------=_Part_120421_6745967.1175527029982--
-- 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 with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles
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éf inir 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éf inir
ou ça coince.
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éf inir ou ça coince.
-- 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 with a subject of "unsubscribe". Trouble? Contact
--
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
-- 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 with a subject of "unsubscribe". Trouble? Contact
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é ne le 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.
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Géné ralement, l'emploi de la cible LOG avec des --log-prefix avec un préf ixe<br> différent pour chaque chaine/table est pratique (à mon avis) pour déf inir<br>ou ça coince.<br></blockquote></div><br>Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc mais un routeur avec micr onoyau linux. Et la seule memoire est une microflash et il ne me reste que tres tres peu de place. <br><br>Mais j'ai trouvé le probleme.<br>Mon script commence par #!/b in/bash, et apparemment, le linux embarqué ne le supporte pas.<br>En mett ant #!/bin/sh à la place, le script est bien pris en compte, et il marche bien, donc je vous remercie beaucoup de votre aide. <br>
------=_Part_121879_29147396.1175530254348--
-- 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 with a subject of "unsubscribe". Trouble? Contact
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é ne le
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.
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Géné ralement, l'emploi de la cible LOG avec des --log-prefix avec un préf ixe<br>
différent pour chaque chaine/table est pratique (à mon avis) pour déf inir<br>ou ça coince.<br></blockquote></div><br>Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc mais un routeur avec micr onoyau linux. Et la seule memoire est une microflash et il ne me reste que tres tres peu de place.
<br><br>Mais j'ai trouvé le probleme.<br>Mon script commence par #!/b in/bash, et apparemment, le linux embarqué ne le supporte pas.<br>En mett ant #!/bin/sh à la place, le script est bien pris en compte, et il marche bien, donc je vous remercie beaucoup de votre aide.
<br>
------=_Part_121879_29147396.1175530254348--
--
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
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é ne le 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.
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb( 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Géné ralement, l'emploi de la cible LOG avec des --log-prefix avec un préf ixe<br> différent pour chaque chaine/table est pratique (à mon avis) pour déf inir<br>ou ça coince.<br></blockquote></div><br>Mon probleme etant que je ne peux pas logguer car c'est pas un vrai pc mais un routeur avec micr onoyau linux. Et la seule memoire est une microflash et il ne me reste que tres tres peu de place. <br><br>Mais j'ai trouvé le probleme.<br>Mon script commence par #!/b in/bash, et apparemment, le linux embarqué ne le supporte pas.<br>En mett ant #!/bin/sh à la place, le script est bien pris en compte, et il marche bien, donc je vous remercie beaucoup de votre aide. <br>
------=_Part_121879_29147396.1175530254348--
-- 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 with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
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 with a subject of "unsubscribe". Trouble? Contact
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
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 with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le poulpe qui bloppe ! a écrit :
Voici mon script à l'heure actuelle: http://fyxx.free.fr/001iptables.txt
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.
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 with a subject of "unsubscribe". Trouble? Contact
Le poulpe qui bloppe ! a écrit :
Voici mon script à l'heure actuelle: http://fyxx.free.fr/001iptables.txt
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.
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
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.
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 with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles
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étou rné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 n e pense pas qu'il puisse y avoir de paquets ESTABLISHED.
Mais je peux me tromper, je l'ai déjà prouvé :D
-- 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étou rné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 n e
pense pas qu'il puisse y avoir de paquets ESTABLISHED.
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étou rné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 n e pense pas qu'il puisse y avoir de paquets ESTABLISHED.