Eine Zeit voller Sperren: Ein Überblick über Internetstörungen im zweiten Quartal 2025

Das Netzwerk von Cloudflare erstreckt sich derzeit über mehr als 330 Städte in über 125 Ländern, und wir sind mit über 13.000 Netzwerkanbietern verbunden, um Millionen von Kunden eine breite Palette von Diensten anbieten zu können. Die Größe unseres Netzwerks und unseres Kundenstamms liefern uns eine einzigartige Perspektive auf die Ausfallsicherheit des Webs und geben uns die Möglichkeit, die Auswirkungen von Internetstörungen sowohl auf lokaler und nationaler Ebene als auch auf Netzwerkniveau zu beobachten.

Wie bereits zu früheren Gelegenheiten angemerkt, soll dieser Beitrag einen allgemeinen Überblick über gesicherte Störungen geben. Die Beschreibung der im Quartal verzeichneten Probleme erhebt keinen Anspruch auf Vollständigkeit. Eine umfangreichere Aufstellung der Fälle, in denen Auffälligkeiten beim Datenverkehr registriert wurden, finden Sie im Outage Center von Cloudflare Radar. In den Grafiken dieses Beitrags wird der Traffic entweder in Bytes oder als Anfragemenge angegeben – je nachdem, mit welcher Kennzahl sich die Auswirkungen der beobachteten Störungen besser veranschaulichen lassen.

In unserem Zusammenfassungsbeitrag für das erste Quartal 2025 haben wir angemerkt, dass wir im Laufe des Quartals keine staatlich angeordneten Internetsperren beobachtet haben. Leider war dieser Fortschritt nur von kurzer Dauer – im zweiten Quartal 2025 haben wir Sperren in Libyen, Iran, Irak, Syrien und Panama beobachtet. Die Abhängigkeit des Internets von einem stabilen Stromnetz wurde im Laufe des Quartals durch einen massiven Stromausfall in Spanien und Portugal deutlich, der die Konnektivität innerhalb dieser Länder unterbrach. Ausfälle von Glasfaserkabeln beeinträchtigten Anbieter in Haiti und Malawi, große nordamerikanische Anbieter erlebten technische Probleme, die den Internet-Traffic störten, und ein russischer Anbieter wurde erneut von einem bedeutenden Cyberangriff getroffen, der das Netzwerk lahmlegte. Leider ist die offizielle Zuordnung der Ursache eines Internetausfalls nicht immer verfügbar – und wir haben im Laufe des Quartals mehrere bedeutende, aber ungeklärte Internetausfälle beobachtet.

Am 16. Mai wurden Internetstörungen bei mehreren libyschen Netzbetreibern beobachtet, wobei die Verbindung Berichten zufolge als Reaktion auf öffentliche Proteste gegen die Regierung der Nationalen Einheit abgeschaltet wurde. Ab 13:30 Uhr UTC (15:30 Uhr Ortszeit) sank der Traffic bei der Libyan International Company for Technology (AS329129), Giga Communication (AS328539), Aljeel Aljadeed for Technology (AS37284) und Awal Telecom (AS328733) um mehr als 50 % im Vergleich zur Vorwoche, wobei es bei letzterem zu einem vollständigen Ausfall kam. Bis etwa 00:00 Uhr UTC (02:00 Uhr Ortszeit) wurde ein geringeres Traffic-Aufkommen beobachtet, wobei der Traffic innerhalb von etwa einer Stunde auf beiden Seiten wiederhergestellt wurde. Giga Communication (AS328539) erlebte am 17. Mai zwischen 02:00 und11:30 Uhr UTC (04:00 und 13:30 Uhr Ortszeit) eine zweite Störung.

