CLOUDNET INTERNET SERVICE PVT LTD — заметный интернет-провайдер Тамилнада, а не задокументированный облачный хостинг

Резюме

• Департамент телекоммуникаций Индии (Department of Telecommunications) включил Cloudnet Internet Service Private Limited в перечень держателей разрешения категории B на предоставление интернет-услуг в Тамилнаде, действующего с 10 апреля 2023 года. Страницы с корпоративными данными связывают те же адрес и контактные данные с компанией из Ченнаи, зарегистрированной в 2021 году. Это подтверждает статус лицензированного интернет-провайдера, а не портфель продуктов облачных вычислений.
• AS150069 был активен 10 июля 2026 года, анонсируя103.21.6.0/23, оба составляющих маршрута/24и2001:df1:66c0::/48. Агрегат IPv4 был виден с октября 2022 года, маршрут IPv6 — с ноября 2022 года. Текущая авторизация маршрутов действительна по RPKI, а записи реестра недавно поддерживались в актуальном состоянии.
• Публичные коллекторы маршрутов показывают для AS150069 лишь одного непосредственного соседа: AS132774 компании Niss Internet Services Private Limited. Это свидетельство одного видимого внешнего пути маршрутизации, а не доказательство того, что у Cloudnet нет частных стыков или резервного канала. Это также не доказательство физического разнообразия маршрутов, автоматического переключения на резерв или резервной ёмкости.
• IPinfo характеризует AS150069 как потребительского интернет-провайдера с выраженным суточным ритмом трафика и сообщает лишь об одном размещённом домене в этом адресном пространстве. Это полезные сигналы, а не проверенные данные об абонентах или продуктах. Публичного каталога услуг Cloudnet, сведений о расположении дата-центра, составе стоек, предложений виртуальных машин и физических серверов, услуг хранения, гарантий доступности, политики резервного копирования или процедуры миграции не найдено.
• Ответственная переоценка: от предполагаемого оператора облачных сервисов — к небольшому, в настоящее время маршрутизируемому интернет-провайдеру Тамилнада, точное розничное покрытие и физическая сеть которого не раскрыты. Его отказоустойчивость зависит от местных линейных сооружений доступа, активного оборудования агрегации, стыка с Niss, дальнейшей связности Niss и кадров технической поддержки. Прежде чем говорить о Cloudnet как об облачном провайдере, потребовались бы доказательства реально размещённых нагрузок.

Облачная гипотеза разбивается о первый же вопрос о продукте

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

Самый сильный публичный документ о компании — не облачный каталог. Этосписок разрешений на предоставление интернет-услуг Department of Telecommunications по состоянию на 31 января 2025 года. В записи указаны Cloudnet Internet Service Private Limited, номер лицензииDS-11/401/2022-DS-III, категория B, зона обслуживания Тамилнад, дата вступления в силу — 10 апреля 2023 года. Уполномоченный контакт, адрес зарегистрированного офиса и номер телефона совпадают с корпоративными записями компании и записями интернет-реестра.

Страница интернет-услуг Департаментаобъясняет, что означает категория B. Это право предоставлять интернет-услуги в одной лицензируемой зоне обслуживания, определяемой как телекоммуникационный округ или территория метрополитена.Сборник Unified Licenceописывает доступ в интернет, IPTV и отдельные формы интернет-телефонии в пределах действия разрешения. Лицензия — материальное доказательство того, что Cloudnet может работать интернет-провайдером в Тамилнаде. Но она не подтверждает, что компания построила покрытие на весь штат, и не превращает разрешение на доступ в доказательство размещённых вычислений.

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

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

При отсутствии продукта и операционной поверхности заявление об облаке следует отвергнуть, а не приукрашивать.

Остаётся другая, более обоснованная картина. У Cloudnet есть действующая автономная система, разрешение интернет-провайдера Тамилнада, небольшое выделение IPv4, выделение IPv6 и видимая зависимость от вышестоящего оператора. Это костяк сети доступа. Физическая инфраструктура за ним в значительной степени не раскрыта — от этого оценивать отказоустойчивость сложнее, но сеть не становится вымышленной.

Компания из Ченнаи и разрешение на деятельность в Тамилнаде

