Pourquoi ne puis-je pas accéder à imgur.com et gravatar.com depuis Ubuntu mais je peux le faire depuis Windows?

J'ai cet étrange problème, je ne peux pas accéder à imgur.com depuis Ubuntu!

J'ai vérifié le /etc/hostsfichier, 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 le cingler ou le traceroute, je ne peux même pas cingler l'IP d'imgur. J'ai également effacé iptables, quelle pourrait ê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 (la même sortie 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.

Exécuter 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 à l'aide de PPoE.

Capturer le flux à travers Wireshark, je vois cela

_{(source: akamaihd.net )}

Curl en cours d'exécution

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 telnetting,

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 mauvais fonctionnement de certains sites Web, même si tous les autres fonctionnent correctement. Il apparaîtra comme un temps mort plutôt que comme une connexion refusée. Il n'apparaîtra qu'avec des transferts assez importants comme des pages Web entières - telnet n'enverra probablement pas de paquets qui doivent être fragmentés. Cela peut également affecter le ssh sortant.

Le correctif consiste à réduire le MTU sur votre périphérique réseau afin que les paquets au-dessus d'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, ce qui se passe, c'est que lorsque vous envoyez des données sur Internet, elles sont divisées en paquets. La taille maximale de ces paquets n'importe où sur Internet est de 1460 octets, sans les en-têtes. Si vous envoyez un message volumineux, il doit être divisé ou fragmenté.

Maintenant, si votre message passe sur 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 enveloppé dans un autre paquet. Cela augmente évidemment la taille du paquet, donc si votre paquet est déjà de taille maximale, il doit être divisé à nouveau. Cependant, comme cela peut être exploité pour effectuer des attaques DDoS, de nombreux routeurs ne fragmentent 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 de chemin MTU a été inventée. Si un paquet est trop gros pour un routeur, il renverra un message disant d'envoyer des paquets plus petits. Cependant, il s'avère que cela pourrait également être exploité, et de nombreux routeurs ne le feront pas non plus.

Ainsi, le moyen de surmonter ce problème consiste à toujours envoyer des paquets légèrement plus petits que le maximum absolu. C'est à cela que sert le paramètre MTU. L'idée est de le définir juste assez petit pour que tout frais supplémentaire ne vous place pas au-dessus de 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 toujours) par expérimentation.

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

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

Ma sortie de boucle.

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