O2 DSL IPv6 : Immer wieder TCP Verbindungsreset bei Zugriff auf Cloudflare IPv6 Adressen.
Seit einigen Tagen, eventuell Wochen, habe ich immer wieder Probleme, dass Webseiten beim Laden abbrechen. Nach einiger Analyse, scheint es so zu sein, dass das Seiten betrifft, die über cloudflare IPv6 angebunden sind, und sehr “nahe” am O2 Netz dran sind (ping ist 20 ms). Z.B. diese Seite hier, über wget geladen, hat gerade in mehr als 30% der Fälle einen Verbindungsabbruch:
wget --progress=dot -O/dev/null -6 https://understandingwar.org --2023-07-11 13:41:13-- https://understandingwar.org/ Resolving understandingwar.org (understandingwar.org)... 2606:4700:10::ac43:1963, 2606:4700:10::6816:4e94, 2606:4700:10::6816:4f94 Connecting to understandingwar.org (understandingwar.org)|2606:4700:10::ac43:1963|:443... connected. GnuTLS: Error in the pull function. Unable to establish SSL connection.
Wenn ich das mit tcpdump aufzeichne, dann sehe ich, dass der Webserver, nach dem TLS “Client Hello” sofort mit TCP Reset antwortet. Da der Ping sehr kurz ist, sieht das für mich so aus, als wenn da irgendwelche caching proxies innerhalb des O2 Netzes die Verbindung abwürgen. Irgendein falsch konfigurierter DoS Schutz oder sowas.
Die gesamte Verbindung unfasst nur 5 IP Pakete, die laut tcpdump so hier aussehen (habe meine eigene IPv6 Adresse zum Schutz der Privatsphäre teilw. maskiert):
Das ganze läuft bei mir unter Linux direkt mit einem DSL-Modem, da ist auf meiner Seite kein Router etc. dazwischen, dem man die Schuld in die Schuhe schieben kann.
Die Route zu dem Webserver ist laut traceroute folgende:
traceroute to 2606:4700:10::ac43:1963 (2606:4700:10::ac43:1963), 30 hops max, 80 byte packets 1 2a02:3001::240 (2a02:3001::240) 12.686 ms 12.600 ms 12.638 ms 2 * 2a02:3001::2df (2a02:3001::2df) 10.637 ms * 3 * * * 4 * * * 5 2a02:3001::280 (2a02:3001::280) 21.089 ms 2a02:3001::22d (2a02:3001::22d) 21.389 ms 2a02:3001::3f (2a02:3001::3f) 20.939 ms 6 * 2a02:3040:0:10::39 (2a02:3040:0:10::39) 26.972 ms * 7 2400:cb00:470:3:: (2400:cb00:470:3::) 33.382 ms 2400:cb00:100:1024::ac44:6d1c (2400:cb00:100:1024::ac44:6d1c) 23.924 ms 2400:cb00:100:1024::ac44:6d12 (2400:cb00:100:1024::ac44:6d12) 26.544 ms
Seite 1 / 2
Hallo @Dirac-Impuls
Willkommen zurück in unserer o2 Community hier. Long time no see und dann gleich mit so einem knackigen Thema
Ich gebe zu, ich habe nur die Hälfte verstanden. Falls deine Herausforderungen noch aktuell sind suchen wir gerne mal jemanden im Unternehmen, die da vielleicht etwas mehr zu sagen können.
@pufferueberlauf0 Du steckst doch auch so krass tief in der Materie drin, das könnte auch ein Thema für dich und deine beeindruckenden Skillz sein
VG Matze
Ich kann das Problem bei meinem Anschluss nicht nachstellen, die problematische IPv6 Adresse funktioniert bei mir wie erwartet. Ich habe auch keine echte Idee was da passiert, tut mir leid.
Moin,
hier gibt es auch keine Probleme.
@schluej
hier gibt es auch keine Probleme.
So a lá ...”Gehen sie weiter hier, gibt es nichts zu sehen?
Gut, das sind mir die liebsten Fälle, danke
VG Matze
Das gleiche Problem existiert hier weiterhin unverändert:
wget --progress=dot -O/dev/null -6 https://understandingwar.org --2023-08-07 13:47:42-- https://understandingwar.org/ Resolving understandingwar.org (understandingwar.org)... 2606:4700:10::6816:4f94, 2606:4700:10::ac43:1963, 2606:4700:10::6816:4e94 Connecting to understandingwar.org (understandingwar.org)|2606:4700:10::6816:4f94|:443... connected. GnuTLS: Error in the pull function. Unable to establish SSL connection.
(und auch auf anderen Webseiten)
Falls das bei euch nicht mit dem obigen Kommando reproduzierbar ist, weil der je nach Region eine andere IPv6 Adresse (also einen anderen Cloudflare Server) benutzt: bei curl kann man explizit eine bestimmte IPv6 Adresse angeben, vielleicht lässt sich damit das Problem nachsstellen?
Der Fehler tritt hier derzeit bei ca 50% der Versuche auf. Ist ein VDSL Bitstream Internet Zugang mit einem Vigor PPPoE modem, im PPPoE Betrieb an einem Linux Rechner. Der ganze IP stack läuft also hier auf meinem Linux Rechner auf einem Linux Kernel v6.1. Kann mir deshalb nicht vorstellen, dass das Problem auf meiner Seite der Verbindung liegt.
Mmmh, das funktioniert so wie es soll, also keine resets (unter Ubuntu 22 LTS, x86_64, Kernel 5.15.0). Allerdings habe ich wie mnn sieht:
@Dirac-Impuls Da du ja -so scheint es- ein manuell erstelltes und in Eigenregie betriebenes Setup benutzt, wäre es da nicht denkbar, dass der Fehler vielleicht nicht auf unserer Seite entsteht?
Wie machen sich die Einschränkungen denn im Daily Business genau bemerkbar? Vielleicht magst du das noch kurz erklären (wenn möglich bitte so, dass man da keinen Master in Informatik braucht, ich muss dem ganzen auch folgen können ).
Ganz lieben Dank.
VG Matze
Ich hoffe Mal, ich darf diesen Beitrag wiederbeleben :D
Nach langem Suchen habe ich endlich diesen Beitrag gefunden - ich habe ein sehr ähnliches bzw. vermutlich identisches Problem mit meinem DSL Anschluss. Mit dem obigen MRE kann ich das auch teilweise reproduzieren - ich habe das Problem ebenso nur teilweise:
pierre@macbookair ~ % curl -v --resolve 'understandingwar.org:443:32606:4700:10::ac43:1963]' -6 https://understandingwar.org > /dev/null * Added understandingwar.org:443:32606:4700:10::ac43:1963] to DNS cache * Hostname understandingwar.org was found in DNS cache % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying g2606:4700:10::ac43:1963]:443... * Connected to understandingwar.org (2606:4700:10::ac43:1963) port 443 (#0) * ALPN: offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): } }325 bytes data] * CAfile: /etc/ssl/cert.pem * CApath: none * Recv failure: Connection reset by peer * LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 * Closing connection 0 curl: (35) Recv failure: Connection reset by peer
Ich konnte nach einigen Tests auch feststellen, sobald ich in den Netzwerkeinstellungen meines Macbook Airs die IPv6 auf Link-Local beschränke treten die Probleme nicht mehr auf. In meiner Fritz!Box bekomme ich auch IPv6 Adressen von Telefonica - daher kann ich mir das Problem auf meiner Seite ebenso schwer erklären.
Beste Grüße
@Dirac-Impuls Da du ja -so scheint es- ein manuell erstelltes und in Eigenregie betriebenes Setup benutzt, wäre es da nicht denkbar, dass der Fehler vielleicht nicht auf unserer Seite entsteht?
Wie machen sich die Einschränkungen denn im Daily Business genau bemerkbar? Vielleicht magst du das noch kurz erklären (wenn möglich bitte so, dass man da keinen Master in Informatik braucht, ich muss dem ganzen auch folgen können ).
Ganz lieben Dank.
VG Matze
Ah, und um den zweiten Absatz zu beantworten - macht sich ziemlich stark bemerkbar. IPv6 ist nicht nutzbar, da jeder dritte Website-Aufruf an Cloudflare fehlschlägt. Merkbar direkt in Safari / Firefox / anderer Browser deiner Wahl, wenn man den Tab 10x neu laden muss bis zumindest ein Teil der Seite lädt. Ansonsten Desktopanwendungen welche Anfragen an die Server der Apps machen um bspw. Updates oder Inhalte herunterzuladen → App muss teilweise 10x neu gestartet werden bis man in die App hereinkommt.
Aber mir scheint auch, dass es ein Cloudflare-spezifisches Problem zu sein scheint. Basierend auf einem anderen Beitrag und einer Antwort eines O2 Mitarbeiters habe ich in der FritzBox die IPv6-Anbindung auf “Native IPv6-Anbindung verwenden” gestellt. Als DNS verwende ich nicht die O2 DNS Server (ich möchte ungern 10 Sekunden auf eine DNS-Antwort warten - und der DNS ist ja offensichtlich nicht das Problem, die Adressen werden ja problemlos aufgelöst. Passiert ja erst beim TLS Handshake):
Ah, und um den zweiten Absatz zu beantworten - macht sich ziemlich stark bemerkbar. IPv6 ist nicht nutzbar, da jeder dritte Website-Aufruf an Cloudflare fehlschlägt. Merkbar direkt in Safari / Firefox / anderer Browser deiner Wahl, wenn man den Tab 10x neu laden muss bis zumindest ein Teil der Seite lädt. Ansonsten Desktopanwendungen welche Anfragen an die Server der Apps machen um bspw. Updates oder Inhalte herunterzuladen → App muss teilweise 10x neu gestartet werden bis man in die App hereinkommt.
@PierreIsHere, das würde mich auch ziemlich nerven, wenn jede dritte Website an Cloudlflare fehlschlägt. Oder jeden Tab 10x neu laden muss, bis dieser mal ordnungsgemäß geöffnet werden kann.
Hat hier aus der Community noch jemand, vielleicht ähnliche Herausforderungen und kann noch unterstützen?
LG Steffen
Abend,
Mich betrifft das Problem auch. Etwa 20-30% aller HTTP Requests zu Cloudflare (AS13335) oder Neocities (AS395409) werden direkt nach den Request Headers mit einen RST gekillt.
tcpdump (IP gekürzt, checksummen stimmen nur scheinbar nicht wegen checksum offloading):
Scheint aber nur IPv6 zu betreffen. IPv6 ausschalten ist bei mir aber keine Option.
Hier müsste mal geprüft werden, ob das RST von Telefonica oder von Cloudflare kommt.
LG
Ich habe das gleiche Problem. Etwa 25% der Verbindungen zu Seiten, die bei Cloudflare liegen, können nicht hergestellt werden. In wireshark sieht man in diesen Fällen immer die gleichen 5 Pakete:
0.000s s> ausgehend] SYN
0.025s s< eingehend] SYN, ACK
0.025s s> ausgehend] ACK
0.027s s> ausgehend] Client Hello
0.052s s< eingehend] RST
Bei einem Ping von 25ms zum betreffenden Server wird deutlich, dass RST eine Antwort auf das Client Hello ist. In Fällen, in denen der Verbindungsaufbau klappt (mit einem quasi-identischen Client Hello Paket), empfange ich statt des RST ein ACK + Server Hello.
Die Probleme habe ich nur mit IPv6 und treten bei diversen Seiten seit einigen Wochen verstärkt auf. Zum Nachstellen konnte ich gut openstreetmap.org nutzen. IPv6 zu deaktivieren ist bei mir auch keine Option.
Ich nutze eine Fritz!Box 7490 mit aktuellem Fritz!OS. Betroffen sind im Netzwerk alle Geräte, die über IPv6 eine Verbindung aufbauen wollen: ein Handy mit Android 9 und zwei Laptops mit Linux (Fedora 40).
Hallo @nokiaaxdontcry und @derp_96883, willkommen hier in unserer o2 Community :-)
Ein spannendes Thema, was ihr mitgebracht habt. Ich habe mal auf die Schnell ein wenig herum probiert, natürlich klappt bei mir alles, Trace auf IPv6 und IPv4 läuft ohne Einschränkungen mit rund 10ms durch, Cloudflare lässt sich einwandfrei wiederholt laden (und die Seite wurde auch via IPv6 aufgerufen), zumindest bei mir sieht also alles so aus, wie es soll.
Zumindest von meiner Seite aus kann ich das so erst einmal nicht nachvollziehen, es ist also schon einmal nichts, das pauschal auftritt.
Falls es auch weiterhin zu dieser Einschränkung kommen sollte, stellt bitte sicher, dass da nicht eventuell eine VPN-Verbindung dazwischen funken könnte und führt gerne einmal einen Trace auf den Server durch, wo ihr aktuell diese Einschränkungen habt und postet diesen Trace dann hier.
So lassen sich unter Umständen da schon einmal Gemeinsamkeiten ableiten oder eventuell wird dort auch schon eine mögliche Ursache eingegrenzt.
Gruß,
Lars
Hallo @o2_Lars ,
ich freue mich, dass wir diesen Thread gefunden haben, da wir das gleiche Problem bei unseren Kunden, die O2 in Berlin nutzen, feststellen. Viele unserer Kunden haben sich beschwert, dass unsere iOS-Anwendung bei ihnen nicht funktioniert. Wir haben herausgefunden, dass 99 % dieser Probleme mit dem SSL-Handshake zusammenhängen, bei dem der Server ein RST sendet, wie in dem obigen Thread beschrieben. Unsere Daten zeigen, dass die Mehrheit der betroffenen Anfragen von Benutzern aus Berlin stammt, die O2 verwenden.
Kürzlich konnten wir das Problem mit einem unserer Kollegen reproduzieren, der O2 und FritzBox auf seinem iPhone nutzt. Interessanterweise tritt dieses Problem nur auf dem iPhone auf, und wir beobachten dasselbe Verhalten bei mehreren iPhone-Anwendungen, die versuchen, eine Verbindung zu Servern herzustellen, die hinter Cloudflare gehostet werden.
Bei unserem Kollegen tritt das Problem nur bei einer Teilmenge der zugewiesenen IP-Adressen auf. Wenn er seinen Router neu verbindet, wird eine neue IP-Adresse zugewiesen, und einige IP-Adressen scheinen überhaupt nicht betroffen zu sein.
Wir sind gerne bereit, weitere Informationen bereitzustellen oder bei der Fehlersuche zu helfen, da dies derzeit viele unserer Kunden betrifft.
In der Zwischenzeit haben wir einen Fall bei Cloudflare eröffnet, um zu sehen, ob von deren Seite aus etwas unternommen werden kann, und wir warten auf eine Antwort. Wir werden diesen Thread auch in dem Cloudflare-Fall erwähnen.
Viele Grüße
Martin Hlavac
Hallo @mhlavac und willkommen hier in unserer o2 Community :-)
Spannende Sache und gleich schon auf einen Großraum eingegrenzt, das nenne ich mal einen netten Einstieg hier bei uns :-)
Danke, dass du dich und den Anschluss deines Kollegen zur Verfügung stellst, ich bin da guter Dinge, dass uns das ein paar interessante Daten liefern wird :-)
Schick wäre es, wenn du beziehungsweise dein Kollege einmal einen Traceroute durchführen könnte einmal, wenn alles funktioniert und dann einmal, wenn es nicht funktioniert.
Vielleicht lässt sich da schon eine mögliche Ursache weiter eingrenzen.
Ich schreib dir gleich noch eine Privatnachricht, die findest du dann bei dir im Posteingang, für den Fall, dass du die Traces nicht öffentlich posten möchtest.
Gruß,
Lars
Hallo @o2_Lars, danke für deine Nachfragen! Ich sitze mit meinem DSL-Anschluss übrigens auch in Berlin.
Es liegt aber nicht direkt am TLS-Handshake. Bei einem HTTP-Zugriff wird ebenfalls das erste Paket nach dem ACK mit einem RST beantwortet. Bei TLS ist es das “Client Hello”, ohne TLS die HTTP-Anfrage (z.B. “GET / HTTP/1.1 ...”).
Da ich sowohl mit OpenStreetMap, als auch mit “understandingwar.org” (aus dem ersten Post) das Verhalten nachstellen kann, hier die Traceroutes (mit 8 statt 3 Queries pro Hop) zu beiden Domains:
traceroute to www.openstreetmap.org (2606:4700:3034::6815:5842), 30 hops max, 80 byte packets 1 kfritz.box] 3.931 ms 4.151 ms 4.674 ms 4.926 ms 5.749 ms 5.728 ms * * 2 2a02:3001::124 18.485 ms 19.104 ms 19.988 ms 20.687 ms 20.970 ms 22.130 ms 22.418 ms 22.405 ms 3 * * 2a02:3001::1ca 18.986 ms 20.781 ms * * * * 4 ::ffff:62.52.192.168 23.931 ms * * 28.503 ms * * * 25.475 ms 5 ::ffff:62.52.192.234 29.042 ms 27.271 ms 26.503 ms * * * ::ffff:62.52.193.55 25.237 ms ::ffff:62.52.192.234 26.481 ms 6 2a02:3001::3f 24.108 ms 2a02:3001::6b 27.101 ms 2a02:3001::3f 27.340 ms 2a02:3001::26a 24.492 ms 2a02:3001::3f 24.094 ms 2a02:3001::26b 25.108 ms 24.369 ms 2a02:3001::3f 22.824 ms 7 * * * * 2001:7f8:2c:1000:0:1a95:0:1 23.777 ms * * * 8 2400:cb00:100:1024::ac44:6d58 24.165 ms 2001:7f8:8:20:0:3417:0:1 24.496 ms 24.031 ms 2400:cb00:472:3:: 23.611 ms 2001:7f8:8:20:0:3417:0:1 23.958 ms 2400:cb00:100:1024::ac44:6d1e 28.909 ms 2400:cb00:100:1024::ac44:6d65 25.263 ms 2001:7f8:8:20:0:3417:0:1 23.210 ms
traceroute to understandingwar.org (2606:4700:10::6816:4e94), 30 hops max, 80 byte packets 1 kfritz.box] 3.947 ms 4.142 ms 4.678 ms 5.277 ms 5.797 ms 5.781 ms * * 2 2a02:3001::124 18.186 ms 18.431 ms 21.779 ms 22.036 ms 22.824 ms 33.397 ms 33.656 ms 33.898 ms 3 2a02:3001::1ca 30.141 ms * 29.331 ms 28.734 ms * 28.122 ms 19.819 ms * 4 * * * ::ffff:62.52.192.168 36.556 ms 34.428 ms 24.020 ms * 28.559 ms 5 * ::ffff:62.52.192.234 26.785 ms * * 27.922 ms * * 22.754 ms 6 2a02:3001::2d9 26.823 ms 25.890 ms 2a02:3001::2da 26.276 ms 2a02:3001::26a 24.152 ms 2a02:3001::2da 26.394 ms 2a02:3001::26b 24.123 ms 2a02:3001::26a 24.071 ms 2a02:3001::2da 26.473 ms 7 2a02:3001::13e 21.574 ms * 25.483 ms 25.387 ms * 26.033 ms * * 8 2001:7f8:8:20:0:3417:0:1 33.324 ms 2001:7f8:2c:1000:0:3417:0:1 29.544 ms 2400:cb00:609:3:: 22.545 ms 2001:7f8:8:20:0:3417:0:1 30.354 ms 2001:7f8:2c:1000:0:3417:0:1 29.966 ms 2001:7f8:8:20:0:3417:0:1 24.406 ms 28.353 ms 2400:cb00:471:3:: 24.513 ms 9 2400:cb00:609:1024::ac47:f926 25.130 ms 2400:cb00:696:3:: 25.669 ms 2400:cb00:471:3:: 27.185 ms 2400:cb00:472:3:: 28.805 ms 2400:cb00:100:1024::ac44:6d1e 27.879 ms 2400:cb00:71:3:: 22.909 ms 2400:cb00:470:1024::ac46:f1c5 22.785 ms 2400:cb00:472:3:: 24.054 ms
Interessant ist dabei, dass beide Server mir über die Kopfzeilen (curl -I eurl]) mitteilen, dass sie in München oder Frankfurt stehen: CF-RAY: nhash]-MUC bzw. CF-RAY: whash]-FRA
Bei andere Seiten, die über Cloudflare laufen, aber keine Probleme machen, habe ich FRA oder MUC nie gesehen. OpenAI.com antwortet bspw. immer aus Warschau (CF-RAY: ahash]-WAW) mit folgendem traceroute:
traceroute to www.openai.com (2606:4700::6812:849), 30 hops max, 80 byte packets 1 pfritz.box] 4.327 ms * * * * * * * 2 2a02:3001::124 49.209 ms 49.503 ms 50.476 ms 51.086 ms 51.708 ms 51.983 ms 51.957 ms 51.928 ms 3 2a02:3001::1ca 17.162 ms 12.981 ms * * * * * * 4 2a02:3001::216 10.451 ms 18.557 ms 10.437 ms 10.771 ms 11.494 ms 11.109 ms 11.307 ms 11.418 ms 5 2001:7f8:19:1::3417:1 14.874 ms 14.525 ms 14.403 ms 14.629 ms 15.274 ms 14.210 ms 11.737 ms 12.548 ms 6 2400:cb00:67:1024::a29e:7051 12.420 ms 2400:cb00:67:1024::a29e:7050 13.181 ms 2400:cb00:67:1024::a29e:7056 12.540 ms 2400:cb00:67:1024::a29e:7053 12.565 ms 2400:cb00:67:1024::a29e:706d 12.654 ms 2400:cb00:67:1024::a29e:7056 12.898 ms 2400:cb00:67:1024::a29e:7054 13.144 ms 2400:cb00:67:1024::a29e:7055 13.398 ms
Gruß
Danke dir, @derp_96883 :-)
Damit lässt sich doch schon mal was anfangen und einen ersten Verdacht habe ich da auch schon.
Auch, wenn wir selbst da nicht eingreifen können, kennen wir da doch den einen und anderen Menschen, der sich das gerne mal anschaut. Mit den Traces sollte sich da bestimmt etwas heraus bekommen lassen.
Auf jeden Fall auch spannend zu sehen, dass deine Fritzbox genau das gleiche Verhalten an den Tag legt wie meine, wenn da mal mehr als ein Trace parallel laufen, meine lässt da auch gerne mal ein paar Pakete unter den Tisch fallen ^^
Also, ich geb das direkt mal intern weiter, spätestens sobald es dazu etwas neues geben sollte, melde ich mich hier :-)
Gruß,
Lars
Eine kurze Info in die Runde: Das ganze ist intern adressiert, wenn ihr im Großraum Berlin ebenfalls Herausforderungen mit Cloudflare-Diensten haben solltet, lasst uns gerne einen Trace zu den jeweiligen Adressen da, das werde ich dann zu den bereits bestehenden dazu packen. Ich bin guter Dinge, dass wir das hinbekommen werden :-)
Gruß,
Lars
Hallo allerseits, es gibt frische Neuigkeiten :-)
Es gab auf einigen Netzelementen ein paar Herausforderungen, dies konnte behoben werden.
Bitte prüft einmal, ob es auch weiterhin zu Einschränkungen mit Cloudflare-Diensten kommt. Ich klopfe auf Holz, dass jetzt alles so läuft, wie es laufen soll :-)
Gruß,
Lars
Moin @o2_Lars, ich hab einen DSL-Anschluss in Berlin und bei mir treten die Probleme weiterhin auf:
$ curl -v --resolve 'understandingwar.org:443:2606:4700:10::6816:4f94' -6 https://understandingwar.org > /dev/null * Added understandingwar.org:443:2606:4700:10::6816:4f94 to DNS cache * Hostname understandingwar.org was found in DNS cache % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying [2606:4700:10::6816:4f94]:443... * Connected to understandingwar.org (2606:4700:10::6816:4f94) port 443 * ALPN: curl offers h2,http/1.1 } [5 bytes data] * TLSv1.3 (OUT), TLS handshake, Client hello (1): } [512 bytes data] * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * Recv failure: Connection reset by peer * OpenSSL SSL_connect: Connection reset by peer in connection to understandingwar.org:443 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 * closing connection #0 curl: (35) Recv failure: Connection reset by peer
$ traceroute -6 'understandingwar.org' traceroute to understandingwar.org (2606:4700:10::6816:4f94), 30 hops max, 80 byte packets 1 dynamic-2a01-0c22-acd4-0000-2e91-abff-febe-6b2b.c22.pool.telefonica.de (2a01:c22:acd4:0:2e91:abff:febe:6b2b) 0.365 ms 0.571 ms 0.728 ms 2 2a02:3001::125 (2a02:3001::125) 28.889 ms 29.475 ms 29.465 ms 3 * * * 4 * * * 5 loopback0.0006.corx.01.muc.de.net.telefonica.de (::ffff:62.52.192.234) 21.683 ms lo0.02.rl2t.99.gut.de.net.telefonica.de (::ffff:62.52.193.55) 19.901 ms * 6 2a02:3001::6b (2a02:3001::6b) 20.457 ms 2a02:3001::26b (2a02:3001::26b) 20.345 ms 20.316 ms 7 * * * 8 2001:7f8:8:20:0:3417:0:1 (2001:7f8:8:20:0:3417:0:1) 17.265 ms 2400:cb00:100:1024::ac44:6d3e (2400:cb00:100:1024::ac44:6d3e) 15.844 ms 2001:7f8:8:20:0:3417:0:1 (2001:7f8:8:20:0:3417:0:1) 17.570 ms
$ curl -Ss -I -6 https://kagi.com | grep HTTP HTTP/2 302 $ curl -Ss -I -6 https://kagi.com | grep HTTP curl: (35) Recv failure: Connection reset by peer $ traceroute -6 kagi.com traceroute to kagi.com (2600:1901:0:daa1::), 30 hops max, 80 byte packets 1 dynamic-2a01-0c22-acd4-0000-2e91-abff-febe-6b2b.c22.pool.telefonica.de (2a01:c22:acd4:0:2e91:abff:febe:6b2b) 0.389 ms 0.515 ms 0.660 ms 2 2a02:3001::125 (2a02:3001::125) 30.966 ms 31.337 ms 31.326 ms 3 * 2a02:3001::1ca (2a02:3001::1ca) 9.493 ms 9.599 ms 4 * * loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168) 18.169 ms 5 * lo0.02.rl2t.99.gut.de.net.telefonica.de (::ffff:62.52.193.55) 20.743 ms loopback0.0003.corx.01.ham.de.net.telefonica.de (::ffff:62.52.192.179) 18.136 ms 6 2a02:3001::22d (2a02:3001::22d) 20.094 ms 2a02:3001::1b8 (2a02:3001::1b8) 13.191 ms 11.330 ms 7 * * * 8 2001:4860:1:1::56a (2001:4860:1:1::56a) 18.017 ms 2001:4860:0:1::591b (2001:4860:0:1::591b) 17.139 ms 2001:4860:0:1::8123 (2001:4860:0:1::8123) 13.022 ms 9 2001:4860:0:1::591d (2001:4860:0:1::591d) 18.640 ms 2001:4860:0:1::8123 (2001:4860:0:1::8123) 13.386 ms 2001:4860:0:1::531f (2001:4860:0:1::531f) 14.043 ms 10 2600:1901:0:daa1:: (2600:1901:0:daa1::) 13.577 ms 2001:4860:0:1::1c5d (2001:4860:0:1::1c5d) 14.790 ms 2600:1901:0:daa1:: (2600:1901:0:daa1::) 14.793 ms
$ curl -Ss -I -6 --resolve 'www.openstreetmap.org:443:2606:4700:3034::6815:5842' https://www.openstreetmap.org | grep HTTP curl: (35) Recv failure: Connection reset by peer $ curl -Ss -I -6 --resolve 'www.openstreetmap.org:443:2606:4700:3034::6815:5842' https://www.openstreetmap.org | grep HTTP HTTP/2 200 $ traceroute -6 www.openstreetmap.org traceroute to www.openstreetmap.org (2606:4700:3034::6815:5842), 30 hops max, 80 byte packets 1 dynamic-2a01-0c22-acd4-0000-2e91-abff-febe-6b2b.c22.pool.telefonica.de (2a01:c22:acd4:0:2e91:abff:febe:6b2b) 0.367 ms 0.465 ms 0.592 ms 2 2a02:3001::125 (2a02:3001::125) 46.619 ms 46.774 ms 46.788 ms 3 2a02:3001::1ca (2a02:3001::1ca) 9.441 ms 9.326 ms * 4 * loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168) 20.270 ms 19.732 ms 5 * * * 6 2a02:3001::6b (2a02:3001::6b) 18.794 ms 19.844 ms 2a02:3001::26a (2a02:3001::26a) 18.477 ms 7 * * * 8 2400:cb00:100:1024::ac44:6d0c (2400:cb00:100:1024::ac44:6d0c) 15.059 ms 2400:cb00:928:3:: (2400:cb00:928:3::) 17.211 ms 2001:7f8:8:20:0:3417:0:1 (2001:7f8:8:20:0:3417:0:1) 18.521 ms
Beste Grüße
Hm. Weniger schön…
Willkommen auf jeden Fall in unserer Community, @j m.
Ich geb das intern direkt mal weiter, damit da mal Blicke drauf geworfen werden. Danke dir auf jeden Fall für die mitgeschickten Infos!
Gruß,
Lars
Seid ihr hier in irgend einer Form weiter gekommen? Ich hab das Problem seit einiger Zeit “etwa genauso”. Kann es sowohl mit Arch Linux (als auch mit Windows 10/11, hier mittels git) auslösen.
Gleiches System, anderer Anschluss+Anbieter hat keine Probleme. Bei mir ist es allerdings auch nicht dauerhaft. Mindestens 50% der Anfragen gehen ohne Problem durch und die anderen 50% bekommen einen Connection reset.
Hallo in die Runde. Auch bei mir besteht das Problem nach über einem Jahr nach wie vor. Ist übrigens auch bei mir ein Berliner O2-VDSL Anschluss (Bitstream über die Telekom, soweit ich weiß).
Ein Jahr lang ohne stabile IP-Konnektivität, irgendwie war das damals mit analogen Modems über Telefonleitung alles stabiler. Und offenbar sind wir Nutzer seitdem sehr genügsam geworden, dass wir uns mit solchen Zuständen arrangieren :)
Ich bin inzwischen darauf konditioniert, Ctrl+R zu drücken, wenn eine Webseiten nicht lädt. Und hab die Hoffnung aufgegeben, dass mit IPv6 jetzt alles besser wird.
@mhlavac : super, dass das inzwischen sogar server-seitig auffällt, dass eine vielzahl von clients aus dem O2 netz nicht mehr durchkommen. Bin gespannt, ob vielleicht cloudflare selbst was rausfindet.
Bin übrigens gerade wieder über das Problem gestolpert hier. Nichtmal xkcd kann man auf Anhieb laden:
$ https_proxy= curl -v -6 https://xkcd.com > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 2a04:4e42::67:443... * Connected to xkcd.com (2a04:4e42::67) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs } s5 bytes data] * TLSv1.3 (OUT), TLS handshake, Client hello (1): } e512 bytes data] * OpenSSL SSL_connect: Connection reset by peer in connection to xkcd.com:443 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 * Closing connection 0 curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to xkcd.com:443
zugehöriger Traceroute:
$ traceroute -6 2a04:4e42::67 traceroute to 2a04:4e42::67 (2a04:4e42::67), 30 hops max, 80 byte packets 1 2a02:3001::23f (2a02:3001::23f) 12.070 ms 12.236 ms 12.438 ms 2 * * * 3 loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168) 21.969 ms * 23.010 ms 4 * * * 5 2a02:3001::26b (2a02:3001::26b) 23.738 ms 22.832 ms 2a02:3001::280 (2a02:3001::280) 21.895 ms 6 2a02:3001::1a2 (2a02:3001::1a2) 21.318 ms 2a02:3001::6d (2a02:3001::6d) 21.771 ms 2a02:3001::1a2 (2a02:3001::1a2) 21.597 ms 7 * * *
..]
30 * * *
Bin übrigens gerade wieder über das Problem gestolpert hier. Nichtmal xkcd kann man auf Anhieb laden:
<..]
xkcd.com ist nicht Cloudflare, sondern Fastly (AS54113). Das Problme ist also größer, und nicht nur auf cloudflare beschränkt! Wie geht es denn den anderen Berlinern hier im Thread beim Zugriff auf xkcd.com?
xkcd.com ist nicht Cloudflare, sondern Fastly (AS54113). Das Problme ist also größer, und nicht nur auf cloudflare beschränkt! Wie geht es denn den anderen Berlinern hier im Thread beim Zugriff auf xkcd.com?
Laut server headern (wget -S)
X-Served-By: cache-fra-etou8220052-FRA
wird in diesem Fall die Anfrage in einem Datenzentrum in Frankfurt beantwortet.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Scanne Datei nach Viren
Tut uns leid, wir prüfen noch den Inhalt dieser Datei, um sicherzustellen, dass sie gefahrlos heruntergeladen werden kann. Bitte versuche es in wenigen Minuten erneut.
