AS60077 macht Cloud.ir sichtbar, ohne physischen Weg

Zusammenfassung

Zum 20. Juli 2026 beschrieben RIPE RDAP und RIPEstat AS60077 als ein aktives und angekündigtes autonomes System, das 18 IPv4-Präfixe mit insgesamt 14.080 Adressen ursprünglich ankündigte und bei 324 von 325 beobachteten RIS IPv4-Peers sichtbar war.
Die öffentliche Akte zeigte kein aktuell von AS60077 stammendes IPv6-Präfix, führte nur AS43754 als beobachteten Nachbarn auf und offenbarte in PeeringDB weder einen Austauschpunkt noch einen gemeldeten Standort. Diese Feststellungen beweisen jedoch nicht das Fehlen von IPv6, Standorten oder anderen privaten Pfaden.
Die aktiven Seiten von Cloud.ir belegen die Existenz eines umfangreichen kommerziellen Angebots, und die SLA präzisiert einige Grenzen. Sie verknüpfen jedoch nicht jeden Dienst mit AS60077 und belegen nicht den physischen Weg, die nutzbare Kapazität, die unabhängige Vielfalt der Zugänge oder das Wiederherstellungsverhalten.
Die nützliche Frage ist also nicht, ob Asre Dadeha Asiatech eine öffentliche Netzwerkpräsenz besitzt: Diese Präsenz ist gut dokumentiert. Es geht vielmehr darum, festzustellen, inwieweit diese Sichtbarkeit es erlaubt, die tatsächliche Bereitstellung eines Cloud-Dienstes zu bewerten, und wo die Bereiche beginnen, die die zwanzig Quellen nicht zu überprüfen erlauben.

Ein Netzwerkbeweis, der nicht zu einem universellen Beweis werden darf

Der Fußabdruck von AS60077 bietet einen außergewöhnlich präzisen Ausgangspunkt im Vergleich zu vielen Cloud-Angeboten, deren Netzwerk schwer zuzuordnen bleibt. Ein angekündigtes autonomes System hinterlässt Spuren, die mehrere Register und Observatorien vergleichen können: ein Name, eine meldende Organisation, Präfixe, ein BGP-Ursprung, beobachtete Nachbarn und für einige Routen eine RPKI-Autorisierung. Diese Elemente erlauben es, einen Teil des öffentlichen Narrativs zu testen, ohne sich nur auf die kommerzielle Terminologie von Cloud.ir zu verlassen.

Diese Präzision hat jedoch eine Grenze. BGP zeigt an, wie Ziele dem Rest des Internets angekündigt werden; es beschreibt nicht automatisch die Gebäude, Server, Speichersysteme oder Verträge dahinter. Eine Route kann stabil und weithin sichtbar sein, während ein bestimmtes Produkt eine andere Architektur nutzt. Umgekehrt kann eine Dienstfunktion verfügbar sein, ohne direkt als ein von AS60077 stammendes Präfix identifizierbar zu sein. Die Quellen liefern keine Tabelle, die jedes Produkt, jede Adresse und jeden Standort verknüpft.

Die Akte muss daher in mehreren Schichten gelesen werden. Die erste betrifft die administrative Identität des Netzwerks. Die zweite betrifft sein zum Zeitpunkt der Erfassung beobachtetes öffentliches Verhalten. Die dritte betrifft die kommerzielle Oberfläche von Cloud.ir. Die vierte, schwieriger zu dokumentieren, wäre die der physischen Bereitstellung und Wiederherstellung: genauer Standort, unabhängige Pfade, verfügbare Kapazität, Umschaltung und Wiederherstellung. Die ersten drei Schichten enthalten konkrete Beweise. Die vierte besteht hauptsächlich aus Aussagen des Betreibers und offenen Fragen.

Diese Trennung schwächt die positiven Ergebnisse nicht. Sie gibt ihnen eine genaue Reichweite. Zu sagen, dass AS60077 aktiv, angekündigt und in der RIS-Stichprobe sehr sichtbar ist, ist eine solide Schlussfolgerung. Zu sagen, dass diese Sichtbarkeit allein die Resilienz aller Cloud.ir-Dienste beweist, wäre eine Erweiterung, die die Akte nicht zulässt. Das Ziel der Analyse ist genau, die Stärke der ersten Feststellung zu bewahren, ohne zur zweiten überzugehen.

Die administrative Identität von AS60077 ist klar und aktuell

RIPE RDAP führt AS60077 unter dem NamenAT-CLOUDmit dem Status aktiv. Die meldende Organisation istORG-ADA42-RIPE/ Asre Dadeha Asiatech. Die Registrierung der Autonomen Systemnummer datiert vom 27. Juni 2022 und die letzte Änderung ist mit 23. Januar 2026 angegeben. Diese Daten beweisen keine tägliche kommerzielle Aktivität, aber sie zeigen, dass das Registerobjekt weder anonym noch seit fernen Zeiten unverändert ist.

Die RIPEstat-Übersicht ergänzte diese Identität. Zum Abfragezeitpunkt 20. Juli 2026, 8 Uhr UTC, ordnete RIPEstat AS60077 dem InhaberAT-CLOUD Asre Dadeha Asiatechzu und gabannounced=truezurück. Register und Routing-Beobachtung erzählten also eine kompatible Geschichte: Die Nummer ist der untersuchten Einheit zugewiesen und wird zum betrachteten Zeitpunkt öffentlich angekündigt.

Diese Kompatibilität ist wichtig, weil die verschiedenen Quellen nicht dieselbe Funktion erfüllen. RIPE RDAP beschreibt einen administrativen Eintrag. RIPEstat aggregiert Beobachtungen und Routing-Daten. bgp.tools bietet eine zusätzliche öffentliche Zusammenfassung. Wenn sie bei Name, Status und Anzahl der IPv4-Präfixe übereinstimmen, steigt das Vertrauen in die Identifikation der Netzwerkkontrolle. Es geht nicht mehr darum, den Betreiber aus einem Logo oder einer Verkaufsseite abzuleiten.

Die Konvergenz macht die meldende Organisation jedoch nicht zum nachgewiesenen Eigentümer jeder physischen Ressource, die das Produkt bedient. Eine ASN identifiziert eine Routing-Richtliniendomäne. Sie ist weder ein Bestandsverzeichnis noch ein vollständiges Betriebsorganigramm. Die Akte erlaubt es, AS60077 Asre Dadeha Asiatech zuzuordnen; sie erlaubt nicht, das Eigentum an Gebäuden, Glasfasern, Generatoren, Geräten oder der gesamten auf den Diensteseiten erwähnten Kapazität zu schließen.

Der NameAT-CLOUDstärkt natürlich die Verbindung zum Cloud.ir-Angebot, aber der Name ersetzt keine technische Kartierung. Die dokumentarische Verbindung ist plausibel und kohärent: Die Register identifizieren Asre Dadeha Asiatech, während die offiziellen Seiten Cloud.ir als ein Dienstangebot präsentieren, das auf den Rechenzentren von Asiatech basiert. Diese Verbindung stellt einen gemeinsamen Kontext her. Sie liefert immer noch nicht den End-to-End-Pfad eines Servers, eines VPS, eines gespeicherten Objekts oder eines CDN-Datenverkehrs.

Achtzehn IPv4-Ankündigungen bilden einen substantiellen Fußabdruck

Der Routing-Status von RIPEstat zählte 18 von AS60077 stammende IPv4-Präfixe und 14.080 IPv4-Adressen. Die Liste der Ankündigungen zeigt, wie sich diese Gesamtzahl zusammensetzt. Sie umfasst78.110.112.0/21, dann85.198.8.0/22,85.198.12.0/22,85.198.16.0/23,85.198.19.0/24,85.198.20.0/23und85.198.22.0/23.