Im Juni kam es im Iran zu mehreren Internetsperren, nachdem Israel erste Angriffe auf die Nuklearanlagen des Landes durchgeführt hatte. Der erste Vorfall ereignete sich am 13. Juni zwischen 07:15 und 09:45 Uhr UTC (10:45 und 13:15 Uhr Ortszeit). Das iranische Kommunikationsministerium gab eine Erklärung ab, die die Sperre ankündigte: „Angesichts der besonderen Umstände des Landes und basierend auf den Maßnahmen der zuständigen Behörden wurden vorübergehende Einschränkungen des Internets des Landes verhängt. Es ist offensichtlich, dass diese Einschränkungen aufgehoben werden, sobald normale Bedingungen wiederhergestellt sind.“ Diese Anordnung zur Sperre betraf unter anderem Netzwerkanbieter wie FanapTelecom (AS24631), Rasana (AS205647 und AS31549), MCCI (AS197207) und TCI (AS58224).

Am 17. Juni wurde die Internetverbindung erneut eingeschränkt, diesmal angeblich, um „Cyberangriffe abzuwehren“, so ein Regierungssprecher. Diese zweite Runde von Sperren begann um 17:30 Uhr Ortszeit (14:00 Uhr UTC) und betraf mehrere Netzwerke. Der Traffic erholte sich um 17:30 Uhr MESZ (19:00 Uhr Ortszeit) auf FanapTelecom (AS24631) und Pars Online (AS16322) sowie um 21:00 Uhr MESZ (23:30 Uhr Ortszeit) auf MCCI (AS197207) und IranCell (AS44244). 22:00 Uhr UTC am 17. Juni (01:30 Uhr Ortszeit) auf RighTel (AS57218) und um 06:00 Uhr UTC am 18. Juni (09:30 Uhr Ortszeit) auf Rasana (AS31549 und AS205647).

Während dieser ersten Internetsperren wurde Berichten zufolge auch der eingehende Internet-Traffic blockiert, und der Nutzerzugang war auf das inländische „National Information Network“ (NIN) des Iran beschränkt.

Nur einen Tag später, am 18. Juni, wurde eine erweiterte dritte Abschaltung eingerichtet, die von 12:50 Uhr UTC (16:20 Uhr Ortszeit) bis 05:00 Uhr UTC (08:30 Uhr Ortszeit) am 25. Juni dauerte. Erneut wurde die Sperre Berichten zufolge als Mittel zum Schutz vor Cyberangriffen eingeführt, wobei ein Regierungssprecher kommentierte: „Wir haben bereits erklärt, dass wir, falls notwendig, auf ein nationales Internet umsteigen und den globalen Internetzugang einschränken werden. Sicherheit ist unser Hauptanliegen, und wir beobachten Cyberangriffe auf die kritische Infrastruktur des Landes sowie Störungen im Bankwesen. Viele der feindlichen Drohnen werden über das Internet gesteuert, und es wird eine große Menge an Informationen auf diesem Weg ausgetauscht. Auch eine Börse für Kryptowährungen wurde gehackt, und angesichts all dieser Probleme haben wir beschlossen, Internetbeschränkungen zu verhängen.“ Diese Sperre führte zu einem fast vollständigen Verlust des Traffics bis 02:00 Uhr UTC (05:30 Uhr Ortszeit) am 21. Juni, als eine gewisse Erholung des Traffics zu beobachten war, wenn auch auf einem Niveau, das deutlich unter den Volumen vor der Sperre blieb. Der Traffic aus dieser teilweisen Erholung stabilisierte sich für mehrere Tage in einem konstanten Zyklus, bis er am 25. Juni wieder das erwartete Niveau erreichte. Die gleichen Netzbetreiber, die von den vorherigen Sperren betroffen waren, waren auch von dieser betroffen.

Im Einklang mit den in den letzten Jahren (2024, 2023, 2022) ergriffenen Maßnahmen haben die Regierungen im Irak erneut regelmäßige Internetsperren verhängt, um Betrug bei nationalen Prüfungen zu verhindern. (Wir sagen hier „Regierungen“, weil die Schließungen sowohl im Hauptteil des Landes als auch in der Region Irakisch-Kurdistan im Norden des Landes stattfanden.)

Die Sperren im Hauptteil des Landes begannen am 20. Mai und dauerten auf Ersuchen des Bildungsministeriums zwischen 03:00‑05:00 Uhr UTC (06:00‑08:00 Uhr Ortszeit) und dauerten bis zum 4. Juni für die Mitte Schulprüfungen und vom 14. Juni bis zum 3. Juli für vorbereitende Schulprüfungen. Zu den Netzwerkanbietern, die die Abschaltungen durchführten, gehörten Earthlink (AS199739), Asiacel (AS51684), Zainas (AS59588), Halasat (AS58322) und HulumTele (AS203214).