Агрегаторы корпоративных данных идентифицируют Cloudnet Internet Service Private Limited по корпоративному идентификационному номеруU64120TN2021PTC142654.Страница компании на Toflerдатирует регистрацию 8 апреля 2021 года, указывает объявленный уставный капитал в 1 млн рупий и оплаченный уставный капитал в 100 000 рупий, а директорами называет Logasundari и Gopikrishnan.Запись ZaubaCorpприводит тот же CIN, регистрацию в Ченнаи и адрес в Коттиваккаме, хотя некоторые поля с датами в её сводках противоречивы, и их не следует использовать вместо актуальной отчётности.

Адрес необычайно полезен для идентификации. Список лицензий размещает компанию на третьем этаже участка 11/236A на улице Vivekanandar Third Street в Коттиваккаме, Ченнаи.Регистрация AS150069 в APNICиспользует сокращённое юридическое наименование CLOUDNET INTERNET SERVICE PVT LTD, а административная роль повторяет те же адрес и номер телефона.Запись о выделении IPv4изапись о выделении IPv6несут то же имя сети —CNISPL— и ту же цепочку контактов. Это не просто похожие предприятия с общим названием: записи сходятся на одной компании.

Эта сходимость также исключает из рассмотрения несколько тёзок. Отдельная компания Cloudnet Broadband Services Private Limited фигурирует в более старых лицензионных материалах Харьяны, а Cloudnet Communications Private Limited — в абонентских таблицах. Другие предприятия в иных местах используют Cloud Net или Cloudnet как торговое наименование. Их не следует использовать для заполнения пробелов в каталоге услуг, числе абонентов или истории этой компании. Якорь идентификации здесь — лицензия Тамилнада, CIN, адрес в Коттиваккаме и AS150069.

Список DoT за 2025 год — доказательство наличия разрешения на дату отчёта, а не ежедневное свидетельство работы в июле 2026 года. С другой стороны, живые маршруты и недавно поддерживаемые объекты интернет-реестра дают гораздо более свежие технические доказательства. Поэтому компанию нельзя описывать как просто зарегистрированную или исторически лицензированную: в момент наблюдения её автономная система несла глобально видимый анонс.

Адрес по-прежнему не отвечает на вопрос, где стоит сетевое оборудование. Зарегистрированный офис может быть административным офисом, точкой присутствия, и тем и другим или ни тем ни другим. В записи IPv4 есть координаты13.427804, 80.14154212, но геолокация в реестре — метаданные, предоставленные оператором, а не обследование аппаратной. IPinfo относит несколько наблюдаемых адресов или маршрутизаторов к Ченнаи, Нагари и их окрестностям, а недавние проверки достигали отвечающих адресов из точек наблюдения в районе Ченнаи. Такая геолокация вероятностна. Она не может указать оптический линейный терминал, подтвердить владение волоконной трассой или установить, что абонент обслуживается на конкретной улице.

Поэтому обоснованное географическое утверждение узко. Cloudnet уполномочен на зону обслуживания Тамилнад, зарегистрирован в Ченнаи и эксплуатирует адресное пространство, которое независимые измерения связывают с Индией и регионом Ченнаи. Публичные данные не показывают розничного покрытия внутри Тамилнада, не подтверждают обслуживание всего Ченнаи и не раскрывают точек присутствия за пределами зарегистрированного адреса.

AS150069 даёт актуальные свидетельства деятельности

Автономная система — это единица политики маршрутизации, а не весь бизнес. Но AS150069 — самое ясное доказательство того, что Cloudnet сейчас действительно что-то эксплуатирует.Обзор ASN от RIPEstatсообщил, что 10 июля 2026 года этот номер AS анонсировался. Вответе об анонсируемых префиксахперечислены агрегат IPv4103.21.6.0/23, два более специфичных маршрута103.21.6.0/24и103.21.7.0/24, а также IPv6-префикс2001:df1:66c0::/48.

Агрегат IPv4 содержит 512 адресов.Текущий статус маршрутизациипоказал AS150069 единственным видимым источником для/23: маршрут видели 326 из 327 сообщающих IPv4-пиров. Статус также показал оба/24под агрегатом. Отдельные ответы о статусе для103.21.6.0/24и103.21.7.0/24зафиксировали те же источник и видимость. Это не след, видимый лишь одному наблюдателю.

Хронология показательна.История маршрутизации/23начинается с анонса агрегата Cloudnet в октябре 2022 года и продолжается до даты исследования. Оба/24впервые появились в декабре 2022 года. Их видимость резко упала на период начиная с марта 2025 года, тогда как покрывающий/23оставался широко видимым, а в мае 2026 года вернулась к широкой видимости. Это изменение гранулярности и распространения маршрутов, а не свидетельство остановки обслуживания. Трафик, адресованный в эти два блока, мог по-прежнему следовать по покрывающему агрегату, когда более специфичный маршрут был не виден.

