AS60077 показывает маршрутный контур, а не всю доставку Cloud.ir

Резюме

RIPE RDAP идентифицирует AS60077 как действующую автономную системуAT-CLOUD, зарегистрированную наORG-ADA42-RIPE/ Asre Dadeha Asiatech, тогда как RIPEstat зафиксировал 18 анонсируемых префиксов IPv4, 14 080 адресов IPv4 и видимость от 324 из 325 передающих данные IPv4-пиров RIS по состоянию на 20 июля 2026 года.
Тот же снимок маршрутизации не показал текущих видимых исходящих префиксов IPv6 и только одного наблюдаемого соседа — AS43754. Единичное появление2a05:1a30::/3413 июля является свидетельством зафиксированного во времени анонса, а не доказательством постоянной клиентской службы IPv6.
Cloud.ir поддерживает действующий клиентский каталог, охватывающий облачные серверы, VPS, облачный дата-центр, облачный коммутатор, управление доменами, CDN и хранилище. Его утверждения о дата-центрах Asiatech, ISO27001, TIA-942 и характеристиках Tier 2/3 в этом наборе источников остаются заявлениями оператора, а не независимо подтверждёнными сведениями об объектах.
AS60077 доказывает, что текущий контур управления IPv4 существует. Сама по себе она не устанавливает, какие службы Cloud.ir используют эту сеть, где физически выполняются нагрузки, существует ли независимый апстрим-путь, какая ёмкость доступна клиентам или как работает восстановление службы за пределами более узких гарантий и исключений в SLA Cloud.ir.

Самые чёткие доказательства находятся на границе сети

Облачную инфраструктуру часто описывают от продукта внутрь. Провайдер перечисляет виртуальные машины, хранилище, услуги дата-центра, функции связи и обещания поддержки, а затем предлагает читателю догадаться об операционной системе, лежащей в их основе. AS60077 позволяет начать анализ в противоположном направлении. Она даёт измеримую сетевую идентичность до того, как начинается язык продуктов.

RIPE RDAP указывает AS60077 как действующую под именемAT-CLOUD. Запись связывает её сORG-ADA42-RIPEи Asre Dadeha Asiatech. В ней указана дата регистрации номера автономной системы 27 июня 2022 года и дата последнего изменения 23 января 2026 года. Эти поля не являются полной корпоративной историей, но служат полезными опорными точками. Они подтверждают, что автономная система — не просто имя, оставшееся на старой веб-странице, и что её запись в реестре поддерживалась сравнительно недавно до сбора источников для этой статьи.

RIPEstat добавляет наблюдаемое состояние маршрутизации. На момент запроса 20 июля 2026 года в 08:00 UTC его обзор AS называл держателяAT-CLOUD Asre Dadeha Asiatechи помечал сеть как анонсируемую. Представление о состоянии маршрутизации затем дало более операционные цифры: 18 видимых префиксов IPv4, 14 080 адресов IPv4 и 324 из 325 передающих данные IPv4-пиров RIS, которые видят эту автономную систему. Оно зафиксировало193.151.156.0/24как последний наблюдавшийся префикс в 16:00 UTC того же дня.

Это убедительное доказательство действующей публичной поверхности маршрутизации. Но это данные на конкретный момент времени. Таблицы маршрутизации меняются, видимость коллекторов имеет пределы, а автономная система — это не то же самое, что весь облачный продукт. Поэтому правильный вывод узкий, но значимый: на момент сбора данных Asre Dadeha Asiatech имела действующий и широко наблюдаемый источник IPv4. Запись не доказывает, что каждый сервер Cloud.ir, том хранилища, узел CDN или клиентское подключение проходит через AS60077.

Это различие важно, потому что имена могут делать отдельные слои взаимозаменяемыми на вид.CLOUD Asre Dadeha Asiatech— это запись в справочнике. Asre Dadeha Asiatech — организация, указанная в сетевых записях.AT-CLOUD— зарегистрированное имя AS. Cloud.ir — клиентский идентификатор сервиса, встречающийся на официальных страницах. Источники связывают эти слои, но не дают пакетной карты от каждого рекламируемого продукта к AS60077. Считать AS видимой оправданно. Считать её полной схемой Cloud.ir — нет.

Восемнадцать префиксов IPv4 образуют существенный публичный сигнал

Перечень префиксов придаёт AS60077 больше содержания, чем один маршрут или неактивная регистрация. Данные RIPEstat об анонсируемых префиксах показали активные анонсы IPv4 в нескольких адресных блоках:78.110.112.0/21;85.198.8.0/22и85.198.12.0/22; меньшие85.198.16.0/23,85.198.19.0/24,85.198.20.0/23и85.198.22.0/23; последовательность блоков /22 от193.151.128.0/22до193.151.152.0/22; а также анонсы /24 от193.151.156.0/24до193.151.159.0/24.

Для исследователя инфраструктуры этот перечень отвечает на несколько базовых вопросов. Анонсируется более одного блока, и перечень содержит несколько адресных блоков, а не один изолированный /24. Сеть была видна почти через всех передающих данные IPv4-пиров в снимке состояния маршрутизации RIPEstat. Сторонняя сводка от bgp.tools независимо описала AS60077 как активную сеть, приписала ей 18 анонсируемых префиксов IPv4, назвала AS43754 её апстримом и присвоила метку хостинга серверов.

