Die Fehlerbeschreibung passt doch so ziemlich 1:1 dazu, bestimmte Netze, Fehler auschließlich aus dem besagten ISP und gleiches Fehlerbild.

Ich habe das Problem um identische Szenarien ergänzt, wodurch auch andere CDN 's betroffen sind mit ebenfalls dem gleichen Fehlerbild. Ebenfalls auschließlich über Telekom-Netz.

Im Anhang noch einmal weitere Beispiele, die mit "http request" betitelten Dateien sind eine HTTP Übertragung von seinem Server. Und die mit "bad" betitelten sind die besagten Übertragungsfehler welche @martin-ebringen im Netz des Providers hat und ich hier bestätigen kann.

Die mit "fine" betitelten, habe ich über unsere redundante Richtfunkanbindung gemacht, welche hier ebenfalls in Magdeburg ausgeht.

Wie unschwer den übertragungszeiten im Browser, bestätigt durch die retransmissions in wireshark zu erkennen ist, läuft hier doch schon gewaltig etwas verkehrt.

Und nachfolgend im Anhang erneut einmal das genau gleiche von Martin beschriebene Problem, angewendet auf einen von mir verwendeten CDN hinter Cloudflare, wie auch unsere Businesspartner verwenden, wodurch sich das gleiche Problem nachweislich eben nicht nur auf die Verbindung zum Rechenzentrum von Hetzner beschränkt.

"cloudflare CDN us bad" ist hier die Aufzeichnung aus dem Telekom-Netz (DSL wie Glasfaser) und die "cloudflare CDN us fine" ist erneut über unsere Redundante Richtfunkanbindung über einen anderen Provider.

Ich habe bis auf weiteres meine Heimanbindung sowie unser Firmennetz auf unseren Ausweichprovider umgeschalten, ich hoffe für dich (Martin) das sich das Problem noch größer für mehr bemerkbar machen wird und somit auch in naher Zukunft angegangen wird.

Moin!

Mir ist seit dem 7.11 (ab ziemlich genau 14:55) auch aufgefallen, dass Verbindungen zu meinem Hetzner Server in Helsinki nun praktisch nicht mehr nutzbar sind.

Nach einigem Hin und Her mit MTR, iperf und so weiter, bin ich zu dem Ergebnis gekommen, dass es sich wohl, wie hier auch schon erwähnt, um ein Problem mit TCP Paketen handeln muss.

Die Problematik kann komplett umgangen werden, indem ich entweder einen VPN Verwende, um von einem anderen Exit Node (bspw. Schweiz) die Verbindung aufzubauen, oder indem ich mittels Wireguard vom Server aus in mein Heimnetz einen Tunnel erstelle, und meinen Traffic durch diesen leite.

Das führt gar so weit, dass ich mittels NATing via Fritzbox und diversen anderen Routern durch den Wireguard Tunnel externen Telekom Nutzern ermöglichen kann, bspw Minecraft (25565 TCP) auf meinem Server zu spielen.

Hetzner hat das Problem bereits auf dem Schirm und ist angeblich mit der Telekom in Kontakt https://status.hetzner.com/incident/5642a887-dc57-447c-b286-f76053bf9e8d

Das Problem betrifft ALLE Telekom Kunden mit denen ich gesprochen habe und KEINE Kunden anderer ISPs in Deutschland.

Gerne liefere ich auch TCP-Dumps o.ä. bei Bedarf nach.

Also erstmal vielen Dank an die Mühen und die Hinweise generell.

Da auf dem Helsinki-Server auch eine Produktiv-Seite mit mehr als 10.000 Kunden täglich gehosted wurde, konnte ich die Fehleranalyse nicht weiterbetreiben und habe in einer Hauruck-Aktion (18h-Schicht) den Server von Helsinki (95.217.207.230) nach Falkenstein (136.243.61.21) umgezogen. Das stand so oder so auf dem Schirm und jetzt wurde ich indirekt dazu gezwungen.

