Bonjour, Sur une autre liste, plusieurs personnes m'ont indiqué que le pb que je rencontrait provenait probablement d'un pb de MTU.
L'adresse www.google.com étant résolue en 64.233.166.104, j'ai saisi les commandes : #ping -c1 -M do -s 1272 64.233.166.104 PING 64.233.166.104 (64.233.166.104) 1272(1300) bytes of data. 72 bytes from 64.233.166.104: icmp_req=1 ttl=41 (truncated) --- 64.233.166.104 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 52.260/52.260/52.260/0.000 ms # ping -c1 -M do -s 1273 64.233.166.104 PING 64.233.166.104 (64.233.166.104) 1273(1301) bytes of data. --- 64.233.166.104 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms J'en ai déduis que le MTU était de 1272+28=1300 sur un lien 4G Bouygues. En appliquant bestialement, la commande ci-après, les commandes qui échouaient, ont fonctionné. ip link set eth0 mtu 1300 J'ai passé beaucoup de temps, pour monter dans mon labo, une plate-forme reproduisant le pb. Je n'ai pas réussi à reproduire le pb. Le lien [1] suggère que le pb est peut être lié à un firewall qui écarte les paquets fragmentés. Comme ma plate-forme de test ne comportant pas de firewall, ceci explique peut-être pourquoi je n'arrive pas à reproduire le pb. [1] http://www.snailbook.com/faq/mtu-mismatch.auto.html Merci à tous pour vos aides. Le 4 mars 2016 à 07:13, Josh <j...@pas-cuit.net> a écrit : > On 03/03/2016 17:51, Olivier wrote: > > En anticipant que l'origine du blocage serait un MTU incorrect, j'ai > > cherché à déterminer celui-ci avant la commande ci-après: > > ping -c1 -M do -s 1272 194.158.122.10 > > où 194.158.122.10 est l'adresse du serveur DNS de Bouygues. > > > > Au delà de 1272, j'ai: > > PING 194.158.122.10 (194.158.122.10) 1273(1301) bytes of data. > > > > --- 194.158.122.10 ping statistics --- > > 1 packets transmitted, 0 received, 100% packet loss, time 0ms > > > > > > > > Avec 1272 et en deçà, j'ai: > > PING 194.158.122.10 (194.158.122.10) 1272(1300) bytes of data. > > 1280 bytes from 194.158.122.10: icmp_req=1 ttl=244 time=55.1 ms > > > > --- 194.158.122.10 ping statistics --- > > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > > rtt min/avg/max/mdev = 55.123/55.123/55.123/0.000 ms > > > > > > Que penser de tout ça ? > > > > Le 3 mars 2016 à 16:37, Olivier <oza.4...@gmail.com> a écrit : > > > > Lu, > > Que c'est très moche de ne pas renvoyer le paquet icmp erreur > "fragmentation needed and DF set" ? :-) > Pourquoi, je n'en sais rien par contre. Bonne question ? > A moins que ça vienne de chez toi/que tu filtres icmp ? > > Il faut aller voir du coté des options --mssfix et --fragment d'open-vpn > pour l'empêcher de transmettre des paquets qui seraient supérieur au mtu > du/des routeurs qui posent soucis (en restant abusivement silencieux, ne > lui permettant pas de découvrir le mtu max et d'ajuster ses datagrams > udp en fonction de celui ci). > > --mssfix devrait être particulièrement utile pour ssh (et tcp en général). > > Sinon, éventuellement passer open-vpn sur tcp à la place d'udp. > > -- > Josh > >
