Dlaczego nie mogę uzyskać dostępu do imgur.com i gravatar.com z Ubuntu, ale mogę to zrobić z systemu Windows?

Mam ten dziwny problem, nie mogę uzyskać dostępu do imgur.com z Ubuntu!

Sprawdziłem /etc/hostsplik, wydaje się, że nie ma wpisu związanego z imgur. Mogę uzyskać do niego dostęp z systemu Windows (to samo połączenie).

Nie mogę pingować ani śledzić, nie mogę nawet pingować adresu IP imgur. Wyczyściłem też iptables, co może być przyczyną?

nie mogę uzyskać dostępu do gravatar.com !! Właśnie to zauważyłem.

Uruchamianie hosta imgur.com (to samo wyjście z serwerami 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.

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

Wybieram połączenie za pomocą PPoE.

Widzę to, przechwytywanie strumienia przez Wireshark

_{(źródło: akamaihd.net )}

Zwijanie się

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

I 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.

Może to być problem z wykrywaniem ścieżki MTU. Może to prowadzić do nieprawidłowego działania niektórych witryn, nawet jeśli wszystkie inne działają poprawnie. Pojawi się jako przerwa, a nie odmowa połączenia. Będzie się wyświetlał tylko przy stosunkowo dużych transferach, takich jak całe strony internetowe - telnet prawdopodobnie nie wyśle ​​żadnych pakietów, które wymagają fragmentacji. Może również wpływać na wychodzące ssh.

Rozwiązaniem jest obniżenie MTU na urządzeniu sieciowym, aby pakiety powyżej pewnego rozmiaru były zawsze pofragmentowane. Zobacz na przykład:

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

Szczegółowo dzieje się tak, że gdy wysyłasz dane przez Internet, są one dzielone na pakiety. Maksymalny rozmiar tych pakietów w dowolnym miejscu w Internecie wynosi 1460 bajtów bez nagłówków. Jeśli wiadomość jest większa niż ta, należy ją podzielić lub pofragmentować.

Teraz, jeśli twoja wiadomość przechodzi przez pewne typy łączy internetowych, musi być zawarta w innym protokole. Oznacza to, że pakiet zawierający nagłówki zostanie zawinięty w inny pakiet. To oczywiście zwiększa rozmiar pakietu, więc jeśli pakiet ma już maksymalny rozmiar, należy go ponownie podzielić. Ponieważ jednak można to wykorzystać do przeprowadzenia ataków DDoS, wiele routerów nie będzie automatycznie fragmentować pakietów, których nie utworzyły. Dlatego pakiety o maksymalnym rozmiarze nie przekroczą tych routerów.

Aby uniknąć tego problemu, wynaleziono ścieżkę MTU. Jeśli pakiet jest zbyt duży dla routera, odeśle wiadomość z informacją, że należy wysłać mniejsze pakiety. Okazuje się jednak, że można to również wykorzystać i tak wiele routerów też tego nie zrobi.

Tak więc sposobem na rozwiązanie tego problemu jest zawsze wysyłanie pakietów nieco mniejszych niż absolutne maksimum. Do tego służy ustawienie MTU. Chodzi o to, aby ustawić go na tyle, aby dodatkowe obciążenie nie spowodowało przekroczenia limitu. Oczywiście nie będziesz wiedział, jak małe to jest, więc musisz znaleźć optymalną wartość (największą wartość, która nadal działa) przez eksperymenty.

Z tego, co widziałem z twoich wyników curl, możesz uzyskać do niego dostęp.

Jeśli nie widzisz tego w przeglądarce, spróbuj użyć innej przeglądarki.

Mój wynik 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