¿Por qué no puedo acceder a imgur.com y gravatar.com desde Ubuntu pero puedo hacerlo desde Windows?

¡Tengo este extraño problema, no puedo acceder a imgur.com desde Ubuntu!

He comprobado el /etc/hostsarchivo, parece que no hay ninguna entrada relacionada con imgur. Puedo acceder desde Windows (misma conexión).

No puedo hacer ping ni trazarlo, ni siquiera puedo hacer ping a la IP de imgur. También borré iptables, ¿cuál podría ser la causa?

¡No puedo acceder a gravatar.com también! Acabo de notar que lo siento.

Ejecutando host imgur.com (el mismo resultado con los servidores 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.

Ejecutando 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  * * *

Marco la conexión usando PPoE.

Capturando la corriente a través de Wireshark, veo esto

_{(fuente: akamaihd.net )}

Rizo corriendo

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

Y 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.

Esto puede ser un problema de descubrimiento de ruta MTU. Esto puede hacer que ciertos sitios web funcionen incorrectamente, aunque todos los demás funcionen bien. Aparecerá como un tiempo de espera en lugar de una conexión rechazada. Solo se mostrará con transferencias razonablemente grandes, como páginas web completas; telnet probablemente no enviará ningún paquete que deba fragmentarse. También puede afectar a ssh salientes.

La solución es reducir la MTU en su dispositivo de red para que los paquetes por encima de cierto tamaño siempre estén fragmentados. Ver por ejemplo:

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

En detalle, lo que sucede es que cuando envía datos a través de Internet, se divide en paquetes. El tamaño máximo de estos paquetes en cualquier lugar de Internet es de 1460 bytes, sin incluir encabezados. Si envía un mensaje grande, debe dividirse o fragmentarse.

Ahora, si su mensaje pasa por ciertos tipos de enlaces de Internet, debe estar encapsulado en otro protocolo. Eso significa que el paquete, incluidos los encabezados, quedará envuelto dentro de otro paquete. Obviamente, esto aumenta el tamaño del paquete, por lo que si su paquete ya tiene el tamaño máximo, debe dividirse nuevamente. Sin embargo, debido a que esto puede explotarse para realizar ataques DDoS, muchos enrutadores no fragmentarán automáticamente los paquetes que no crearon. Por lo tanto, sus paquetes de tamaño máximo no cruzarán estos enrutadores.

Para evitar este problema, se inventó el descubrimiento de la ruta MTU. Si un paquete es demasiado grande para un enrutador, enviará un mensaje que le indicará que envíe paquetes más pequeños. Sin embargo, resulta que esto también podría explotarse, y muchos enrutadores tampoco lo harán.

Entonces, la forma de superar este problema es enviar siempre paquetes un poco más pequeños que el máximo absoluto. Para eso está la configuración de MTU. La idea es establecerlo lo suficientemente pequeño como para que cualquier sobrecarga adicional no lo supere. Por supuesto, no sabrá qué tan pequeño es, por lo que debe encontrar el valor óptimo (el valor más grande que aún funciona) mediante la experimentación.

Por lo que he visto de su salida de rizo, puede acceder a ella.

Si no puede verlo en su navegador, intente con otro navegador.

Mi salida de rizo.

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