Im193.151-Raum umfassen die Ankündigungen die Blöcke193.151.128.0/22,193.151.132.0/22,193.151.136.0/22,193.151.140.0/22,193.151.144.0/22,193.151.148.0/22und193.151.152.0/22. Vier spezifischere Präfixe vervollständigen die Menge:193.151.156.0/24,193.151.157.0/24,193.151.158.0/24und193.151.159.0/24. Diese Aufzählung beschreibt nicht die Nutzung jedes Blocks, aber sie zeigt, dass die Gesamtzahl auf einer Reihe identifizierbarer Ankündigungen beruht und nicht auf einer kommerziellen Schätzung.

Am 20. Juli 2026 um 16 Uhr UTC gab RIPEstat193.151.156.0/24als zuletzt beobachtetes Präfix an. Derselbe Status zeigte, dass 324 der 325 berücksichtigten RIS IPv4-Peers AS60077 sahen. Ein solcher Anteil bedeutet, dass der Ursprung zum Zeitpunkt der Messung in diesem Erfassungssystem weitgehend sichtbar war. Er garantiert nicht, dass jeder Internetnutzer einen leistungsfähigen Pfad hatte, aber er schließt das Bild einer nur marginalen oder unsichtbaren Ankündigung in der Stichprobe aus.

bgp.tools zeigte AS60077 ebenfalls als aktives Netzwerk mit 18 stammenden IPv4-Präfixen, keinen stammenden IPv6-Präfixen und AS43754 als Upstream. Der Eintrag verwendete insbesondere ein mit Server-Hosting verbundenes Etikett. Diese Zusammenfassung ist als öffentliche Bestätigung nützlich, fügt aber keinen Beweis für die Kundenkapazität hinzu. Ein Kategorie-Etikett beschreibt, wie das Netzwerk klassifiziert wird; es misst nicht die Anzahl aktiver Maschinen, die Auslastung oder das Volumen der noch verfügbaren Ressourcen.

Der Fußabdruck kann als Verfolgungsbasis dienen. Eine Variation der Anzahl der Präfixe, eine Änderung des Ursprungs oder eine Entwicklung der RIS-Sichtbarkeit wäre im Laufe der Zeit beobachtbar. Für ein Sorgfaltsteam sind diese Indikatoren nützlicher, wenn sie mit Zeitstempeln versehen und mit späteren Beobachtungen verglichen werden. Für sich allein genommen geben sie eine Momentaufnahme. Über die Zeit verglichen können sie eine Expansion, Kontraktion, Migration oder einen zu untersuchenden Vorfall signalisieren.

Auch in dieser Verfolgungsrolle bleibt Vorsicht geboten. Die Sammler beobachten nicht jede private BGP-Sitzung, und ihre Sicht hängt von ihren Beobachtungspunkten ab. Eine von fast allen RIS-Peers gesehene Route ist nicht gleichbedeutend mit einem störungsfreien Dienst. Sie zeigt an, dass eine Steuerinformation weit verbreitet ist. Die Qualität der Bereitstellung hängt immer noch von den Datenpfaden, der Überlastung, den Geräten, den Standorten und den Anwendungen ab, die diese Ankündigungen nicht beschreiben.

Der Adressraum ist kein Maß für die Cloud-Kapazität

Die Zahl von 14.080 IPv4-Adressen scheint quantitativ, was sie leicht überinterpretierbar macht. Sie misst die theoretische Größe der derzeit in der verwendeten Ansicht als Ursprung zugewiesenen Präfixe. Sie offenbart nicht, wie viele Adressen zugewiesen, reserviert, ungenutzt, gemeinsam genutzt, gefiltert oder internen Funktionen gewidmet sind. Sie sagt auch nicht, wie viele Kunden, virtuelle Maschinen oder Dienste diesem Raum entsprechen.

Eine öffentliche Adresse kann eine Maschine, ein Edge-Gerät, eine Übersetzungsfunktion, einen gemeinsam genutzten Abschluss oder eine temporäre Ressource darstellen. Mehrere Lasten können dieselbe Adresse gemeinsam nutzen, während eine einzelne Architektur mehrere Adressen verbrauchen kann. Das Verhältnis zwischen angekündigtem Raum und Rechenkapazität ist daher weder fest noch direkt aus den Routen berechenbar. Der gleiche Vorbehalt gilt für Speicher, Arbeitsspeicher, verkaufbare Bandbreite und elektrische Leistung.

Diese Unterscheidung ist im Fall von Cloud.ir von zentraler Bedeutung, da der Katalog mehrere Produktfamilien präsentiert. Ein Cloud-Server, ein VPS, ein Speicherdienst, ein CDN und eine Domain-Verwaltung legen ihre Ressourcen nicht unbedingt auf die gleiche Weise offen. Die zwanzig Quellen verbinden die 18 Präfixe nicht mit einer Aufschlüsselung nach Produkt. Sie erlauben es auch nicht, den Anteil des Raums zu identifizieren, der für die Steuerungsinfrastruktur, interne Dienste oder Kunden reserviert ist.

Die tatsächlich nutzbare Kapazität ist ein operativer und wirtschaftlicher Begriff. Sie hängt von der installierten Hardware, den Überbuchungsgrenzen, den Sicherheitsreserven, der Spitzennachfrage und den Standortbeschränkungen ab. Sie hängt auch von der verfügbaren Netzwerkkapazität zu den Benutzern ab, nicht nur von der Anzahl der Adressen. Keiner dieser Parameter ist im untersuchten Korpus quantifiziert.

Eine rigorose Analyse muss daher zwei Abkürzungen ablehnen. Die erste wäre, die 14.080 Adressen als 14.080 kommerzielle Einheiten zu behandeln. Die zweite wäre zu glauben, dass das Fehlen von Kapazitätsdaten bedeutet, dass es keine signifikante Kapazität gibt. Die Akte stellt eine IPv4-Oberfläche messbarer Größe fest; sie erlaubt es nicht, diese Oberfläche in verkaufbares Angebot oder nachhaltige Last umzurechnen.

Für einen Käufer ist der richtige Gebrauch der Zahl bescheidener. Sie kann dazu dienen, zu überprüfen, ob der Betreiber einen kohärenten öffentlichen Fußabdruck kontrolliert, und die mit einem Dienst verbundenen Präfixe bei Tests zu identifizieren. Sie ersetzt keine Zusage über Ressourcen, eine Kapazitätsarchitektur, Kontingenzschwellen oder Leistungsnachweise. Ein Routing-Datensatz wird für die Sorgfalt nützlich, wenn er mit einem bestimmten Produkt verknüpft ist, nicht wenn er in einen universellen Indikator umgewandelt wird.

Das gültige RPKI-Präfix bringt drei Beweisarten in Einklang

Das Präfix193.151.156.0/24bietet einen besonders aufschlussreichen Kontrollpunkt. Die RPKI-Validierung von RIPEstat gab den Statusvalidzurück, mit ROAs, die den Ursprung 60077 abdecken. Das bedeutet, dass für diese Stichprobe die Zuordnung zwischen dem angekündigten Präfix und AS60077 der veröffentlichten Ursprungsautorisierung entspricht.

RIPE RDAP ordnete dasselbe Präfix dem aktiven PA-BereichIR-AT-20210316zu, der für den Iran registriert ist und193.151.128.0bis193.151.158.255abdeckt. Die Registrierung erwähnteASIATECH-MNTund die administrativen und technischen Kontakte des Asiatech NOC. Eine BGP-Beobachtung, eine RPKI-Autorisierung und eine administrative Ressourcenzuweisung treffen sich somit um dasselbe Beispiel.

Diese Übereinstimmung ist aussagekräftiger als eine einzelne Registerzeile. Sie zeigt, dass der tatsächlich gesehene Ursprung dem autorisierten Ursprung für das getestete Präfix entspricht und dass der Raum mit einem unter Asiatech-Identifikatoren verwalteten Bereich verbunden ist. Für die Netzwerkzuordnung ist dies ein positives Ergebnis. Es verringert das Risiko, AS60077 mit einer nur auf einer Seite erwähnten Nummer oder einem nicht autorisierten Ursprung für dieses Beispiel zu verwechseln.