Die Anbindung an den neuen Server funktioniert wunderbar, so wie das auch grundsätzlich vor dem Do, 10.11.2024 auf dem Helsinki-Server war.

D. h. ich kann jetzt in Ruhe weiter analysieren, was das Problem ist - denn, obwohl auf dem Server keine Last mehr ist, tritt das Problem weiterhin und primär verstärkt zwischen 14.00 auf und 0.00 Uhr auf (bisher am Do, Fr, Sa und heute So).

Für die noch nicht umgezogenen Seiten ist das nicht dramatisch, weil diese nicht von Endkunden genutzt werden (= hier kann also nichts kaputt gehen, egal was ich teste :-)).

@armin23 

Vielen Dank, dass du ebenfalls bestätigen kannst, dass die Verbindung sich ganz anders verhält (je nach Provider). Das es sich evtl. um ein größeres Problem handelt (und auch CDNs) betrifft, kann natürlich sein, aber auf diesem Level kann ich nicht mitsprechen, weil ich eben alles andere als ein Netzwerkprofi bin - was ich vielleicht ändern sollte ;-). Trotzdem hilft es schon sehr, wenn man die Bestätigung bekommt, dass andere das auch nachvollziehen können.

@k.breitscheid 

Vielen Dank ebenfalls für die Bestätigung der hohen Ping-Zeiten und den Hinweis, dass man mit MTR auch TCP-Pakete testen kann. Jetzt muss ich nur noch rausfinden, wie man das auch unter Windows machen kann. Denn dann kann ich nochmal auf Hetzner zugehen - denn Hetzner möchte als Beweis einen MTR-Report (mit mind. 200 Aufrufen). Das ist für mich nicht nur jetzt im akuten Fall wichtig, sondern auch, um zukünftig bei solchen Fällen eine Analyse betreiben zu können (ich wusste bis Do nichts von MTR oder Wireshark ...) <- d. h. daran arbeite ich jetzt, diese KH-Lücke zu schließen.

@steffenba 

Vielen Dank für deine Fehlerbeschreibung - das hätte jetzt 1:1 von mir kommen können.

Mit ICMP-Paketen gibt es keine Probleme und ich verwalte ihn remote über VPN (ebenfalls keine Probleme). 

Hetzner hat das Problem bereits auf dem Schirm und ist angeblich mit der Telekom in Kontakt https://status.hetzner.com/incident/5642a887-dc57-447c-b286-f76053bf9e8d

Diese Info habe ich nicht von Hetzner bekommen - und diese Statusmeldung wird auch auf https://status.hetzner.com nicht angezeigt.

Das Problem betrifft ALLE Telekom Kunden mit denen ich gesprochen habe und KEINE Kunden anderer ISPs in Deutschland.

Ich habe über 40 Kunden, die bestätigt haben, dass sie das Problem auch betrifft. Bei Kunden mit O2, Vodafone und AT A1 gab es keine Probleme.

Hallo zusammen,

aktuell kann ich zu dem Problem zwar keine weiteren Erkenntnisse beitragen, die nicht weiter oben schon thematisiert wurden. Als Telekom-Nutzer und Hetzner-Helsinki-Serverbetreiber bin ich aber auch betroffen.

Und ich möchte mich mal bei den bisherigen Teilnehmern für die Ausführungen und detaillierte Recherche bedanken. Ich habe am Wochenende ebenfalls sehr viel Zeit investiert um rauszufinden, warum mein Server von zuhause aus quasi nicht mehr bedienbar ist und war schon kurz davor, den Server selbst, mein Betriebssystem, den Router oder meine Verkabelung austauschen zu wollen... nur dass sich das Problem eben bei mir ausschließlich bei Verbindungen zu Hetzner Helsinki bemerkbar macht und ich nun die absurde Situation habe, dass ich über getunnelten Remote-Desktop zur Firma flüssiger an dem System arbeiten kann als direkt von zuhause.

