Pourquoi ne puis-je pas accéder à imgur.com et gravatar.com à partir d’Ubuntu mais à Windows?

J’ai ce problème étrange, je ne peux pas accéder à imgur.com à partir d’Ubuntu!

J’ai vérifié le fichier /etc/hosts , il ne semble pas y avoir d’entrée liée à imgur. Je peux y accéder depuis Windows (même connexion).

Je ne peux pas cingler ou traceroute, je ne peux même pas cingler l’adresse IP de imgur. J’ai aussi nettoyé iptables, quelle pourrait en être la cause?

Je ne peux pas accéder à gravatar.com aussi !! Je viens de remarquer que désolé.

Exécution de l’hôte imgur.com (même résultat avec les serveurs DNS de Google)

 gowtham@gowtham-hacktohell:~$ host imgur.com imgur.com has address 23.23.110.58 imgur.com has address 23.23.110.81 imgur.com has address 54.243.128.92 imgur.com mail is handled by 5 alt1.aspmx.l.google.com. imgur.com mail is handled by 1 aspmx.l.google.com. imgur.com mail is handled by 10 aspmx2.googlemail.com. imgur.com mail is handled by 5 alt2.aspmx.l.google.com. imgur.com mail is handled by 10 aspmx3.googlemail.com.

Lancer tcptraceroute

 gowtham@gowtham-hacktohell:~$ tcptraceroute imgur.com Selected device ppp0, address 117.199.141.54, port 44995 for outgoing packets Tracing the path to imgur.com (54.243.128.92) on TCP port 80 (http), 30 hops max 1 117.199.128.1 17.534 ms 17.764 ms 17.896 ms 2 218.248.171.102 93.272 ms 26.393 ms 109.985 ms 3 115.114.130.49.STATIC-Chennai.vsnl.net.in (115.114.130.49) 49.442 ms 47.180 ms 46.981 ms 4 * * * 5 ix-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) 70.085 ms 69.712 ms 70.361 ms 6 if-2-2.tcore1.MLV-Mumbai.as6453.net (180.87.38.1) 186.862 ms 186.434 ms 185.515 ms 7 if-9-5.tcore1.WYN-Marseille.as6453.net (80.231.217.17) 181.965 ms 182.963 ms 184.682 ms 8 if-8-1600.tcore1.PYE-Paris.as6453.net (80.231.217.6) 186.152 ms 184.483 ms 182.950 ms 9 if-12-2.tcore1.PVU-Paris.as6453.net (80.231.154.70) 191.271 ms 189.655 ms 188.606 ms 10 if-3-2.tcore1.FR0-Frankfurt.as6453.net (80.231.153.54) 187.245 ms 186.013 ms 193.808 ms 11 xe-0-1-0-6.r02.frnkge03.de.bb.gin.ntt.net (129.250.9.57) 288.412 ms 281.124 ms 281.011 ms 12 ae-2.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.217) 352.432 ms 357.071 ms 357.256 ms 13 ae-1.r21.asbnva02.us.bb.gin.ntt.net (129.250.3.20) 391.405 ms 394.961 ms 391.812 ms 14 ae-2.r00.asbnva02.us.bb.gin.ntt.net (129.250.3.114) 378.128 ms 381.786 ms 385.697 ms 15 ae-4.amazon.asbnva02.us.bb.gin.ntt.net (168.143.232.50) 370.938 ms 353.306 ms 351.793 ms 16 72.21.220.55 361.004 ms * 364.525 ms 17 205.251.245.55 368.187 ms 380.907 ms 375.333 ms 18 * * * 19 * * * 20 * * *

Je compose la connexion en utilisant PPoE.

Capturer le stream à travers Wireshark, je le vois

Running curl

 gowtham@gowtham-hacktohell:~$ curl -I http://imgur.com HTTP/1.1 200 OK Server: nginx Date: Fri, 11 Jan 2013 12:24:01 GMT Content-Type: text/html Connection: keep-alive Cache-Control: max-age=5, s-maxage=5, must-revalidate X-Cached: EXPIRED

Et le telnet,

 gowtham@gowtham-hacktohell:~$ telnet imgur.com 80 Trying 23.23.110.58... Connected to imgur.com. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Server: nginx Date: Fri, 11 Jan 2013 12:25:11 GMT Content-Type: text/html Connection: close Cache-Control: max-age=5, s-maxage=5, must-revalidate X-Cached: HIT Connection closed by foreign host.

Cela peut être un problème de découverte de chemin MTU. Cela peut entraîner un fonctionnement incorrect de certains sites Web, même si tous les autres fonctionnent correctement. Il apparaîtra comme un délai d’attente plutôt que de connexion refusée. Il apparaîtra uniquement avec des transferts relativement importants, tels que des pages Web entières – telnet n’enverra probablement aucun paquet devant être fragmenté. Cela peut aussi affecter les SSH sortants.

Le correctif consiste à abaisser le MTU sur votre périphérique réseau afin que les paquets dépassant une certaine taille soient toujours fragmentés. Voir par exemple:

http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-discovery.html

En détail, lorsque vous envoyez des données par Internet, elles sont scindées en paquets. La taille maximale de ces paquets sur l’Internet est de 1 460 octets, sans en-tête. Si vous envoyez un message plus volumineux, il doit être divisé ou fragmenté.

Maintenant, si votre message passe par certains types de liens Internet, il doit être encapsulé dans un autre protocole. Cela signifie que le paquet, y compris les en-têtes, sera emballé dans un autre paquet. Cela augmente évidemment la taille du paquet, donc si votre paquet a déjà une taille maximale, il doit être divisé à nouveau. Cependant, comme ceci peut être exploité pour réaliser des attaques DDoS, de nombreux routeurs ne fragmenteront pas automatiquement les paquets qu’ils n’ont pas créés. Par conséquent, vos paquets de taille maximale ne traverseront pas ces routeurs.

Afin d’éviter ce problème, la découverte du chemin MTU a été inventée. Si un paquet est trop gros pour un routeur, il enverra un message disant d’envoyer des paquets plus petits. Cependant, il s’avère que cela pourrait également être exploité et que de nombreux routeurs ne le feront pas non plus.

Pour résoudre ce problème, vous devez donc toujours envoyer des paquets légèrement inférieurs au maximum absolu. C’est à cela que sert le paramètre MTU. L’idée est de le définir juste assez petit pour que les frais généraux supplémentaires ne vous fassent pas dépasser la limite. Bien sûr, vous ne saurez pas à quel point c’est petit, vous devez donc trouver la valeur optimale (la plus grande valeur qui fonctionne encore) par expérimentation.

D’après ce que j’ai vu de votre sortie de boucle, vous pouvez y accéder.

Si vous ne le voyez pas sur votre navigateur, essayez avec un autre navigateur.

Ma sortie curl.

 curl -I http://imgur.com HTTP/1.1 200 OK Server: nginx Date: Sat, 12 Jan 2013 03:21:00 GMT Content-Type: text/html Connection: keep-alive Cache-Control: max-age=5, s-maxage=5, must-revalidate X-Cached: HIT