warum sich website bei UNS nicht aufrufen lässt?

Hat jemand eine Idee, warum sich

http://www.geocaching-ms.de

bei UNS nicht aufrufen lässt?

Hab's mit 'nem Mac unter Chrome und Safari, auf 'nem PC unter Firefox und auf 'nem iPhone unter Safari versucht. Wenn das iPhone nicht im W-Lan ist, funktioniert's.

Provider ist Alice/O2. Die Verbindung zur Außenwelt läuft über einen älteren Speedport von der Telekom...

Vorschläge?

Besten Dank!

Edit: Entweder es passiert nix, oder es erscheint about:blank.

Das ist ein DNS-Problem Deines Internetanbieters, vielleicht mal die Hotline anrufen

Mögliche Gründe:
- ein Nameserver deines Providers ist ausgefallen (möglich, aber nicht sehr wahrscheinlich)
- in der hosts-Datei wird die Adresse umgeleitet (Scherz?)
- im Router kann man Adressen blockieren (hat der eine Firewall-Funktion?)

Ist nicht ganz alltäglich.

MadCatERZ schrieb:

Das ist ein DNS-Problem Deines Internetanbieters, vielleicht mal die Hotline anrufen

Zum Vergrößern anklicken....

Nein, ist es nicht. Wenn es das wäre, würde Firefox "Server not found" melden.
@huckeputz: Mach mal auf dem PC so ein Eingabeaufforderungsfenster auf und gibt dort ein: tracert www.geocaching-ms.de
Das Ergebnis dann bitte hier posten.

Hat nichts mit DNS zu tun. Hab das Problem auch.

Das ist meiner Meinung nach ein Problem mit dem sogenannten MSS-Clamping. Der Server scheint "großzügig" ICMP-Pakete zu blocken, auch solche, die für die Ermittlung der Paketgröße zwischen Server und Client eingesetzt werden.

Je nach Routing können dann große Pakete verloren gehen oder eben nicht.

Auf Linux-Clients kann man mit einem iptables-Kommando eine verkleinerte MSS beim Verbindungsaufbau erzwingen, mit der es geht. So mache ich es.

Die saubere Lösung wäre eine saubere Konfiguration des Webservers. Hab's aber aufgegeben, in solchen Fällen den Betreiber zu kontaktieren. Das Problem wird dort eigentlich nicht verstanden, ICMP halt als böse angesehen. Dass man ICMP auch braucht, damit TCP richtig funktioniert, wird dann gerne übersehen.

baer schrieb:

Das ist meiner Meinung nach ein Problem mit dem sogenannten MSS-Clamping. Der Server scheint "großzügig" ICMP-Pakete zu blocken, auch solche, die für die Ermittlung der Paketgröße zwischen Server und Client eingesetzt werden.

Zum Vergrößern anklicken....

Ja, an sowas hab ich auch gedacht. Die Seite wird von einem kleinen Krauter gehostet, der seine Kisten bei Hetzner stehen hat. Aber Path MTU Discovery funktioniert. »Resume: pmtu 1476 hops 8 back 7«. 1476 kommt mir allerdings ziemlich wenig vor. Versuch doch mal, auf Deinem DSL-Router eine andere MTU einzustellen, also 1468 z.Bsp. Eine schöne Lösung wäre das allerdings nicht. Ich steck allerdings kaum noch drin in der Materie, kann gut sein, daß ich was übersehe.

Rupa schrieb:

...

Zum Vergrößern anklicken....

Da man auf der Wiese ist, weis ich noch nicht mal, ob die Antwort ernst gemeint ist...verstehe kein Wort und vermutlich auch der Themenstarter

Chris_rocks31 schrieb:

Rupa schrieb:

...

Zum Vergrößern anklicken....

Da man auf der Wiese ist, weis ich noch nicht mal, ob die Antwort ernst gemeint ist...verstehe kein Wort und vermutlich auch der Themenstarter

Zum Vergrößern anklicken....

Der Vorschlag war, in den Einstellungen des Routers den Wert für MTU herabzusetzen auf 1468. Das geht i.d.R. irgendwo in den PPPoE-Einstellungen (wenn es ein DSL-Router ist). Aber bitte erstmal abwarten, was baer dazu sagt, der scheint sich da besser auszukennen, als ich es derzeit noch tue.

Als Betreiber der angesprochene Seite sag ich mal "Hallo" in die Runde. Ich habe über den Thread-Autor von der Problematik überhaupt erst erfahren. Solch ein Problem wurde zuvor nie an mich herangetragen.
Und das was baer schreibt klingt ja einigermaßen beunruhigend, selbst wenn ich kein Wort davon verstehe. ;-)

Dennoch wundert mich, dass der Seitenaufruf beim Thread-Starter auf keinem seiner Clients klappt, dafür aber bei tausenden anderen schon. Das ist schon sehr seltsam.
Andere Alice / O2-Nutzer aus Münster können auch auf die Seite zugreifen. Hab gestern Abend noch zwei Bekannte gefragt.

Komisch, komisch ...

Meine Lösung auf meinem Linux-Rechner sieht wie folgt aus:


