为什么我不能从Ubuntu访问imgur.com和gravatar.com但可以从Windows进行访问？
我有这个奇怪的问题，我无法从Ubuntu访问imgur.com！
我检查了/etc/hosts文件，似乎没有与imgur相关的条目。 我可以从Windows（相同的连接）访问它。
我无法ping它或追踪它，我甚至无法ping通imgur的IP。 我也清除了iptables，可能是什么原因？
我也无法访问gravatar.com !! 我只是注意到了抱歉。
运行主机imgur.com（与谷歌的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捕获流，我看到了这一点
跑步curl
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
和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.
这可能是MTU路径发现问题。 这可能导致某些网站工作不正常，即使所有其他网站都正常工作。 它将显示为超时而不是拒绝连接。 它只会出现像整个网页这样合理的大型传输 – telnet可能不会发送任何需要分段的数据包。 它也会影响传出的ssh。
修复方法是降低网络设备上的MTU，以便超过特定大小的数据包始终碎片化。 参见例如：
http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-discovery.html
详细地说，当您通过互联网发送数据时，它会被分成数据包。 互联网上任何地方的这些数据包的最大大小是1460字节，不包括标题。 如果您发送的邮件大于该邮件，则必须将其拆分或分段。
现在，如果您的消息超过某些类型的互联网链接，则必须将其封装在另一个协议中。 这意味着包含标头的数据包将被包含在另一个数据包中。 这显然会增加数据包的大小，因此如果您的数据包已经是最大数量，则必须再次拆分。 但是，由于可以利用此漏洞来执行DDoS攻击，因此许多路由器不会自动对未创建的数据包进行分段。 因此，您的最大大小数据包不会通过这些路由器。
为了避免这个问题，发明了MTU路径发现。 如果数据包对于路由器而言太大，它将发回一条消息，表示发送较小的数据包。 然而，事实certificate这也可以被利用，并且许多路由器也不会这样做。
因此，克服此问题的方法是始终发送略小于绝对最大值的数据包。 这就是MTU设置的用途。 我们的想法是将它设置得足够小，以至于任何额外的开销都不能超过极限。 当然你不会知道它有多小，所以你必须通过实验找到最佳值（仍然有效的最大值）。
从我所看到的你的curl输出，你可以访问它。
如果您无法在浏览器中看到它，请尝试使用其他浏览器。
我的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