ทำไมฉันถึงไม่สามารถเข้าถึง imgur.com และ gravatar.com จาก Ubuntu แต่ทำได้จาก Windows

ฉันมีปัญหาแปลก ๆ นี้ฉันไม่สามารถเข้าถึง imgur.com จาก Ubuntu ได้!

ฉันตรวจสอบ/etc/hostsไฟล์แล้วดูเหมือนว่าจะไม่มีรายการที่เกี่ยวข้องกับ imgur ฉันสามารถเข้าถึงได้จาก Windows (การเชื่อมต่อเดียวกัน)

ฉันไม่สามารถ ping หรือติดตามมันฉันไม่สามารถ ping IP ของ imgur ได้ ฉันลบ iptables ด้วยสาเหตุอาจเกิดจากอะไร

ฉันไม่สามารถเข้าถึง gravatar.com ด้วยเช่นกัน !! ฉันเพิ่งสังเกตเห็นว่าขอโทษ

ใช้งานโฮสต์ imgur.com (ผลลัพธ์เดียวกันกับเซิร์ฟเวอร์ dns ของ 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.

กำลังรัน 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

และ 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 ถูกคิดค้น หากแพ็กเก็ตใหญ่เกินไปสำหรับเราเตอร์มันจะส่งข้อความกลับไปบอกว่าจะส่งแพ็คเก็ตขนาดเล็กลง อย่างไรก็ตามปรากฎว่าสิ่งนี้อาจถูกนำไปใช้ประโยชน์เช่นกันและเราเตอร์จำนวนมากจะไม่ทำเช่นนั้น

ดังนั้นวิธีที่จะเอาชนะปัญหานี้คือการส่งแพ็กเก็ตเล็กกว่าค่าสูงสุดเล็กน้อยเสมอ นั่นคือการตั้งค่า MTU แนวคิดคือการตั้งค่าให้เล็กพอที่ค่าใช้จ่ายเพิ่มเติมใด ๆ จะไม่ทำให้คุณเกินขีด จำกัด แน่นอนคุณจะไม่ทราบว่ามีขนาดเล็กเพียงใดดังนั้นคุณต้องค้นหาค่าที่ดีที่สุด

จากสิ่งที่ฉันได้เห็นจากเอาต์พุตของคุณคุณสามารถเข้าถึงได้

หากคุณไม่เห็นบนเบราว์เซอร์ลองด้วยเบราว์เซอร์อื่น

เอาท์พุทขดของฉัน

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