Danke für die Auflösung des Gaslighings, das hat mir in jedem Fall viel Nerven und Geld gespart. Und ich hoffe für uns alle, dass das Problem zeitnah behoben wird.

Das Problem besteht offensichtlich immer noch. Mittlerweile konnte ich auch auf einem Windows-11-System das "Windows Subsystem for Linux (WSL)" und mtr installieren können:

1. Powershell als admin öffnen (z. B. "Win + Taste X" - im Menü "Terminal (Administrator)" auswählen
2. WSL installieren mit dem Befehl "wsl --install" (in der Regel wird wohl ein Ubuntu installiert) + Neustarten von Windows
3. Ubuntu starten (einfach nach "Ubuntu" suchen) - oder in einem Powershell den Befehl "wsl" eingeben -> startet scheinbar eine bash console
4. In der bash console die Befehle

sudo apt update

sudo apt install mtr

eingeben.

Dann sollte mtr installiert sein.

Dann in der bash console mtr mit dem betroffenen Server ausprobieren - zunächst ICMP (hier nur 10 cyclen / weitere Hilfe mit "mtr --help")

mtr -c 10 --report 95.217.207.230

 2.|-- fritz.box 0.0% 10 0.9 1.2 0.9 1.8 0.4
3.|-- ********* 0.0% 10 16.0 7.5 5.0 16.0 3.5
4.|-- f-ed12-i.F.DE.NET. DTAG .DE 0.0% 10 12.3 12.7 11.7 13.9 0.6
5.|-- ae8-0.fra20.core-backbone 0.0% 10 11.4 15.3 10.5 52.6 13.1
6.|-- ae1-2081.sth10.core-backb 0.0% 10 31.1 32.6 29.5 51.9 6.8
7.|-- core-backbone.hetzner.com 0.0% 10 30.2 32.1 29.6 42.8 4.2
8.|-- core53.sto.hetzner.com 0.0% 10 30.7 30.8 30.6 31.2 0.2
9.|-- core31.hel1.hetzner.com 0.0% 10 37.3 36.8 35.2 37.6 0.8
10.|-- ex9k2.dc4.hel1.hetzner.co 0.0% 10 37.8 37.7 36.2 38.5 0.7
11.|-- mail.asgard-solutions.de 0.0% 10 36.8 36.7 35.5 37.5 0.7

Dann habe ich es wie oben von @k.breitscheid vorgeschlagen mit TCP probiert 

mtr -c 100 --tcp --report 95.217.207.230

erhalte dann aber das ist nicht unbedingt das erhoffte Ergebnis

 2.|-- fritz.box 0.0% 100 0.9 1.1 0.7 2.2 0.3
3.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
4.|-- f-ed12-i.F.DE.NET. DTAG .DE 0.0% 100 13.4 13.4 12.5 14.6 0.4
f-ed12-i.F.DE.NET. DTAG .DE
5.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
6.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11.|-- mail.asgard-solutions.de 4.0% 100 9888. 1127. -2253 9888. 2435.6

Denn, die fritz.box scheint alle Pakete zu verwerfen (= jetzt muss ich erstmal rausfinden, wie man die fritz.box umstellen kann :-)).

Nun ist das Problem übrigens auch auf der Hauptseite des Hetzner Robot angeschrieben.

Weiterhin scheint es nun etwas begrenzter aufzutreten.

Während via 25565/tcp nun der Traffic scheinbar recht ordentlich durchläuft, macht 443/tcp konkret Probleme.

Auch 25565/tcp zickt wieder.

Lasse ich via 444/tcp auf Server und Client ein iperf laufen, so braucht er zwar etwas um loszulegen, und macht lt. Wireshark auch einige retransmissions, aber es geht.

Lasse ich via 443/tcp auf Server und Client ein iperf laufen, so legt er im Endeffekt gar nicht los, in Wireshark tauchen diverse retransmissions auf und irgendwann wird die Verbindung mittels RST ACK quittiert.

Port 80: geht

