10
Falsche Cached Web-Inhalte hinter Telekom Speedport?
Hallo zusammen,
ich habe ein mir bisher unbekanntes Phänomen.
Ich betreue eine Wordpress Homepage auf einem root Server, erreichbar über https only.
Der Kunde hat Probleme in zwei Netzwerken (beides mit Telekom Speedport W???), und zwar wird ihm die Seite gecached angezeigt. Also nur so kann ich mir das erklären.
Unter der Domain www.meine-seite.de war während des Websiteumzugs eine Wartungsseite geschaltet, jetzt ist hinter der Domain natürlich die richtige Webseite erreichbar (WordPress auf Apache mit Let's Encrypt und HSTS).
Ist er in diesen beiden Netzwerken wird ihm immer die alte Webseite angezeigt, bzw. halt der HSTS Fehler. Browser wurde mehrfach zurückgesetzt, auch verschiedenen Devices getestet.
Überall anders auf der Welt funktioniert die Seite, nur bei ihm zu Hause nicht. Die Zertifikatsinformationen sind vom Oktober wenn man die Seite aufruft, eigentlich müsste da ja immer das tagesaktuelle Datum im Browser stehen.
Router neustart ist schon passiert. Ich habe keinen blassen Schimmer in welche Richtung ich noch weitersuchen soll. Vielleicht hat hier jemand eine Idee.
Gruß und frohe (Rest-)Feiertage,
Markus
ich habe ein mir bisher unbekanntes Phänomen.
Ich betreue eine Wordpress Homepage auf einem root Server, erreichbar über https only.
Der Kunde hat Probleme in zwei Netzwerken (beides mit Telekom Speedport W???), und zwar wird ihm die Seite gecached angezeigt. Also nur so kann ich mir das erklären.
Unter der Domain www.meine-seite.de war während des Websiteumzugs eine Wartungsseite geschaltet, jetzt ist hinter der Domain natürlich die richtige Webseite erreichbar (WordPress auf Apache mit Let's Encrypt und HSTS).
Ist er in diesen beiden Netzwerken wird ihm immer die alte Webseite angezeigt, bzw. halt der HSTS Fehler. Browser wurde mehrfach zurückgesetzt, auch verschiedenen Devices getestet.
Überall anders auf der Welt funktioniert die Seite, nur bei ihm zu Hause nicht. Die Zertifikatsinformationen sind vom Oktober wenn man die Seite aufruft, eigentlich müsste da ja immer das tagesaktuelle Datum im Browser stehen.
Router neustart ist schon passiert. Ich habe keinen blassen Schimmer in welche Richtung ich noch weitersuchen soll. Vielleicht hat hier jemand eine Idee.
Gruß und frohe (Rest-)Feiertage,
Markus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 359242
Url: https://administrator.de/contentid/359242
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
10 Kommentare
Neuester Kommentar
Nicht die Webseite wird gecached sein sondern die alten DNS-Informationen.
Hast du vor dem Umzug die TTL auf einen ausreichend niedrigen Wert gesetzt?
Falls nicht, geistert das jetzt noch bis zum Ablauf durch die DNS-Caches der Telekom.
Das kannst du testen, indem du ein simples nslookup in den problematischen Netzen machst. Wenn da noch die alte IPv4- oder IPv6-Adresse zurückgeliefert wird, weißt du woran es liegt.
Hast du vor dem Umzug die TTL auf einen ausreichend niedrigen Wert gesetzt?
Falls nicht, geistert das jetzt noch bis zum Ablauf durch die DNS-Caches der Telekom.
Das kannst du testen, indem du ein simples nslookup in den problematischen Netzen machst. Wenn da noch die alte IPv4- oder IPv6-Adresse zurückgeliefert wird, weißt du woran es liegt.
Hallo,
probier das ganze mal mit wget.
Da siehst Du zu einem die IP und kannst Dir sicher sein, dass nichts von der Software gecachet wird.
Stefan
probier das ganze mal mit wget.
Da siehst Du zu einem die IP und kannst Dir sicher sein, dass nichts von der Software gecachet wird.
Stefan
Ich habe heute nochmal von einem dritten DSL Anschluss versucht (diesmal mit FritzBox 7490). Auch hier das Problem das HSTS sich einschaltet im Browser. Mit dem selben Notebook habe ich bei mir zu Hause kein Problem.
Das es an einem Gerät liegt kann ich zu 100% ausschließen, da es an mehreren Standorten ja funktioniert. Es muss irgendein Unterschied sein zwischen den einzelnen Anschlüssen.
Kann es auch an der Umleitung von HTTP zusammenhängen?
Das es an einem Gerät liegt kann ich zu 100% ausschließen, da es an mehreren Standorten ja funktioniert. Es muss irgendein Unterschied sein zwischen den einzelnen Anschlüssen.
Kann es auch an der Umleitung von HTTP zusammenhängen?
Die Umleitung ist vermutlich weniger das Problem.
Verbindest du dich denn in allen Fällen wirklich zum selben Server? Teste das bitte - auch mittels "ping" - einmal nach.
Irgendeinen Unterschied zwischen den Netzen muss es geben und der Ansatz DNS ist vielversprechender als irgendein Layer7-Filter.
Verbindest du dich denn in allen Fällen wirklich zum selben Server? Teste das bitte - auch mittels "ping" - einmal nach.
Irgendeinen Unterschied zwischen den Netzen muss es geben und der Ansatz DNS ist vielversprechender als irgendein Layer7-Filter.
Also ich bin inzwischen ein bisschen weiter. Es handelt sich wohl um folgendes Problem: https://telekomhilft.telekom.de/t5/Telefonie-Internet/Telekom-DNS-ignori ...
Ich habe mit mehreren Leuten gesprochen die Telekom Anschlüsse nutzen und können mir das Verhalten bestätigen, sogar im Mobilfunknetz treten diese Probleme auf.
Gibt es einen Kniff (den ich noch nicht kenne) um DNS Updates irgendwie zu triggern? Ich habe Zugriff auf die Webseite komplett über den Server (inkl. apache usw..) die Domain wird von Netcup gehostet, ich hab überlegt auf DNSSEC (die Option gibts bei Netcup) umzustellen um damit irgendwie die Telekom Server zu triggern und dann wieder zu deaktivieren (oder auch zu lassen, ist halt nur etwas overkill). Kann das klappen?
Ich habe halt keine Chance die Leute zu informieren, und mit einer Lösung zu versorgen. Zu breit gefächertes Publikum...
Gruß,
Markus
Ich habe mit mehreren Leuten gesprochen die Telekom Anschlüsse nutzen und können mir das Verhalten bestätigen, sogar im Mobilfunknetz treten diese Probleme auf.
Gibt es einen Kniff (den ich noch nicht kenne) um DNS Updates irgendwie zu triggern? Ich habe Zugriff auf die Webseite komplett über den Server (inkl. apache usw..) die Domain wird von Netcup gehostet, ich hab überlegt auf DNSSEC (die Option gibts bei Netcup) umzustellen um damit irgendwie die Telekom Server zu triggern und dann wieder zu deaktivieren (oder auch zu lassen, ist halt nur etwas overkill). Kann das klappen?
Ich habe halt keine Chance die Leute zu informieren, und mit einer Lösung zu versorgen. Zu breit gefächertes Publikum...
Gruß,
Markus
Kannst du uns die betroffene Domain (notfalls per PN) mitteilen, zusammen mit der alten IP-Adresse?
Ich würde mir das gerne mal genauer ansehen.
Ich würde mir das gerne mal genauer ansehen.
Nach etwas längerem hin und her ist der Verursacher gefunden: IPv6
Laut Angaben des Kundensupports für Privatanschlüsse bei der Telekom, setzt die Telekom wohl "ausschließlich" auf IPv6 Kommunikation bei den DNS Servern. Haushalte mit einer FritzBox können händisch wohl den Fallback auf IPv4 DNS Server aktivieren, aber alle mit Speedport nutzen immer IPv6 Adressen der Telekom DNS Server, ebenso das Mobilfunknetz.
In den DNS Einstellungen der Webseite war die IPv6 Konfiguration nicht vollständig (auf die Idee wäre ich niemals gekommen) und deswegen konnte die Seite nicht aufgerufen werden und die Aufrufe führten ins leere, bzw. der Browser brachte HSTS Fehler auf Grund der alten, gecachten Inhalte.
Laut Angaben des Kundensupports für Privatanschlüsse bei der Telekom, setzt die Telekom wohl "ausschließlich" auf IPv6 Kommunikation bei den DNS Servern. Haushalte mit einer FritzBox können händisch wohl den Fallback auf IPv4 DNS Server aktivieren, aber alle mit Speedport nutzen immer IPv6 Adressen der Telekom DNS Server, ebenso das Mobilfunknetz.
In den DNS Einstellungen der Webseite war die IPv6 Konfiguration nicht vollständig (auf die Idee wäre ich niemals gekommen) und deswegen konnte die Seite nicht aufgerufen werden und die Aufrufe führten ins leere, bzw. der Browser brachte HSTS Fehler auf Grund der alten, gecachten Inhalte.
Das ist nichts was die Telekom macht - das ist normales und standardisiertes Verhalten aller Clients an Dualstack-Anschlüssen 
Sobald IPv6 sowohl am Client als auch am Server verfügbar ist, wird das immer gegenüber IPv4 bevorzugt.
Aber gut, dass du den Fehler jetzt gefunden hast
Sobald IPv6 sowohl am Client als auch am Server verfügbar ist, wird das immer gegenüber IPv4 bevorzugt.
Aber gut, dass du den Fehler jetzt gefunden hast
Ja, aber IPv6 war halt nicht am Server verfügbar und es gab somit kein Fallback auf IPv4. Das ist das was mich wundert, andere Anbieter haben das hinbekommen, auch die Business Anschlüsse der Telekom haben das Problem nicht gehabt. Ich habe bestimmt an >20 verschiedenen Anschlüssen getestet, da war alles dabei und immer das gleiche Schema. Sobald Telekom = Fehler.
Ich seh den Fehler ja ein an der Konfiguration meines Servers, aber trotzdem das Verhalten komisch.
Ich seh den Fehler ja ein an der Konfiguration meines Servers, aber trotzdem das Verhalten komisch.
Ein Fallback gibt es nur, wenn keine Verbindung auf Layer 4 zustande kommt - also z.B. der TCP-Handshake nicht funktioniert.
Sobald du eine TCP-Verbindung hast und der Fehler auf einem höheren Layer auftritt (in deinem Fall TLS-Aushandlung), gibt es keinen Fallback. Denn dann hat die Verbindung auf Layer 3/4 funktioniert, der Fehler tritt dann auf der Anwendungsebene auf.
Sobald du eine TCP-Verbindung hast und der Fehler auf einem höheren Layer auftritt (in deinem Fall TLS-Aushandlung), gibt es keinen Fallback. Denn dann hat die Verbindung auf Layer 3/4 funktioniert, der Fehler tritt dann auf der Anwendungsebene auf.
1