Ни одно из этих наблюдений не раскрывает, как адреса распределяются между клиентами. Префикс может обслуживать облачные серверы, системы управления, общие сервисы, внутренние платформы, открытые в интернет, или другие рабочие нагрузки. Пакет данных не назначает отдельным маршрутам ярлыки продукта, арендатора, региона или использования. Даже совокупный счётчик 14 080 адресов IPv4 — это наблюдение об адресном пространстве, а не утверждение, что 14 080 адресов доступны для продажи или сейчас используются клиентами.

Данные RIPEstat о согласованности маршрутизации дают ещё одну полезную границу. Префиксы IPv4, наблюдавшиеся в BGP для AS60077, также присутствовали в RIPE Whois. Такое совпадение снимает один вид неоднозначности: действующие публичные анонсы не были оторваны от соответствующих данных реестра в этом снимке. В то же время представление о согласованности содержало более широкие или составные диапазоны, которые присутствовали в Whois, но не в BGP. Поэтому зарегистрированное пространство и маршрутизируемое пространство не являются взаимозаменяемыми списками.

Объект реестра может описывать диапазон, не доказывая, что тот же диапазон сейчас анонсируется, а более широкая регистрация может содержать лишь некоторые компоненты, видимые как маршруты.

Та же осторожность относится к записям политики маршрутизации. AS43754 появилась и в данных BGP, и в свидетельствах импорта/экспорта Whois. AS212895 появилась в импортных данных Whois, но не в наблюдаемой картине BGP. Это различие не позволяет называть AS212895 текущим путём, резервным путём или независимым механизмом резервирования. Это лишь свидетельство того, что в данных реестра, использованных RIPEstat, существовала ссылка на политику. Без соответствующего наблюдаемого отношения маршрутов в этом пакете данных операционное значение остаётся нерешённым.

В результате получается чётко определённый результат по плоскости управления. AS60077 была не просто зарегистрирована; она анонсировала разнообразный набор префиксов IPv4, который был широко видим. Этот результат сильнее маркетингового заявления и слабее аудита ёмкости сервиса. Он сообщает клиентам и пирам, что публичная граница маршрутизации существует. Он не сообщает, что находится за каждым адресом, насколько загружена эта инфраструктура и какая физическая зависимость станет решающей при сбое.

Видимость через коллекторы — это не карта доставки

Цифра 324 из 325 IPv4-пиров RIS впечатляет, поскольку показывает достижимость через коллекторы, участвующие в этом снимке. Её не следует превращать в обещание процентной доступности. Видимость коллектора отвечает на вопрос, переносили ли отчитывающиеся пиры пути к источнику. Она не измеряет отклик приложения, потери пакетов у конкретного клиента, перегрузку на частном стыке, ёмкость внутри объекта или состояние виртуальной машины.

Именно здесь публичные сетевые исследования могут стать излишне самоуверенными. Широко распространённый маршрут — необходимое условие доступа к интернет-сервису по этим адресам, но распространение маршрута лишь одно звено доставки. Сервер всё равно может быть недоступен. Рабочая нагрузка клиента может быть изолирована конфигурацией. Зависимость от хранилища может отказать, пока маршрут остаётся идеально видимым. И наоборот, сервис может использовать сетевые пути, которые не появляются под автономной системой, ожидаемой исследователем.

Набор источников не прослеживает продукты Cloud.ir из конца в конец, поэтому не может закрыть ни одну из этих возможностей.

Временные метки тоже важны. RIPEstat сообщил обзор AS в одно время запроса и указал последний наблюдавшийся префикс в другое время 20 июля. Эти наблюдения поддерживают актуальный снимок, но не непрерывную историю всех 18 префиксов и не гарантию на следующий день. Дата последнего изменения в RIPE RDAP показывает обслуживание записи в реестре, а не непрерывную маршрутизацию. Даты изменения карты сервисов в 2025 и 2026 годах показывают, что официальные страницы продуктов поддерживались, а не то, что каждая базовая система прошла проверку доступности в эти даты.

Дисциплинированное прочтение удерживает каждую временную метку при том утверждении, которое она поддерживает. 20 июля AS60077 выглядела анонсируемой и широко видимой по IPv4. В захваченной официальной веб-поверхности Cloud.ir представил актуальный каталог сервисов. Статья может объединить эти факты в картину активной публичной работы, но не может заполнить разрыв между коллектором маршрутов и рабочей нагрузкой клиента предположениями о физическом размещении или производительности.

Этот разрыв — не техническая деталь. Это центральная проблема должной проверки в данном случае. Открытые данные необычно конкретны на границе и скудны за ней. Чем точнее можно измерить границу, тем сильнее соблазн считать остальную платформу столь же задокументированной. Это не так.

IPv6 присутствует как след, а не как актуальная заявка о сервисе

Данные IPv6 показывают, почему набору источников нужны и история маршрутов, и текущее состояние маршрутизации. Данные RIPEstat об анонсируемых префиксах содержали2a05:1a30::/34, но только на одну отметку времени 13 июля 2026 года. В использованном снимке состояния маршрутизации AS60077 имела ноль видимых исходящих префиксов IPv6, и её не видел ни один из 321 передающего данные IPv6-пира RIS. bgp.tools аналогично свёл сеть к нулю исходящих префиксов IPv6.