Die Reichweite der Validierung muss jedoch eng bleiben. Das Ergebnis betrifft193.151.156.0/24zum Zeitpunkt der Abfrage. Der Korpus liefert kein detailliertes RPKI-Audit jedes der 18 Präfixe. Es wäre daher falsch zu schreiben, dass der gesamte Fußabdruck allein auf der Grundlage dieser Stichprobe notwendigerweise gültig ist. Die überprüfbare Schlussfolgerung ist, dass mindestens eine wichtige gängige Route über eine kohärente RPKI-Autorisierung verfügt.

RPKI zertifiziert auch nicht den Dienst hinter der Adresse. Der Mechanismus hilft Netzwerken zu beurteilen, ob ein Ursprung für ein Präfix autorisiert ist. Er testet weder die Verfügbarkeit eines Servers noch die Integrität der Daten. Er bestätigt nicht das Gebäude, den Eigentümer der Hardware, die Notstromversorgung, die Isolierung zwischen Kunden oder die Qualität des Supports. Eine Route kann RPKI-gültig sein und dennoch zu einem aus anderen Gründen nicht verfügbaren Dienst führen.

Diese Grenze ist keine Schwäche von RPKI; sie spiegelt seinen Zweck wider. Eine gute Analyse verlangt nicht von einem Routing-Sicherheitsmechanismus, eine Frage der Geschäftskontinuität zu lösen. Sie nutzt das Ergebnis für das, was es beweist: die Autorisierung des Ursprungs. Sie sucht dann nach anderen Elementen für Kapazität, Redundanz und Wiederherstellung.

Für ein Kundenteam kann dieses Präfix dennoch zu einem konkreten Bezugspunkt werden. Es kann überprüfen, ob sich seine eigenen Adressen oder Cloud.ir-Ziele in den AS60077 zugeordneten Ankündigungen befinden, ob der Ursprung stabil bleibt und ob der RPKI-Status kohärent bleibt. Diese Kontrolle beantwortet nicht alle Fragen, aber sie verwandelt einen Teil der Beziehung in ein beobachtbares Signal anstatt in ein bloßes Versprechen.

BGP und RIPE Whois beschreiben nicht denselben Zustand

Die Kohärenzansicht von RIPEstat bringt eine weitere wesentliche Unterscheidung. Die in BGP gesehenen IPv4-Präfixe von AS60077 erschienen auch in RIPE Whois. Diese Annäherung unterstützt die administrative Kohärenz der aktuellen Ankündigungen. Sie verringert die Diskrepanz zwischen den beobachteten Routen und den im Register veröffentlichten Objekten.

Dieselbe Ansicht zeigte jedoch mehrere breitere Bereiche oder Komponenten, die in RIPE Whois vorhanden waren, ohne in BGP gesehen zu werden. Diese Diskrepanz ist nicht unbedingt eine Anomalie. Ein Registerobjekt kann eine reservierte Ressource, ein Aggregat, eine potenzielle Politik oder eine Konfiguration abdecken, die derzeit nicht in dieser Form angekündigt wird. Das Register beschreibt, was gemeldet ist; BGP zeigt einen Teil dessen, was tatsächlich verbreitet wird.

Dieser Unterschied erfordert eine disziplinierte Terminologie. Ein in Whois eingetragener Bereich ist nicht automatisch eine aktive Route. Eine Importrichtlinie ist nicht automatisch eine sichtbare Sitzung. Umgekehrt beweist das Fehlen einer Beziehung in der öffentlichen Ansicht nicht, dass keine private oder temporäre Beziehung existiert. Es muss präzisiert werden, ob man von einem administrativen Objekt, einer gemeldeten Richtlinie oder einer Routing-Beobachtung spricht.

AS43754 veranschaulicht eine Konvergenz: Es erscheint in den Import- und Exportinformationen sowohl auf BGP- als auch auf Whois-Seite. AS212895 veranschaulicht den gegenteiligen Fall: Es war in den Whois-Importdaten enthalten, aber nicht in BGP. Die Akte erlaubt es daher zu sagen, dass AS43754 in der untersuchten Rolle sowohl gemeldet als auch beobachtet wird. Sie erlaubt es nicht, AS212895 allein aufgrund der Meldung als aktiven Pfad darzustellen.

Diese Nuance wird entscheidend, wenn man die Redundanz bewertet. Eine Liste von Richtlinien kann den Eindruck mehrerer Optionen erwecken, aber eine eingetragene Option ist noch kein verfügbarer, getesteter und dimensionierter Weg. Um eine Umschaltbehauptung zu stützen, müsste man den Pfad beobachten, seine Unabhängigkeit kennen und über Elemente zu seinem Funktionieren bei einem Ausfall verfügen. Keine dieser drei Ebenen ist für AS212895 im Korpus belegt.

Der Vergleich zwischen Whois und BGP fungiert somit als Filter gegen die wörtliche Lesart der Register. Er bewahrt den Wert der Meldungen, ohne sie mit dem Netzwerkzustand zu verwechseln. Im Fall von AS60077 stärkt er das Vertrauen in die derzeit gesehenen Präfixe, während er verhindert, jedes Objekt oder jede gemeldete Importrichtlinie in operative Kapazität umzuwandeln.

IPv6 ist ein punktuelles Signal, kein nachgewiesener aktueller Ursprung

Die IPv6-Momentaufnahme steht in starkem Kontrast zur IPv4-Oberfläche. Der Routing-Status von RIPEstat zählte kein aktuell als von AS60077 stammend sichtbares IPv6-Präfix. Keiner der 321 RIS IPv6-Peers der Stichprobe sah das autonome System in dieser Rolle. bgp.tools zeigte ebenfalls null stammende IPv6-Präfixe an.

Die Liste der angekündigten Präfixe enthielt jedoch2a05:1a30::/34für einen einzigen Zeitstempel, den 13. Juli 2026. Diese Beobachtung ist präzise genug, um erhalten zu bleiben, aber zu begrenzt, um eine dauerhafte Dienstschlussfolgerung zu stützen. Sie kann einer kurzen Ankündigung, einem Test, einem Übergang oder einem Ereignis entsprechen, das die Quellen nicht beschreiben. Die zusammengestellten Quellen geben weder eine Erklärung noch Kontinuität.

Zwei symmetrische Fehler sind möglich. Der erste wäre, diesen einzelnen Eintrag zu verwenden, um zu behaupten, dass AS60077 derzeit einen stabilen IPv6-Ursprung betreibt. Der aktuelle Routing-Status belegt dies nicht. Der zweite wäre zu behaupten, dass kein Cloud.ir-Dienst über IPv6 verfügt. Die Produkte könnten einen anderen Ursprung nutzen, Pfade verwenden, die die Erfassung nicht mit AS60077 verbindet, oder Funktionen anbieten, die in diesen Daten nicht sichtbar sind.

Die vertretbare Formulierung ist daher zeitlich und gegenständlich begrenzt: Zum Zeitpunkt der Momentaufnahme zeigte die Akte kein aktuell von AS60077 stammendes IPv6-Präfix, trotz eines punktuellen Auftretens von2a05:1a30::/34eine Woche zuvor. Dieser Satz beschreibt genau die Beobachtung, ohne die aktuelle Abwesenheit in universelle Abwesenheit zu verwandeln.

Für einen Kunden, der Dual-Stack-Konnektivität benötigt, sollte diese Unsicherheit zu einer produktweisen Überprüfung führen. Es müsste gefragt werden, welche IPv6-Adressen zugewiesen sind, welches autonome System sie stammt, welche Dienste abgedeckt sind und wie die Konnektivität getestet wird. Eine bloße Erwähnung von IPv6 würde nicht ausreichen; umgekehrt reicht die Ansicht von AS60077 nicht aus, um jede Möglichkeit auszuschließen.

Die Episode vom 13. Juli kann auch als Verfolgungspunkt dienen. Wenn das Präfix stabil wieder auftaucht, kann sich die Schlussfolgerung ändern. Wenn es abwesend bleibt, wird die Akte weiterhin einen im Wesentlichen IPv4-öffentlichen Fußabdruck beschreiben. Eine Zeitstempelanalyse ermöglicht diese Aktualisierung, ohne das tatsächlich Beobachtete zu löschen.

