Mengapa saya tidak dapat mengakses imgur.com dan gravatar.com dari Ubuntu tetapi dapat melakukannya dari Windows?

8

Saya memiliki masalah aneh ini, saya tidak dapat mengakses imgur.com dari Ubuntu!

Saya telah memeriksa /etc/hostsfile, sepertinya tidak ada entri terkait dengan imgur. Saya dapat mengaksesnya dari Windows (koneksi yang sama).

Saya tidak bisa ping atau traceroute, saya bahkan tidak bisa ping IP imgur. Saya sudah iptables juga, apa penyebabnya?

saya tidak dapat mengakses gravatar.com juga !! Saya hanya memperhatikan bahwa maaf.

Menjalankan host imgur.com (output yang sama dengan server 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.

Menjalankan 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  * * *

Saya memanggil koneksi menggunakan PPoE.

Menangkap arus melalui Wireshark, saya melihat ini


(sumber: akamaihd.net )

Running 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

Dan 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.
HackToHell
sumber
Saya juga tidak bisa melakukan ping imgur.com, tetapi, AFAICT, Tanya Ubuntu bergantung pada situs itu untuk grafik dan tampilan itu baik-baik saja.
Gambar AU tidak dimuat untuk saya: '(imgur mungkin telah menonaktifkan balasan icmp
HackToHell
Maaf! Saya bisa ping dengan i.stack.imgur.comsukses. Di situlah (setidaknya sebagian) gambar berada. Apakah Anda mulai mengalami masalah ini baru-baru ini? Karena Anda berhasil melalui Windows, ISP / DNS tampaknya tidak bisa disalahkan ...
Mungkin filter di router Anda? Satu yang hanya menargetkan IP / MAC mesin Ubuntu Anda.
Kevin
2
Layak dicoba. Anda tidak menentukan apa pun tentang di mana OS Anda berada. Mesin yang terpisah, VMs dll- akan memiliki MAC yang berbeda. Flatmates saya sering rig router dengan filter lelucon.
Kevin

Jawaban:

5

Ini mungkin masalah penemuan jalur MTU. Ini dapat menyebabkan situs web tertentu tidak berfungsi dengan benar meskipun semua yang lain berfungsi dengan baik. Ini akan muncul sebagai waktu habis daripada koneksi ditolak. Ini hanya akan muncul dengan transfer yang cukup besar seperti seluruh halaman web - telnet mungkin tidak akan mengirim paket apa pun yang perlu difragmentasi. Ini juga dapat mempengaruhi ssh keluar.

Cara mengatasinya adalah menurunkan MTU pada perangkat jaringan Anda sehingga paket di atas ukuran tertentu selalu terfragmentasi. Lihat misalnya:

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

Secara terperinci apa yang terjadi adalah ketika Anda mengirim data melalui internet, data itu dibagi menjadi beberapa paket. Ukuran maksimum untuk paket-paket ini di mana saja di internet adalah 1460 byte tidak termasuk header. Jika Anda mengirim pesan yang lebih besar dari itu, pesan itu harus dibagi, atau difragmentasi.

Sekarang, jika pesan Anda membahas jenis tautan internet tertentu, pesan itu harus dienkapsulasi dalam protokol lain. Itu berarti bahwa paket termasuk header akan dibungkus dengan paket lain. Itu jelas meningkatkan ukuran paket, jadi jika paket Anda sudah ukuran maksimum itu harus dibagi lagi. Namun, karena ini dapat dieksploitasi untuk melakukan serangan DDoS, banyak router tidak akan secara otomatis memecah paket yang tidak mereka buat. Oleh karena itu paket ukuran maksimum Anda tidak akan melewati router ini.

Untuk menghindari masalah ini, penemuan jalur MTU ditemukan. Jika sebuah paket terlalu besar untuk sebuah router, itu akan mengirim kembali pesan yang mengatakan untuk mengirim paket yang lebih kecil. Namun, ternyata ini bisa dieksploitasi juga, dan begitu banyak router tidak akan melakukannya.

Jadi cara untuk mengatasi masalah ini adalah dengan selalu mengirim paket sedikit lebih kecil dari maksimum absolut. Untuk itulah pengaturan MTU. Idenya adalah untuk mengaturnya cukup kecil sehingga setiap overhead tambahan tidak membuat Anda melebihi batas. Tentu saja Anda tidak akan tahu seberapa kecil itu sehingga Anda harus menemukan nilai optimal (nilai terbesar yang masih berfungsi) dengan eksperimen.

Alistair Buxton
sumber
MTU pada 1, masih memiliki masalah: C
HackToHell
Wah, banyak imgur !!!! Ini sangat lambat !! Terima kasih: 0
HackToHell
MTU pada 1 jauh terlalu rendah. Coba 400, 800 dll. Tingkatkan sampai berhenti bekerja.
Alistair Buxton
Saya menambahkan beberapa detail pada jawabannya. MTU = 1 berarti Anda mengirim seluruh paket untuk setiap byte data yang dikirim. Setiap paket memiliki header 8 byte sehingga Anda kehilangan hampir 90% dari bandwidth Anda pada header paket dengan cara ini.
Alistair Buxton
Saya memiliki MTU di 549 sekarang, hampir semua situs memuat sekarang <3
HackToHell
0

Dari apa yang saya lihat dari output ikal Anda, Anda dapat mengaksesnya.

Jika Anda tidak dapat melihatnya di browser Anda, coba dengan browser lain.

Output ikal saya.

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
Ggarron
sumber
1
Sebagian besar yang diposting OP tidak melibatkan penggunaan browser, browser apa pun.