Безопасный вывод не в том, что у Cloud.ir нет сервиса IPv6. Публичные коллекторы маршрутов не могут исключить любую клиентскую схему, другой исходный ASN, непубличное использование, сервис, предоставляемый через партнёра, или более позднее изменение маршрутизации. Но ни одна из этих альтернатив также не доказана этим набором данных. Данные поддерживают лишь более узкое утверждение: сбор источников не показал, что AS60077 сейчас анонсирует пространство IPv6, а единственное указанное появление2a05:1a30::/34было слишком кратким, чтобы установить постоянный публичный источник.

Это различие имеет практическую ценность. Покупатель, ищущий нативный IPv6, не должен считать историческую отметку времени подтверждением. Ему нужен текущий ответ по конкретному продукту: какие сервисы Cloud.ir предоставляют IPv6, какая автономная система анонсирует соответствующий маршрут, назначаются ли адреса клиентам и какие условия поддержки и доступности применяются. Набор данных не даёт таких ответов.

Отсутствие текущего видимого источника также не следует превращать в утверждение об инженерных возможностях. Оно ничего окончательно не говорит о планах, внутреннем развёртывании, готовности оборудования или клиентском спросе. Это наблюдение о публичной плоскости управления в момент сбора данных. Разница между «не виден в этом снимке маршрутизации» и «не существует» мала по формулировке, но велика по доказательной силе.

Доказательства AS60077 по IPv4 поэтому актуальны и обширны. Данные по IPv6 историчны и кратковременны. Раздельное хранение этих двух состояний предотвращает знакомую ошибку отчётности, при которой любое появление префикса становится постоянной характеристикой провайдера. Для этой статьи2a05:1a30::/34— маркер ограничения: он показывает, что данные были достаточно чувствительными, чтобы зафиксировать краткое событие, и одновременно показывает, почему это событие не может нести более широкую заявку о сервисе.

Валидный источник маршрута — не сертификат отказоустойчивости

Один из префиксов AS60077 имеет дополнительный уровень проверки. Проверка RPKI для193.151.156.0/24вернулаvalid, при этом ROA-записи разрешали источник 60077 для этого префикса. RIPE RDAP сопоставил адрес с действующим выделенным диапазоном PA под именемIR-AT-20210316, с кодом страны IR, охватывающим диапазон от193.151.128.0до193.151.158.255. Регистрация указывалаASIATECH-MNTи Asiatech NOC в административных и технических контактных данных.

Вместе эти источники создают непротиворечивую цепочку для выборки. Диапазон существует в реестре. Идентификаторы обслуживания и контактов указывают обратно в операционный контекст Asiatech. Наблюдалось, что AS60077 анонсирует /24. Результат RPKI показал, что источник был разрешён проверяющими ROA-записями на момент запроса. Это именно тот вид многоуровневых доказательств, который делает заявление о маршрутизации более достоверным.

Он всё же отвечает только на вопрос маршрутизации. Валидность RPKI не подтверждает дата-центр, не проверяет облачную плоскость управления, не измеряет доступную пропускную способность, не подтверждает резервирование апстрима и не гарантирует, что клиент сможет восстановить данные после инцидента. Она не показывает, исправен ли сервер, отвечающий по адресу. Она не устанавливает, что все 18 префиксов IPv4 имеют одинаковое состояние проверки, поскольку набор данных фиксирует конкретный результат проверки для193.151.156.0/24.

Ценность результата в его точности. Лучше сказать, что эта проверенная выборка с актуальным анонсом имела валидный источник, чем обобщать о безопасности всего сервиса. Лучше также признать, что авторизация маршрута и подтверждение качества услуги решают разные задачи. Первая помогает сетям отклонять источник, не соответствующий опубликованной авторизации. Вторая требует доказательств о системах, объектах, персонале, процедурах, договорном объёме и восстановлении.

Диапазон RDAP заслуживает такой же осторожности. Действующая выделенная регистрация PA поддерживает связь с адресным пространством. Поле страны и идентификаторы контактов дают контекст реестра. Они не указывают конкретный серверный зал, не доказывают, где находится рабочая нагрузка клиента, и не устанавливают, что весь зарегистрированный диапазон сейчас маршрутизируется AS60077. Действительно, верхняя граница, описанная RDAP, и смесь наблюдаемых анонсов /22 и /24 показывают, почему регистрацию адресов нужно читать вместе с данными BGP, а не заменять ими.

Эта выборка поэтому — одна из самых сильных частей открытых данных и одна из самых ясных демонстраций их предела. Маршрут можно связать с авторизованным источником и поименованными контактами реестра. Физическая и операционная цепочка за маршрутом остаётся незадокументированной теми же источниками.

Наблюдаемая топология сводится к AS43754

Представление соседей RIPEstat вернуло одного наблюдаемого соседа для AS60077: AS43754. Данные о согласованности маршрутизации также показали AS43754 в отношении BGP и в соответствующих материалах импорта/экспорта Whois. RIPEstat и RIPE RDAP определяют AS43754 как действующую и принадлежащую компании Asiatech Data Transmission. bgp.tools представляет тот же ASN как апстрим AS60077.

Такая сходимость делает AS43754 существенной частью видимой картины зависимостей. Это не просто строка политики из старой записи. Она появилась в наблюдаемом отношении маршрутизации, была активна в реестре и обзорных источниках и была независимо указана как апстрим. Публичная картина, доступная этому набору источников, поэтому ведёт от AS60077 к единственному наблюдаемому сетевому соседу в более широком контексте Asiatech.