In der Region Kurdistan begannen die Sperren am 1. Juni und dauerten bis zum 6. Juli. Sie fanden mittwochs und sonntags zwischen 03:30 und 04:30 Uhr UTC (06:30 und 07:30 Uhr Ortszeit) statt. Zu den Netzwerkanbietern, die die Sperren durchgeführt haben, gehörten IQ Online (AS48492), KorekTel (AS59625), Newroz Telecom (AS21277), und KNET (AS206206).

Wie der Irak hat auch Syrien schon seit mehreren Jahren landesweite Internetsperren eingeführt, um Betrug bei Prüfungen zu verhindern (2021, 2022, 2023, 2024). Im Gegensatz zu den Vorjahren hat die Regierung 2025 jedoch nur die Unterbrechung der Mobilfunkverbindung angeordnet und in einer veröffentlichten Erklärung vermerkt (übersetzt): „Im Rahmen unseres Engagements, die Integrität öffentlicher Prüfungen zu gewährleisten und die Zukunft unserer geschätzten Schüler und Schülerinnen zu sichern, und basierend auf unserer nationalen Verantwortung, eine faire und transparente Prüfungsumgebung zu gewährleisten, wird in Gebieten in der Nähe von Prüfungszentren in der gesamten Arabischen Republik Syrien eine vorübergehende Sperrung der Mobilfunkkommunikation verhängt. … Die Sperrung der Mobilfunkverbindung wird ausschließlich innerhalb des engstmöglichen geografischen und zeitlichen Rahmens durchgeführt, und zwar während der Zeit, in der sich die Schüler in den Prüfungssälen aufhalten.“

Im zweiten Quartal fanden die mit dem „Basic Education Certificate“ verbundenen Abschaltungen am 21., 24. und 29. Juni zwischen 05:15 und 06:00 Uhr UTC (08:15 bis 09:00 Uhr Ortszeit) statt. Die Prüfungen und die damit verbundenen Internetsperren für das „Secondary Education Certificate“ sind für den Zeitraum vom 12. Juli bis zum 3. August geplant.

Da diese Sperren nur die mobile Konnektivität beeinträchtigten, führten sie nur zu einem teilweisen Rückgang des angekündigten IP-Adressraums, im Gegensatz zu einem vollständigen Verlust wie in den Vorjahren zu sehen war.

Am 21. Juni veröffentlichte die ASEP Panamá (die Regulierungsbehörde für Telekommunikation) einen X-Beitrag, in dem angekündigt wurde, dass (übersetzt) „...in Übereinstimmung mit dem Kabinettsdekret Nr. 27 vom 20. Juni 2025 und auf formelle Anweisung des Ministeriums für Regierung die vorübergehende Aussetzung der Mobiltelefonie- und Internetdienste für Privathaushalte in der Provinz Bocas del Toro koordiniert wurde.“ Die Aussetzung sollte dem Beitrag zufolge bis zum 25. Juni gelten, jedoch wurde in einem späteren Post auf X vermerkt, dass sie bis Sonntag, den 29. Juni 2025, verlängert werden würde.

Die Sperrung der Internetverbindung wurde als Reaktion auf Proteste und Demonstrationen gegen Reformen des Sozialversicherungsfonds, der Altersvorsorge und der Renten, insbesondere in der Provinz Bocas del Toro, durchgeführt.

ie untenstehende Grafik zeigt einen deutlichen Traffic-Verlust bei Cable Onda (AS18809) in Bocas Del Toro, Panama, um ca. 03:30 Uhr UTC am 21. Juni (22:30 Uhr Ortszeit am 20. Juni), mit einer Erholung gegen 06:00 Uhr UTC (01:00 Uhr Ortszeit) am 30. Juni. Die Wiederherstellung steht im Einklang mit dem letzten zugehörigen X-Beitrag von ASEP, der (übersetzt) feststellte: „... Die Internet- und Mobilfunkdienste in der Provinz Bocas del Toro wurden am Montag, den 30. Juni, um 00:01 Uhr wiederhergestellt…“.