IPv6 — это не просто резервирование в реестре.Статус маршрутизации для2001:df1:66c0::/48показал, что 10 июля AS150069 анонсировал префикс всем 321 сообщающим IPv6-пирам. Маршрут впервые наблюдался в ноябре 2022 года. Объект маршрута в APNIC был изменён 8 июля 2026 года — за два дня до наблюдения, а связанная контактная запись обновлялась и в июне. Эти даты говорят о продолжающемся администрировании ресурсов, но не сообщают, сколько абонентского трафика идёт по IPv6 и сколько пользователей его получают.

Различие между установленной и доступной ёмкостью принципиально./23— это пул адресов, а не покупка полосы пропускания. Пятьсот двенадцать IPv4-адресов не означают 512 абонентов, серверов, портов или мегабит. Провайдер может использовать адреса для интерфейсов маршрутизаторов, пулов операторского NAT (CGNAT), бизнес-каналов, инфраструктуры или резервного запаса. Один дом может использовать несколько публичных адресов; многие домохозяйства могут делить один адрес. Почти непостижимо большее число числовых адресов внутри IPv6-префикса/48ещё менее пригодно как мера ёмкости.

И три одновременных анонса IPv4 не утраивают сеть./23и два составляющих/24покрывают одно и то же адресное пространство. Более специфичные анонсы могут поддерживать политику маршрутизации, управление трафиком или операционный переход, но видимые данные маршрутизации не раскрывают, какая из целей действует. Если считать агрегат и составляющие за 1024 уникальных IPv4-адреса, одни и те же 512 адресов будут посчитаны дважды.

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

Единственный непосредственный сосед — видимая внешняя граница

Представление соседей AS в RIPEstat10 июля 2026 года обнаружило одного непосредственного соседа: AS132774. APNIC идентифицирует этот номер AS какNiss Internet Services Private Limited— сеть Тамилнада, зарегистрированную в Тирунелвели.Представление AS150069 в CIDR Reportнезависимо показывает ту же смежность и отсутствие нижестоящих AS.

Коллекторы маршрутов видят топологию, а не договоры. AS, непосредственно предшествующий Cloudnet в наблюдаемых путях, согласуется с тем, что Niss предоставляет транзит, управляемую маршрутизацию или иную форму вышестоящей связности. Но это не раскрывает цену, гарантированную полосу, условия превышения, физический стык, поставщика волокна, срок уведомления, обязательства по восстановлению и то, покупает ли Cloudnet услугу напрямую. Коммерческий ярлык «вышестоящий оператор» здесь — разумный вывод, но публичный результат строго таков: один видимый внешний BGP-сосед.

Это различие важно при обсуждении резервирования. Один видимый сосед — аргумент против утверждения о публично продемонстрированном разнообразии вышестоящих каналов. Но это не доказательство того, что у Cloudnet всего один кабель. У Cloudnet могут быть два физически раздельных канала к разным маршрутизаторам Niss при том же пути ASN. Может быть резервная сессия, простаивавшая в момент наблюдения. Может приниматься маршрут по умолчанию через соединение, невидимое коллекторам. И наоборот: несколько BGP-сессий к одному провайдеру могут сходиться в одной кабельной канализации, здании, маршрутизаторе или зоне электропитания.

Число сессий и физическое разнообразие — разные вещи.

Топология самого Niss шире. Взаписи Niss на PeeringDBуказаны пиринг NIXI Chennai и площадки в Ченнаи и Тирунелвели, аbgp.toolsперечисляет для AS132774 несколько вышестоящих операторов. Это заявленные и наблюдаемые факты о Niss, а не перенесённые свойства Cloudnet. Пакет Cloudnet может выиграть от дальнейших опций Niss после достижения AS132774, но наличие у Niss нескольких апстримов не доказывает, что у Cloudnet есть два независимых пути к Niss.

Живой просмотр looking-glass в RIPEstat для/23многократно помещал AS132774 непосредственно перед AS150069 в собранных путях. Многие пути далее проходили через AS9498 компании Bharti Airtel за пределами Niss. Это указывает на видимую в тот момент цепочку: Cloudnet, Niss, затем более крупные транзитные сети. Это не значит, что у Cloudnet прямой договор с Airtel, и не устанавливает, где происходит физическая сдача трафика.

