[RESOLU] Navigation web via réseau local

[kcd]

Bonjour,
j'ai voulu troquer ipcop contre une Debian, pour cela je me suis procuré une autre machine (tout en gardant ipcop d'installer sur mon ancien routeur, au cas ou, et j'ai bien fait ). L'installation de type minimaliste, (ssh, exim4) n'a posé aucun problème.

Il est alors apparut le problème suivant : je ne peux accéder qu'à certains sites web (donc on parle bien du traffic en http) à partir des postes "clients". En étant loggué sur le routeur "Debian", via telnet, ou lynx, j'accède aux sites que les clients ne voient pas. Le ftp fonctionne (ftp.debian.org, kernel.org) quand à lui.

Un des sites auxquels les clients n'acèdent pas : http://xfce.org/ (exemple parmis tant d'autres...)
Le client obtient un timeout, le routeur, lui, récupère bien la page web.
A noter que quand ipcop me faisait ofice de routeur, xfce.org était parfaitement accessible.

L'aspect dns a été tout de suite exclut puisque la résolution de noms se fait bien. Je peux en effet pinguer xfce.org depuis un client, et donc logiquement le traceroute depuis ce même client renvoi l'acheminement de mon paquet comme il faut.

Lors des tests, toutes les régles de firewall on été "flushés" et la politique par défaut des chaînes INPUT FORWARD, et OUTPUT ont toutes été fixées a ACCEPT.
Seule la régle de nat est restée :

Code: Tout sélectionner

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

debian.org, et hotmail.com étaient inaccessibles avec ce routeur la semaine dernière; à ce jour cela fonctionne parfaitement.

J'ai également essayé de changer le MTU de l'interface ppp0. Je l'ai fixé a 1464, ce qui n'a strictement rien changé, tout en sachant que sur lancien routeur ipcop la mtu était de 1492, ce qui n'empechait pas de voir http://xfce.org/ par exemple.

Merci d'avance pour les suggestions de chacun, je ne vois vraiment pas ce que j'aurais pu laissé au hasard (à part peut être un problème matériel ?).

A bientôt.

[Franck78]

Salut,

Etant donné que tu dis ce cela fonctionne parfaitement entre Debian et l'internet, pas la peine de chercher du coté 'RED' à priori.

Tu as plutôt loupé le remplacement 'GREEN/ipcop' par 'GREEN/debian'

Et quand ca marche de temps en temps, c'est une config réseau défectueuse:
-ip/mask/default gateway sur les clients
-proxy
-Ipcop fournit un 'petit' service DNS. Il te faut aussi rendre ce service à tes clients GREEN (dnsmasq).

[kcd]

Merci d'avoir répondu.

Ce n'est pas la première fois que je fais ce genre de choses (routeur Debian). Dans mon travail, j'ai été amené à le faire, et j'ai simplement un proxy, et pas de serveur dns a cache exclusif.

