Por que não consigo acessar imgur.com e gravatar.com do Ubuntu, mas posso fazê-lo do Windows?

8

Eu tenho esse problema estranho, não consigo acessar o imgur.com do Ubuntu!

Eu verifiquei o arquivo /etc/hosts , parece não haver entrada relacionada a imgur. Eu posso acessá-lo do Windows (mesma conexão).

Eu não consigo pingar nem rastreá-lo, não consigo nem mesmo fazer ping no IP do imgur. Eu limpei o iptables também, qual poderia ser a causa?

não consigo acessar gravatar.com também !! Eu só notei que sinto muito.

Executando o host imgur.com (a mesma saída com os servidores dns do 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.

Executando o 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  * * *

Discar a conexão usando o PPoE.

Capturando o fluxo através do Wireshark, vejo isso

Execução de onda

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.
    
por HackToHell 11.01.2013 / 12:05

2 respostas

5

Isso pode ser um problema de descoberta de caminho da MTU. Isso pode levar a que certos sites funcionem incorretamente, embora todos os outros funcionem bem. Ele aparecerá como um tempo limite em vez de conexão recusada. Ele só aparecerá com transferências razoavelmente grandes, como páginas inteiras - o telnet provavelmente não enviará nenhum pacote que precise ser fragmentado. Isso pode afetar o ssh de saída também.

A correção é reduzir o MTU em seu dispositivo de rede para que os pacotes acima de um determinado tamanho sejam sempre fragmentados. Veja por exemplo:

link

Em detalhes, o que acontece é que quando você envia dados pela internet, ele é dividido em pacotes. O tamanho máximo desses pacotes em qualquer lugar da Internet é de 1460 bytes, sem incluir cabeçalhos. Se você enviar uma mensagem maior do que isso, ela deve ser dividida ou fragmentada.

Agora, se sua mensagem ultrapassar determinados tipos de links da Internet, ela deve ser encapsulada em outro protocolo. Isso significa que o pacote incluindo os cabeçalhos serão colocados dentro de outro pacote. Isso obviamente aumenta o tamanho do pacote, então se o seu pacote já tiver tamanho máximo, ele deve ser dividido novamente. No entanto, como isso pode ser explorado para executar ataques DDoS, muitos roteadores não fragmentam automaticamente os pacotes que não criaram. Portanto, seus pacotes de tamanho máximo não cruzarão esses roteadores.

Para evitar esse problema, a descoberta do caminho da MTU foi inventada. Se um pacote for grande demais para um roteador, ele enviará uma mensagem dizendo para enviar pacotes menores. No entanto, isso também pode ser explorado, e muitos roteadores também não farão isso.

Portanto, a maneira de superar esse problema é sempre enviar pacotes um pouco menores que o máximo absoluto. É para isso que serve a configuração da MTU. A idéia é configurá-lo apenas o suficiente para que qualquer sobrecarga extra não ultrapasse o limite. É claro que você não saberá quão pequeno é isso, então você tem que encontrar o valor ideal (maior valor que ainda funciona) por experimentação.

    
por Alistair Buxton 20.06.2013 / 11:42
0

Pelo que vi da sua saída de curvas, você pode acessá-lo.

Se você não conseguir vê-lo no seu navegador, tente usar outro navegador.

Minha saída de onda.

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
    
por ggarron 12.01.2013 / 04:23