Website nicht erreichbar - aber warum?

[X_FISH]

Ich schaue zwischendurch zur Ablenkung gerne mal bei 9gag.com vorbei. Nur geht das bei meiner Linuxkiste nicht mehr. Ich finde jedoch keine Ursache.

Bisherige Analyse:

~ $ ping 9gag.com
PING 9gag.com (176.34.112.194) 56(84) bytes of data.
^C
--- 9gag.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

Wenn ich eine der Seiten zum Checken von Verfügbarkeit im Netz nutze, beispielsweise http://www.issitedownrightnow.com/status/de/9gag.com , erhalte ich eine andere IP für 9gag.com?

In vielen Fällen liegt das Problem jedoch an korrupter DNS. In dem Fall verwenden Sie einfach diese IP Adresse (50.18.62.138), geben Sie sie in das Adressfeld Ihres Browsers ein und drücken Eingabe. Wenn es funktioniert, dann seien Sie versichert, es ist ein DNS Fehler.

50.18.62.138 via Onlinetest, 176.34.112.194 per ping? WTF?

DNS war Kabel-BW, habe ich jetzt auf OpenDNS geändert - gleiches Resultat.

Mit der Windowskiste klappt es problemlos: 9gag ist erreichbar. Angeschlossen sind beide Rechner per Kabel über einen Switch, daran sollte es also auch nicht liegen.

Hat jemand 'ne Idee was da »verbogen« sein könnte?

Grüße, Martin

 

[Dalai]

Ein nslookup auf die 50.18.62.138 zeigt, dass dahinter ein Amazon EC2 Server steckt. Ein nslookup auf 9gag.com zeigt diese IP-Adressen: 176.34.246.218, 176.34.112.194. Übrigens lässt ein Ping keine Aussagen über die Erreichbarkeit eines Webservers zu, und zu oft noch nicht einmal über die Erreichbarkeit eines Systems, weil man Antworten auf Echorequests (Pings) auch unterlassen kann.

Ich würde mal mit

telnet 9gag.com 80

auf dem Linux-System einen Zugriff probieren. Oder mit einem anderen Browser.

MfG Dalai

 

[Eye-Q]

9gag wird nicht nur auf einem Server gehostet, sondern über ein CDN, weswegen unterschiedliche PCs auch unterschiedliche IP-Adressen für den DNS-Namen 9gag.com zurückbekommen können.

Dass die entsprechenden Server nicht auf Ping antworten, ist wahrscheinlich gewollt, auch von meinem PC aus laufen Pings auf 9gag.com ins Leere, obwohl ich auf die Website komme. Ping ist allerdings ICMP, HTTP(S) ist TCP, die haben wenig miteinander zu tun, außer dass sie über die selbe Infrastruktur laufen.

Auch ich würde es mal mit einem anderen Browser versuchen.

 

[Riddler82]

Wenn es Windows-Server sind reagieren die Standardmäßig nicht auf ICMP.

Hast du schon versucht den DNS-Cache gezielt zu leeren von deiner Linuxkiste?

hast du mal ein mtr oder tracerout/tracepath probiert stattdessen?

PS: Der Tipp mit der IP ist nutzlos wenn unter einer IP mehrere Domains gehosted sind. Entweder kommt dann eine fehlerseite oder die Default-Domain.

 

[Dalai]

Hast du schon versucht den DNS-Cache gezielt zu leeren von deiner Linuxkiste?

AFAIK verwenden Linux-Systeme standardmäßig keinen DNS-Cache sondern fragen für so ziemlich jede Anfrage ihren DNS-Server. Ich kenne jedenfalls keinen Befehl zu ipconfig /flushdns für Linux. Und selbst wenn man nach "linux flush dns cache" sucht, findet man in erster Linie Angaben zu den DNS-Servern sowie zu nicht standardmäßig (vor)installierten Daemons.

MfG Dalai

 

[Riddler82]

