up2date derrière iptables

Dans le message
<news:pan.2004.05.23.19.48.33.551094@math-info.univ-paris5.fr>,
*François Patte* tapota sur f.c.o.l.configuration :

Bonjour,

Bonsoir,

J'essaie de mettre à jour une distribution fedora sur une machine
située sur un réseau privée derrière iptables.

up2date me renvoie une erreur 400 bad request.

C'est un message d'erreur suite à une requete http.

l'addresse est http:/xmlrpc.redhat.com/...

Le type d'adresse le confirme. Par contre, êtes vous sûr de cette adresse,
car celle-ci ne semble pas exister.
Et en utilisant un autre serveur ?

y a-t-il un port particulier pour ce genre de requète?
les log d'iptables ne me montre rien de particulier...

Non, à part bien sûr autoriser la machine à faire du trafic sur les ports 80
(http) et 443 (https) des machines distantes. Ce qui est le cas puisque le
serveur semble vous répondre.

Merci

De rien.

--
TiChou

Le Mon, 24 May 2004 03:06:51 +0200, TiChou a écrit :

Dans le message
<news:pan.2004.05.23.19.48.33.551094@math-info.univ-paris5.fr>,
*François Patte* tapota sur f.c.o.l.configuration :

Bonjour,

Bonsoir,

J'essaie de mettre à jour une distribution fedora sur une machine
située sur un réseau privée derrière iptables.

up2date me renvoie une erreur 400 bad request.

C'est un message d'erreur suite à une requete http.

l'addresse est http:/xmlrpc.redhat.com/...

Le type d'adresse le confirme. Par contre, êtes vous sûr de cette adresse,
car celle-ci ne semble pas exister.

Oui, je me suis trompé: il manque un étage, mais ça ne change rien
au problème...

http://xmlrpc.rhn.redhat.com/XMLRPC
ou bien https (même adresse)

Et en utilisant un autre serveur ?

y a-t-il un port particulier pour ce genre de requète? les log
d'iptables ne me montre rien de particulier...

Non, à part bien sûr autoriser la machine à faire du trafic sur les
ports 80 (http) et 443 (https) des machines distantes. Ce qui est le cas
puisque le serveur semble vous répondre.

Ligne du script chargeant iptables concernant les ports http et
https:

/sbin/iptables -A OUTPUT -o ppp0 -p tcp -m multiport --dport 80,443 -m state --state NEW,ESTABLISHED -j LOG_ACCEPT
/sbin/iptables -A INPUT -i ppp0 -p tcp -m multiport --sport 80,443 -m state --state ESTABLISHED -j LOG_ACCEPT

malgré le "LOG_ACCEPT" rien ne passe dans les logs

lignes concernant la circulation sur le "LAN":

/sbin/iptables -A INPUT -i eth1 -s 192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -o eth1 -d 192.168.0.0/24 -j ACCEPT

internet sur le "LAN":

/sbin/iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

/sbin/iptables -A FORWARD -i ppp0 -o eth1 -p tcp -m state --state ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -o ppp0 -i eth1 -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

Le problème vient vraiment du pare-feu puisque ce problème n'a
absolument pas lieu si on exécute les mêmes commandes depuis la
passerelle (même version: fedora core1).

Il y a le problème du proxi: certains sites obligent à utiliser
squid (problème de MTU en ADSL). J'ai donc squid qui tourne et,
depuis le LAN, on est obligé de passer par squid. Ce cas est
prévu par la configuration de up2date, mais que l'on mette le proxi
ou non, le résultat est le même!

Merci

De rien.
si! si! et je réitère: merci pour toute aide.

François Patte

Dans le message
<news:pan.2004.05.24.12.12.34.357510@math-info.univ-paris5.fr>,
*François Patte* tapota sur f.c.o.l.configuration :

J'essaie de mettre à jour une distribution fedora sur une machine
située sur un réseau privée derrière iptables.

up2date me renvoie une erreur 400 bad request.

C'est un message d'erreur suite à une requete http.

l'addresse est http:/xmlrpc.redhat.com/...

Le type d'adresse le confirme. Par contre, êtes vous sûr de cette
adresse, car celle-ci ne semble pas exister.

Oui, je me suis trompé: il manque un étage, mais ça ne change rien
au problème...

http://xmlrpc.rhn.redhat.com/XMLRPC
ou bien https (même adresse)

y a-t-il un port particulier pour ce genre de requète? les log
d'iptables ne me montre rien de particulier...

Non, à part bien sûr autoriser la machine à faire du trafic sur les
ports 80 (http) et 443 (https) des machines distantes. Ce qui est le cas
puisque le serveur semble vous répondre.

Ligne du script chargeant iptables concernant les ports http et
https:

/sbin/iptables -A OUTPUT -o ppp0 -p tcp -m multiport --dport 80,443 -m
state --state NEW,ESTABLISHED -j LOG_ACCEPT
/sbin/iptables -A INPUT -i ppp0 -p tcp -m multiport --sport 80,443 -m
state --state ESTABLISHED -j LOG_ACCEPT