AS43754 ist die sichtbare Abhängigkeit, kein Beweis für unabhängige Vielfalt

Die Nachbarschaftsansicht von RIPEstat gab für AS60077 nur AS43754 zurück. RIPEstat und RIPE RDAP beschrieben AS43754 als aktiv und im Besitz der Asiatech Data Transmission company. bgp.tools zeigte es ebenfalls als Upstream von AS60077. Mehrere Quellen konvergieren also auf eine sichtbare Beziehung und die Identität des anderen Netzwerks.

Diese Konvergenz erlaubt es, die beobachtete öffentliche Abhängigkeit zu benennen. Sie erlaubt es nicht, die gesamte Topologie zu zeichnen. Die Sammler können private Beziehungen, Ersatzsitzungen, nicht exportierte Pfade oder Konfigurationen übersehen, die nur im Fehlerfall aktiviert werden. Die Tatsache, dass nur ein Nachbar erscheint, ist kein mathematischer Beweis dafür, dass es keinen anderen gibt.

Der Vorbehalt bezüglich der toten Winkel darf jedoch nicht umgekehrt werden. Man kann die Möglichkeit unsichtbarer Pfade nicht nutzen, um eine unabhängige Redundanz zu behaupten. In der Akte ist kein zweiter aktiver und unabhängiger Upstream verifiziert. AS212895 erscheint in einer Whois-Erklärung, wird aber nicht in BGP beobachtet. AS43754 bleibt der einzige Nachbar, den die zusammengestellten öffentlichen Daten tatsächlich zeigen.

Die Identität von AS43754 wirft eine zusätzliche Frage zur Fehlerdomäne auf. Es ist der Asiatech Data Transmission company zugeordnet, während AS60077 der Asre Dadeha Asiatech zugeordnet ist. Die Namen deuten auf eine Asiatech-Nähe hin, aber die Quellen liefern nicht die detaillierte rechtliche oder operative Struktur, die es erlauben würde, alle ihre gemeinsamen Abhängigkeiten zu kartieren. Es wäre daher überzogen zu erklären, dass sie notwendigerweise jedes Gerät oder jeden Standort teilen.

Es wäre ebenso überzogen, AS43754 als Beweis für externe Unabhängigkeit zu behandeln. Eine nützliche Vielfalt beurteilt sich anhand der tatsächlich getrennten Ressourcen: Betreiber, Glasfasern, Gebäudeeingänge, Geräte, Stromversorgung, Steuerung und Kapazität. Die unterschiedliche Nummer eines autonomen Systems allein stellt nicht fest, dass diese Dimensionen unabhängig sind. Der Korpus liefert nicht die notwendigen Informationen, um diesen Test durchzuführen.

Der Unterschied zwischen Redundanz und Unabhängigkeit ist wichtig. Eine Architektur kann mehrere Geräte oder mehrere Verbindungen unter derselben Steuerung umfassen und einen echten Schutz gegen bestimmte Ausfälle bieten. Dieser Schutz kann wertvoll sein. Er deckt nicht notwendigerweise einen gemeinsamen Ausfall ab, der denselben Betreiber, denselben Standort, denselben Glasfasergraben oder dieselbe Steuerungsebene betrifft. Die Quellen beschreiben die abgedeckten Szenarien nicht.

Für einen Käufer sollte die Frage daher nicht nur lauten: "Gibt es eine zweite Verbindung?" Es müsste gefragt werden, wer sie betreibt, wo sie verläuft, wo sie endet, welche Kapazität sie während eines Ausfalls behält und wann die Umschaltung getestet wurde. Es müsste auch bekannt sein, ob die vom Vertrag betroffenen Dienste diese Pfade tatsächlich nutzen. Die öffentlichen Daten bieten mit AS43754 einen Ausgangspunkt, nicht die vollständigen Antworten.

Der sichtbare Nachbar ist auch eine Erinnerung daran, dass die große Verbreitung der Präfixe nicht gleichbedeutend mit großer Vielfalt ist. Eine Route kann 324 RIS-Peers erreichen, indem sie upstream über eine konzentrierte Abhängigkeit führt. Die Sammler sehen das Ergebnis der Verbreitung; sie offenbaren nicht alle physischen Schwachstellen, die vor dieser Verbreitung liegen.

PeeringDB dokumentiert hauptsächlich, was nicht offengelegt wird

PeeringDB hatte einen aktuellen Netzwerkeintrag für ASN 60077 im Namen von Asre Dadeha Asiatech. Die Felderstatus=okundrir_status=okzeigten an, dass die Registrierung im Rahmen der Plattform und des betreffenden Registers in Ordnung war. Das Vorhandensein des Eintrags ist ein zusätzliches Identitätssignal.

Der öffentliche operative Inhalt dieses Eintrags war jedoch sehr begrenzt. PeeringDB gabix_count=0undfac_count=0an. Es wurden keine Website, kein Looking Glass, keine Route-Server oder Richtlinien-URL bereitgestellt. Der Eintrag gab auch keine Verkehrsschätzung oder Reichweite preis. Für eine Datenbank, die zur Beschreibung von Zusammenschaltungen konzipiert wurde, lässt diese Detailarmut wenig verwertbare Elemente zur Rekonstruktion einer Präsenz.

Die Nullen sind als Nullmeldungen in dieser Quelle zu lesen, nicht als Beweis für eine physische Abwesenheit. PeeringDB hängt von den von seinen Teilnehmern eingegebenen und gepflegten Informationen ab. Ein Netzwerk kann einen Standort nutzen, ohne ihn in seinem Eintrag zu veröffentlichen, sich privat verbinden oder seine Richtlinie nicht detaillieren.fac_count=0bedeutet daher nicht "kein Rechenzentrum".

Ebenso beweistix_count=0nicht, dass keine Zusammenschaltung existiert. Es bedeutet, dass der Eintrag keine öffentliche Anbindung an einen Austauschpunkt meldete. Transitbeziehungen und private Zusammenschaltungen erschöpfen sich nicht in Austauschpunktleitungen. Der einzige von RIPEstat beobachtete Nachbar AS43754 liefert eine andere Art von Signal, aber immer noch keine Standortangabe.

Diese fehlende Offenlegung hat dennoch eine praktische Konsequenz. Ein externer Analyst kann PeeringDB nicht nutzen, um das Herkunftsgebäude, die metropolitanische Vielfalt, die Trennung der Glasfasereingänge oder die Teilnahme an einer öffentlichen Austauschmatrix zu überprüfen. Die Route ist im Internetmaßstab sichtbar, während ihr physischer Ausgangspunkt in dieser Datenbank undurchsichtig bleibt.

Der Eintrag bietet auch kein Looking Glass, mit dem ein Dritter die Routingsicht aus dem Netzwerk selbst untersuchen könnte. Er veröffentlicht keine Richtlinie, die die Bedingungen für Peering erklären würde. Diese Lücke beweist keinen schlechten Betrieb; sie reduziert lediglich die Möglichkeiten einer unabhängigen Validierung anhand offener Informationen.

Für die Sorgfalt fungiert PeeringDB hier weniger als Karte, sondern eher als dokumentarische Grenze. Es bestätigt, dass eine Netzwerkidentität einen aktuellen Eintrag hat, und zeigt dann, dass die Felder, die diese Identität mit Standorten und Austauschpunkten verbinden könnten, leer sind. Diese Kombination verstärkt die These des Artikels: Die IPv4-Kontrolle ist sichtbar, aber der physische Weg ist es nicht.

Ein Betreiber könnte diese Unsicherheit durch die Veröffentlichung präziser Informationen verringern, aber die Veröffentlichung allein würde noch nicht die Resilienz beweisen. Eine Standortmeldung müsste mit einem Nachweis der aktuellen Präsenz abgeglichen werden; eine Austauschpunktmeldung müsste mit Zusammenschaltungsdaten abgeglichen werden. PeeringDB wäre dann eine bessere Spur, kein universelles Zertifikat.