178.73.164.29 ist die IP-Adresse des Servers. Dabei wird die MSS für alle Verbindungen zu diesem Server und eben nur diesen Server (!) auf 1000 runtergesetzt, wahrscheinlich würden etwas größere Werte auch noch gehen. Hatte keine Lust, den genauen Wert rauszufinden...

Ob sowas auch unter Windows geht, und wenn ja, wie, entzieht sich leider meiner Kenntnis.

Die MTU zu reduzieren, muss auch funktionieren, da die MTU quasi die obere Grenze für die MSS ist (der PC kann für die einzelne Verbindung keine größeren Pakete schicken, als er es generell kann). Allerdings sollte man nicht vergessen, dass dies dann für die gesamte Internet-Kommunikation gilt, d.h. es werden weniger Daten pro Paket gesendet und vor allen Dingen auch empfangen, was (leichten) Einfluss auf die Download-Geschwindigkeit haben kann.

Ich würde mit 1480 anfangen und dann die MTU solange runtersetzen, bis die Webseite grade geht. Mit 1400 sollte man meist auf der sicheren Seite sein.

Wie macht man das unter Windows? Wieder leider keine Ahnung. Es müsste in den Einstellungen des Ethernet-Interfaces zu finden sein, aber wo genau weiß ich leider mangels Benutzung von Windows nicht.

Jetzt mal auf Deutsch, was passiert hier eigentlich?

Daten werden im Internet in Pakete verpackt. Diese Pakete haben eine gewisse Größe. Diese liegt meist knapp unter 1500 Byte.

Das Problem ist jetzt das, dass zwischen den zwei Kommunikationspartnern beliebig viele Router stehen können und der Kommunikationsweg sich sogar noch dynamisch ändern kann.

Die Links zwischen manchen Routern haben nun unter Umständen eine verkleinerte Paketgröße. Das fängt schon bei DSL an: Da es sich beim PPPoE um ein Tunneling handelt, sprich Pakete in andere Pakete verpackt werden, gehen ein paar Byte Platz im Paket verloren (sozusagen für die "Umverpackung").

Daher ist die Ermittlung der größten erlaubten Paketgröße - und genau das ist die MSS für die jeweilige Verbindung - eine nicht-triviale Angelegenheit. Selbst wenn sich die beiden Kommunikationspartner auf etwas einigen, kann es sein, dass das einem Router unterwegs "nicht passt".

Daher kann es passieren, dass ein Webserver ein Paket losschickt, was irgendwo nicht passt ("verdächtig" ist immer DSL, siehe oben). D.h. ein Router stellt fest, dass er dieses Paket zwar erhalten hat, aber nicht über die zur Weiterleitung vorgesehene Leitung weiterreichen kann.

Das heute übliche Verfahren ist das, dass dieser Router das Paket verwirft und dies aber dem Sendenden mitteilt und zwar über ein bestimmtes Paket vom Typ ICMP.

Dieses Verfahren nennt sich übrigens "Path MTU Discovery" und genau damit gibt es hier ein Problem (meine Aussage, es wäre ein Problem mit dem MSS Clamping, war somit übrigens nicht ganz richtig).

Mit einem gesunden Halbwissen konfiguriert man nun seinen Webserver so, dass er keine ICMP-Pakete annimmt. Denn es gibt auch ICMP-Pakete anderer Art, mit denen man unter bestimmten Umständen böse Dinge machen kann. Blockt man nun ICMP generell, macht man das vorher beschriebene Verfahren kaputt.

Denn eigentlich sollte der Webserver auf die Nachricht hin, dass er ein zu großes Paket geschickt hat, ein etwas kleineres schicken. Solange, bis es durchgeht.

Da er die Nachricht aber durch die Fehlkonfiguration nicht beachtet, weiß er nicht, warum das Paket verloren gegangen ist. Unter den Umständen bleibt ihm nichts anderes übrig, als das Paket immer wieder zu wiederholen. Das macht er für einige Minuten, dann gibt er auf.

Im Browser passiert nun folgendes: Die Webseite wurde angefordert, die Header wurden geschickt, der Browser wartet auf die Antwort. Nun ist eine Webseite aber meist viel größer als ein Paket, d.h. der Webserver schickt meist gleich zu Anfang ein recht großes Paket, was aber nie beim Browser ankommt, weil es ja unterwegs von einem Router verworfen wurde.

Daher wartet nun der Browser "ewig", sprich bis zu einem im Browser eingestellten Timeout, auf eine Antwort.

Als Abhilfe kann man nun auf Seite des eigenen PCs von vornherein sagen, dass kleinere Pakete geschickt werden sollen. Dazu setzt man entweder für die konkrete Verbindung die MSS oder generell die MTU des Interfaces, was dann eben für alle Pakete gilt.

Obiges iptables-Kommando sagt meinem PC: Wenn Du eine Verbindung zu dieser bestimmten Adresse aufbaust, vergiss nicht, mitzuteilen, dass Du maximal 1000 Byte im Paket haben willst. Halt hinreichend wenig.