Der bedeutendste Stromausfall des zweiten Quartals ereignete sich am 28. April und betraf große Teile von Portugal und Spanien. Die Auswirkungen des Ereignisses wurden ausführlich im Blog-Beitrag „Wie sich der Stromausfall am 28. April 2025 in Portugal und Spanien auf den Internet-Traffic und die Konnektivität auswirkte“ behandelt, der die Veränderungen beim Traffic auf Länder-, Netzwerk- und regionaler Ebene sowie die Auswirkungen auf die Netzwerkqualität und den angekündigten IP-Adressraum untersuchte.

In Portugal ging der Internet-Traffic zurück, als das Stromnetz ausfiel – im Vergleich zur Vorwoche sank er sofort um 50 % und lag innerhalb von fünf Stunden um 90 % unter dem Niveau der Vorwoche.

In Spanien sank der Internet-Traffic, als das Stromnetz ausfiel, wobei der Traffic sofort um etwa 60 % im Vergleich zur Vorwoche zurückging und innerhalb der nächsten fünf Stunden auf etwa 80 % unter das Niveau der Vorwoche fiel.

In beiden Ländern erreichte der Datenverkehr gegen 01:00 Uhr Ortszeit (Mitternacht UTC) am 29. April wieder das erwartete Niveau. Weitere Einzelheiten zum Ausfall finden Sie im oben verlinkten Blogbeitrag.

Es scheint, dass Marokko möglicherweise auch in irgendeiner Weise von dem Stromausfall in Portugal/Spanien betroffen war, oder zumindest Orange Maroc. In einem Beitrag auf X erklärte der Anbieter (übersetzt): „Der Internet-Traffic wurde nach einem massiven Stromausfall in Spanien und Portugal unterbrochen, was internationale Verbindungen beeinträchtigt.“ Der Datenverkehr aus dem Netzwerk (AS36925) fiel stark um 12:00 Uhr UTC (13:00 Uhr Ortszeit), 90 Minuten nach Beginn des Stromausfalls, mit einem vollständigen Ausfall um 15:00 Uhr UTC (16:00 Uhr Ortszeit). Der Traffic erreichte am 28. April gegen 23:30 Uhr UTC (29. April, 00:30 Uhr Ortszeit) wieder das erwartete Niveau.

Genera PR, ein Stromversorger in Puerto Rico, veröffentlichte am 16. April auf X, dass sie „... einen massiven Stromausfall auf der gesamten Insel aufgrund der unerwarteten Abschaltung aller Kraftwerke, einschließlich der von Genera PR und anderen privaten Betreibern, erlebt haben. Diese Situation hat zu einer erheblichen Störung der Stromversorgung geführt...“ Luma Energy, das private Energieunternehmen, das für die Stromverteilung und -übertragung in Puerto Rico verantwortlich ist, veröffentlichte einen eigenen Beitrag auf X, in dem es hieß (übersetzt): „Gegen 12:40 Uhr wurde ein Ereignis verzeichnet, das den Dienst auf der gesamten Insel betrifft.“

Obwohl der gemeldete Stromausfall „massiv“ und „inselweit“ war, hatte er keine übermäßigen Auswirkungen auf den Internet-Traffic von Puerto Rico, der zunächst um etwa 40 % zurückging. In den nächsten Tagen veröffentlichten beide Unternehmen mehrere Updates auf ihren X-Konten, die den Fortschritt bei der Wiederherstellung des Dienstes dokumentierten. Bis 15:00 Uhr UTC (11:00 Uhr Ortszeit) am 18. April hatte sich der Traffic auf das erwartete Niveau normalisiert, entsprechend einem Beitrag von Luma Energy, der (übersetzt) feststellte: „Mit Stand von 10:00 Uhr am 18. April und dank der außergewöhnlichen Reaktion von LUMA sowie des unermüdlichen Einsatzes der Arbeitskräfte der Insel – in Abstimmung mit der Regierung von Puerto Rico und den Stromerzeugern – hat LUMA die Stromversorgung für 1.450.367 Kunden, was 98,8 % aller Kunden entspricht, in weniger als 38 Stunden seit Beginn des inselweiten Ausfalls wiederhergestellt.”