Чего она не показывает, так это независимого резервирования апстримов. Поскольку AS43754 идентифицируется как компания Asiatech Data Transmission, её появление нельзя считать доказательством того, что у AS60077 есть отдельно управляемый внешний путь. Набор источников не нашёл второго наблюдаемого BGP-соседа, который мог бы поддержать такое утверждение. Присутствие AS212895 в импортных данных Whois не меняет этот вывод, поскольку она не появилась в наблюдаемой картине BGP в этом наборе данных.

Формулировки должны оставаться точными. «Один наблюдаемый сосед» не означает «в реальности существует только одно подключение». Публичные наборы данных маршрутизации могут не видеть частные схемы, резервные конфигурации, неактивные в момент сбора, внутренние пути или отношения, не раскрытые в выбранном представлении. Набор данных не проверял конфигурации маршрутизаторов и не получал схему сети. Он может сказать, что независимый мультиапстрим-путь не был подтверждён, а не что никакой другой путь технически невозможен.

Это различие особенно важно, когда речь идёт об облачном сервисе. Провайдер может строить резервирование на многих уровнях, и не всё оно выглядит как отдельный публичный сосед. Несколько физических каналов могут заканчиваться в одном апстрим-ASN. Разные объекты могут использовать одну и ту же апстрим-организацию. Внутренняя инженерия трафика может менять пути без изменения числа соседей, видимых коллекторам. Ни одна из этих конфигураций здесь не продемонстрирована. Они остаются возможностями, а не выводами.

С точки зрения клиента текущая публичная картина ставит целенаправленный вопрос, а не выносит вердикт. Если у AS43754 возникнет операционная проблема, какой альтернативный маршрут, если он есть, понесёт адресное пространство, анонсируемое AS60077? Является ли эта альтернатива независимо управляемой, физически отдельной и регулярно проверяемой? Охватывает ли она все клиентские префиксы или лишь часть? Источники не отвечают.

Вопрос важен, потому что связь ASN может выявлять организационную концентрацию, даже если не раскрывает все физические каналы. AS60077 видна как отдельный источник, но единственный наблюдаемый апстрим — это другая сеть Asiatech. Это может быть продуманной архитектурой и может работать надёжно. Данные просто не устанавливают независимый домен отказа. Карту маршрутов, которая останавливается на AS43754, не следует представлять как завершённую карту отказоустойчивости.

PeeringDB фиксирует сеть, но оставляет физическую карту пустой

PeeringDB имеет актуальную сетевую запись для ASN 60077 с именем Asre Dadeha Asiatech. Поля сетевого и RIR-статуса записи равныok. Это поддерживает базовую цепочку идентичности и показывает, что ASN имеет признанную запись в широко используемом справочнике взаимоподключений.

Остальная часть публичного профиля примечательна тем, чего она не раскрывает. На момент сбора он сообщалix_count=0иfac_count=0. В нём не указаны веб-сайт, looking glass, сервер маршрутов, URL политики, уровень трафика или географический охват. Эти поля не устанавливают, что у сети нет объектов, подключений к точкам обмена, трафика и политики маршрутизации. Нулевое или пустое поле в PeeringDB — это свидетельство о раскрытии информации в этой записи, а не окончательное доказательство состояния базовой инфраструктуры.

Эта оговорка не делает нули бессмысленными. PeeringDB — одно из мест, где сетевые операторы могут сделать отношения к объектам и взаимоподключениям публично читаемыми. В данном случае запись нельзя использовать для подтверждения конкретного города, подключения к точке обмена интернет-трафиком, присутствия на объекте, публичной пиринговой инфраструктуры или раскрытого масштаба трафика AS60077. Пустая физическая карта, таким образом, выдерживает проверку по источникам.

Результат резко контрастирует с картиной BGP. RIPEstat может посчитать префиксы и наблюдающих пиров. RPKI может проверить выбранный источник. RDAP может назвать организацию и контакты по адресам. PeeringDB, однако, не добавляет привязки к объекту, которая связала бы эти маршруты с названным зданием или площадкой. Открытые данные становятся менее детальными именно там, где анализ переходит от логической достижимости к физической доставке.

Это отсутствие также не позволяет легко заявлять о резервировании. Две записи об объектах в разных местах сами по себе не доказывали бы независимость электропитания, транспорта, персонала или переключения при отказе, но они по крайней мере создали бы публичные объекты, которые можно проверить. Здесь таких записей об объектах AS60077 в захваченной записи нет. Набор источников не может сравнивать площадки, подтверждать разделение городов или проверять, используют ли несколько точек обслуживания одну и ту же базовую зависимость.

Ответственная интерпретация состоит из двух частей. Во-первых, Asre Dadeha Asiatech поддерживает активную сетевую идентичность с записью в PeeringDB, находящейся в хорошем состоянии. Во-вторых, эта запись не даёт публичных доказательств объектов или точек обмена для AS60077. Превращать второе утверждение в обвинение в отсутствии объектов было бы несправедливо и неточно. Столь же неточно позволять страницам продуктов Cloud.ir заполнять пробел так, будто коммерческое описание является реестром объектов.

Публичная проверяемость сама по себе является эксплуатационным свойством для покупателей, пиров и исследователей. Она влияет на то, насколько быстро внешняя сторона может понять концентрацию и выйти на нужные технические контакты. AS60077 легко найти как источник маршрутов, но трудно сопоставить с физическим сервисом. Эта асимметрия — один из центральных выводов статьи.

Cloud.ir демонстрирует актуальную и широкую поверхность сервисов