Cloud.ir besitzt eine aktive und identifizierbare kommerzielle Oberfläche

Die kommerzielle Seite der Akte ist kein bloßes Archiv. Die Website Cloud.ir antwortete zum Zeitpunkt der Erfassung über HTTPS. Ihre Startseite, ihre Vorstellungsseite, ihre Kontaktseite und ihre Dienst-Sitemap bildeten eine für Interessenten und Kunden zugängliche Oberfläche. Diese Verfügbarkeit unterscheidet das Angebot von einer Marke, die nur historische Spuren hinterlassen würde.

Die Sitemap verwies auf Seiten für Cloud-Server, VPS, Cloud-Rechenzentrum, Cloud-Switch, Domain-Verwaltung, CDN und Cloud-Speicher. Dielastmod-Werte der Hauptseiten lagen in den Jahren 2025 und 2026. Diese Daten garantieren nicht, dass jedes Produkt tiefgreifend geändert wurde, aber sie zeigen, dass der Katalog in einem aktuellen Zeitraum gepflegt wird.

Die offiziellen Seiten geben an, dass der Cloud-Dienst im Jahr 1399 des iranischen Kalenders begann und mehr als zwanzig Produkte umfasst. Sie geben auch an, dass das Angebot auf den Rechenzentren von Asiatech im Iran läuft. Diese Elemente beschreiben das operative Narrativ des Unternehmens und ermöglichen es zu verstehen, wie es seine Abhängigkeit von der Asiatech-Infrastruktur darstellt.

Die Akte stützt daher zwei unterschiedliche Feststellungen. Einerseits besitzt AS60077 eine öffentliche IPv4-Präsenz, die Asre Dadeha Asiatech zugeordnet ist. Andererseits präsentiert Cloud.ir derzeit einen Cloud-Katalog, der in eigenen Texten mit den Rechenzentren von Asiatech verbunden ist. Die Nähe der Namen und Aussagen macht die Verbindung relevant.

Diese Verbindung stellt jedoch keine dienstweise Entsprechung dar. Die Quellen sagen nicht, dass jede Adresse eines Cloud-Servers zu einem der 18 Präfixe gehört. Sie sagen nicht, dass ein VPS, ein CDN und der Speicher exakt dasselbe Netzwerk nutzen. Sie offenbaren nicht die möglichen autonomen Systeme, die für externe Funktionen, Abwehr oder Verteilung verwendet werden.

Die Kontaktseite fügt eine Beziehungsoberfläche hinzu, aber die Quellen messen nicht die Qualität oder Reaktionszeit. Eine zugängliche Seite beweist, dass ein Kanal veröffentlicht ist; sie beweist weder, dass ein Team zu jeder Stunde antwortet, noch dass ein komplexer Vorfall innerhalb einer bestimmten Frist gelöst wird. Dieselbe Unterscheidung muss auf jedes sichtbare kommerzielle Element angewendet werden.

Der Wert des Katalogs ist daher real, aber begrenzt. Er stellt fest, dass Cloud.ir eine Reihe von Diensten verkauft und beschreibt. Er hilft, die Produkte zu identifizieren, für die eine genauere Sorgfalt durchgeführt werden sollte. Er ersetzt nicht die Architektur jedes Produkts. Je breiter der Katalog, desto riskanter wird eine globale Zuordnung zu einem einzigen Netzwerkpfad.

Die Rechenzentrumsaussagen bleiben Aussagen des Betreibers

Die Cloud.ir-Seiten verwenden Verweise auf ISO27001, TIA-942 und auf Stufen, die in einer Tier-2/3-ähnlichen Terminologie dargestellt werden. Sie verbinden die Dienste auch mit Asiatech-Rechenzentren im Iran. Diese Aussagen sind relevant, weil sie die Standards und die Resilienz anzeigen, die der Betreiber hervorheben möchte.

Der Korpus enthält jedoch weder ein unabhängiges Zertifikat, noch einen Prüfbericht, noch eine genaue Liste der Standorte, auf die sich jede Aussage bezieht. Er liefert weder den Umfang einer möglichen Zertifizierung, ihre Gültigkeitsdauer, die zertifizierte Einheit oder die Ausschlüsse. Ein Verweis auf eine Norm auf einer Diensteseite reicht nicht aus, um zu belegen, dass jede Komponente jedes Produkts abgedeckt ist.

Die gleiche Vorsicht gilt für Tier-2/3-ähnliche Stufen. Diese Ausdrücke können ein Design, einen Anspruch, eine beanspruchte Stufe oder eine auf einen bestimmten Standort angewendete Klassifizierung beschreiben. Ohne unabhängiges Dokument und ohne Identifikation des Standorts ist es unmöglich, genau zu wissen, was bewertet wurde. Der Artikel muss sie daher Cloud.ir zuschreiben und nicht als von den zwanzig Quellen verifizierte Ergebnisse präsentieren.

Die Daten beschreiben auch nicht die Strom- und Kühltopologie. Sie geben weder die Anzahl der Strompfade, noch die Notstromdauer, noch die Trennung der Generatoren, noch die verfügbare thermische Kapazität an. Sie dokumentieren nicht die Glasfasereingänge, die Entfernung zwischen Standorten oder die gemeinsamen Abhängigkeiten. All diese Elemente wären notwendig, um eine Rechenzentrumsbehauptung in eine Resilienzanalyse umzuwandeln.

Das Fehlen dieser Unterlagen widerlegt die Behauptungen nicht. Es zeigt lediglich, dass der öffentliche Beobachter sie mit diesem Korpus nicht überprüfen kann. Ein absolutes negatives Urteil wäre ebenso ungerechtfertigt wie eine vorbehaltlose Akzeptanz. Die korrekte Formulierung ist, dass die Seiten diese Aussagen machen und der Korpus sie nicht unabhängig verifiziert.

Diese explizite Zuschreibung schützt auch den Wert zukünftiger Beweise. Wenn Cloud.ir später ein Zertifikat veröffentlicht, dessen Umfang, Standort und Datum klar sind, kann die Akte ergänzt werden, ohne die aktuelle Beobachtung umzuschreiben. Wenn eine andere Quelle eine Präsenz bestätigt, kann sie als Bestätigung hinzugefügt werden. Heute bleibt die physische Schicht eine zu überprüfende Aussage.

Für einen Kunden hängt der Präzisionsbedarf vom Produkt ab. Eine verwaltete Domain, eine kritische virtuelle Maschine und eine Sicherungskopie haben nicht dieselben Anforderungen. Es müsste bekannt sein, in welchem Standort sich jede Komponente befindet, welche Kontrollen gelten und welche Abhängigkeiten gemeinsam genutzt werden. Die globale Marke eines Rechenzentrums entspricht nicht dieser Granularität.

Kein Dokument verknüpft bisher jedes Produkt mit seiner Route und seinem Standort

Die Hauptlücke der Akte liegt zwischen den Netzwerkbeweisen und den Diensteseiten. Auf der einen Seite liefern die Quellen eine Liste von Präfixen und ein autonomes System. Auf der anderen Seite liefern sie Produktnamen und kommerzielle Versprechen. Dazwischen fehlt eine Zuordnungsmatrix.

Eine solche Matrix würde für den Cloud-Server die verwendeten Bereiche, das stammende autonome System, den Standort oder die Standorte, den Haupt-Upstream und den Sicherungsmechanismus angeben. Sie würde die gleiche Arbeit für VPS, Speicher, CDN und andere Dienste leisten. Sie würde auch angeben, ob Steuerungsebene und Datenebene dieselben Abhängigkeiten teilen.

Ohne diese Matrix bleiben mehrere Architekturen möglich. Einige Produkte könnten AS60077 direkt nutzen. Andere könnten auf AS43754, auf Drittanbieternetzwerke oder auf Ressourcen basieren, die im Korpus nicht sichtbar sind. Das CDN könnte eine andere Verteilung als der Cloud-Server haben. Der Speicher könnte einen anderen internen Pfad haben. Die Quellen erlauben es nicht, zwischen diesen Möglichkeiten zu wählen.