Эта граница создаёт понятный механизм отказа. Если выйдет из строя единственный активный стык Cloudnet с Niss или маршрутная сессия будет отозвана без рабочей альтернативы, все глобально маршрутизируемые адреса Cloudnet могут стать недостижимыми, даже если абонентское волокно и локальные коммутаторы останутся под питанием. Если соединение с Niss продолжит работать, но его гарантированная ёмкость будет исчерпана, пользователи увидят перегрузку, а не чистый обрыв. Если неверен фильтр маршрутов или авторизация, может отказать одно семейство адресов или одна длина префикса, тогда как остальные продолжат работать.

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

Физическая сеть начинается там, где BGP перестаёт объяснять

BGP может показать, что AS150069 делает адресный блок достижимым. Но он не может показать кабель от помещения абонента до первого активного устройства. Между этими точками могут находиться оптический сетевой терминал, абонентское волокно, сплиттер, воздушное или подземное распределительное волокно, оптический линейный терминал, агрегация Ethernet, арендованный backhaul, патч-панели, блоки питания и охлаждение. Публичные данные не определяют, что из этого Cloudnet использует или чем владеет.

Разрешение категории B позволяет компании предоставлять услуги по всей лицензируемой зоне обслуживания Тамилнад; оно не подтверждает конкретную схему доступа. Cloudnet может эксплуатировать оптику до дома (FTTH), корпоративный Ethernet, радиоканалы, обслуживание через местных кабельных партнёров или их комбинацию. Публичных карт покрытия, проектных схем, спецификаций оптической сети, записей о вышках или соглашений с местными кабельными операторами не найдено. Наличие двух отвечающих IP-адресов внедавнем скане IPinfoпоказывает, что конечные точки отвечали на измерения, но не то, как построена последняя миля.

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

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

Ни одно публичное заявление Cloudnet не раскрывает время автономной работы резервного питания, охват генераторами, обслуживание батарей, два независимых ввода или схему электропитания площадок.

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

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

Вопрос о физическом размещении должен оставаться открытым. Коттиваккам — место зарегистрированного офиса. Координаты в реестре указывают на другую точку на севере Тамилнада, а сторонние измерения связывают адреса с Ченнаи, Нагари и другими метками Тамилнада. Базы данных IP-геолокации могут отражать регистрацию адресов, предположительное расположение пользователей или смещение измерений. Ничто из этого не доказывает, что у Cloudnet есть стойка в названном дата-центре или оборудование на конкретной площадке.

Биллинг, поддержка и договоры могут нарушить работу исправной сети

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

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

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

Оптовый договор с видимым соседом — ещё одна возможная точка контроля. Волокно и маршрутизатор могут быть технически исправны, тогда как обслуживание прерывает спор между провайдерами, истёкший заказ, неоплаченный счёт, ограничение ёмкости или истёкшая авторизация маршрута. Нет доказательств, что между Cloudnet и Niss происходил какой-либо подобный спор. Дело в структуре: там, где достижимость зависит от другого оператора, коммерческая непрерывность должна входить в оценку отказоустойчивости наравне с оптикой и электропитанием.

Отказ по договору с провайдером становится серьёзнее, когда нет подтверждённой альтернативы. Смена вышестоящего оператора — это не просто заказ линии. Новый провайдер должен дотянуться до точки сдачи трафика, принять маршруты Cloudnet, применить фильтры, поддерживать IPv4 и IPv6, учитывать действительные авторизации маршрутов и обеспечить достаточную ёмкость. Абонентскому трафику могут понадобиться новые маршруты по умолчанию, пути DNS или адресная политика. Если миграцию проводить в спешке после прекращения прежнего сервиса, сеть может остаться офлайн, даже если Cloudnet сохранит контроль над своим ASN и префиксами.

Перевод отдельных абонентов доступа порождает иную проблему миграции. Если Cloudnet прекратит обслуживание района или передаст абонентов другому оператору, непрерывность будет зависеть от права собственности на абонентское волокно и оборудование, переносимости записей об абонентах, сроков уведомления, возвратов и способности нового оператора подготовить подключение. Публичный BGP может не показать изменений, если адреса и источник остаются прежними, или показать крупные изменения, если абонентам выделят новые адреса. Ни тот ни другой исход сам по себе не объясняет, кто принял на себя розничные обязательства.

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

Установленная ёмкость — это не розничная ёмкость