Wie in den untenstehenden Grafiken zu sehen ist, beeinträchtigte der Stromausfall nicht nur die Konnektivität der Endnutzer, was zu dem beobachteten Rückgang des Datenverkehrs führte, sondern hatte auch Auswirkungen auf die lokale Internet-Infrastruktur, wobei einige Störungen im angekündigten IP-Adressraum sichtbar wurden.

In einem Facebook-Post von SKELEC (The St. Kitts Electricity Company) wurden die Kunden von St. Kitts und Nevis am 9. Mai darauf aufmerksam gemacht, dass „...ein Fehler in unserem Needsmust-Stromwerk auftrat, das zu einem inselweiten Ausfall führte. Die Wiederherstellung hat begonnen und die vollständige Wiederherstellung wird in zwei Stunden erfolgen.” Der Beitrag wurde um 17:31 Uhr UTC (13:31 Uhr Ortszeit) veröffentlicht, etwa 30 Minuten nachdem der Internet-Traffic auf der Insel zunächst zurückgegangen war. Die Wiederherstellung des Traffics begann zunächst gegen 17:45 Uhr UTC (13:45 Uhr Ortszeit), also gut innerhalb der zweistündigen Schätzung für die vollständige Wiederherstellung der Stromversorgung. Der Internet-Traffic erreichte jedoch erst um 20:15 Uhr UTC (16:15 Uhr Ortszeit) wieder das erwartete Niveau.

Am 18. Mai wurde berichtet, dass „Hohe Spannungen im regionalen 400-kV-Netz bei niedrigem Verbrauch zu einem kurzfristigen Ausfall im 110-kV-Übertragungsnetz Nordmazedoniens führten...“, so der staatliche Stromversorger MEPSO. Berichten zufolge war der Großteil des Landes von dem Ausfall betroffen, doch MEPSO stellte auch fest, dass die Stromversorgung des Landes innerhalb einer Stunde nach Beginn des Ausfalls wiederhergestellt war. Obwohl der Stromausfall nur kurz war, führte er dazu, dass der Internet-Traffic des Landes während der Störung, die zwischen 03:00 und 04:45 Uhr UTC (05:00 und 06:45 Uhr Ortszeit) auftrat, im Vergleich zur Vorwoche um fast 60 % sank.

Am 1. Juni halbierte sich der Internet-Traffic auf den Malediven im Vergleich zur Vorwoche, als ein weit verbreiteter Stromausfall die Großregion Malé beeinträchtigte. Lokale Internet Service Provider wie Ooredoo und Dhiraagu nutzten die sozialen Medien, um ihre Kunden vor möglichen Unterbrechungen von Festnetz- und mobilen Breitbandverbindungen zu warnen. Auf Landesebene wurde der Internet-Traffic zwischen 07:30 und 13:00 Uhr UTC (12:30 und 18:00 Uhr Ortszeit) unterbrochen.

Der Stromausfall hatte auch eine geringe Auswirkung auf die Internetinfrastruktur, da der angekündigte IPv4-Adressraum einen leichten Rückgang (von 355 auf 350 /24s) verzeichnete, der kurz nach dem anfänglichen Rückgang des Traffics einsetzte, sich aber nach Ende der Störung wieder normalisierte.

Ein nahezu vollständiger Internetausfall beim Anbieter Flow Curaçao (AS52233) am 14. und 15. Juni löste Empörung und Forderungen nach Antworten seitens der Telekommunikationsaufsichtsbehörde des Landes aus. Der Internet-Traffic von Flow fiel am 14. Juni um 18:00 Uhr UTC (14:00 Uhr Ortszeit) erheblich ab und sank in den folgenden Stunden weiter. Anzeichen einer Erholung wurden am 15. Juni gegen 11:00 Uhr UTC (07:00 Uhr Ortszeit) sichtbar, wobei eine vollständigere Erholung um 14:00 Uhr UTC (10:00 Uhr Ortszeit) eintrat. Ein Facebook-Post von Flow Barbados, der am 18. Juni veröffentlicht wurde, verwies auf eine lokale Störung, die am 14. Juni begann, wies jedoch auf einen kommerziellen Stromausfall in einer ihrer wichtigsten regionalen Netzwerkstandorte auf Curaçao hin, der wahrscheinlich die Ursache für diesen Internetausfall war.