Diese Unsicherheit verbietet es, einen Routing-Erfolg als Ersatz für einen Produkttest zu verwenden. Die Tatsache, dass193.151.156.0/24weitgehend sichtbar und RPKI-gültig ist, beweist nicht, dass eine bestimmte Instanz verfügbar ist. Umgekehrt beweist eine verfügbare Instanz nicht, dass sie sich in diesem Präfix befindet. Die Bewertung muss von der tatsächlich gekauften Ressource ausgehen.

Eine Verifikationsmethode könnte mit den vom Kunden beobachteten Adressen beginnen. Sie würde sie mit den Präfixen, ihrem Ursprung und ihrem RPKI-Status abgleichen. Sie würde dann vom Betreiber die Bestätigung des Standorts und der anwendbaren Pfade verlangen. Schließlich würde sie diese Antworten mit den vertraglichen Zusagen und Umschalttests vergleichen. Jeder dieser Schritte deckt eine andere Schicht ab.

Die Kontrolle muss auch die Verwaltungsfunktionen umfassen. Ein Portal, eine API, ein Backup-System und der Datenverkehr einer Maschine können von verschiedenen Netzwerken abhängen. Ein Ausfall, der die Datenebene verschont, aber die Authentifizierung betrifft, kann einen Eingriff verhindern. Die untersuchten Seiten liefern diese Aufschlüsselung nicht; sie erlauben daher nicht, eine Unabhängigkeit gutzuschreiben, die nicht gezeigt wird.

Diese dokumentarische Lücke erklärt, warum die These nicht die Existenz von Cloud.ir betrifft. Das Angebot und das Netzwerk sind gut sichtbar. Sie betrifft die Verbindung zwischen beiden. Eine Cloud-Infrastruktur ist erst dann durchgängig bewertet, wenn die Routen, Standorte, Kapazitäten und Wiederherstellungsverfahren mit den tatsächlich genutzten Diensten verknüpft werden können.

Die SLA zeichnet eher eine Verantwortungsgrenze als einen Wiederherstellungsplan

Die SLA von Cloud.ir ist ein wesentliches Dokument, weil sie zeigt, was der Betreiber abdecken und ausschließen möchte. Der Text beschränkt die Verfügbarkeitsgarantien auf das Netzwerk und den Cloud-Server im Rahmen des normalen Betriebs. Diese Reichweite ist enger als die allgemeine Vorstellung einer Verfügbarkeit des gesamten Kundenerlebnisses.

Das Dokument schließt insbesondere die Software und Betriebssysteme des Kunden, Konfigurationsfehler und Ausfälle von Geräten im Eigentum des Kunden aus. Diese Aufteilung ist in einem Infrastrukturmodell üblich: Der Anbieter schützt bestimmte Schichten, während der Kunde für das verantwortlich bleibt, was er installiert und verwaltet. Sie bedeutet dennoch, dass eine für den Benutzer sichtbare Unterbrechung außerhalb der Garantie liegen kann, wenn ihre Ursache der Kundenschicht zugeschrieben wird.

Denial-of-Service-Angriffe gehören ebenfalls zu den Ausschlüssen. Diese Erwähnung ist für einen dem Internet ausgesetzten Dienst wichtig. Sie besagt nicht, dass kein Schutz existiert; sie zeigt an, dass die beschriebene Garantie nicht als universelle Abdeckung dieses Szenarios gelesen werden sollte. Die Quellen detaillieren weder einen Abwehrdienst noch die Bedingungen, unter denen ein Angriff übernommen würde.

Wartung und kritische Patches sind ebenfalls ausgeschlossen. Ein geplantes Fenster und ein dringender Eingriff können daher eine Nichtverfügbarkeit verursachen, ohne in die gleiche Berechnung wie ein gewöhnlicher Ausfall zu fallen. Um die erlebte Verfügbarkeit zu bewerten, muss ein Kunde nicht nur den angekündigten Prozentsatz kennen, sondern auch die aus der Berechnung herausgenommenen Kategorien, die Häufigkeit der Eingriffe und die Vorankündigung.

Die SLA erwähnt ferner höhere Gewalt, Aussetzungen, vom Kunden verlangte Stopps, Nichtzahlung und bestimmte rechtliche oder sicherheitsbedingte Anordnungen. Diese Ausschlüsse zeigen, dass der Zugang zum Dienst von technischen, vertraglichen und regulatorischen Faktoren abhängt. Eine Architektur kann einwandfrei funktionieren und dennoch aus einem außerhalb der Hardware liegenden Grund nicht verfügbar sein.

Diese Liste sollte nicht als an sich abnormal dargestellt werden. Eine SLA dient genau dazu, eine Grenze zu definieren. Ihr analytischer Wert liegt in der Tatsache, dass sie verhindert, ein Verfügbarkeitsversprechen in eine absolute Garantie zu verwandeln. Zwei aus Benutzersicht identische Vorfälle können je nach Ursache und verantwortlicher Partei unterschiedlich klassifiziert werden.

Das konsultierte Dokument liefert nicht die Umschaltsequenzen für jeden Dienst. Es gibt kein Wiederherstellungszeitziel, kein Wiederherstellungspunktziel, kein Übungsergebnis oder keinen Vorfallverlauf. Es gibt nicht an, welche Kapazität verfügbar bleibt, wenn eine Hauptkomponente ausfällt. Die vertragliche Grenze ist sichtbar; der technische Wiederherstellungsmechanismus bleibt undurchsichtig.

Diese Unterscheidung gilt insbesondere für Daten. Eine Verfügbarkeitsgarantie des Servers oder des Netzwerks beantwortet nicht automatisch die Frage nach Persistenz, Replikation oder Wiederherstellung. Der Korpus erlaubt es nicht, festzustellen, wo sich die Kopien befinden, ob sie einen Standort teilen oder wie sie getestet werden. Es wäre daher falsch, die Datenwiederherstellung aus einer Zugangsgarantie abzuleiten.

Die SLA stellt auch nicht fest, dass alle Produkte des Katalogs denselben Schutz genießen. Ihre Sprache bezieht sich auf das Netzwerk und den Cloud-Server unter definierten Bedingungen. Ein Kunde von VPS, Speicher oder CDN muss die für seinen spezifischen Dienst geltenden Verpflichtungen überprüfen. Der kommerzielle Katalog und der vertragliche Umfang sollten nicht als identisch angenommen werden.

Um Angebote zu vergleichen, sollte ein Käufer drei Informationssätze anfordern. Der erste ist die Berechnungsformel der Verfügbarkeit mit Ausschlüssen. Der zweite ist die Wiederherstellungsarchitektur mit Abhängigkeiten. Der dritte ist der Betriebsnachweis in Form von Tests und dokumentierten Vorfällen. Die untersuchte SLA liefert einen Teil des ersten Satzes, aber nicht die anderen beiden.

Die Sichtbarkeit der Steuerung sagt nichts über das Verhalten bei einem Ausfall aus

AS60077 kann weiterhin seine 18 Präfixe ankündigen, während ein bestimmter Dienst ein internes Problem hat. Umgekehrt kann sich eine Route ändern, während der Dienst über einen anderen Pfad zugänglich bleibt. BGP und Anwendungsverfügbarkeit entwickeln sich auf unterschiedlichen Ebenen. Ihre Beziehung muss beobachtet, nicht angenommen werden.

Ein Server-, Speicher- oder Softwareausfall entzieht nicht notwendigerweise die Route. Die Sammler würden dann weiterhin den Ursprung sehen, auch wenn der Kunde seine Ressource nicht mehr nutzen kann. Ein Upstream-Ausfall könnte dagegen die Sichtbarkeit verändern, während die internen Systeme intakt bleiben. Die Quellen enthalten keine Vorfallchronologie, die es erlauben würde, diese Signale zu vergleichen.

Der gleiche Vorbehalt gilt für die Umschaltung. Ein zweites Gerät oder ein zweiter Standort kann existieren, ohne die Last korrekt zu übernehmen. Der nützliche Beweis ist nicht nur seine Existenz, sondern das Ergebnis einer Übung oder eines realen Ereignisses. Man muss die Erkennungszeit, die Entscheidungszeit, die Konvergenzzeit und den Zustand der Daten nach der Wiederherstellung kennen.

