Tại sao tôi không thể truy cập imgur.com và gravatar.com từ Ubuntu nhưng có thể làm như vậy từ Windows?

Tôi gặp vấn đề kỳ lạ này, tôi không thể truy cập imgur.com từ Ubuntu!

Tôi đã kiểm tra /etc/hoststệp, dường như không có mục nào liên quan đến imgur. Tôi có thể truy cập nó từ Windows (cùng kết nối).

Tôi không thể ping nó hoặc theo dõi nó, tôi thậm chí không thể ping IP của imgur. Tôi cũng đã xóa iptables, nguyên nhân có thể là gì?

tôi cũng không thể truy cập gravatar.com !! Tôi chỉ nhận thấy rằng xin lỗi.

Chạy máy chủ imgur.com (cùng một đầu ra với các máy chủ dns của 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.

Chạy 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  * * *

Tôi quay số kết nối bằng PPoE.

Bắt luồng qua Wireshark, tôi thấy điều này

_{(nguồn: akamaihd.net )}

Chạy cong

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

Và dịch chuyển

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.

Đây có thể là một vấn đề phát hiện đường dẫn MTU. Điều này có thể dẫn đến một số trang web hoạt động không chính xác mặc dù tất cả các trang web khác hoạt động tốt. Nó sẽ xuất hiện như một thời gian chờ chứ không phải kết nối từ chối. Nó sẽ chỉ hiển thị với các chuyển khoản lớn một cách hợp lý như toàn bộ trang web - telnet có thể sẽ không gửi bất kỳ gói tin nào cần phải phân mảnh. Nó có thể ảnh hưởng đến ssh đi quá.

Cách khắc phục là hạ MTU trên thiết bị mạng của bạn để các gói trên một kích thước nhất định luôn bị phân mảnh. Xem ví dụ:

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

Cụ thể những gì xảy ra là khi bạn gửi dữ liệu qua internet, nó được chia thành các gói. Kích thước tối đa cho các gói này ở bất cứ đâu trên internet là 1460 byte không bao gồm các tiêu đề. Nếu bạn gửi một tin nhắn lớn hơn thì nó phải được chia ra hoặc phân mảnh.

Bây giờ, nếu tin nhắn của bạn đi qua một số loại liên kết internet nhất định, nó phải được gói gọn trong một giao thức khác. Điều đó có nghĩa là gói bao gồm các tiêu đề sẽ được bọc bên trong gói khác. Điều đó rõ ràng làm tăng kích thước của gói, vì vậy nếu gói của bạn đã có kích thước tối đa thì nó phải được chia lại. Tuy nhiên, vì điều này có thể được khai thác để thực hiện các cuộc tấn công DDoS, nhiều bộ định tuyến sẽ không tự động phân đoạn các gói mà chúng không tạo ra. Do đó, gói kích thước tối đa của bạn sẽ không vượt qua các bộ định tuyến này.

Để tránh vấn đề này, phát hiện đường dẫn MTU đã được phát minh. Nếu một gói quá lớn cho một bộ định tuyến, nó sẽ gửi lại một thông báo nói rằng gửi các gói nhỏ hơn. Tuy nhiên, hóa ra điều này cũng có thể bị khai thác và rất nhiều bộ định tuyến sẽ không làm điều đó.

Vì vậy, cách khắc phục vấn đề này là luôn gửi các gói nhỏ hơn một chút so với mức tối đa tuyệt đối. Đó là những gì cài đặt MTU dành cho. Ý tưởng là đặt nó đủ nhỏ để bất kỳ chi phí phụ nào không đưa bạn vượt quá giới hạn. Tất nhiên bạn sẽ không biết nó nhỏ đến mức nào nên bạn phải tìm giá trị tối ưu (giá trị lớn nhất vẫn hoạt động) bằng thử nghiệm.

Từ những gì tôi đã thấy về đầu ra curl của bạn, bạn có thể truy cập nó.

Nếu bạn không thể nhìn thấy nó trên trình duyệt của mình, hãy thử với một trình duyệt khác.

Đầu ra curl của tôi.

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