Die einzige saubere Lösung wäre, den Webserver richtig zu konfigurieren. Aber das dem Betreiber klar zu machen...

Rupa schrieb:

Aber Path MTU Discovery funktioniert.

Zum Vergrößern anklicken....

In Richtung des Webservers meiner Meinung nach eben nicht. Das kann man vom PC aus gar nicht feststellen, da sich die dazugehörigen Kommunikation in unserem Fall ja nur zwischen dem Router, der den Engpass entdeckt und dem Webserver abspielt.

Es ist aber mehr als plausibel anzunehmen, dass der Webserver, noch wahrscheinlicher eine vorgeschaltete Firewall, ICMP-Pakete blockt. Jedenfalls führt das genau zu den beobachteten Probleme. Zuverlässig verifizieren kann man das nur mit einem tcpdump auf dem Webserver und Kontrolle der entsprechenden Firewallregeln.

Heidewitzka, hier hat sich ja was getan. Besten Dank erstmal für die rege Teilnahme!

Ich bin allerdings Laie und bin mir nicht sicher, ob ich am Router rumtüddeln sollte...

"tracert www.geocaching-ms.de" Hab' ich über die Eingabeaufforderung des PCs meiner werten Gattin versucht, allerdings schließt sich das Fenster automatisch, bevor ich eine Hardcopy machen könnte....

Ich habe übrigens mit einer Bekannten in MS gesprochen, bei ihr ist ein Zugriff auf die Seite mit OSX und Windows via Alice/O2 ebenfalls möglich...

baer schrieb:

Rupa schrieb:

Aber Path MTU Discovery funktioniert.

Zum Vergrößern anklicken....

In Richtung des Webservers meiner Meinung nach eben nicht. Das kann man vom PC aus gar nicht feststellen, da sich die dazugehörigen Kommunikation in unserem Fall ja nur zwischen dem Router, der den Engpass entdeckt und dem Webserver abspielt.

Zum Vergrößern anklicken....

Naja, das Verhalten von traceroute und tracepath hatte mich gestern zu dem Schluß verleitet, daß das Problem im Netz Deines ISP bzw. des des TO zu suchen ist. Seltsamerweise ist das Verhalten von hetzner-gw.fs1.livinginternet.de heute anders als gestern und es legt den Schluß nahe, daß dieser Router das Problem ist. Gestern konnte ich die nächsten beiden (und letzten) Hops noch sehen, und damit war klar, daß hetzner-gw.fs1.... das Gateway in's Netz des Hosters von geocaching-ms.de ist.

huckeputz schrieb:

Ich bin allerdings Laie und bin mir nicht sicher, ob ich am Router rumtüddeln sollte...

Zum Vergrößern anklicken....

Wenn Du nicht "rumtüddelst", sondern geziehlt in den Interneteinstellungen oder PPPoE-Einstellungen (oder anders, jeder Hersteller nennt diesen Menüpunkt leider anders) nach dem Kürzel MTU suchst, kann da eingentlich nichts schief gehen. Du wirst dort höchstwahrscheinlich einen Wert von 1492 finden. Ändere das in 1468 und starte den Router neu. Oder laß es und lebe damit, daß manche Seiten nicht "funktionieren". Wenn der Router sehr einfach ist, kann es auch sein, daß Du in der Hinsicht gar nichts einstellen kannst, dann hättest Du immer noch die Möglichkeit, den Wert in den Einstellungen für die Netzwerkschnittstelle in Windows zu ändern. Mangels Zeit kann ich da aber erst morgen nachsehen, wie das geht (ich fahr Windows auch nur ganz selten mal hoch, um zu gucken, was für ein Leid ich mir erspare. ;-))

Sonst probier doch erst mal aus, ob Du über einen Proxy raufkommst. Wir hatten neulich ein ähnliches Problem, da bin ich per VPN über unser Firmennetzwerk gegangen und dann hat es geklappt

Rupa schrieb:

Naja, das Verhalten von traceroute und tracepath hatte mich gestern zu dem Schluß verleitet, daß das Problem im Netz Deines ISP bzw. des des TO zu suchen ist.

Zum Vergrößern anklicken....

Das spielt wahrscheinlich auch eine Rolle, denn bei anderen funktioniert es ja. Vermutlich steht der Router, der den Engpass hat, relativ nah bei meinem ISP - vielleicht irgendwo ein IP-IP-Tunnel oder sowas.

Dennoch glaube ich immer noch, dass die Firewall des Hosters von http://www.geocaching-ms.de generell ICMP blockt. Denn sonst würde dieser Engpass eben nichts ausmachen.

Dafür spricht auch, dass der traceroute eben bei hetzner-gw.fs1.livinginternet.de abbricht. Dahinter ist vermutlich die Firewall des Hosters und die lässt nicht nur kein ICMP rein, sondern vermutlich auch keins raus... Denn die Antwort-Pakete von traceorute sind ja auch ICMP...

Auf die Proxy-Idee bin ich gar nicht gekommen, läuft aber leider auch nicht.

Ich denke, ich werde mal prüfen, ob ich die Werte am Router umstellen kann und dann berichten...

Gut's Nächtle und danke erstmal.