Der einzige beobachtete öffentliche Nachbar, AS43754, konzentriert die Aufmerksamkeit auf den Upstream-Pfad, erlaubt aber nicht, das gesamte Verhalten zu modellieren. Eine versteckte Redundanz könnte eingreifen. Eine gemeinsame Abhängigkeit könnte auch die Umschaltung begrenzen. Ohne Topologie und ohne Test bleiben beide Hypothesen offen. Die Analyse muss diese Unsicherheit festhalten, anstatt das günstigste oder alarmierendste Szenario zu wählen.

Die RIS-Sichtbarkeit selbst ist ein externer Indikator. Sie zeigt, dass viele Beobachtungspunkte die Ankündigung empfangen. Sie misst nicht die Latenz, Verluste, Sättigung oder den Erfolg einer Verbindung zu einer Anwendung. Ein Netzwerk kann sichtbar und degradiert sein. Eine Steuerungsmessung muss durch Daten- und Dienstmessungen ergänzt werden.

Diese Unterscheidung vermeidet eine häufige Verwechslung in der Cloud-Ökonomie. Die Ressourcen, die ein Angebot verkaufbar machen, erschöpfen sich nicht in Adressierung und Routing. Sie umfassen Rechnen, Speicher, Energie, Kühlung, Betrieb, Support und die Fähigkeit, eine Komponente zu ersetzen. Der Korpus zeigt einen Teil der ersten Ebene, aber nicht das Ganze.

Die Schlussfolgerung sollte daher nicht sein, dass Routing-Daten zweitrangig sind. Sie sind unverzichtbar, um das Netzwerk zuzuordnen und zu überwachen. Ihr Nutzen steigt, wenn ihre Grenze anerkannt wird. Sie erkennen bestimmte Unterbrechungen und machen bestimmte Behauptungen überprüfbar; sie ersetzen keinen Kontinuitätsplan.

Was ein Käufer anhand der verfügbaren Beweise überprüfen kann

Der erste Schritt besteht darin, das tatsächlich betroffene Produkt zu identifizieren. Eine Organisation, die einen Cloud-Server kauft, hat nicht genau dieselben Abhängigkeiten wie eine Organisation, die CDN oder Speicher nutzt. Es müssen die Adressen, Dienstnamen, Verwaltungspunkte und vertraglichen Verpflichtungen dieser Ressource eingeholt werden.

Die beobachteten Adressen können dann mit den 18 Präfixen von AS60077 verglichen werden. Wenn sie sich darin befinden, hat der Käufer eine konkrete Verbindung zwischen seinem Dienst und dem analysierten Fußabdruck. Wenn sie sich nicht darin befinden, sollte er nicht automatisch auf eine Anomalie schließen: Der Dienst kann einen anderen Ursprung nutzen. Er muss fragen, welche Einheit und welches autonome System dann die Bereitstellung übernehmen.

Für Adressen, die unter AS60077 fallen, können der BGP-Ursprung und der RPKI-Status überwacht werden. Das Beispiel193.151.156.0/24zeigt, wie RIPEstat, RIPE RDAP und die ROAs gekreuzt werden können. Die gleiche Arbeit sollte für das genaue Präfix des Kunden durchgeführt werden. Ziel ist es, die Zuordnung und Änderungen zu überprüfen, nicht die vollständige Verfügbarkeit abzuleiten.

Die nächste Frage betrifft die Standorte. Welches Gebäude beherbergt den Hauptdienst? Wo befindet sich die Sicherungskopie? Teilen sich die beiden Standorte die Stromversorgung, Kühlung, einen Glasfasereingang oder einen Betreiber? PeeringDB liefert diese Antworten für AS60077 nicht. Sie müssen daher aus einer präzisen Dokumentation oder einem geeigneten unabhängigen Nachweis stammen.

Der Upstream muss mit der gleichen Granularität behandelt werden. AS43754 ist der sichtbare Nachbar, aber der Käufer muss wissen, ob für seinen Dienst ein anderer Pfad existiert, ob er aktiv ist, ob er über ausreichende Kapazität verfügt und ob er einem physisch getrennten Weg folgt. Eine Whois-Richtlinie oder eine zusätzliche AS-Nummer stellt keinen Umschaltbeweis dar.

Die Kapazität muss in den Einheiten des Produkts ausgedrückt werden. Für Rechnen kann dies garantierte Ressourcen, Überbuchungsgrenzen und Reserven umfassen. Für das Netzwerk umfasst dies Bandbreiten, Kontingenzpunkte und die bei einem Ausfall aufrechterhaltene Kapazität. Für Speicher umfasst dies Replikation, Integrität und Wiederherstellung. Die 14.080 IPv4-Adressen beantworten keine dieser Fragen.

Die Wiederherstellung muss durch Ziele und Ergebnisse verifiziert werden. Welche Frist gilt für einen gedeckten Vorfall? Welcher maximale Datenverlust ist vorgesehen? Wann wurde eine Umschaltung getestet? Welche Ausschlüsse der SLA gelten? Der Korpus zeigt die Ausschlüsse, aber nicht die Testergebnisse. Eine kommerzielle Antwort sollte auf den Vertrag und einen bestimmten Dienst bezogen sein.

IPv6 erfordert eine separate Kontrolle. Das punktuelle Signal von2a05:1a30::/34belegt kein aktuelles Angebot; die derzeitige Abwesenheit eines AS60077-Ursprungs belegt nicht die Abwesenheit jedes IPv6-Produkts. Ein Kunde muss Adressen anfordern und die Konnektivität auf der von ihm zu nutzenden Ressource testen.

Schließlich muss der Kunde einen Ausstiegspfad behalten. Die Fähigkeit, Daten zu exportieren, das DNS umzuziehen, Konfigurationen wiederherzustellen und Zugriffe zu entziehen, verringert die Abhängigkeit von einer perfekten Wiederherstellung des Anbieters. Die Quellen beschreiben die Cloud.ir-Mechanismen zu diesen Punkten nicht. Sie zeigen, warum diese Fragen vor einem Vorfall gestellt werden müssen.

Dieses Vorgehen verwandelt die öffentliche Unsicherheit in ein Sorgfaltsprogramm. Es nimmt nicht an, dass die Antworten negativ sein werden. Es unterscheidet lediglich die bereits beobachtbaren Elemente von denen, die eine direkte Bestätigung benötigen. Das öffentliche Netzwerk bietet Anhaltspunkte; der Vertrag, die Architektur und die Tests müssen die Kette vervollständigen.

Was die zwanzig Quellen nicht zu behaupten erlauben

Die Akte erlaubt es nicht, den genauen Weg bis zu einem Rechenzentrum zu behaupten. Kein Präfix ist mit einer Standortadresse, einem Raum, einem Rack oder einem Glasfasereingang verknüpft. Die Cloud.ir-Seiten sprechen von Asiatech-Rechenzentren im Iran, aber sie geben nicht die notwendige Kartierung, um jeden Dienst mit einem Ort zu verbinden.

Sie erlaubt es nicht, das Eigentum an den Einrichtungen oder Geräten zu behaupten. Eine Organisation kann Ressourcen betreiben, mieten, weiterverkaufen oder gemeinsam nutzen. Die Netzwerkregister entscheiden nicht über diese Modelle. Die kommerziellen Bedingungen reichen auch nicht aus, um das Eigentumsrecht zu begründen.

Sie erlaubt es nicht, eine unabhängige vorgelagerte Redundanz zu beweisen. AS43754 ist der einzige beobachtete Nachbar; AS212895 bleibt eine in BGP nicht gesehene Whois-Erklärung. Nicht-öffentliche Pfade können existieren, aber sie sind nicht nachgewiesen. Die physische und operative Unabhängigkeit ist noch weniger dokumentiert.

