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