Публичных тарифов или таблицы скоростей Cloudnet, которые можно было бы сопоставить с сетью, нет. Даже если бы они были, рекламируемая скорость доступа — лишь внешний край вопроса о ёмкости. Абонентский тариф 100 Мбит/с не резервирует 100 Мбит/с через каждый коммутатор агрегации, backhaul и транзитный канал во все часы. Провайдеры объединяют ёмкость в предположении, что все абоненты не будут одновременно требовать максимальную скорость.

Соответствующие эксплуатационные величины отсутствуют. Cloudnet не публикует число активных договоров, распределение скоростей, гарантированный транзит, ёмкость пиринга, схему backhaul, загрузку портов, пропускную способность в час наибольшей нагрузки, коэффициент переподписки или данные о перегрузках. Пул из 512 IPv4-адресов эти пробелы не закрывает. Операторский NAT (CGNAT) может позволить более чем 512 устройствам абонентов делить этот пул; статические бизнес-сервисы могут потреблять несколько адресов на договор; а IPv6 меняет адресную арифметику, сам по себе не добавляя ни бита транзитной ёмкости.

Cloudflare Radar показывал для AS150069оценку числа пользователейв несколько сотен, причём отображаемая оценка менялась между снимками и подстраницами. Такие оценки используют сигналы трафика и измерений, а не биллинговую систему провайдера. Они указывают на небольшую наблюдаемую пользовательскую базу и подтверждают трактовку сети как потребительского ISP, но их не следует цитировать как реестр абонентов. Один договор может обслуживать домохозяйство или предприятие со множеством людей, тогда как часть пользователей может не попадать в исходные измерения.

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

Нормативные требования TRAI 2024 года к качеству широкополосной связиустанавливают ориентиры и обязанности по отчётности для операторов доступа и широкополосной связи, включая подключение услуг, производительность сети, устранение неисправностей и обработку жалоб. Вежеквартальном отчёте о результатах за декабрь 2024 годапоясняется, что опубликованная сводка по широкополосной связи охватывала операторов с более чем 10 000 абонентов. Cloudnet в публичной сводке среди таких крупных операторов не значится. Отсутствие Cloudnet в публичной сводке не устанавливает его размер и не освобождает от применимых обязательств; оно означает лишь, что национальную сводку нельзя использовать как специфичное для Cloudnet доказательство производительности.

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

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

Для облачного сервиса потребовался бы иной набор доказательств

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

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

Второе — расположение. «Размещено в Индии» или «размещено в Ченнаи» потребовало бы доказательств площадки, где находятся данные и вычисления. ASN, зарегистрированный в Индии, не указывает расположение сервера. Трафик может маршрутизироваться через индийскую сеть к оборудованию в другом объекте или юрисдикции; наоборот, Cloudnet может использовать стороннюю индийскую инфраструктуру, не отражённую в его собственном адресном пространстве. Страна из реестра и место хранения данных — разные утверждения.

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

Четвёртое — резервирование. Облачный сервис может реплицировать данные между дисками, узлами, стойками, залами, зданиями или регионами — каждый уровень защищает от своего отказа. Две копии на одном узле не переживут отказ узла. Два узла в одной стойке могут делить распределитель питания. Две стойки в одном здании могут делить внешнее питание, охлаждение и вышестоящее волокно. Два здания могут зависеть от одной городской канализации или плоскости управления. Без раскрытой архитектуры и проверенного пути восстановления слово «облако» ничего не говорит о домене отказа.

Пятое — выход. Клиенту, восстанавливающемуся после сбоя провайдера, нужны экспортируемый образ, дамп базы данных, копия объектов, контроль над DNS и достаточно времени и полосы для переезда. Расторжение договора, спор по счетам или прекращение деятельности компании могут быть не менее разрушительны, чем аппаратный отказ, если учётные данные или данные привязаны к одной учётной записи. Условий Cloudnet, описывающих возврат данных, удаление, помощь при миграции, сроки хранения резервных копий или блокировку учётной записи, не найдено.

Это не обвинения в том, что Cloudnet не обладает такими возможностями. Это минимальные вопросы, на которые должны ответить публичные доказательства, прежде чем приписывать компании эти возможности. Частная котировка, договор или техническое расписание могут изменить вывод для конкретного клиента. Пока таких доказательств нет, AS150069 следует читать как свидетельство сетевой деятельности, а не облачный продукт.

RPKI — полезная гигиена маршрутизации, но не отказоустойчивость сама по себе