malgré le "LOG_ACCEPT" rien ne passe dans les logs

Ici ne sera loggé que les connexions initiées sur la passerelle, pas sur les
machines du réseau.

lignes concernant la circulation sur le "LAN":

/sbin/iptables -A INPUT -i eth1 -s 192.168.0.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -o eth1 -d 192.168.0.0/24 -j ACCEPT

internet sur le "LAN":

/sbin/iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

/sbin/iptables -A FORWARD -i ppp0 -o eth1 -p tcp -m state --state
ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -o ppp0 -i eth1 -p tcp -m state --state
NEW,ESTABLISHED -j ACCEPT

Pour logger les connexions forwardées sur le LAN, vous pouvez mettre votre
cible LOG_ACCEPT.

Le problème vient vraiment du pare-feu puisque ce problème n'a
absolument pas lieu si on exécute les mêmes commandes depuis la
passerelle (même version: fedora core1).

Pourtant ici le firewall autorise aux machines du LAN d'établir toutes les
connexions TCP voulues. Pourquoi limiter à TCP d'ailleurs ?
Et il ne me semble pas que up2date utilise un protocole particulier qui
nécessiterait l'ouverture et la redirection de port en entrée.

Il y a le problème du proxi: certains sites obligent à utiliser
squid (problème de MTU en ADSL).

Je ne vois pas en quoi le problème (tout relatif) du MTU en ADSL oblige
d'utiliser un proxy. Il suffit que les interfaces réseaux soient
correctement configurées (ifconfig ethX mtu 14xx).

J'ai donc squid qui tourne et, depuis le LAN, on est obligé de passer par
squid.

Pourtant, au niveau de la passerelle, rien n'empêche de se connecter
directement à un site distant vu que vos règles iptables autorise de
forwarder ces connexions.

Par contre, le proxy peut effectivement poser un problème pour up2date s'il
tente de faire des requêtes HTTP particulières (autres que GET et POST par
exemple) et que ces types de requêtes ne soient pas autorisés par Squid.

Ce cas est prévu par la configuration de up2date, mais que l'on mette le
proxi ou non, le résultat est le même!

Je pense plutôt à un problème de configuration de cet outil qu'à un problème
de connexion. Ou bien un problème de serveur indisponible.
Le fait que cet outil vous renvoit une réponse de type 4XX montre qu'il
s'est connecté à un serveur distant. Mais je ne connais peut être pas toutes
les subtilités de cet outil dont j'avoue ne pas me servir.
Si quelqu'un d'autre l'utilise dans le même type de configuration, qu'il se
manifeste.

--
TiChou

Le Mon, 24 May 2004 15:05:42 +0200, TiChou a écrit :

Dans le message
<news:pan.2004.05.24.12.12.34.357510@math-info.univ-paris5.fr>,
*François Patte* tapota sur f.c.o.l.configuration :

Il y a le problème du proxi: certains sites obligent à utiliser
squid (problème de MTU en ADSL).

Je ne vois pas en quoi le problème (tout relatif) du MTU en ADSL oblige
d'utiliser un proxy. Il suffit que les interfaces réseaux soient
correctement configurées (ifconfig ethX mtu 14xx).

Je n'ai toujours pas la réponse à mon problème d'up2date, mais ici
il y a eu jadis des tas de discussions à propos de mtu et d'adsl et
je n'ai jamais trouvé de réponse claire; le fait est que certains
sites sont difficiles à atteindre (voire impossibles à) derrière
iptables et que le proxi est nécessaire.

vous préconisez: ifconfig ethX mtu 14xx

mais comment faire quand on utilise un modem ethernet adsl et que
eth0 (dans mon cas) n'est pas "configuré" mais seulement utilisé
par le lien ppp0?

il y a bien une ligne sans /etc/sysconfig/network-scripts/ifcfg-ppp0
qui doit se rapporter à cette question:

CLAMPMSS12

mais ifconfig eth0 retourne, quoiqu'il advienne:

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

....

Merci de m'éclairer.

François Patte

Dans le message
<news:pan.2004.05.25.13.15.22.122989@math-info.univ-paris5.fr>,
*François Patte* tapota sur f.c.o.l.configuration :

Il y a le problème du proxi: certains sites obligent à utiliser
squid (problème de MTU en ADSL).

Je ne vois pas en quoi le problème (tout relatif) du MTU en ADSL oblige
d'utiliser un proxy. Il suffit que les interfaces réseaux soient
correctement configurées (ifconfig ethX mtu 14xx).

Je n'ai toujours pas la réponse à mon problème d'up2date, mais ici
il y a eu jadis des tas de discussions à propos de mtu et d'adsl et
je n'ai jamais trouvé de réponse claire; le fait est que certains
sites sont difficiles à atteindre (voire impossibles à) derrière
iptables et que le proxi est nécessaire.

Attention à la confusion. iptables est outil qui permet la manipulation du
mécanisme Netfilter du noyau. Il n'est en aucun cas lié au problème de MTU.

