[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [HS] lenteur sur internet, modification de MTU ?

Charles Plessy a écrit :


Depuis torg (extérieur), j'essaye de joindre kunpuu (mon routeur). Les
paquets de moins de 1427 octets passent sans fragmentation,
Plus exactement les paquets ICMP echo de moins de 1427 octets de données (option -s de ping), soit des paquets IP de de moins de 1455 octets en ajoutant les 8 octets d'en-tête ICMP et les 20 octets d'en-tête IP. La MTU est la taille maxi d'un paquet IP entier avec ses en-têtes. 


et pour les autres, si le drapeau DF vaut 1, torg reçoit un message de
ksgnim4.asahi-net.or.jp, que je soupçonne être mon modem ou une machine
juste derrière. En effet, la route pour l'internet mondial depuis kunpuu
(mon routeur) est :
211.13.152.16 dev ppp0  proto kernel  scope link src 220.157.247.254
C'est le routeur d'accès qui "termine" ta session PPP. C'est soit le concentrateur d'accès (AC) PPPoE comme dans le cas des BAS ADSL de Wanadoo/Orange, soit un serveur d'accès situé plus loin si la session PPP est relayée comme dans le cas des tunnels L2TP vers les LNS des FAI en collecte IP/ADSL. Cette deuxième éventualité serait cohérente avec la MTU observée qui aurait pour but d'éviter la fragmentation du tunnel entre concentrateur d'accès PPPoE et routeur d'accès PPP. Je crois en avoir parlé dans un précédent message. 


Si je fais le même test depuis torg (extérieur) vers d'autres serveurs,
j'obtiens des valeurs différentes : MTU de 1500-28 = 1472 pour
www.debian.org (comme ça c'est moins hors sujet ;) ou pour
postman.riken.jp (on va y revenir).


Plus exactement MTU = 1472(données de ping)+28(en-têtes IP+ICMP) = 1500.


Voyons maintenant depuis sorbet, ma machine à l'intérieur qui me pose problème
(ainsi que toutes les autres en fait) si je ne baisse pas la MTU à la main à
1412 (ce qui est ennuyeux quand j'ai des invités utilisant d'autres systèmes
d'exploitation, car dans ce cas, je ne sais pas le faire).


Voici quelques solutions efficaces pour les connexions TCP.
- Dans le fichier d'options de pppd pour la connexion PPPoE de ton routeur qui doit se trouver dans /etc/ppp/peers, spécifier l'option -m 1454 dans la ligne pty "/usr/sbin/pppoe... Cela a pour effet de limiter la valeur de MSS (taille maximum de segment TCP) annoncée dans les paquets SYN établissant une connexion TCP.
- Créer sur le routeur une règle iptables avec la cible TCPMSS ayant le même but (elle est dans man iptables) : 

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu
Prérequis : la MTU de l'interface PPP doit avoir la bonne valeur (1454 maxi) sinon la règle risque d'être inefficace. Si le serveur PPP ne transmet pas cette valeur, la fixer avec l'option mtu dans le fichier d'options de pppd. Ou alors utiliser la règle suivante (pas testée) : 

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -m tcpmss --mss 1455: -j TCPMSS --set-mss 1454
- Si les postes du LAN sont configurés par DHCP, configurer le serveur DHCP pour envoyer l'option interface-mtu avec la valeur désirée. En espérant qu'elle soit prise en compte par les clients. 


Quand je ne précise
pas la MTU, celle-ci se positionne automatiquement à 1500. En faisant le test
plus haut, je mesure la MTU à 1426,


En fait MTU = 1426+28 = 1454.


pour torg (charles.plessy.org, maintenant à
l'extérieur), www.debian.org ou postman.riken.jp. Donc si j'ai bien compris,
les paquets ICMP circulent bien, car s'il y avait un trou noir je devrais
perdre la réponse.
Oui, du moins entre ton routeur et torg. Ce qui ne présume pas de ce qui se passe entre ton routeur et d'autres machines. 


Mais dans ce cas, je n'arrive pas à m'expliquer pourquoi j'arrive à relever ma
boîte IMAP chez postman.riken.jp quand je limite la MTU à 1412 (nombre
déterminé au pifomètre dans le passé, je suppose qu'avec 1426 cela marcherait
aussi ?),


Je dirais 1454.


alors que si je laisse la machine libre de choisir la valeur (1500),
j'obtiens un superbe timeout, capturé ci-dessous.

      7 0.064934    192.168.0.3           134.160.33.2          TCP      49302 > imaps [SYN] Seq=0 Len=0 MSS=1460 TSV=72899 TSER=0 WS=7
      8 0.078895    134.160.33.2          192.168.0.3           TCP      imaps > 49302 [SYN, ACK] Seq=0 Ack=1 Win=23168 Len=0 MSS=1460 TSV=518652272 TSER=72899 WS=2
On voit que les deux machines annoncent une MSS de 1460, correspondant à une MTU de 1460+20(en-tête TCP)+20(en-tête IP) de 1500. 


      9 0.078967    192.168.0.3           134.160.33.2          TCP      49302 > imaps [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=72903 TSER=518652272
     10 0.079725    192.168.0.3           134.160.33.2          SSLv2    Client Hello
     11 0.094310    134.160.33.2          192.168.0.3           TCP      imaps > 49302 [ACK] Seq=1 Ack=106 Win=5792 Len=0 TSV=518652287 TSER=72903
     12 0.098629    134.160.33.2          192.168.0.3           SSL      [TCP Previous segment lost] Continuation Data
     13 0.098690    192.168.0.3           134.160.33.2          TCP      [TCP Dup ACK 10#1] 49302 > imaps [ACK] Seq=106 Ack=1 Win=5888 Len=0 TSV=72908 TSER=518652287 SLE=1449 SRE=1922
Apparemment la réponse du serveur était divisée en deux segments, et le premier n'est pas arrivé (previous segment lost). 


Le problème rencontré ici, je le rappelle, n'est pas spécifique à l'IMAP.
J'observe aussi le même phénomène avec des sites webs, surtout des webmails ou
des sites de commerce en ligne, pour lesquels j'ai du mal à faire des tests car
premièrement ils bloquent les pings,
Et peut-être pas seulement les pings mais carrément tous les ICMP, ce qui pourrait expliquer qu'ils ne prennent pas en compte le MTU signalé par le routeur d'accès ksgnim4.asahi-net.or.jp. 


et deuxièmement les blocages
n'apparaissent que dans certaines conditions que je ne peux pas reproduire
moi-même, en particulier pour les webmails dans lesquels je n'ai pas de compte
(mais mes invités en ont, c'est comme ça que j'avais découvert ce problème).
Cependant le problème ne se produit pas avec tous les serveurs, n'est-ce pas ? Ce seraient donc les serveurs à problèmes qui sont fautifs.
Reply to: