Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre
avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au
bout et reste bloqué.
Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun
message d'erreur et que le dit script fonctionne sans problème sur une
autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque
j'exécute mes commandes iptables les unes après les autres à la main mais
vous vous doutez bien que c'est loin d'être pratique.
Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut
m'indiquer dans quel sens chercher, je suis preneur :-)
Merci,
Oumar
--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)
#========================================#
# initialisation des parametres du noyau #
#========================================#
# par defaut le serveur n'est pas un routeur : routage IP desactive
echo "0" > /proc/sys/net/ipv4/ip_forward
# activer le reverse path filtering contre le spoofing IP source
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "1" > /proc/sys/net/ipv4/conf/$IF_WAN/rp_filter
# chaine de traitement de tous les type de paquets IP rejetes
iptables -N reject
iptables -A reject -p tcp -j reject_tcp
iptables -A reject -p udp -j reject_udp
iptables -A reject -p icmp -j log_and_drop
# autres protocoles : emission limitee ICMP "protocol unreachable"
iptables -A reject -m limit --limit 10/s -j REJECT --reject-with icmp-proto-unreachable
iptables -A reject -j log_and_drop
#======================================#
# traitement des paquets NEW en entree #
#======================================#
# chaine de traitement des paquets INPUT NEW sur l'interface wan
iptables -N in_wan_new
# accepte les protocoles et ports autorises
iptables -A in_wan_new -j in_accept
# accepte avec limite les ICMP "echo request" (ping)
iptables -A in_wan_new -p icmp --icmp-type echo-request -m limit --limit 5/s -j ACCEPT
iptables -A in_wan_new -j reject
#==========================================#
# traitement des paquets RELATED en entree #
#==========================================#
# connexions TCP RELATED : accepte connexions sur ports non privilegies
iptables -N related_tcp
iptables -A related_tcp -p tcp --syn --dport 1024: -j ACCEPT
# accepte les paquets RST
iptables -A related_tcp -p tcp --tcp-flags RST RST -j ACCEPT
iptables -A related_tcp -j reject_tcp
# connexions UDP RELATED : accepte connexions sur ports non privilegies
iptables -N related_udp
iptables -A related_udp -p udp --dport 1024: -j ACCEPT
iptables -A related_udp -j reject_udp
# paquets ICMP RELATED : 4 types acceptes, le reste bloque
iptables -N related_icmp
iptables -A related_icmp -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A related_icmp -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A related_icmp -p icmp --icmp-type source-quench -j ACCEPT
iptables -A related_icmp -p icmp --icmp-type parameter-problem -j ACCEPT
iptables -A related_icmp -j log_and_drop
# chaine de traitement des paquets RELATED
iptables -N related
iptables -A related -p tcp -j related_tcp
iptables -A related -p udp -j related_udp
iptables -A related -p icmp -j related_icmp
# autres protocoles : accepte
iptables -A related -j ACCEPT
#=======================#
# regles des interfaces #
#=======================#
# interface de loopback : accepte tout
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# interface WAN
# traitement INPUT WAN : filtrage a etats des paquets entrants
iptables -N in_wan
iptables -A in_wan -m state --state ESTABLISHED -j ACCEPT
iptables -A in_wan -m state --state NEW -j in_wan_new
iptables -A in_wan -m state --state RELATED -j related
# le reste (state INVALID) => bloque
iptables -A in_wan -j log_and_drop
iptables -A INPUT -i $IF_WAN -j in_wan
# traitement OUTPUT WAN : accepte tout
iptables -N out_wan
iptables -A out_wan -j ACCEPT
iptables -A OUTPUT -o $IF_WAN -j out_wan
# fin
--sm4nu43k4a2Rpi4c--
--
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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bulot Grégory
Le samedi 30 juin 2007 13:05, Oumar Niane a écrit :
Bonjour,
Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au bout et reste bloqué.
Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun message d'erreur et que le dit script fonctionne sans problème sur une autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque j'exécute mes commandes iptables les unes après les autres à la mai n mais vous vous doutez bien que c'est loin d'être pratique.
Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut m'indiquer dans quel sens chercher, je suis preneur :-)
J'imagine que les logs ont déjà été regardés ... Entre chaque lignes (je suppose que c'est un batch qui lance les commandes) faire un sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque (voir si c'est la ligne pré cédante qui entre en conflit temporelle avec la ligne courante)
Le samedi 30 juin 2007 13:05, Oumar Niane a écrit :
Bonjour,
Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre
avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au
bout et reste bloqué.
Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun
message d'erreur et que le dit script fonctionne sans problème sur une
autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque
j'exécute mes commandes iptables les unes après les autres à la mai n mais
vous vous doutez bien que c'est loin d'être pratique.
Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut
m'indiquer dans quel sens chercher, je suis preneur :-)
J'imagine que les logs ont déjà été regardés ...
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
faire un
sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque (voir si c'est la ligne pré cédante
qui entre en conflit temporelle avec la ligne courante)
Le samedi 30 juin 2007 13:05, Oumar Niane a écrit :
Bonjour,
Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au bout et reste bloqué.
Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun message d'erreur et que le dit script fonctionne sans problème sur une autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque j'exécute mes commandes iptables les unes après les autres à la mai n mais vous vous doutez bien que c'est loin d'être pratique.
Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut m'indiquer dans quel sens chercher, je suis preneur :-)
J'imagine que les logs ont déjà été regardés ... Entre chaque lignes (je suppose que c'est un batch qui lance les commandes) faire un sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque (voir si c'est la ligne pré cédante qui entre en conflit temporelle avec la ligne courante)
Oumar Niane
On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
J'imagine que les logs ont déjà été regardés ...
Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois lignes:
ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes) faire un sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu consultes le script que j'avais joint à mon mail précédent, il bloque après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas que ce soit une instruction particulière qui pose problème puisque si je commente cette ligne, il bloque sur la suivante et ainsi de suite.
Merci pour ta réponse,
Oumar
-- One OS to rule them all, One OS to find them. One OS to call them all, And in salvation bind them. In the bright land of Linux, Where the hackers play. (J. Scott Thayer, with apologies to J.R.R.T.)
-- 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
On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
J'imagine que les logs ont déjà été regardés ...
Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois
lignes:
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
faire un
sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
consultes le script que j'avais joint à mon mail précédent, il bloque
après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas
que ce soit une instruction particulière qui pose problème puisque si je
commente cette ligne, il bloque sur la suivante et ainsi de suite.
Merci pour ta réponse,
Oumar
--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)
--
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
On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
J'imagine que les logs ont déjà été regardés ...
Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois lignes:
ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes) faire un sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu consultes le script que j'avais joint à mon mail précédent, il bloque après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas que ce soit une instruction particulière qui pose problème puisque si je commente cette ligne, il bloque sur la suivante et ainsi de suite.
Merci pour ta réponse,
Oumar
-- One OS to rule them all, One OS to find them. One OS to call them all, And in salvation bind them. In the bright land of Linux, Where the hackers play. (J. Scott Thayer, with apologies to J.R.R.T.)
-- 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 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
mouss
Oumar Niane wrote:
On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
J'imagine que les logs ont déjà été regardés ...
Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois lignes:
ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes) faire un sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu consultes le script que j'avais joint à mon mail précédent, il bloque après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas que ce soit une instruction particulière qui pose problème puisque si je commente cette ligne, il bloque sur la suivante et ainsi de suite.
si je ne me trompe, juste après, le script execute:
/etc/network/firewall/fw_accept
il faut donc regarder dedans ce qui peut prendre du temps. regarde si ta machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le genre de trucs qui peuvent ralentir (et si en plus, les paquest correspondants sont drop'és quelque part dans leur chemin, alors, ça dure encore plus longtemps, puisqu'il faut attendre un timeout).
-- 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
Oumar Niane wrote:
On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
J'imagine que les logs ont déjà été regardés ...
Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois
lignes:
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
faire un
sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
consultes le script que j'avais joint à mon mail précédent, il bloque
après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas
que ce soit une instruction particulière qui pose problème puisque si je
commente cette ligne, il bloque sur la suivante et ainsi de suite.
si je ne me trompe, juste après, le script execute:
/etc/network/firewall/fw_accept
il faut donc regarder dedans ce qui peut prendre du temps. regarde si ta
machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le
genre de trucs qui peuvent ralentir (et si en plus, les paquest
correspondants sont drop'és quelque part dans leur chemin, alors, ça
dure encore plus longtemps, puisqu'il faut attendre un timeout).
--
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
On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
J'imagine que les logs ont déjà été regardés ...
Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois lignes:
ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes) faire un sleep 1s ; echo "Etape X à venir ...."
histoire de voir à quelle ligne cela bloque
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu consultes le script que j'avais joint à mon mail précédent, il bloque après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas que ce soit une instruction particulière qui pose problème puisque si je commente cette ligne, il bloque sur la suivante et ainsi de suite.
si je ne me trompe, juste après, le script execute:
/etc/network/firewall/fw_accept
il faut donc regarder dedans ce qui peut prendre du temps. regarde si ta machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le genre de trucs qui peuvent ralentir (et si en plus, les paquest correspondants sont drop'és quelque part dans leur chemin, alors, ça dure encore plus longtemps, puisqu'il faut attendre un timeout).
-- 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 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
-- 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
Bulot Grégory
Le samedi 30 juin 2007 14:22, Oumar Niane a écrit :
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu consultes le script que j'avais joint à mon mail précédent, il bloq ue après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas ...
Milles excuses, j'avais pas fait attention à la pièce jointe
Le samedi 30 juin 2007 14:22, Oumar Niane a écrit :
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
consultes le script que j'avais joint à mon mail précédent, il bloq ue
après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas ...
Milles excuses, j'avais pas fait attention à la pièce jointe
Le samedi 30 juin 2007 14:22, Oumar Niane a écrit :
J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu consultes le script que j'avais joint à mon mail précédent, il bloq ue après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas ...
Milles excuses, j'avais pas fait attention à la pièce jointe
Pascal Hambourg
Salut,
Oumar Niane a écrit :
Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au bout et reste bloqué.
Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun message d'erreur et que le dit script fonctionne sans problème sur une autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque j'exécute mes commandes iptables les unes après les autres à la main mais vous vous doutez bien que c'est loin d'être pratique.
Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut m'indiquer dans quel sens chercher, je suis preneur :-)
Vu qu'il paraît que je suis l'auteur initial de ce script, je me sens un peu obligé de répondre, bien que n'ayant pas de solution à proposer. Et je n'ai aucun moyen de tester, ne disposant pas d'une machine AMD64.
Pour la petite histoire, je ne suis pas sûr d'avoir jamais testé ce script. Je l'avais écrit pour le serveur hébergé d'un ami qui n'en a finalement pas voulu, prétextant qu'il n'avait pas vraiment besoin d'un firewall (pas totalement faux puisque déjà seuls les services voulus étaient ouverts à l'extérieur) et qu'il avait peur de verrouiller la machine en cas de fausse manip.
Au chapitre des raisons possibles du blocage, je n'ai guère d'idées. Il y a déjà eu des bugs d'ABI en 64 bits entre iptables et le noyau, mais le fait que les commandes passent à la main infirme cette hypothèse.
Il a aussi été constaté que parfois la création de règles iptables pouvait être anormalement longue, mais il me semble que cela concerne plutôt iptables-restore. As-tu essayé d'attendre un peu pour voir ce qui se passe ? Ou de surveiller les appels système de la commande qui bloque avec strace ?
L'interpréteur de commande est-il le même en console et dans le script ? En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être est-ce différent sur ta Debian amd64. Au fait, c'est bien une Debian amd64 et non juste une Debian i386 installée sur une machine AMD64 ?
-- 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,
Oumar Niane a écrit :
Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre
avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au
bout et reste bloqué.
Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun
message d'erreur et que le dit script fonctionne sans problème sur une
autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque
j'exécute mes commandes iptables les unes après les autres à la main mais
vous vous doutez bien que c'est loin d'être pratique.
Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut
m'indiquer dans quel sens chercher, je suis preneur :-)
Vu qu'il paraît que je suis l'auteur initial de ce script, je me sens un
peu obligé de répondre, bien que n'ayant pas de solution à proposer. Et
je n'ai aucun moyen de tester, ne disposant pas d'une machine AMD64.
Pour la petite histoire, je ne suis pas sûr d'avoir jamais testé ce
script. Je l'avais écrit pour le serveur hébergé d'un ami qui n'en a
finalement pas voulu, prétextant qu'il n'avait pas vraiment besoin d'un
firewall (pas totalement faux puisque déjà seuls les services voulus
étaient ouverts à l'extérieur) et qu'il avait peur de verrouiller la
machine en cas de fausse manip.
Au chapitre des raisons possibles du blocage, je n'ai guère d'idées.
Il y a déjà eu des bugs d'ABI en 64 bits entre iptables et le noyau,
mais le fait que les commandes passent à la main infirme cette hypothèse.
Il a aussi été constaté que parfois la création de règles iptables
pouvait être anormalement longue, mais il me semble que cela concerne
plutôt iptables-restore. As-tu essayé d'attendre un peu pour voir ce qui
se passe ? Ou de surveiller les appels système de la commande qui bloque
avec strace ?
L'interpréteur de commande est-il le même en console et dans le script ?
En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être
est-ce différent sur ta Debian amd64. Au fait, c'est bien une Debian
amd64 et non juste une Debian i386 installée sur une machine AMD64 ?
--
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
Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au bout et reste bloqué.
Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun message d'erreur et que le dit script fonctionne sans problème sur une autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque j'exécute mes commandes iptables les unes après les autres à la main mais vous vous doutez bien que c'est loin d'être pratique.
Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut m'indiquer dans quel sens chercher, je suis preneur :-)
Vu qu'il paraît que je suis l'auteur initial de ce script, je me sens un peu obligé de répondre, bien que n'ayant pas de solution à proposer. Et je n'ai aucun moyen de tester, ne disposant pas d'une machine AMD64.
Pour la petite histoire, je ne suis pas sûr d'avoir jamais testé ce script. Je l'avais écrit pour le serveur hébergé d'un ami qui n'en a finalement pas voulu, prétextant qu'il n'avait pas vraiment besoin d'un firewall (pas totalement faux puisque déjà seuls les services voulus étaient ouverts à l'extérieur) et qu'il avait peur de verrouiller la machine en cas de fausse manip.
Au chapitre des raisons possibles du blocage, je n'ai guère d'idées. Il y a déjà eu des bugs d'ABI en 64 bits entre iptables et le noyau, mais le fait que les commandes passent à la main infirme cette hypothèse.
Il a aussi été constaté que parfois la création de règles iptables pouvait être anormalement longue, mais il me semble que cela concerne plutôt iptables-restore. As-tu essayé d'attendre un peu pour voir ce qui se passe ? Ou de surveiller les appels système de la commande qui bloque avec strace ?
L'interpréteur de commande est-il le même en console et dans le script ? En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être est-ce différent sur ta Debian amd64. Au fait, c'est bien une Debian amd64 et non juste une Debian i386 installée sur une machine AMD64 ?
-- 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
Oumar Niane
Salut,
J'ai réussi à résoudre le problème en autorisant le trafic sur l'interface de loopback toute suite après l'initialisation de, tables et des paramètres noyau. Je n'ai pas pour autant compris ce qui clochait :-(.
On Sun, Jul 01, 2007 at 04:19:08PM +0200, Pascal Hambourg wrote :
Vu qu'il paraît que je suis l'auteur initial de ce script,
Rendons à César ce qui est à César :-) . En tout cas, merci pour ce script car il m'a rendu bien des services.
As-tu essayé d'attendre un peu pour voir ce qui se passe ?
Rien au bout de 5min
Ou de surveiller les appels système de la commande qui bloque avec strace ?
L'interpréteur de commande est-il le même en console et dans le script ? En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être est-ce différent sur ta Debian amd64.
Non c'est pareil
Au fait, c'est bien une Debian amd64 et non juste une Debian i386 installée sur une machine AMD64 ?
C'est bien une debian amd64
Si quelqu'un, avec ces infos supplémentaires, arrive à trouver une explication, je suis preneur.
Merci pour toutes vos réponses,
Oumar
-- One OS to rule them all, One OS to find them. One OS to call them all, And in salvation bind them. In the bright land of Linux, Where the hackers play. (J. Scott Thayer, with apologies to J.R.R.T.)
-- 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,
J'ai réussi à résoudre le problème en autorisant le trafic sur
l'interface de loopback toute suite après l'initialisation de,
tables et des paramètres noyau. Je n'ai pas pour autant compris
ce qui clochait :-(.
On Sun, Jul 01, 2007 at 04:19:08PM +0200, Pascal Hambourg wrote :
Vu qu'il paraît que je suis l'auteur initial de ce script,
Rendons à César ce qui est à César :-) . En tout cas, merci pour ce
script car il m'a rendu bien des services.
As-tu essayé d'attendre un peu pour voir ce qui se passe ?
Rien au bout de 5min
Ou de surveiller les appels système de la commande qui bloque
avec strace ?
L'interpréteur de commande est-il le même en console et dans le script ?
En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être
est-ce différent sur ta Debian amd64.
Non c'est pareil
Au fait, c'est bien une Debian amd64 et non juste une Debian i386 installée
sur une machine AMD64 ?
C'est bien une debian amd64
Si quelqu'un, avec ces infos supplémentaires, arrive à trouver une
explication, je suis preneur.
Merci pour toutes vos réponses,
Oumar
--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)
--
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
J'ai réussi à résoudre le problème en autorisant le trafic sur l'interface de loopback toute suite après l'initialisation de, tables et des paramètres noyau. Je n'ai pas pour autant compris ce qui clochait :-(.
On Sun, Jul 01, 2007 at 04:19:08PM +0200, Pascal Hambourg wrote :
Vu qu'il paraît que je suis l'auteur initial de ce script,
Rendons à César ce qui est à César :-) . En tout cas, merci pour ce script car il m'a rendu bien des services.
As-tu essayé d'attendre un peu pour voir ce qui se passe ?
Rien au bout de 5min
Ou de surveiller les appels système de la commande qui bloque avec strace ?
L'interpréteur de commande est-il le même en console et dans le script ? En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être est-ce différent sur ta Debian amd64.
Non c'est pareil
Au fait, c'est bien une Debian amd64 et non juste une Debian i386 installée sur une machine AMD64 ?
C'est bien une debian amd64
Si quelqu'un, avec ces infos supplémentaires, arrive à trouver une explication, je suis preneur.
Merci pour toutes vos réponses,
Oumar
-- One OS to rule them all, One OS to find them. One OS to call them all, And in salvation bind them. In the bright land of Linux, Where the hackers play. (J. Scott Thayer, with apologies to J.R.R.T.)
-- 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