Официальная сервисная сторона не бездействует. Cloud.ir был доступен по HTTPS во время сбора источников. Его главная страница и карта сервисов содержали активные страницы облачных серверов, VPS, облачного дата-центра, облачного коммутатора, управления облачными доменами, CDN и облачного хранилища. Карта показывала даты изменения ключевых сервисных страниц в 2025 и 2026 годах, что поддерживает представление о поддерживаемом клиентском каталоге, а не о заброшенном архиве.

Согласно собственному описанию Cloud.ir, облачный сервис начал работу в 1399 году по иранскому календарю, предлагает более 20 облачных продуктов и работает на базе дата-центров Asiatech в Иране. Эти утверждения помогают определить, как оператор хочет, чтобы клиенты понимали платформу. Страница контактов также предоставляет актуальный контур продаж и поддержки. Вместе официальные страницы подтверждают вывод об активной коммерческой презентации.

Они не устанавливают самостоятельно масштаб клиентской базы. Страница продукта не подсчитывает активных арендаторов, не раскрывает проданные или резервные ресурсы, не определяет адреса, используемые каждой службой, и не доказывает, что рекламируемая функция доступна в каждом развёртывании. Набор данных не содержит списка клиентов, данных об использовании, трассировки маршрутов по каждой услуге или проверенного аудитом реестра ресурсов. Поэтому использование широты меню как показателя широты физической ёмкости было бы ошибкой.

Связь с AS60077 следует описывать с той же сдержанностью. Сетевые записи называют Asre Dadeha Asiatech, а официальные сервисные страницы размещают Cloud.ir на дата-центрах Asiatech. Этого достаточно, чтобы анализировать связную публичную операционную поверхность. Недостаточно, чтобы утверждать, что все сервисы Cloud.ir доставляются из AS60077. CDN, служба хранения, облачный коммутатор, плоскость управления или клиентская виртуальная машина могут иметь путь доставки, отличный от публичного источника, который видит исследователь. Набор данных не разрешает эти пути на уровне продуктов.

Это не причина отбрасывать страницы продуктов. Они устанавливают, что клиентам предлагают купить и какие операционные обещания заслуживают изучения. Облачные серверы и VPS предполагают зависимости от вычислений и сети. Облачное хранилище поднимает вопросы сохранности и восстановления. Сервисы CDN поднимают вопросы размещения на границе и достижимости источника. Предложение облачного дата-центра вызывает самые прямые вопросы об объекте, электропитании, охлаждении и межплощадочной архитектуре. Официальный каталог поэтому — полезная карта заявок и зависимостей, даже если он не доказывает реализацию за ними.

Широта этого каталога также делает узость публичной сетевой карты более значимой. Если бы Cloud.ir рекламировал лишь один экспериментальный сервис, неполная запись топологии могла бы описывать небольшую границу. При заявленных более чем 20 продуктах из нескольких сервисных семейств клиентам нужно знать, какие доказательства относятся к какому продукту. Набор источников может подтвердить работающий веб-сайт, поддерживаемые сервисные страницы, активный ASN IPv4 и набор действующих маршрутов. Он не может соединить каждую плитку продукта с конкретным префиксом, объектом или процедурой восстановления.

Различие между поверхностью сервисов и цепочкой доставки должно оставаться видимым на протяжении всей статьи. Страницы Cloud.ir — первичное доказательство того, что, по словам оператора, он предлагает. RIPE, RIPEstat, RPKI, PeeringDB и bgp.tools — публичные доказательства частей сетевой идентичности. Ни один класс источников, ни вместе, ни по отдельности, не завершает физическую карту.

Заявления о дата-центрах и стандартах остаются самоописанием

Официальные страницы Cloud.ir используют формулировки об отказоустойчивости дата-центров и стандартах. Они описывают работу на базе дата-центров Asiatech в Иране и содержат утверждения, связанные с ISO27001, TIA-942 и характеристиками Tier 2/3. Эти заявления могут быть значимы для проектной и комплаенс-работы оператора, но рассматриваемый набор источников не подтвердил их независимо.

Ограничение конкретно. Набор источников не содержал независимого сертификата объекта, привязанного к названной площадке и актуальной области действия. Он не установил точный список объектов, не определил, какие продукты Cloud.ir работают на какой площадке, и не показал, распространяется ли один и тот же сертификат на все локации. Он не задокументировал линии электропитания, топологию охлаждения, время работы генераторов, организацию топливного обеспечения, физические вводы сети или доступный клиентам объём вычислений и хранения.

Это не показывает, что утверждения ложны. Это показывает, что их доказательный статус отличается от фактов маршрутизации AS60077. Коллектор маршрутов может независимо наблюдать источник. RDAP может независимо вернуть объект реестра. Описания дата-центров в этом наборе данных исходят из собственных страниц оператора. Поэтому их следует атрибутировать как заявления Cloud.ir, а не переписывать как независимо сертифицированные условия.

Названия стандартов могут создавать особенно сильное впечатление, поскольку они сжимают сложный вопрос подтверждения качества в знакомый ярлык. Однако определяющее значение имеет область действия. Сертификация системы управления, ссылка на проект объекта и описание доступности уровня Tier отвечают на разные вопросы. Набор источников не предоставляет документы, необходимые для определения точной формулировки, выдавшего органа, охваченного юридического лица, охваченного здания, срока действия или исключений. Повторение ярлыков без такой области действия сделало бы статью более уверенной, чем позволяют доказательства.

