为什么我不能从Ubuntu访问imgur.com和gravatar.com，但可以从Windows访问呢？

我有一个奇怪的问题，我无法从Ubuntu访问imgur.com！

我检查了/etc/hosts文件，似乎没有与imgur相关的条目。我可以从Windows（相同的连接）访问它。

我无法ping或跟踪路由，甚至无法ping imgur的IP。我也清除了iptables，可能是什么原因？

我也无法访问gravatar.com！我只是注意到对不起。

运行主机imgur.com（与Google的DNS服务器相同的输出）

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.

运行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  * * *

我使用PPoE拨号连接。

通过Wireshark捕获流，我看到了

_{（来源：akamaihd.net）}

连续卷曲

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

和远程登录

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.

这可能是MTU路径发现问题。即使所有其他网站都可以正常工作，这也可能导致某些网站无法正常工作。它将显示为超时而不是拒绝连接。它只会以相当大的传输量出现，例如整个网页-telnet可能不会发送任何需要分段的数据包。它也会影响传出的ssh。

解决方法是降低网络设备上的MTU，以便始终将特定大小以上的数据包分段。参见例如：

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

详细地说，发生的情况是，当您通过Internet发送数据时，数据被拆分为数据包。这些数据包在Internet上任何位置的最大大小为1460字节（不包括标头）。如果发送的消息大于该消息，则必须将其拆分或分段。

现在，如果您的消息通过某些类型的Internet链接，则必须将其封装在另一个协议中。这意味着包含报头的数据包将被包装在另一个数据包中。显然，这会增加数据包的大小，因此，如果您的数据包已经达到最大大小，则必须再次拆分。但是，由于可以利用它来执行DDoS攻击，因此许多路由器不会自动对未创建的数据包进行分段。因此，最大大小的数据包将不会穿过这些路由器。

为了避免这个问题，发明了MTU路径发现。如果数据包对于路由器而言太大，它将发回一条消息，说明要发送较小的数据包。但是，事实证明，这也可以被利用，因此很多路由器也不会这样做。

因此，解决此问题的方法是始终发送略小于绝对最大值的数据包。这就是MTU设置的目的。想法是将其设置得足够小，以免任何额外的开销都不会超出限制。当然，您不会知道它有多小，因此您必须通过实验找到最佳值（仍然有效的最大值）。

根据我对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