vous préconisez: ifconfig ethX mtu 14xx

mais comment faire quand on utilise un modem ethernet adsl et que
eth0 (dans mon cas) n'est pas "configuré" mais seulement utilisé
par le lien ppp0?

Je ne parlais pas de configurer le MTU sur la passerelle, mais sur les
machines clientes sur lesquelles vous dites avoir des problèmes et sur
lesquelles vous dites être obligé de passer par un proxy. Et ces machines
clientes sont, j'imagine, raccordées sur le réseau et accède à Internet via
leur carte réseau ethernet.

Il n'empêche qu'il faut tout de même vérifier que votre connexion PPP est
correctement configurée et que le MTU de l'interface ppp0 est bien à 1492
(pour une connexion PPPoE).

il y a bien une ligne sans /etc/sysconfig/network-scripts/ifcfg-ppp0
qui doit se rapporter à cette question:

CLAMPMSS12

Oui, cette valeur du MSS permet en principe aux machines clientes d'adapter
le MTU de leur interface comme il faut, mais ce n'est pas toujours le cas.
Si donc vous recontrez de sproblèmes de MTU sur vos machines clientes, il
faudra donc le configurer manuellement et lui donner la valeur 1492 dans le
cas d'une connexion PPPoE sur votre passerelle.

Merci de m'éclairer.

J'espère que c'est fait.

--
TiChou

Le Tue, 25 May 2004 16:28:48 +0200, TiChou a écrit :

Dans le message
<news:pan.2004.05.25.13.15.22.122989@math-info.univ-paris5.fr>, *François
Patte* tapota sur f.c.o.l.configuration :

vous préconisez: ifconfig ethX mtu 14xx

mais comment faire quand on utilise un modem ethernet adsl et que eth0
(dans mon cas) n'est pas "configuré" mais seulement utilisé par le
lien ppp0?

Il n'empêche qu'il faut tout de même vérifier que votre connexion PPP
est correctement configurée et que le MTU de l'interface ppp0 est bien à
1492 (pour une connexion PPPoE).

Si donc vous recontrez de sproblèmes de MTU sur vos
machines clientes, il faudra donc le configurer manuellement et lui donner
la valeur 1492 dans le cas d'une connexion PPPoE sur votre passerelle.

Vu et merci. Une précision: configuration automatique en ajoutant une
ligne:

MTU92

dans /etc/sysconfig/network-scripts/ifcfg-ethx

Ma question iptables (car c'était bien lui le responsable de mes ennuis
avec up2date... je sais, c'est moi le fautif pour cause de mauvaise
interprétation du manuel!):

il y avait dans mon script, la ligne suivante:

/sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.1:3128

destinée à rendre le proxi "transparent" et qui ne marche pas à moins
de configurer squid.

quand je relançais mon script pour iptables, après avoir supprimé cette
ligne, la règle était gardée en mémoire par iptables et up2date ne
marchait pas. Or ce script contient les lignes suivantes au tout début:

/sbin/iptables -F
/sbin/iptables -X

et je pensais que ceci permettait de remettre à "zéro" toutes les
règles avant d'exécuter la suite du script: donc ma règle fautive
aurait dû être effacée. Apparemment, il n'en est rien et, du coup, je ne
comprends pas bien le sens de ces lignes....

Merci.

François Patte

Dans le message
<news:pan.2004.05.26.06.52.14.653402@math-info.univ-paris5.fr>,
*François Patte* tapota sur f.c.o.l.configuration :

[...]

Ma question iptables (car c'était bien lui le responsable de mes ennuis
avec up2date...

Et/ou votre proxy qui n'autorisait pas certains types de requetes http.

je sais, c'est moi le fautif pour cause de mauvaise interprétation du
manuel!):

il y avait dans mon script, la ligne suivante:

/sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT
--to-destination 192.168.0.1:3128

destinée à rendre le proxi "transparent" et qui ne marche pas à moins
de configurer squid.

quand je relançais mon script pour iptables, après avoir supprimé cette
ligne, la règle était gardée en mémoire par iptables et up2date ne
marchait pas. Or ce script contient les lignes suivantes au tout début:

/sbin/iptables -F
/sbin/iptables -X

et je pensais que ceci permettait de remettre à "zéro" toutes les
règles avant d'exécuter la suite du script:

Non, pas toutes les règles. Seulement les règles de la table filter.
Si l'option '-t nom_table' n'est pas précisée dans la commande iptables,
alors par défaut iptables manipule les règles de la table filter.

donc ma règle fautive aurait dû être effacée.

Non, car votre règle ne fait pas partie de la table filter mais de la table
nat (option '-t nat' dans votre règle).

Apparemment, il n'en est rien et, du coup, je ne comprends pas bien le
sens de

ces lignes....

Il faut rajouter les règles suivantes :

iptables -t nat -F
iptables -t nat -X

et si vous utilisez aussi la table mangle :

iptables -t mangle -F
iptables -t mangle -X

Merci.

De rien.

--
TiChou