Zwei Schäden an der Glasfaserinfrastruktur führten am 28. Mai um 21:00 Uhr UTC (17:00 Uhr Ortszeit) zu einem vollständigen Internetausfall bei Digicel Haiti (AS27653), wie aus einem (übersetzten) X-Post des Generaldirektors des Unternehmens hervorgeht. Der Kabelschaden nahm das Netzwerk vollständig vom Internet, da der angekündigte IPv4- und IPv6-Adressraum ebenfalls auf null fiel. Digicel Haiti blieb bis 00:45 Uhr am 29. Mai (20:45 Uhr Ortszeit am 28. Mai) offline, als sowohl der Datenverkehr als auch der angekündigte IP-Adressraum wieder das erwartete Niveau erreichten.

Airtel Malawi (AS37440) erlebte am 24. Juni einen 90-minütigen Internetausfall, verursacht durch anhaltenden Vandalismus an ihrem Glasfasernetz. Obwohl der Datenverkehr zwischen 12:30 und 14:00 Uhr UTC (14:30 und 16:00 Uhr Ortszeit) praktisch verschwand, blieb das Netzwerk zumindest teilweise online, da zumindest ein Teil des IPv4-Adressraums des Netzwerks weiterhin im Internet angekündigt wurde.  Der angekündigte IPv6-Adressraum fiel jedoch während des Ausfalls auf null.

Aufgrund eines schiefgelaufenen Router-Updates wurde am 21. Mai der Internetdienst für Kunden von Bell Canada (AS577) in Ontario und Quebec unterbrochen. Ein erster X-Post des Anbieters, der um 13:52 Uhr UTC (09:52 Uhr Ortszeit) veröffentlicht wurde, machte die Kunden auf die Dienstunterbrechung aufmerksam. Der Beitrag folgte dem Beginn der Störung um etwa eine halbe Stunde, als der Traffic gegen 13:15 Uhr UTC (09:15 Uhr Ortszeit) um bis zu 70 % zurückging, verglichen mit der gleichen Zeit eine Woche zuvor. Auch der Anfrage-Traffic an die DNS-Auflösung 1.1.1.1 von Cloudflare verzeichnete einen deutlichen Rückgang. Auch der angekündigte IPv4-Adressraum war zu vernachlässigen.

Die Störung war nur von kurzer Dauer, da der Traffic bereits eine Stunde später wieder das erwartete Niveau erreichte. Ein späterer X-Post bestätigte, dass die Dienste bis 15:00 Uhr UTC (11:00 Uhr Ortszeit) vollständig wiederhergestellt waren, wobei ein weiterer Post darauf hinwies, dass das ursprüngliche Update schnell zurückgesetzt wurde, um den Dienst wiederherzustellen. 

In Teilen der Vereinigten Staaten kam es am 19. Juni zu einer weit verbreiteten Unterbrechung des Internets für Lumen/CenturyLink (AS209)-Kunden. Das Traffic-Aufkommen sank ab 21:45 Uhr UTC um über 50 % im Vergleich zur Vorwoche. Die Störung dauerte nur ein paar Stunden, und der Traffic normalisierte sich bis zum 20. Juni um 00:00 Uhr UTC wieder.

Social-Media-Beiträge von betroffenen Abonnenten deuteten darauf hin, dass das Problem möglicherweise mit dem DNS zusammenhing, da diejenigen, die ihre DNS-Auflösung auf Cloudflares 1.1.1.1 umstellten, wieder auf das Internet zugreifen konnten. Die nachstehende Grafik zeigt, dass der Datenverkehr zu 1.1.1.1 von Lumen/CenturyLink das Niveau der Vorwoche übertraf, als die Störung begann, und bis zum 20. Juni erhöht blieb. Probleme mit der DNS-Auflösung eines Internet Service Providers können für Abonnenten wie ein Internetausfall erscheinen, da sie nicht mehr auf alles zugreifen können, was eine DNS-Abfrage erfordert (effektiv alle Internetressourcen), was letztlich zu einem Rückgang des Datenverkehrs zu diesen Ressourcen (von der betroffenen Nutzerbasis) führt, wie das obige Diagramm zeigt.

