Perché non riesco ad accedere a imgur.com e gravatar.com da Ubuntu ma posso farlo da Windows?

Ho questo strano problema, non riesco ad accedere a imgur.com da Ubuntu!

Ho controllato il /etc/hostsfile, non sembra esserci alcuna voce relativa a imgur. Posso accedervi da Windows (stessa connessione).

Non riesco a eseguire il ping o il traceroute, non riesco nemmeno a eseguire il ping dell'IP di imgur. Ho cancellato anche iptables, quale potrebbe essere la causa?

non riesco ad accedere anche a gravatar.com !! Ho appena notato che mi dispiace.

Esecuzione dell'host imgur.com (lo stesso output con i server DNS di 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.

Esecuzione di 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  * * *

Compongo la connessione tramite PPoE.

Catturando il flusso attraverso Wireshark, vedo questo

_{(fonte: akamaihd.net )}

Curl in esecuzione

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

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

Potrebbe trattarsi di un problema di individuazione del percorso MTU. Ciò può comportare il malfunzionamento di alcuni siti Web anche se tutti gli altri funzionano correttamente. Apparirà come timeout anziché connessione rifiutata. Verrà visualizzato solo con trasferimenti ragionevolmente grandi come intere pagine Web: probabilmente Telnet non invierà alcun pacchetto che deve essere frammentato. Può influire anche su SSH in uscita.

La soluzione è abbassare l'MTU sul dispositivo di rete in modo che i pacchetti sopra una determinata dimensione siano sempre frammentati. Vedi ad esempio:

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

In dettaglio, ciò che accade è che quando si inviano dati su Internet, questi vengono suddivisi in pacchetti. La dimensione massima per questi pacchetti ovunque su Internet è 1460 byte, escluse le intestazioni. Se si invia un messaggio di grandi dimensioni, è necessario suddividerlo o frammentarlo.

Ora, se il tuo messaggio supera determinati tipi di collegamenti Internet, deve essere incapsulato in un altro protocollo. Ciò significa che il pacchetto, comprese le intestazioni, verrà avvolto all'interno di un altro pacchetto. Ciò ovviamente aumenta la dimensione del pacchetto, quindi se il pacchetto ha già la dimensione massima, deve essere nuovamente suddiviso. Tuttavia, poiché può essere sfruttato per eseguire attacchi DDoS, molti router non frammenteranno automaticamente i pacchetti che non hanno creato. Pertanto i pacchetti di dimensioni massime non attraverseranno questi router.

Per evitare questo problema è stata inventata la scoperta del percorso MTU. Se un pacchetto è troppo grande per un router, rispedirà un messaggio che dice di inviare pacchetti più piccoli. Tuttavia, si scopre che anche questo potrebbe essere sfruttato, e così anche molti router non lo faranno.

Quindi il modo per superare questo problema è inviare sempre pacchetti leggermente più piccoli del massimo assoluto. Ecco a cosa serve l'impostazione MTU. L'idea è di impostarla solo in modo che le spese generali non ti superino il limite. Ovviamente non saprai quanto è piccolo, quindi devi trovare il valore ottimale (il valore più grande che funziona ancora) attraverso la sperimentazione.

Da quello che ho visto del tuo output di curl, puoi accedervi.

Se non riesci a vederlo sul tuo browser, prova con un altro browser.

Il mio risultato di arricciatura.

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