Pour ce qui est de la plage ip utilisée chez moi rien de plus simple :
192.168.0.0/24
Pas de serveur dhcp étant donné la difficulté à trouver la cause de ce problème, que je n'avais encore jamais rencontré. Auparavant, dhcpd tournait et j'avais les même diffficultés. (je fournissait par la même occasion les adresses des serveurs dns de mon fournisseur d'accès, à présent elles sont sur mon pc rentrées à la main dans /etc/resolv.conf).

Pour le moment il n'y a qu'un seul client et c'est ma machine. L'ip est rentré à la main, ainsi que la route par défaut qui pointe vers le routeur.

Je ne me servais pas du proxy sur ipcop, donc je ne pense pas que cela puisse venir de là. Je crois tout de même que je vais me résoudre à installer un squid pour voir comment cela réagit. Je ferais peut être bien de faire de même avec dnsmasq voir si cela se stabilise comme cela.

A bientôt.

[micjack]

Salut,

Tu utilise les memes cartes reseau qui etaient sur IPCop?
As tu jeté un zeuil si tu n'avait pas de collisions ou autre sur tes cartes? (verif avec ifconfig par exemple)
Par contre je laisserais le MTU par defaut ( 1492 visiblement, si modem ethernet)
Puis à mon sens, Squid ne va pas arranger les choses pour les tests

[kcd]

Bonjour,
non ce ne sont pas les même cartes réseaux. Je vais me résigner à les utiliser, je pense.
Aucune collision sur toutes les interfaces réseaux, aucun paquet rejeté.
Pour ce qui est de squid, je n'en ai pas besoin pour le moment, il est vrai que je n'en aurais guère l'utilité pour la suite. Je ne comptais pas au départ l'installer.

La mtu sur ppp0 est à 1492, j'ai juste essayé avec une autre valeur hier, pour constater que le résultat était le même :s .

EDIT : les cartes réseaux sont une 3com 3c515 ISA Fast Etherlink, et une Realtek 3129 en PCI.

A bientôt.

[kcd]

Bonsoir,
bon j'ai du nouveau et suis même pas loin d'en avoir fini, après plusieurs tests, j'en ai déduit que c'était bien ma configuration sur la Debian stable (avec tout par défaut) qui n'allait pas. J'ai pour cela mis à jour et laissé pppoe se mettre à jour. Après ca, j'ai meme installé les versions des scripts des mainteneurs des paquets, (et sauvé mon script de firewall qui était dans /etc/ppp/ip-up), et j'ai été agréablement surpris que cela fonctionne.

J'ai poussé encore un peu, et j'ai découvert que par défaut j'avais une régle iptables :

Code: Tout sélectionner

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

qui était lancé ici : /etc/ppp/ip-up.d/0clampmss.

J'avais vu cela en faisant :

Code: Tout sélectionner

# iptables -L
...
Chain FORWARD (policy ACCEPT)
target     prot opt source        destination         
TCPMSS  tcp  --  anywhere     anywhere  tcp flags:SYN,RST/SYN tcpmss match 1400:1536TCPMSS clamp to PMTU
....


Donc, si je flushait toutes les régles (iptables -F), je ne voyait toujours pas http://xfce.org/ (du fait de l'absence de cette règle). Je n'ai jamais vu ca, j'ai été surpris autant que vous, quand vous lirez.
Je suis encore en train de chercher, le pourquoi du comment sur ces mtu et mss.

C'était donc bien une histoire de fragmentation, de mon réseau local à Internet, vu que certains routeurs bossent bien, et d'autres moins bien

A bientôt.

[micjack]

Zarbi ton truc, car MSS et de - 40 sur le MTU...

Mais bon, c'est le resultat qui compte

[tomtom]

Donc, si je flushait toutes les régles (iptables -F), je ne voyait toujours pas http://xfce.org/ (du fait de l'absence de cette règle). Je n'ai jamais vu ca, j'ai été surpris autant que vous, quand vous lirez.
Je suis encore en train de chercher, le pourquoi du comment sur ces mtu et mss.

C'était donc bien une histoire de fragmentation, de mon réseau local à Internet, vu que certains routeurs bossent bien, et d'autres moins bien

Si on comprend un totu petit peu ce que l'on fait, il n'y a aucune raison d'être surpris.
D'autant que je suis persuadé d'avoir déja expliqué sur ce forum copmment marchet le MTU et le MSS.

Revisions.

Un paquet ethernet classique (celui emis par ton client vers la debian) :

DEST MAC | SOURCE MAC | ETHER TYPE | PAQUET IP | CRC

Ce qui est à noter tout de suiten c'est qu'avec ethernet le paquet IP fait 1500 octets maximum.

Maintenant, te debian fait son traffic (masquerading, etc) et envoie le paquet sur internet, mais en PPPOE.

Nouveau paquet :

DEST MAC | SOURCE MAC | ETHER TYPE | PPPOE | PAQUET IP | CRC

devine un peu, le pseudo entete fait 8 octets !
Donc, pour nous la data maximum sera de 1492 (le fameux !! ) octets.
Passer la MTU de l'interface à 1492 permet donc d'viter de fragmenter à tout va des paquets de 1500 octets.


Mais alors, quel est le problème ????

Quand le serveur xfce.org te rpond, il ne sait pas que tu fais du PPPOE. Il t'envoie donc un paquet ip de 1500 octets... qui arrive bien jusqu'à ta debian. Mais elle, elle ne sait pas gerer ça et renvoie donc à l'emmetteur (en suivant la RFC !) un paquet ICMP fragmentation needed.
Le gros problème vient du fait que parfois, la passerelle elle-même bloque les paquets icmp sortant (parceque le rigolo qui l'a configurée pense que l'icmp est dangereux, et que bloquer le ping est une mesure de sécurité, alor sque l'icmp est nécessaire au fonctionnement de IP !! ), quand ce n'est pas un FAI debile ou le firewall cote serveur qui s'en charge.
Et du coup, le serveur ne reçoit jamais les icmp fragmentation needed, le client ne reçoit jamais rien, la session tcp finit par mourrir.


Il y a une solution ?

Oui ! Contourner le problème en amont.

Nous allons jouer sur le MSS, c'est à dire la taille des données TCP (et non plus ip). On peu juger que quel que soit la suite de protocoles utilisés en dessous, 40 octets suffiront. Donc, si on n'evoie pas de segments de plus de 1460 octets, tout devrait bien se passer (d'ou le fameux -40 de micjack).

Il y a plusieurs possibilités :
- soit le client pppoe (et ca devrait etre le cas de celui de debian... ?) falsifie le mss negocié avec le serveur pour mettre celui qu'il veut (mtu - 40) renvoyé au client. Ainsi, le client pense avoir negocie ce mss et ca marche.

- soit on utilise la fameuse cible netfilter qui va bien : TCPMSS, qui a été créee pour ça.

Dans les deux cas, cela risque de poser des problèmes avec ipsec, mais comem de toutes façons tu fais du nat.... et tu n'utilises peut-etre pas ipsec

A savoir que le problème ne se poserait pas si les fai et les hebergeurs et les bricolos arretaient de maltraiter icmp aveuglemment.


My 2 cents

T.

[kcd]

Merci pour cette explication. J'ai eu une discussion avec un ami, hier, et nous en sommes venus un peu au même point que toi sur l'histoire de framentation, et surtout concernant le retour du paquet (d'xfce.org par exemple). Cette conclusion nous est venue du fait que certains sites fragmentent, et d'autres, non.

Cependant, jai bien essayé de jouer sur la mtu, sans que rien n'y change pour autant. Tout à fait d'accord aussi sur le principe de la fixer à 1492, vu que l'on rajoutes 4 octects à notre trame ip. Donc si je te suis bien, en mettant une mtu (sur ppp0, Debian) inférieur ou égale à 1460, cela ne devrait plus poser aucun problème ? Or j'ai bien essayé des valeurs, allant même jusqu'à 500 (histoire d'étudier le comportement), sans que rien ne change.

Je pense que l'on peut dire que ce topic est résolu, de part la cause du problème que j'ai identifié, et de part les compléments d'informations que j'ai reçu ici.

A bientôt, et encore merci.

[tomtom]

Cependant, jai bien essayé de jouer sur la mtu, sans que rien n'y change pour autant. Tout à fait d'accord aussi sur le principe de la fixer à 1492, vu que l'on rajoutes 4 octects à notre trame ip. Donc si je te suis bien, en mettant une mtu (sur ppp0, Debian) inférieur ou égale à 1460, cela ne devrait plus poser aucun problème ? Or j'ai bien essayé des valeurs, allant même jusqu'à 500 (histoire d'étudier le comportement), sans que rien ne change.

Tu confonds MTU et MSS

MTU, c'est la tailel maximale d'un paquet IP
MSS, c'est la taille maximale d'un segment TCP

en général, on trouve MSS=MTU-40, mais ce n'est pas du tout obligatoire.

Le MSS se négocie au niveau tcp. Mais malheureusement, avec l'icmp bloqué, ca ne negocie pas.
L'autre truc, c'est qu'une fois que le MSS est negocié, il l'est par les 2 partenaires qui utilisent le même (client et serveur), ce qui n'est pas le cas du MTU (géré par l'interface au niveau ethernet !!).
Si tu mets ton MTU à 500, tu envoies encore plus vite des icmp fragmentation needed, et comme elels n'arrivent toujours pas au serveur, ça ne règle rien (ça empirerait même plutot !).
En revanche, en utilisant la règle iptables précedemment citée, tu diminues la valeur du MSS, et donc le partenaire distant envoie des paquets moins gros et qui ne nécessitent pas de fragmentation et donc le problème est contourné ! (mais pas résolu !!!! )

t.

[arapaho]

http://abcdrfc.free.fr/rfc-vf/rfc791.html

[tomtom]

http://abcdrfc.free.fr/rfc-vf/rfc791.html

et http://www.networksorcery.com/enp/proto ... p/msg3.htm