Та же проблема относится к фразе «дата-центры Asiatech». Она указывает на организационную зависимость и страну, но не на путь к объекту. Она не говорит, использует ли конкретная рабочая нагрузка Cloud.ir одну или несколько площадок, используют ли эти площадки общий апстрим, как реплицируются данные и может ли клиент выбирать домен отказа. Маршруты AS60077 не могут восполнить эти недостающие детали. Нулевое число объектов в PeeringDB не даёт независимой привязки к площадке, которая закрыла бы пробел.

Для покупателей инфраструктуры полезными следующими доказательствами были бы конкретные и привязанные к продукту сведения: поименованный список объектов; связь между каждой площадкой и продаваемыми услугами; сертификационные документы с областью действия и датами; описание независимых путей электропитания и сети; обязательства по ёмкости; проверенные процедуры восстановления. Рассматриваемый набор данных не содержит ни одного из этих элементов. Поэтому уместно назвать путь доставки публично недоказанным, а не заявлять об отсутствии базовой инфраструктуры.

Это различие защищает обе стороны анализа. Оно не позволяет самоописанию оператора стать незаслуженным результатом аудита и не позволяет отсутствующим публичным доказательствам стать незаслуженным обвинением. Статья может сказать ровно то, что было видно: Cloud.ir сделал заявления, граница маршрутизации была активна, а независимые источники в наборе данных не подтвердили физические детали за ними.

SLA очерчивает более узкий эксплуатационный периметр

Среди официальных страниц Cloud.ir SLA — самый полезный источник для понимания того, где заканчивается обещание сервиса. Он ограничивает гарантии доступности доступностью сети и облачного сервера в обычных условиях эксплуатации. Затем он исключает широкий круг обстоятельств, включая программное обеспечение клиента, операционные системы, конфигурацию, атаки типа «отказ в обслуживании», приостановку обслуживания, техническое обслуживание, критические исправления, обстоятельства непреодолимой силы, отказы оборудования клиента, простой по запросу клиента, неоплату, а также правовые предписания или распоряжения органов безопасности.

Эти исключения важны, потому что клиент воспринимает приложение как единую систему, тогда как договор разделяет её на уровни. Маршрут может оставаться видимым, пока операционная система отказывает. Облачный сервер может работать, пока конфигурация клиента препятствует доступу. Инфраструктура может быть доступна, пока атака типа «отказ в обслуживании» влияет на использование. Техническое обслуживание или критическое исправление могут прервать службу, не рассматриваясь так же, как обычный сетевой сбой. SLA определяет, какие части этого опыта входят в гарантию, а какие нет.

Страницу не следует читать как доказательство того, что какое-либо исключённое событие произошло. Само существование исключений также не свидетельствует о низком качестве сервиса. Это договорное доказательство об атрибуции. Оно сообщает читателю, что широкое заявление о доступности облака нельзя толковать как гарантию, покрывающую любую причину простоя.

Эта граница особенно важна при сравнении с каталогом продуктов. Cloud.ir представляет облачные серверы, VPS, хранилище, CDN, управление доменами, коммутацию сети и услуги облачного дата-центра. Захваченный текст SLA сосредоточивает гарантию доступности на доступности сети и облачного сервера в обычных условиях эксплуатации. Набор источников не показывает единого столь же детального обещания восстановления, охватывающего каждое семейство продуктов.

Поэтому покупателю не следует предполагать, что заголовочная концепция доступности одинаково применима к восстановлению хранилища, поведению CDN, конфигурации клиента или зависимостям услуг дата-центра.

Исключения также объясняют, почему AS60077 не может ответить на вопрос об отказоустойчивости. Данные BGP могут показать, видимы ли префиксы. Они не могут определить, подпадает ли перерыв под техническое обслуживание, критическое исправление, распоряжение органов безопасности, программное обеспечение клиента или обстоятельства непреодолимой силы. Они не могут показать, имеет ли клиент право на средство правовой защиты. Они не могут измерить, насколько быстро перестраивается отказавший сервис и возвращаются ли сохранённые данные на ту же точку во времени.

Важнее всего то, что SLA не предоставляет недостающий путь к объекту. Тот факт, что доступность сети покрывается в обычных условиях эксплуатации, не раскрывает, какое здание, канал или апстрим обслуживает сервис. Он не устанавливает, что вторая площадка может принять нагрузку. Он не раскрывает объём резервной ёмкости, зарезервированной для переключения при отказе. Он не говорит, обходится ли AS43754 при инциденте с апстримом. Это отдельные эксплуатационные факты.

Обращение к техническому обслуживанию и критическим исправлениям заслуживает пристального внимания. Это операционно необходимые действия, но их исключение означает, что наблюдаемый результат для клиента может выпадать из обычного расчёта доступности, описанного на странице. Набор данных не предоставляет данных о частоте обслуживания, качестве уведомлений или исторической продолжительности, поэтому вывод о фактических перерывах невозможен. Можно сказать лишь, что техническое обслуживание относится к границе договора, а не к безусловному обещанию доступности.

То же верно для атак типа «отказ в обслуживании» и правовых предписаний или распоряжений органов безопасности. Они могут влиять на достижимость или непрерывность службы по причинам, которые снимок источника маршрута не объяснит. Статья не должна спекулировать о вероятности таких событий. Их значение в том, что оператор прямо относит их к исключениям. Полная оценка риска нуждается и в SLA, и в таблице маршрутов, поскольку эти два документа отвечают на разные вопросы.