Cloudnet сделал конкретный шаг в области безопасности маршрутизации.Проверка в RIPEstat для агрегата IPv4обнаружила действительную авторизацию происхождения маршрута, покрывающую AS150069 и разрешающую анонсы вплоть до/24. Составляющие маршруты, следовательно, действительны в рамках той же авторизации.Проверка для IPv6-префикса/48также действительна.

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

Тем не менее текущая комбинация значима: зарегистрированные ресурсы, активные источники IPv4 и IPv6, объекты маршрутов и действительные авторизации происхождения. Это говорит о большей операционной зрелости, чем неактивное название компании. Но это же обостряет вопрос об отказоустойчивости, потому что видимая топология остаётся узкой. Корректно авторизованная достижимость через одного наблюдаемого соседа — это всё равно один наблюдаемый сосед.

Более специфичные анонсы IPv4 добавляют ещё один операционный нюанс. В период низкой видимости/24агрегат/23оставался широко видимым. Анонсирование и агрегата, и специфичных маршрутов может сохранить покрывающий маршрут, если специфичный исчезнет. Это также может использоваться для политики или смягчения атак. Публичные коллекторы не могут раскрыть замысел, а агрегат не создаёт второго физического пути. Резервирование маршрутизации и резервирование каналов нельзя смешивать.

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

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

Суточный ритм в данных IPinfo, лицензия интернет-провайдера и отсутствие хостингового каталога указывают на сеть доступа. Оценки наблюдаемых пользователей от Cloudflare и отвечающие адреса в районе Ченнаи подтверждают это направление. Но они не раскрывают имена, точные места или типы клиентов. Поэтому вероятная затронутая аудитория условна: домохозяйства, малый бизнес или учреждения, получающие связность через AS150069 или через услугу доступа Cloudnet.

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

Зависимость выходит за пределы держателя договора. Местный оператор или реселлер может размещать абонентов за маршрутизируемым пространством Cloudnet. Нижестоящих ASN видно не было, но нижестоящие розничные договорённости не требуют отдельного ASN. Если Cloudnet поставляет ёмкость другому оператору доступа, сбой на границе Cloudnet–Niss может затронуть пользователей, которые не знают ни одного из этих названий. Публичная маршрутизация не позволяет сосчитать такие договорённости.

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

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

Отсутствие публичной страницы инцидентов или истории статуса сервиса не позволяет вынести суждение о производительности. Молчание не доказывает идеальную надёжность, а разрозненные сообщения пользователей без проверки не установили бы общесетевые показатели. Текущие доказательства позволяют картировать цепочку отказов, но не оценивать историческую доступность Cloudnet.

Что позволило бы получить более полную операционную картину

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

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

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

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

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

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

Пока этих материалов нет, самым сильным доказательством Cloudnet остаются его лицензированная идентичность интернет-провайдера и живая маршрутизация. Неизвестное — не декоративные пробелы. Это именно те места, где сервис может отказать: абонентская линия, электропитание агрегации, backhaul, стык с Niss, дальнейший транзит, эскалация поддержки и восстановление абонентов.

Живая небольшая сеть с более скромной историей, чем её название

CLOUDNET INTERNET SERVICE PVT LTD — не пустая корпоративная оболочка. У него есть разрешение категории B на предоставление интернет-услуг в Тамилнаде, согласованная идентичность в Ченнаи во всех публичных записях, действующая автономная система, выделение IPv4 на 512 адресов, анонсируемый IPv6-префикс/48и действительные авторизации происхождения маршрутов. Его маршруты видны с 2022 года, а данные реестра поддерживались в актуальном состоянии вплоть до даты наблюдения.

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

Это не разочаровывающий результат, а более полезный. Название больше не заслоняет операционную поверхность, которую действительно можно наблюдать. Cloudnet, судя по всему, проводит трафик доступа в Тамилнаде через AS150069 и Niss Internet Services. Его отказоустойчивость будут определять обычные вещи: кабели, активная электроника, backhaul, конфигурация маршрутов, запасные части и люди, способные всё это восстановить.

Уровень доказательности сетевых данных слабый для полной оценки инфраструктуры, несмотря на веские доказательства активности ASN. Маршрутизация видна; физическая и коммерческая система за ней — нет. Более высокая оценка требует доказательств того, где подключаются абоненты, как уходит трафик, что переключается на резерв, как ведёт себя ёмкость под нагрузкой и кто устраняет каждый слой. Любое будущее заявление об облачном сервисе должно начинаться на шаг раньше — с доказательства того, что существует размещённый сервис, который можно оценивать.