Mag sein, dass es "standardmäßig" keinen DNS-Cache nutzt. Aber es hat auch niemand gesagt, dass nicht einer nachträglich aktiviert wurde, oder?

Ich selber habe hier in Firma nauch schon öfter das Phänomen gehabt, dass bei mir lokal eine Domain falsch aufgelöst hat, obwohl theoretisch kein eigener Cache da sein dürfte und alle Kollegen die selben internen Nameserver benutzen.

Oft hat es sich dann nach mehrfachem Drücken von STRG+F5 bzw STRG+R gegeben.

ggf. wäre auch mal interessant was so in der /etc/hosts steht oder was route -n und die resolv.conf so sagen.

 

[X_FISH]

Der Ping sollte für die Ermittlung der aufgelösten IP dienen. Hätte ich evtl. dazuschreiben sollen.

Browser: Mehrere genutzt, scheint also nicht vom Client abhängig zu sein (Chrome, Chromium, Firefox -> alle ohne Erfolg.

An der Distro selbst wird es auch nicht liegen (Mint 17.2). Nutze es auch an zwei anderen Kisten - allerdings an einem anderen Ort - und kann dort problemlos auf 9gag.com zugreifen.

~ $ telnet 9gag.com 80
Trying 176.34.112.194...
Connected to 9gag.com.
Escape character is '^]'.
GET / HTTP/1.1
HOST 9gag.com
HTTP/1.1 400 BAD_REQUEST
Content-Length: 0
Connection: Close

Connection closed by foreign host.

Grüße, Martin

 

[Dalai]

Oft hat es sich dann nach mehrfachem Drücken von STRG+F5 bzw STRG+R gegeben.

Aha, also geht's um einen Browser. Der hat möglicherweise einen Cache, aber der hat nichts mit dem des Systems zu tun.

@X_FISH: Irgendein Proxy im System bzw. Browser eingetragen?

MfG Dalai

 

[Riddler82]

Ob es bei mir wirklich am Browser liegt ist auch nicht ganz sicher, weil es auch bei mir mehrere Browser betrifft.

Nebenbei: Ich verdiene meine Brötchen mit der Betreuung von einigen tausend Linux-Kisten, deinen belehrenden Ton kannst du für dich behalten. Aber nobody is perfect, niemand weiß alles.

edit: ich hatte auch schon den Fall, dass ein DIG hier verschiedene Ergebnisse brachte, obwohl beide Systeme die selben Vorraussetzungen hatten, warum haben wir nie rausgefunden, irgendwann stimmte es dann auf beiden. Und da war der Browser definitiv außen vor.

 

[X_FISH]

Kein Proxy in der Browserconfig, kein Proxy in der Netzwerkadmin (GUI-Assistenten durchgeschaut).

Es ist auch kein Anonymisierungsgedöns installiert. Was ich allerdings noch ausprobieren könnte: Seite via Tor Browser aufrufen. Ob sich dann etwas ändert -> melde ich dann heute Nachmittag durch, bin gerade nicht am Gerät.

Grüße, Martin

--- Update ---

Update: Per Tor Browser kann ich die Seite aufrufen.

Grüße, Martin

 

[Dalai]

Ja, dann prüf mal mit tracert & Co, wie weit du kommst, wie bereits von Riddler82 vorgeschlagen. Ich hatte auch mal einen Fall, dass ich von meinem Anschluss eine bestimmte Seite nicht erreichen konnte, was aber auf eine (möglicherweise?) andere Ursache zurückzuführen war.

MfG Dalai

 

[X_FISH]

Linux:

~ $ traceroute -m 90 9gag.com
traceroute to 9gag.com (176.34.112.194), 90 hops max, 60 byte packets
 1  172.30.9.223 (172.30.9.223)  8.994 ms  10.140 ms  9.557 ms
 2  172.30.9.222 (172.30.9.222)  10.917 ms  10.911 ms  10.898 ms
 3  84.116.190.6 (84.116.190.6)  13.819 ms  14.399 ms  14.396 ms
 4  de-fra01a-rd3-xe-0-2-1.aorta.net (84.116.134.9)  15.017 ms  15.012 ms  14.369 ms
 5  84.116.133.97 (84.116.133.97)  14.994 ms  17.301 ms us-was02a-ri1-ge-4-1-0.aorta.net (84.116.130.206)  17.306 ms
 6  178.236.15.20 (178.236.15.20)  17.293 ms  25.082 ms  12.852 ms
 7  54.239.62.193 (54.239.62.193)  14.556 ms 54.239.62.197 (54.239.62.197)  16.176 ms  15.572 ms
 8  54.239.62.206 (54.239.62.206)  14.519 ms 54.239.62.210 (54.239.62.210)  13.937 ms 54.239.62.204 (54.239.62.204)  14.503 ms
 9  54.239.5.34 (54.239.5.34)  36.848 ms 54.239.5.76 (54.239.5.76)  39.146 ms 54.239.107.122 (54.239.107.122)  51.070 ms
10  54.239.107.111 (54.239.107.111)  36.814 ms 54.239.5.25 (54.239.5.25)  39.695 ms 54.239.5.55 (54.239.5.55)  37.553 ms
11  * 54.239.5.25 (54.239.5.25)  39.661 ms  39.636 ms
12  178.236.0.225 (178.236.0.225)  41.376 ms 178.236.1.141 (178.236.1.141)  34.659 ms 178.236.0.227 (178.236.0.227)  34.077 ms
13  178.236.1.139 (178.236.1.139)  34.073 ms  31.655 ms 178.236.0.218 (178.236.0.218)  35.881 ms
14  178.236.0.214 (178.236.0.214)  34.189 ms 178.236.0.218 (178.236.0.218)  35.138 ms 178.236.0.216 (178.236.0.216)  32.100 ms
15  176.32.106.131 (176.32.106.131)  33.086 ms * *
16  * * *
17  * * *
18  ec2-79-125-1-97.eu-west-1.compute.amazonaws.com (79.125.1.97)  35.597 ms  36.180 ms *
19  * ec2-79-125-1-103.eu-west-1.compute.amazonaws.com (79.125.1.103)  38.728 ms  37.792 ms
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
31  * * *
32  * * *
33  * * *
34  * * *
35  * * *
36  * * *
37  * * *
38  * * *
39  * * *
40  * * *
41  * * *
42  * * *
43  * * *
44  * * *
45  * * *
46  * * *
47  * * *
48  * * *
49  * * *
50  * * *
51  * * *
52  * * *
53  * * *
54  * * *
55  * * *
56  * * *
57  * * *
58  * * *
59  * * *
60  * * *
61  * * *
62  * * *
63  * * *
64  * * *
65  * * *
66  * * *
67  * * *
68  * * *
69  * * *
70  * * *
71  * * *
72  * * *
73  * * *
74  * * *
75  * * *
76  * * *
77  * * *
78  * * *
79  * * *
80  * * *
81  * * *
82  * * *
83  * * *
84  * * *
85  * * *
86  * * *
87  * * *
88  * * *
89  * * *
90  * * *

_____

Windows (Seite wird im Browser angezeigt):

C:\Users\Bender>tracert -h 90 9gag.com

Routenverfolgung zu 9gag.com [176.34.112.194] über maximal 90 Abschnitte:

  1     9 ms     9 ms     8 ms  172.30.9.223
  2     9 ms    12 ms    12 ms  84.116.190.6
  3    12 ms    30 ms    17 ms  de-fra01a-rd3-xe-0-2-1.aorta.net [84.116.1

  4    14 ms    13 ms    13 ms  84.116.133.97
  5    12 ms    13 ms    13 ms  178.236.15.20
  6    13 ms     *       12 ms  178.236.15.20
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8    12 ms    47 ms    52 ms  54.239.107.14
  9    52 ms     *       54 ms  54.239.107.14
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11    36 ms    33 ms     *     54.239.41.147
 12     *       34 ms    41 ms  178.236.0.229
 13    33 ms    35 ms    36 ms  178.236.0.218
 14    35 ms    33 ms    33 ms  176.32.106.131
 15    32 ms     *       32 ms  176.32.106.131
 16     *        *        *     Zeitüberschreitung der Anforderung.
 17     *        *        *     Zeitüberschreitung der Anforderung.
 18     *        *        *     Zeitüberschreitung der Anforderung.
 19    33 ms     *       32 ms  ec2-79-125-1-99.eu-west-1.compute.amazonaw
[79.125.1.99]
 20     *        *        *     Zeitüberschreitung der Anforderung.
 21     *        *        *     Zeitüberschreitung der Anforderung.
 22     *        *        *     Zeitüberschreitung der Anforderung.
 23     *        *        *     Zeitüberschreitung der Anforderung.
 24     *        *        *     Zeitüberschreitung der Anforderung.
 25     *        *        *     Zeitüberschreitung der Anforderung.
 26     *        *        *     Zeitüberschreitung der Anforderung.
 27     *        *        *     Zeitüberschreitung der Anforderung.
 28     *        *        *     Zeitüberschreitung der Anforderung.
 29     *        *        *     Zeitüberschreitung der Anforderung.
 30     *        *        *     Zeitüberschreitung der Anforderung.
 31     *        *        *     Zeitüberschreitung der Anforderung.
 32     *        *     ^C

Grüße, Martin

 

[Dalai]

Ich sehe, dass deine Linux-Kiste eine zusätzliche IP aus deinem Netz ansteuert. Stimmen denn die Netzwerkeinstellungen überein, insbesondere der Gateway? Und wie sieht's mit IPv6 aus?

MfG Dalai

 

[X_FISH]

ipv6 habe ich bereits per /etc/sysctl.conf deaktiviert. Auf der Windowskiste ist es auch nicht aktiv.

Das Gateway ist auf beiden Rechnern gleich gesetzt (Kabelrouter von Kabel-BW).

Muss jetzt wieder zur Arbeit, morgen früh/tagsüber wieder mehr.

Grüße, Martin

 

[gruenmuckel]

Eventuell ein Problem der MTU? Wenn dann die Anfragen framentiert weitergeleitet werden sollen, aber irgendwo auf dem Weg nur unfragmentierte zugelassen werden?

 

[Dalai]

Kannst du denn die ersten beiden IP-Adressen des Traceroute je einem Gerät zuordnen? Und soll die zweite dort sein? Normalerweise ist es ja so, dass nach dem Gateway nur noch externe Adressen aufgelistet werden, sofern nicht noch irgendein anderes Gerät dazwischenhängt (Proxy oder sowas).

MfG Dalai

 

[Riddler82]

Auf OS Ebene siehts gut aus. Hm.
Lediglich die Zeile ist merkwürdig, ja:

2 172.30.9.222 (172.30.9.222) 10.917 ms 10.911 ms 10.898 ms

Jetzt wäre noch interessant das ganze im Browser zu sehen, aber mir ist da grad kein Tool geläufig. Höchstens die Chrome Entwicklertools, aber die machen in dem Sinn ja kein traceroute.

 

[X_FISH]

Kannst du denn die ersten beiden IP-Adressen des Traceroute je einem Gerät zuordnen?

Nein. Netzwerktopologie:

Beide Rechner <--- CAT5 ---> 100 Mbit Switch <--- CAT5 --> »Kabelrouter« Kabel-BW <--- Coax in die Wand ---> Multimediadose

Am Kabelrouter sind sonst noch eine FritzBox (für voip) und ein Linksys (für WLAN) angeschlossen. Zum Testen waren beide Geräte abgetrennt bzw. ausgeschaltet. Danach habe ich erst die beiden Rechner hochgefahren.

Windows-Kiste und Linux-Kiste sind physikalisch zwei Rechner. Kein Multi-OS-PC. Beim Testen der Linuxkiste war der Windowsrechner aus.

Und soll die zweite dort sein? Normalerweise ist es ja so, dass nach dem Gateway nur noch externe Adressen aufgelistet werden, sofern nicht noch irgendein anderes Gerät dazwischenhängt (Proxy oder sowas).

Du meinst die 172.30.9.223?

Ist nicht in meinem lokalen Netzwerk. Auch nicht annähernd die WAN-IP des Kabelrouters.

Grüße, Martin

 

[gruenmuckel]

Guck mal hier, ganz unten kannste auch tracen:
http://www.dnsstuff.com/tools


Bzw. direkt der Trace: http://www.dnsstuff.com/tools#traceroute|type=domain&&value=9gag.com

 

[Dalai]

Du meinst die 172.30.9.223?

Nein, ich meinte die 172.30.9.222.

Ist nicht in meinem lokalen Netzwerk. Auch nicht annähernd die WAN-IP des Kabelrouters.

Wie jetz? Die 172.30.9.0 ist nicht dein LAN? Wie kommt dann die 172.30.9.223 an die erste Stelle des Traceroutes, wenn das nicht der Gateway ist? Nicht dass du ein Klasse B Netz hast (Subnetzmaske 255.255.0.0) statt eines typischen Klasse C (Subnetzmaske 255.255.255.0), bzw. mit diesem Adressbereich 255.240.x.y.

[ADD]
Übrigens ist die genannte IP-Adresse eine private, wie man z.B. bei Wikipedia nachlesen kann. So, erstmal genug kluggeschissen .
[/ADD]

Guck mal hier, ganz unten kannste auch tracen:
http://www.dnsstuff.com/tools

Da braucht man noch nicht einmal "ins Ausland" zu gehen . Heise hat auch sowas.

MfG Dalai

 

[Riddler82]

Jupp, laut RFC 1918 ist alles zwischen 172.16.0.0 bis 172.31.255.255 privat und wird im WWW regulär nicht benutzt.

Gib uns doch mal, was "ip a" sagt unter linux bzw "ipconfig" unter Windows, könnte auch interessant sein.

Die genannten Trace-Tools tracen leider nicht von deinem eigenen Stanort aus, so weit ich weiß, helfen also nur indirekt.

Irgendeine Kinderschutzfunktion wirst du ja nicht versehentlich aktiviert haben auf der Linux-Kiste?

 

[tomturbo]

Die 172er könnte auch vom Provider kommen und einen Zwangsproxy darstellen, der filtert oder spinnt.
Übrigens ist traceroute auch ICMP.

Jedenfalls sehr merkwürdig das Ganze.

lg
__tom

 

[X_FISH]

Wie jetz? Die 172.30.9.0 ist nicht dein LAN? Wie kommt dann die 172.30.9.223 an die erste Stelle des Traceroutes, wenn das nicht der Gateway ist?

IP der Rechner: 192.168.0.11 und 192.168.0.10. GW 192.168.0.1... Daher ist mir die 172.x.x.x völlig fremd...

Ist jemand bei Unitymedia/Kabel-BW und kann selbst mal einen Test machen ob er auch in dem Bereich eine Rückmeldung erhält?

Grüße, Martin

 

[Riddler82]

Ich hab weiter oben nicht ohne Spaß schon nach "route -n" und der resolv.conf gefragt. Da steht manchmal auch was interessantes.

Oder noch besser, was sagt "route -C" oder -e ?

Ein Zwangsproxy oder Reverseproxy iswt möglich, allerdings würde man vermuten, dass dieser dann transparent und für den Kunden nicht sichtbar ausgeführt wird.

 

[tomturbo]

Naja wenn der Proxy nicht über layer 2 drinnen ist, kann er routingtechnisch nicht unsichtbar sein.

Könnte schlicht auch ein Routingproblem beim Provider sein, warum sich das Ganze so merkwürdig verhält.