Исключения на стороне клиента создают ещё один слой неоднозначности. Программное обеспечение, операционные системы, конфигурация и оборудование клиента могут вызывать простой, который с места пользователя выглядит как облачный сбой. Договор Cloud.ir отличает эти причины от покрываемой доступности инфраструктуры. Это делает мониторинг и эскалацию поддержки важными, но набор данных не содержит примеров инцидентов, истории времени реакции или данных о разрешении обращений, по которым их можно было бы оценить.

Таким образом, SLA даёт больше, чем юридическую сноску. Он определяет максимальное безопасное заявление о публичном обещании сервиса. Cloud.ir предлагает рамку доступности для сети и облачного сервера в обычных условиях при указанных исключениях. Набор данных не доказывает сквозную доступность приложений, доступность при любых причинах, переключение между объектами, восстановление данных или единую гарантию по всему каталогу.

Четыре уровня доказательств должны оставаться раздельными

Набор источников легче интерпретировать, если разделить его на четыре уровня.

Первый — идентичность. RIPE RDAP связывает AS60077,AT-CLOUD,ORG-ADA42-RIPEи Asre Dadeha Asiatech. Запись RDAP по адресу связываетIR-AT-20210316,ASIATECH-MNTи Asiatech NOC с диапазоном, охватывающим проверенный префикс. Это долговечные записи реестра с датами и полями статуса.

Второй — текущее наблюдение за сетью. RIPEstat зафиксировал AS60077 как анонсируемую, насчитал 18 префиксов IPv4 и 14 080 адресов IPv4, зафиксировал широкую видимость через RIS по IPv4, обнаружил одного наблюдаемого соседа и не показал текущего видимого источника IPv6. bgp.tools представил согласованную публичную сводку. Проверка RPKI подтвердила источник 60077 для193.151.156.0/24. Эти результаты устанавливают измеримую публичную плоскость управления на момент сбора данных.

Третий — коммерческая поверхность сервисов. Официальные страницы Cloud.ir представляют более 20 продуктов и содержат актуальные страницы вычислительных сервисов, VPS, дата-центра, коммутации, доменов, CDN и хранилища. Они утверждают, что сервис работает на дата-центрах Asiatech в Иране, и описывают стандарты и характеристики уровней. SLA определяет договорную границу доступности и исключения. Это первичные источники собственных предложений и заявок оператора.

Четвёртый — физическое и восстановительное подтверждение. Этот уровень связал бы продукты и префиксы с названными объектами, независимыми сетевыми путями, доступными уровнями ресурсов, схемой репликации, процедурами восстановления и проверенным резервированием. Он также привязал бы заявления о стандартах к конкретным площадкам и актуальной области действия сертификатов. Таких доказательств в этом наборе источников нет.

Путаница возникает, когда факт одного уровня используется для заполнения другого. Действующая регистрация AS не может доказать текущий маршрут, поэтому важно наблюдение RIPEstat. Текущий маршрут не может доказать существование объекта, поэтому важны PeeringDB и независимые данные о площадках. Страница продукта не может доказать резервную ёмкость. SLA не может доказать, что переключение при отказе сработает. Валидный источник RPKI не может доказать, что приложение клиента доступно.

Уровни действительно взаимодействуют. Записи идентичности делают наблюдаемый маршрут атрибутируемым. Записи маршрутов делают видимой часть сети оператора сервиса. Официальные страницы объясняют, почему эта сеть важна для клиентов. SLA раскрывает условия, при которых опыт клиента и договорная гарантия могут расходиться. Объединённая картина сильнее любого отдельного источника, но всё же имеет определённую границу.

Эта граница — точка, в которой статья должна перестать делать фактические утверждения и начать формулировать вопросы. Публичные доказательства поддерживают действующую сеть и действующую витрину. Они не поддерживают завершённое утверждение о физическом разнообразии, независимых апстримах, ёмкости или восстановлении. Сохранение этой линии более информативно, чем повторение маркетингового языка или трактовка каждого отсутствующего поля как доказательства сбоя.

Нерешённые вопросы относятся к конкретным продуктам

Серьёзный клиент, оценивающий Cloud.ir, получит больше от короткого набора точных запросов, чем от общего требования «большей прозрачности». Первый запрос должен сопоставить сетевые доказательства с купленной услугой. Какие продукты Cloud.ir используют адреса, анонсируемые AS60077? Находятся ли конечные точки управления, рабочие нагрузки клиентов, службы хранения и узлы CDN на одном источнике? Используют ли некоторые продукты AS43754 или другую автономную систему напрямую? Набор данных не даёт такого сопоставления.

Второй запрос должен касаться физического пути. Какие названные объекты размещают каждую службу и может ли клиент выбрать или проверить локацию? Являются ли две заявленные площадки независимыми по электропитанию, охлаждению, доступу в здание и сетевому вводу или они разделяют существенную зависимость? PeeringDB не может ответить, потому что запись AS60077 не имеет привязок к объектам, а официальные страницы в этом наборе источников не дают независимо подтверждённого реестра объектов.

Третий запрос должен прояснить архитектуру апстримов. AS43754 был единственным наблюдаемым соседом. Если AS60077 потеряет достижимость через эту сеть, какой альтернативный путь должен понести её префиксы? Активна ли альтернатива в BGP, зарезервирована ли на случай отказа или предоставляется внутри той же организации? Как часто она проверяется и какие префиксы покрыты? Ссылка на импорт AS212895 в Whois недостаточна для ответа на эти вопросы, поскольку она не наблюдалась как отношение BGP в наборе данных.