Port 443: geht nicht

Port 444: geht

Ich hatte heute morgen zwischen 8 und 10 Uhr auch den Eindruck, dass der Seitenaufbau recht fix war, daher kann es also sogar sein, dass das Problem zeitlich begrenzt auftritt. Ich teste das morgen früh noch ein Mal.

Mit MTR-Statistiken kann ich dienen, zwar nicht von zuhause auf ein Hetzner-System, aber andersrum.

Von Helsinki gruselige Latenzen und Packet Loss, die aber erst ab #9 einsetzen (was ein Telekom-System ist):

~ # mtr -c 100 --tcp --report 87.188.149.57
Start: 2024-11-11T20:29:18+0100
HOST: eris5b                    Loss%  Snt   Last    Avg  Best   Wrst   StDev
 1.|-- 5.eris-olymp.de           0.0%  100    0.3    0.2   0.1    0.4     0.1
 2.|-- static.65.130.108.65.clie 0.0%  100    0.5    1.1   0.4   32.7     3.8
 3.|-- core32.hel1.hetzner.com   0.0%  100    0.5    0.5   0.3    0.8     0.1
       core31.hel1.hetzner.com
 4.|-- core52.sto.hetzner.com    0.0%  100    6.9    6.9   6.8    7.3     0.1
       core53.sto.hetzner.com
       core53.sto.hetzner.com
       core52.sto.hetzner.com
 5.|-- core3.sto.hetzner.com     0.0%  100    7.0   14.7   6.9   61.0    11.1
       core3.sto.hetzner.com
 6.|-- ae7-0.sth10.core-backbone 0.0%  100    7.0    6.9   6.8    7.2     0.1
 7.|-- ae13-2081.fra10.core-back 0.0%  100   24.7   24.4  24.3   24.7     0.1
 8.|-- ae22.cr6-fra2.ip4.gtt.net 0.0%  100   39.1   26.2  22.5   68.1     7.6
 9.|-- 80.150.168.84             6.0%  100  1185.  773.3  26.4  7293.  1311.3
10.|-- p57ba85b5.dip0.t-ipconnec 1.0%  100  1198.  1194.  33.2  7491.  1848.7
11.|-- p57bc9539.dip0.t-ipconnec 2.0%  100  185.6  1179.  36.6  7549.  1914.6

Von Falkenstein hingegen alles gut:

mtr -c 100 --tcp --report 87.188.149.57
Start: 2024-11-11T20:29:14+0100
HOST: rts42d                        Loss%  Snt  Last   Avg  Best  Wrst  StDev
1.|-- rts42.systems.wegewerk.ne      0.0%  100   0.2   0.2   0.2   0.3    0.0
2.|-- 100.85.244.129                 0.0%  100   0.4   0.7   0.3   8.9    1.0
3.|-- core23.fsn1.hetzner.com        0.0%  100   7.5   2.7   0.4  16.6    3.6
      core21.fsn1.hetzner.com
      core22.fsn1.hetzner.com
      core24.fsn1.hetzner.com
4.|-- juniper4.dc2.nbg1.hetzner      0.0%  100  16.8   4.1   2.8  27.0    4.0
      juniper5.dc2.nbg1.hetzner.com
      juniper4.dc2.nbg1.hetzner.com
      juniper5.dc2.nbg1.hetzner.com
      juniper4.dc2.nbg1.hetzner.com
      juniper5.dc2.nbg1.hetzner.com
      juniper5.dc2.nbg1.hetzner.com
      juniper4.dc2.nbg1.hetzner.com
5.|-- 62.157.248.137                 0.0%  100   9.1   6.6   2.9  32.3    5.8
      fr-ea1.fr.de.net.dtag.de
6.|-- p57ba85b5.dip0.t-ipconnec      0.0%  100  12.7  13.3  12.6  40.8    3.2
7.|-- p57bc9539.dip0.t-ipconnec      0.0%  100  16.8  16.7  16.4  17.2    0.2