Der russische Internetanbieter ASVT (AS8752) war Berichten zufolge Ziel eines großen DDoS-Angriffs, der zu einem mehrtägigen vollständigen Internetausfall führte. Diese Attacke folgte einem Angriff auf den russischen Anbieter Nodex (AS29329) im März, der ebenfalls einen vollständigen Ausfall des Dienstes verursachte. Mit einem Durchsatz von 70,07 Gbit/s/6,92 Millionen Paketen pro Sekunde sorgte der Angriff dafür, dass der Traffic am 28. Mai gegen 05:00 Uhr UTC (08:00 Uhr Moskauer Zeit) fast auf Null sank, wobei der effektive Ausfall etwa 10 Stunden dauerte. Obwohl der Datenverkehr gegen 15:00 Uhr UTC (18:00 Uhr Moskauer Zeit) wieder anlief, blieb er in der folgenden Woche unter den erwarteten Werten.

Interessanterweise verzeichnete das Abfragevolumen zur 1.1.1.1 DNS-Auflösung von Cloudflare aus ASVT einen raschen Anstieg, als der Datenverkehr nach dem ersten Ausfall zurückkehrte, und blieb während der gesamten Dauer der Störung erhöht. Es ist unklar, ob der Anstieg mit Problemen der nativen DNS-Auflösung von ASVT während des Angriffs zusammenhängt, die Benutzer zwangen, alternative Resolver zu suchen, oder ob er damit zusammenhängt, dass ASVT-Abonnenten nach Möglichkeiten suchen, den durch den Angriff verursachten Schaden zu umgehen.

Laut einem (jetzt nicht verfügbaren) „Störungsbericht“ und einem damit verbundenen X-Beitrag von Telia Finland (AS1759) hat das Unternehmen bestätigt, dass „beim Betrieb von Mobilfunknetz-Datenverbindungen und Festnetz-Breitbandverbindungen eine weitreichende Störung festgestellt wurde.” Die weit verbreitete Störung führte zu einem kurzen, nahezu vollständigen Ausfall für die Abonnenten zwischen 06:30 und 07:15 Uhr UTC (09:30 und 10:15 Uhr Ortszeit).

Telia Finland hat die Ursache der Störung nicht bekannt gegeben, aber es ist klar, dass sie die IPv4-Konnektivität beeinträchtigt hat, wie in der unten stehenden Grafik zu sehen ist, die den angekündigten IPv4-Adressraum zeigt. (Am angekündigten IPv6-Adressraum hat sich nichts geändert.) Dieser Verlust der IPv4-Konnektivität führte zu einem gleichzeitigen Anstieg des Anteils des Datenverkehrs von Telia Finland über IPv6 — normalerweise unter 5 %, stieg er während der Störung auf über 30 %. Der Anfrage-Traffic von Telia Finland, an die 1.1.1.1-Auflösung von Cloudflare kam zu diesem Zeitpunkt ebenfalls in die Höhe.

Am 7. Mai gegen 19:15 Uhr UTC (03:15 Uhr Ortszeit am 8. Mai) kam es für die Abonnenten von SkyCable (AS23944) auf den Philippinen zu einem vollständigen Internetausfall. Der Internet-Traffic aus dem Netzwerk sank auf null, ebenso wie der angekündigte IPv4-Adressraum. Die Störung dauerte bis 03:00 Uhr UTC am 8. Mai (11:00 Uhr Ortszeit), und SkyCable veröffentlichte keine Informationen über die Ursache des achtstündigen Dienstausfalls.