Четвёртый запрос касается IPv6. Единственная отметка времени2a05:1a30::/34должна побуждать к актуальному продуктовому ответу, а не к выводу «да или нет» из публичных данных. Доступен ли IPv6 клиентам сейчас? Если да, какой продукт, какой префикс, какой исходный ASN и какой SLA применяются? Если нет, набор данных не даёт оснований прогнозировать, когда это может измениться.

Пятый запрос должен отделять выделенные ресурсы от доступной ёмкости. Восемнадцать префиксов IPv4 и 14 080 адресов демонстрируют маршрутизируемое адресное пространство, а не доступные вычисления, хранилище, пропускную способность или резерв для восстановления. Клиентам нужны обязательства, соответствующие покупаемому ресурсу: зарезервированная или эластичная ёмкость, пределы при переключении, поведение репликации хранилища и условия, при которых ресурсы могут быть недоступны. Ничто из этого нельзя вывести из числа префиксов.

Шестой запрос должен ввести заявления о стандартах в область действия. Какое юридическое лицо и какой объект покрыты ISO27001? Какая именно оценка TIA-942 или проектное утверждение делается? Что означает Tier 2/3 для конкретного сервиса и площадки? Каковы даты документов, выдавшее учреждение и исключения? Вопросы не предполагают, что заявления недействительны. Они запрашивают доказательства, необходимые для перевода их из описания оператора в независимо проверяемое подтверждение.

Седьмой запрос должен проследить SLA в операциях. Как уведомляют о техническом обслуживании и критических исправлениях? Какая телеметрия отличает сбой сети провайдера от конфигурации клиента? Какая последовательность восстановления применяется, когда уровни вычислений, хранения и сети отказывают вместе? Каков путь эскалации, когда событие попадает в спорное исключение? Набор данных подтверждает, что контуры контактов поддержки и продаж существуют, но не даёт исторических данных о времени реакции или восстановлении.

Наконец, покупателям следует спрашивать, какие заявления являются договорными. Страница сервиса может описывать высокую доступность, сохранность или непрерывную связь, тогда как SLA определяет более узкие покрываемые условия. Набор источников не показывает, как каждое заявление о продукте включено в соглашение с клиентом. Точное расписание услуг с соответствующими исключениями и средствами правовой защиты значило бы больше, чем обобщённое облачное обещание.

Эти запросы следуют непосредственно из пробелов в доказательствах. Они не предполагают, что Cloud.ir не имеет объектов, ёмкости, альтернативных каналов, процедур восстановления или сертификатов. Они определяют, что внешний читатель не может проверить по набору из 20 источников, использованному здесь. Такова правильная роль анализа инфраструктуры по открытым источникам: превращать неопределённость в конкретную должную проверку, а не в безосновательную уверенность.

Видимый источник маршрута — лишь начало подтверждения

AS60077 даёт Asre Dadeha Asiatech ясную и актуальную публичную границу. RIPE RDAP идентифицирует автономную систему и организацию. RIPEstat показывает 18 префиксов IPv4, широкую видимость через коллекторы и анонсируемое состояние. Проверенный префикс имеет валидный источник RPKI и непротиворечивую регистрацию адреса. bgp.tools приходит к согласованной сводке. Cloud.ir, в свою очередь, представляет активный и широкий каталог сервисов.

Этих выводов достаточно, чтобы отвергнуть два упрощённых прочтения. Это не просто облачное имя без наблюдаемой сетевой работы. Но это и не полностью задокументированная цепочка доставки лишь потому, что маршруты видимы. Доказательства сильнее всего там, где начинается плоскость управления интернетом, и слабее всего там, где клиентский риск становится физическим и процедурным.

Единственный наблюдаемый сосед, AS43754, — настоящий сигнал зависимости, но не доказательство полной топологии и не свидетельство независимо управляемого резерва. Пустые поля объектов и точек обмена в PeeringDB ограничивают публичное подтверждение, не доказывая отсутствие. Официальные описания дата-центров и стандартов остаются в этом наборе данных самоприписанными. SLA устанавливает реальную рамку доступности, одновременно вырезая условия, которые не позволяют ей стать гарантией от всех причин.

Итоговый вывод взвешен. Публичные доказательства поддерживают действующую поверхность маршрутизации IPv4, связанную с Asre Dadeha Asiatech, и актуальную клиентскую поверхность сервисов Cloud.ir. Они не доказывают точные объекты за сервисами, путь каждого продукта, независимое разнообразие апстримов, доступную клиентам ёмкость, текущее происхождение IPv6 или границу восстановления после многоуровневого сбоя.

Это не обвинение. Это граница доказательств. AS60077 делает оператора более удобным для наблюдения, и такая видимость ценна. Она также делает ясным, сколько остаётся за пределами таблицы маршрутов. Для клиентов, решающих, способен ли облачный сервис пережить отказ, следующие решающие документы — не дополнительные подсчёты префиксов. Это сопоставления продуктов с сетью, доказательства по конкретным объектам, детали независимых путей, записи об области действия подтверждений и обязательства по восстановлению, которые переживают исключения в SLA.

AS60077 раскрывает границу маршрутизации, а не полную цепочку доставки Cloud.ir

Почему это важно