Le 12/12/2017 à 09:15, Olivier a écrit :
Après recherches, il s'avère qu'en valorisant à 1472, le MTU (par une
commande "ifconfig eth0 mtu up"), les conséquences du problème ont disparu
(plus d'affichage SSH tronqué, scp OK).
J'aimerai comprendre ce qui s'est passé et ce qui a, en apparence, du
moins, rendu nécessaire ce changement de MTU.
Un changement de MTU (diminution) le long du chemin et une mauvaise
gestion de la fragmentation et des messages ICMP "destination
unreachable - fragmentation needed but DF (don't fragmet flag) set".
Lorsqu'un routeur reçoit un paquet IPv4 qu'il doit router par une
interface de MTU inférieure à la taille du paquet, doit :
- si le paquet a le flag DF à 0, fragmenter le paquet et envoyer les
fragments par l'interface ;
- si le paquet a le flag DF à 1, écarter le paquet et renvoyer un
message d'erreur ICMP "destination unreachable - fragmentation needed
but DF set" annonçant la taille maximum à l'adresse source du paquet.
Les problèmes possibles sont nombreux :
- Le routeur écarte les paquets trop gros mais n'envoie pas de messages
ICMP, ou l'équipement où a lieu la baisse de MTU n'est pas un routeur
(exemple : concentrateur d'accès PPPoE ADSL qui n'est qu'un relais entre
un tunnel PPPoE et un tunnel L2TP).
- Les messages d'erreur ICMP sont filtrés en chemin par un firewall ou
ignorés par l'émetteur du paquet initial.
- les fragments sont filtrés en chemin par un firewall.
Les VPN et autres tunnels sont de gros pourvoyeurs de baisse de MTU
et/ou de fragmentation car l'encapsulation augmente la taille des paquets.