Sie erlaubt es nicht, die für Kunden verfügbare Kapazität zu berechnen. Die Anzahl der Adressen misst weder Prozessoren, noch Arbeitsspeicher, noch Speicher, noch Energie, noch verbleibende Bandbreite. Die Diensteseiten liefern im Korpus kein verifiziertes Inventar, das diese Lücke schließen würde.

Sie erlaubt es nicht zu behaupten, dass kein IPv6-Dienst existiert. Sie stellt lediglich das Fehlen eines derzeit in der Momentaufnahme sichtbaren Ursprungs AS60077 IPv6 und die Existenz eines punktuellen Signals am 13. Juli 2026 fest. Die anderen Architekturen sind nicht getestet.

Sie erlaubt es nicht, ISO27001, TIA-942 oder die Tier-2/3-ähnlichen Stufen als unabhängig für das gesamte Angebot zertifiziert darzustellen. Diese Verweise stammen von den Seiten des Betreibers, und ihr Umfang ist im Korpus nicht durch ein externes Dokument belegt.

Sie erlaubt es nicht, das Wiederherstellungsverhalten abzuleiten. Die SLA beschreibt Grenzen und Ausschlüsse, aber keine verifizierte Wiederherstellungssequenz. Es sind keine Übungsmessungen, keine detaillierten Verläufe und keine produktweisen Ziele enthalten.

Schließlich erlaubt sie es nicht, alle Cloud.ir-Dienste AS60077 zuzuordnen. Die Beziehung zwischen der Marke, Asre Dadeha Asiatech und dem Netzwerk ist auf mehreren Ebenen gestützt, aber die produktweise Matrix fehlt. Diese Grenze muss jede Nutzung des Fußabdrucks begleiten.

Diese Verbote zu schlussfolgern sind keine Liste von Verdächtigungen. Sie sind die normale Konsequenz einer Untersuchung auf der Grundlage begrenzter öffentlicher Quellen. Sie verhindern, dass ein fehlender Beweis zu einer Anschuldigung wird, ebenso wie sie verhindern, dass eine Aussage zu einer Gewissheit wird.

Die Signale, die die Unsicherheit verringern würden

Eine erste Verbesserung wäre eine öffentliche oder vertragliche Kartierung, die die Produkte mit den Präfixen und autonomen Systemen verbindet. Sie würde es erlauben zu wissen, welche Schlussfolgerungen zu AS60077 tatsächlich für den Cloud-Server, den VPS, den Speicher oder das CDN gelten. Sie würde auch unterschiedliche Abhängigkeiten zwischen Produkten sichtbar machen.

Eine zweite Verbesserung wäre eine präzise Offenlegung der Standorte und Zusammenschaltungen. Ein vollständigerer PeeringDB-Eintrag könnte Hinweise liefern, müsste aber bestätigt werden. Eine Bestätigung der Präsenz, eine Pfadarchitektur und eine Beschreibung der Fehlerdomänen würden einen stärkeren Beweis liefern als der bloße Name eines Rechenzentrums.

Eine dritte Verbesserung beträfe den Upstream. Die stabile Beobachtung eines zweiten unabhängigen Nachbarn, begleitet von einer Beschreibung der physischen Vielfalt und Umschalttests, würde die Bewertung ändern. Eine alleinige Whois-Richtlinie würde nicht ausreichen. Es müsste gezeigt werden, dass der Pfad aktiv, dimensioniert und tatsächlich nutzbar ist, wenn AS43754 nicht verfügbar ist.

Für IPv6 würde eine stabile Ankündigung von2a05:1a30::/34oder eines anderen Präfixes, sichtbar im aktuellen Status und mit Produkten verbunden, ein stärkeres Signal darstellen. Zugewiesene Adressen und Tests würden die Beobachtung ergänzen. Der einzelne Eintrag vom 13. Juli würde dann zu einer Episode in einer dokumentierten Entwicklung werden, anstatt ein isoliertes Signal zu sein.

Die Rechenzentrumsaussagen würden mit Zertifikaten, deren Umfang, Einheit, Standort und Gültigkeit klar identifiziert sind, an Wert gewinnen. Elemente zu Stromversorgung, Kühlung, Glasfasern und Notfallkapazitäten würden den Übergang von einem Etikett zu einer analysierbaren Architektur ermöglichen.

Schließlich würden Wiederherstellungsziele, Testergebnisse und Vorfallverläufe die Lücke zwischen der SLA und dem tatsächlichen Verhalten verringern. Eine Garantie ist informativer, wenn sie mit der Art und Weise verbunden ist, wie der Dienst zurückkehrt, der während der Beeinträchtigung verfügbaren Kapazität und der Datenqualität nach der Wiederherstellung.

Jedes dieser Signale muss in seiner Schicht bleiben. Eine neue Route belegt keine Standortzertifizierung. Ein Zertifikat belegt keine vorgelagerte Vielfalt. Ein Umschalttest beweist nicht die dauerhafte kommerzielle Kapazität. Die Stärke der Akte würde aus ihrer Kombination kommen, nicht aus der Umwandlung eines einzelnen Indikators in eine vollständige Antwort.

Ein überprüfbarer Fußabdruck, eine noch unvollständige Lieferkette

Der Fall von CLOUD Asre Dadeha Asiatech zeigt, warum Routing-Daten sowohl mächtig als auch unzureichend sind. Sie identifizieren AS60077, bestätigen seine IPv4-Aktivität, detaillieren 18 Ankündigungen, messen eine Sichtbarkeit bei 324 von 325 RIS IPv4-Peers und liefern ein gültiges RPKI-Beispiel. Sie verbinden den Ursprung auch mit RIPE RDAP-Objekten und Asiatech-Kontakten.

Diese Ergebnisse etablieren eine echte öffentliche Steuerungsoberfläche. Sie erlauben es, das Netzwerk zu verfolgen, eine Zuordnung zu überprüfen und eine beobachtete Route von einer bloßen Behauptung zu unterscheiden. Sie bilden eine solidere Grundlage als ein allein genommener kommerzieller Katalog.

Dieselben Daten heben die Grenzen der Ansicht hervor. Kein aktuelles IPv6-Präfix war als von AS60077 stammend sichtbar, trotz eines punktuellen Signals. AS43754 war der einzige beobachtete Nachbar. PeeringDB offenbarte weder Standort noch Austauschpunkt. Der physische Weg, die nutzbare Kapazität und die unabhängige Vielfalt konnten daher nicht rekonstruiert werden.

Cloud.ir fügt eine aktive Kundenoberfläche, einen Katalog mit mehr als zwanzig beanspruchten Produkten und kürzlich gepflegte Seiten hinzu. Seine SLA klärt mehrere Ausschlüsse. Aber der Korpus verbindet nicht jedes Produkt mit einer Route, einem Standort, einer Kapazität und einem Wiederherstellungsmechanismus. Er verifiziert nicht unabhängig die Rechenzentrumsverweise.

Die robusteste Schlussfolgerung ist somit asymmetrisch. Es gibt genügend Beweise, um zu sagen, dass das IPv4-Netzwerk von AS60077 aktiv und weitgehend sichtbar ist und dass Cloud.ir ein aktuelles kommerzielles Angebot präsentiert. Es gibt nicht genügend Beweise, um zu sagen, wie jeder Dienst die Einrichtungen durchläuft, welche unabhängige Redundanz ihn schützt, welche Kapazität mobilisierbar bleibt oder wie er sich nach einem Ausfall erholt.

Diese Asymmetrie ist weder ein Schwachverdict noch eine Genehmigung der Resilienz. Sie ist eine Wissensgrenze. Um sie zu überschreiten, muss ein Käufer seinen konkreten Dienst mit den Präfixen, Standorten, Pfaden, dem Vertrag und den Tests verbinden. Solange diese Kette nicht geliefert wird, macht AS60077 Cloud.ir im Internet sichtbar, ohne die gesamte Infrastruktur, die seine Dienste bereitstellt, transparent zu machen.

AS60077 macht Cloud.ir im Internet sichtbar, ohne den physischen Weg seiner Dienste zu offenbaren

Warum es wichtig ist