Am 22. Mai erlitt der thailändische Mobilfunkanbieter TrueMove H (AS132061) einen landesweiten Ausfall, der die Konnektivität der Abonnenten beeinträchtigte. Der Anbieter erkannte die Störung an und entschuldigte sich dafür, lieferte jedoch keinen offiziellen Grund für den Ausfall. (Ein Artikel in der lokalen Presse berichtete, „dass der Ausfall durch technische Fehler auf den Computerservern von True verursacht wurde“ und dass andere vermuteten, dass „das Problem durch einen Fehler auf den DNS-Servern von True verursacht worden sein könnte“.)

Um 03:00 Uhr UTC (10:00 Uhr Ortszeit) fiel der Datenverkehr zunächst um über 80 % im Vergleich zur Vorwoche. Der Datenverkehr begann sich fast sofort langsam zu erholen und erreichte gegen 08:00 Uhr UTC (15:00 Uhr Ortszeit) wieder das erwartete Niveau. Während der ersten Stunde der Störung wurde auch ein kurzer, teilweiser Rückgang des angekündigten IPv4-Adressraums beobachtet.

Zwei Tage nach einem Ausfall aufgrund einer Kabelbeschädigung kam es am 30. Mai zu einem weiteren Komplettausfall bei Digicel Haiti (AS27653). Im Gegensatz zum vorherigen Ausfall wurden von Digicel Haiti oder seinem Director General keine zusätzlichen Informationen zu diesem Ausfall in den sozialen Medien veröffentlicht. Das Netzwerk verschwand effektiv um 14:15 Uhr UTC (10:15 Uhr Ortszeit) aus dem Internet, wobei sowohl der Datenverkehr als auch der angekündigte IP-Adressraum (IPv4 und IPv6) auf Null sanken. Der Ausfall dauerte fast drei Stunden. Gegen 17:00 Uhr UTC (19:00 Uhr MESZ) kehrten der Traffic und der angekündigte IP-Adressraum wieder vollständig zurück.

Am 10. Juni war ein Internetausfall in Syrien Berichten zufolge das ADSL-Festnetz in mehreren Provinzen betroffen. Der Traffic sank um 08:15 Uhr UTC (11:15 Uhr Ortszeit) um bis zu zwei Drittel unter den gleichen Zeitpunkt in der Vorwoche, wobei die Unterbrechung zwei Stunden dauerte. Der angekündigte IPv4-Adressraum fiel während des Ausfalls ebenfalls, was auf ein mögliches Infrastrukturproblem hindeutet. Wie im Folgenden zu sehen ist, war jedoch auch das Anfragevolumen aus Syrien an die 1.1.1.1-DNS-Auflösung von Cloudflare während des Ausfalls erhöht. Dieses Verhalten wurde in der Vergangenheit bei staatlich angeordneten Internetsperren in Syrien beobachtet, wenn der Datenverkehr das Land verlassen konnte, aber nicht zurückkehren konnte. Es gab keinen weiteren Hinweis darauf, dass dieser Ausfall auf eine absichtliche Sperre zurückzuführen war, aber es gab keine offizielle Erklärung für die Störung.

Die von der Regierung angeordneten Internetsperren kehrten im zweiten Quartal mit aller Macht zurück, und dieser Trend setzt sich im dritten Quartal fort, obwohl die neuesten Sperren prüfungsbedingt und nicht durch Proteste verursacht wurden. Und während in der Vergangenheit häufig Internetstörungen im Zusammenhang mit Stromausfällen beobachtet wurden, oft in kleineren Ländern mit weniger stabiler Infrastruktur, erinnert uns der massive Ausfall in Spanien und Portugal am 28. April daran, dass ähnlich wie das Internet auch die elektrische Infrastruktur oft über Länder hinweg miteinander verbunden ist, was bedeutet, dass Probleme in einem Land möglicherweise erhebliche Probleme in anderen verursachen können.

Das Team von Cloudflare Radar überwacht ständig Störungen im Internet und macht seine Beobachtungen im Outage Center von Cloudflare Radar, in den sozialen Netzwerken und in Blogbeiträgen unter blog.cloudflare.com/de-de/ öffentlich. Folgen Sie uns bei @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon) und radar.cloudflare.com (Bluesky) oder nehmen Sie per E-Mail Kontakt zu uns auf.