ZEROSPACE Christian Wittenberg trading as Zerospace Cloud продаёт арендуемые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Кратко

• Реестр RIPE RDAP идентифицируетAS201801как ZEROSPACE и связывает его с Christian Wittenberg trading as Zerospace Cloud в Велдховене, Нидерланды;обзор ASв RIPEstat сообщил, что автономная система анонсируется по состоянию на 15 июля 2026 года.
• Маршрутизируемое адресное пространство невелико, но заметно:статус маршрутизациипоказал один префикс IPv4, 256 адресов IPv4, восемь IPv6-префиксов /48 и двух наблюдаемых соседей, аанонсируемые префиксыперечисляли 185.140.53.0/24 плюс восемь видимых IPv6-префиксов /48.
• Гигиена происхождения маршрутов — сильная сторона: RIPEstat вернул действительный RPKI для185.140.53.0/24и для2a07:1a84::/48, при этом проверка IPv6 опирается на ROA для 2a07:1a84::/44 с максимальной длиной /48.
• Доказательства операционной деятельности слабые:PeeringDBперечисляет Zerospace Cloud, но показывает нулевое количество публичных IX и нулевое количество площадок;геофидпривязывает фрагменты адресов к десяти городским меткам, однако не доказывает наличие локальных стоек, питания, оборудования, поддержки и возможности переноса клиентских данных в этих городах.

У компании есть реальная сетевая идентичность, но она новая

Первый факт, который стоит отделить от шума, — Zerospace Cloud это не просто маркетинговая фраза. RIPE RDAP по адресуhttps://rdap.db.ripe.net/autnum/201801регистрирует AS201801 как ZEROSPACE со статусом active, событием регистрации 30 января 2026 года и событием последнего изменения 13 марта 2026 года. Организацией в том же ответе RDAP указан Christian Wittenberg trading as Zerospace Cloud, с публичной адресной меткой «Велдховен, Нидерланды». В ответе RDAP также названы Zerospace Cloud Network Operations как административный и технический контакт и Zerospace Cloud Abuse Department как контакт по злоупотреблениям. Для небольшого облачного или хостингового провайдера это полезная исходная точка: есть названная организация, названная сеть и названные операционные контактные роли.

Записи об адресах соответствуют идентичности AS. RIPE RDAP по адресуhttps://rdap.db.ripe.net/ip/185.140.53.0/24идентифицирует диапазон 185.140.53.0–185.140.53.255 как ZEROSPACE-CLOUD, assigned PA, страна NL, статус active, с примечаниями, указывающими на геофид по адресуhttp://download.zerospace.cloud/ipam/geofeed.csv. RIPE RDAP по адресуhttps://rdap.db.ripe.net/ip/2a07:1a84::/44идентифицирует 2a07:1a84::/44 как ZEROCLOUD, aggregated by LIR, страна NL, статус active, с той же организацией и той же ссылкой на геофид. Обзор префикса в RIPEstat по адресуhttps://stat.ripe.net/data/prefix-overview/data.json?resource=185.140.53.0/24идентифицирует AS201801 как держателя происхождения IPv4-префикса /24.

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

Правильный вопрос не в том, существует ли AS201801. Он существует. Правильный вопрос — какие клиентские сервисы можно безопасно размещать поверх него.

Публичный сигнал маршрута активен. Обзор AS в RIPEstat по адресуhttps://stat.ripe.net/data/as-overview/data.json?resource=AS201801сообщил, что держатель — ZEROSPACE Christian Wittenberg trading as Zerospace Cloud, а автономная система анонсируется по состоянию на запрос от 15 июля 2026 года. Статус маршрутизации в RIPEstat по адресуhttps://stat.ripe.net/data/routing-status/data.json?resource=AS201801показал широкую публичную видимость: 324 из 326 пиров IPv4 RIS и 322 из 322 пиров IPv6 RIS видели маршрутизируемое пространство. Это не признак неиспользуемой регистрации. Это признак небольшой сети, видимой глобальной системе маршрутизации.

Для покупателей инфраструктуры живая видимость маршрута необходима, но недостаточна. Провайдер может маршрутизировать /24 и несколько IPv6-префиксов /48, оставаясь при этом зависимым от арендованных виртуальных серверов, колокации через реселлера, одного поставщика remote hands или небольшого набора апстримов. Маршрут показывает, что пакеты могут находить анонсируемые префиксы. Он не показывает, сможет ли клиент получить замену оборудования после отказа диска, выгрузить большой набор данных в условиях нехватки времени, восстановиться после сбоя хранилища или дозвониться до человека, уполномоченного устранять инцидент с питанием.

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

Маршрутизируемое адресное пространство невелико, заметно и анонсируется неравномерно

Картина по IPv4 компактна. Данные об анонсируемых префиксах в RIPEstat по адресуhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201801показали, что 185.140.53.0/24 анонсировался непрерывно в окне с 1 по 15 июля 2026 года. Статус маршрутизации засчитал это как один префикс IPv4 и 256 адресов IPv4. Для хостингового или облачного сервиса /24 может быть операционно полезен, но он невелик. Его хватит на целевой сервис в духе anycast, NAT-шлюзы, управленческие конечные точки клиентов, набор VPS-нод или ограниченное число напрямую выделенных клиентских адресов. Сам по себе он не является доказательством крупной вычислительной инфраструктуры.

Картина по IPv6 шире в арифметике адресов и тоньше в текущей видимости. Запись RDAP покрывает 2a07:1a84::/44, в котором помещается шестнадцать возможных префиксов /48. Сетевой объект PeeringDB по адресуhttps://www.peeringdb.com/api/net?asn=201801перечисляет в профиле один префикс IPv4 и шестнадцать префиксов IPv6. Однако конечная точка announced-prefixes в RIPEstat показала в окне обзора восемь видимых IPv6-префиксов /48: 2a07:1a84::/48,:1::/48,:2::/48,:3::/48,:4::/48,:5::/48,:6::/48 и:9::/48. Вид согласованности маршрутизации AS в RIPEstat по адресуhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201801добавил полезную деталь: 2a07:1a84::/44 присутствовал в whois, но сам не анонсировался в BGP, при этом несколько префиксов /48 были и в whois, и в BGP, а несколько других — в whois, но не в BGP.

Это различие важно для понимания установленной и доступной мощности. Установленная адресная ёмкость — это зарегистрированный IPv6-агрегат /44 и заявление PeeringDB о шестнадцати IPv6-префиксах. Доступная маршрутизируемая мощность — это подмножество, реально видимое в BGP в соответствующий период. Мощность, доступная клиенту, ещё уже: это префиксы, которые клиент может заказать по контракту, маршрутизировать через известную площадку, защитить с помощью RPKI, мониторить, сопровождать и переносить, если провайдер, площадка или апстрим выйдут из строя.

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

Сроки появления IPv6 также указывают на сеть, находящуюся в активном изменении. RIPEstat показал, что 2a07:1a84::/48 и 2a07:1a84:5::/48 были видны с начала июля, причём у:5::/48 был короткий разрыв между 3 и 5 июля. Несколько других префиксов /48 стали видны с 12 июля 2026 года. Это не доказывает нестабильность в смысле влияния на клиентов: новые IPv6-площадки или сервисные узлы часто вводятся волнами. Но это означает, что клиенту стоит спросить, какие /48 считаются продакшен-префиксами, какие являются тестовыми или промежуточными выделениями, какие привязаны к городской метке и какие прошли проверку переключения.

Валидация происхождения маршрутов — одна из лучших частей досье Zerospace. RIPEstat вернул состояние valid для 185.140.53.0/24 по адресуhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=185.140.53.0/24с происхождением AS201801 и максимальной длиной /24. Состояние valid он вернул и для 2a07:1a84::/48 по адресуhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=2a07:1a84::/48, при проверке по ROA для 2a07:1a84::/44 с максимальной длиной /48. RPKI не поддерживает работу серверов, но он даёт маршрутным фильтрам способ отличать разрешённые анонсы происхождения от неразрешённых. Для новой небольшой сети такая гигиена важна.

Картина по апстримам видна, а по площадкам — нет

Записи об апстримах яснее записей о площадках. Соседи ASN в RIPEstat по адресуhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201801показали двух наблюдаемых соседей: AS57758 и AS63473. Обзор AS в RIPEstat идентифицирует AS57758 как CBWS Holding B.V., а AS63473 — как HostHatch, LLC. Представление whois по адресуhttps://stat.ripe.net/data/whois/data.json?resource=AS201801также перечисляет записи политики импорта и экспорта для AS20473, AS63473 и AS57758, тогда как публичное наблюдение соседей на момент проверки показало AS57758 и AS63473. AS20473 в обзоре AS в RIPEstat — это The Constant Company, LLC, которую в названии AS обычно связывают с Vultr.

Этого достаточно, чтобы описать поверхность зависимостей, но недостаточно, чтобы подтвердить разнообразие. Два наблюдаемых соседа лучше одного, если они действительно независимы в пути обслуживания клиента, находятся в разных площадках или доменах отказов и оба настроены на префиксы клиента. Но две ASN могут делить одно здание, одну комнату meet-me, одно городское волокно, одно событие сбоя питания или одно окно удалённого обслуживания. Публичные данные BGP не говорят нам, стоят ли маршрутизаторы Zerospace в одной стойке или в нескольких точках.

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

PeeringDB усиливает эту осторожность. Сетевая запись Zerospace Cloud по адресуhttps://www.peeringdb.com/api/net?asn=201801перечисляет AS201801, сайтhttps://zerospace.cloud, IRR as-set AS201801:AS-ZEROSPACE-CLOUD, один префикс IPv4, шестнадцать префиксов IPv6, policy_general Open, статус ok, метку времени создания в октябре 2022 года и метку времени обновления 8 февраля 2026 года. Но конечная точка exchange LAN в PeeringDB по адресуhttps://www.peeringdb.com/api/netixlan?asn=201801не вернула ни одной публичной строки IX LAN, а конечная точка площадок по адресуhttps://www.peeringdb.com/api/netfac?net_id=31374не вернула ни одной публичной строки о площадках. PeeringDB ведётся самими операторами и может быть неполной, поэтому пустой список площадок — не доказательство их отсутствия. Это доказательство того, что публичное подтверждение площадок отсутствует.

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

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

Геофид описывает городские метки, а не гарантированную локальную инфраструктуру

Геофид по адресуhttps://download.zerospace.cloud/ipam/geofeed.csv— один из самых информативных публичных артефактов в досье Zerospace. Он привязывает 185.140.53.0/29 к Амстердаму, 185.140.53.8/29 к Лондону, 185.140.53.16/29 к Стокгольму, 185.140.53.24/29 к Сеулу, 185.140.53.32/29 к Сингапуру, 185.140.53.40/29 к Гонконгу, отдельные /32 в диапазоне 185.140.53.48–185.140.53.55 — к Токио, 185.140.53.56/29 — к Сиднею, 185.140.53.64/29 — к Нью-Йорку и 185.140.53.72/29 — к Лос-Анджелесу. IPv6-префиксы /48 он привязывает по той же городской схеме: 2a07:1a84::/48 — к Амстердаму,:1::/48 — к Лондону,:2::/48 — к Стокгольму,:3::/48 — к Сеулу,:4::/48 — к Сингапуру,:5::/48 — к Гонконгу,:6::/48 — к Токио,:7::/48 — к Сиднею,:8::/48 — к Нью-Йорку и:9::/48 — к Лос-Анджелесу.

Это сигнал о глобальной зоне обслуживания, а не доказательство глобальных мощностей. По IPv4 большинство городских записей — это /29, то есть по восемь адресов каждая. Токийские записи IPv4 — отдельные /32 или очень небольшие группы, и геофид покрывает не каждый адрес в /24 с явно названным городом. Геолокация RIPEstat по адресуhttps://stat.ripe.net/data/geoloc/data.json?resource=185.140.53.0/24и представление MaxMind GeoLite по адресуhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=185.140.53.0/24отражают похожий разброс, но также показывают, что большая доля IPv4-префикса /24 в запрошенном представлении приходится на Швецию без указания города. Это означает, что публичная геолокационная картина неоднородна: у одних фрагментов адресов есть точные городские метки, а большая часть IPv4-пространства не представлена в виде детальной карты вычислений по городам.

С локализацией IPv6 тоже нужно разбираться внимательно. Геолокация RIPEstat дляhttps://stat.ripe.net/data/geoloc/data.json?resource=2a07:1a84::/44и представление MaxMind GeoLite по адресуhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=2a07:1a84::/44показали /44, разбитый на несколько /48 с городскими метками, при этом значительная доля агрегата отображается как Швеция без города. Геофид перечисляет:7::/48 для Сиднея и:8::/48 для Нью-Йорка, однако конечная точка announced-prefixes не показала эти /48 среди восьми видимых префиксов в окне обзора. Это не обязательно противоречие: записи геофида могут описывать предполагаемую или зарегистрированную локализацию, тогда как видимость маршрутов меняется со временем. Это напоминание о том, что заявления о локализации нужно сверять с текущим состоянием маршрутов.

От этого различия страдают не только конечные пользователи в этих городах. Небольшой облачный провайдер может обслуживать VPN-шлюзы, edge-узлы, управляемый хостинг, нагрузки разработчиков, цели резервного копирования, игровую инфраструктуру, тестовые среды, сервисы малого бизнеса или региональные точки доступа. Если выйдет из строя фрагмент с меткой Амстердама, европейскому клиенту могут быть важны задержки и юридическое местоположение. Если выйдет из строя фрагмент Гонконга или Сингапура, пользователи Азиатско-Тихоокеанского региона увидят более высокие задержки или переключение в другой регион.

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

Поэтому правильный вопрос для проверки — не «упоминает ли геофид мой город?». Он звучит так: «какая физическая или виртуальная площадка обслуживает адрес с моей городской меткой, кто её эксплуатирует, какие апстримы её несут, какое питание и оборудование за ней стоят и как её будут восстанавливать или переносить?». Городская метка помогает клиенту решить, о чём спрашивать. Её нельзя использовать как доказательство того, что Zerospace владеет инфраструктурой во всех десяти городах.

Сайт и записи DNS вскрывают отдельную зависимость доступности

Основной сайт тоже нужно отделять от клиентской инфраструктуры. Конечная точка DNS-chain в RIPEstat по адресуhttps://stat.ripe.net/data/dns-chain/data.json?resource=zerospace.cloudпоказала, что zerospace.cloud использует авторитативные серверы имён Cloudflare — ali.ns.cloudflare.com и rudy.ns.cloudflare.com, с A-записями 172.67.142.47 и 104.21.87.70 и AAAA-записями 2606:4700:3035::ac43:8e2f и 2606:4700:3036::6815:5746 на момент запроса 15 июля 2026 года. Конечная точка DNS-chain дляhttps://stat.ripe.net/data/dns-chain/data.json?resource=download.zerospace.cloudпоказала те же адреса за Cloudflare для хоста загрузок. Конечная точка дляhttps://stat.ripe.net/data/dns-chain/data.json?resource=www.zerospace.cloudвернула авторитативные серверы имён Cloudflare, но без прямых записей дляwww.zerospace.cloud.

При прямой HTTPS-проверке 15 июля 2026 годаhttps://zerospace.cloudне вернул пригодную для использования страницу в пределах 15-секундного таймаута curl из этого окружения. Более ранние проверки через Cloudflare могут выявлять сбои доступности источника в стиле 522, когда источник не отвечает Cloudflare. Даже не полагаясь на какой-либо единичный преходящий результат HTTP, данные DNS показывают, что публичный путь к сайту опосредован Cloudflare. Это распространённая и часто разумная практика. Она также означает, что доступность сайта — не то же самое, что доступность маршрутов AS201801.

Здесь две отдельные зависимости. Во-первых, маркетинговое или управляющее веб-присутствие Zerospace зависит от DNS и проксирования Cloudflare, а также от того, какой сервис-источник стоит за Cloudflare. Во-вторых, маршрутизируемые клиентские префиксы Zerospace зависят от AS201801, его соседей-апстримов и физических или виртуальных локаций, которые несут эти префиксы. Покупатель не должен делать вывод, что раз сайт стоит за Cloudflare, то и клиентский трафик стоит за Cloudflare.

Не должен он и делать вывод, что раз AS201801 виден в BGP, то клиентский портал, документация, уведомления о статусе или канал поддержки останутся доступными при сбое источника сайта.

Хост загрузок интересен тем, что он отдавал геофид, хотя основной сайт во время проверки не был читаемой публичной страницей. Это говорит о том, что одни пути через Cloudflare могут быть доступны, а другие — нет. Для операционной деятельности клиента вопрос в том, размещены ли критичные порталы, формы поддержки, панели управления, страницы статуса, геофиды и API-конечные точки независимо или разделяют одну и ту же зависимость от источника. Если единственный путь в поддержку — веб-форма за хрупким источником, то сбой сети или источника может задержать восстановление, даже когда маршрут BGP остаётся поднятым.

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

Физические зависимости в основном скрыты за сетевым уровнем

Публичное досье Zerospace даёт нам маршрутные ресурсы, но не даёт полной физической карты. По AS201801 в PeeringDB нет публичной записи о площадке. В этом обзоре на основном сайте не нашлось публичной страницы о площадках. В доступных здесь материалах нет опубликованного списка шкафов, заявления о плотности мощности, схемы охлаждения, поставщика remote hands, политики учёта оборудования, архитектуры резервного копирования, страницы статуса или руководства по миграции. Это не значит, что всего этого не существует. Это значит, что публично это не подтверждено.

Стек физических зависимостей для клиента при этом конкретен. Если Zerospace продаёт арендуемые мощности, какой-то сервер или виртуальный инстанс должен где-то стоять. У этого «где-то» есть стойка или хост-машина, ввод питания, путь охлаждения, сеть управления, порт апстрима, зависимость от хранилища и процедура доступа. Если выйдет из строя диск, кто-то или какая-то автоматика должна заменить или перенести нагрузку. Если выйдет из строя маршрутизатор, второй путь должен понести префикс. Если сработает автомат в шкафу, для этого шкафа должен быть план.

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

Питание и охлаждение — наименее заметные части досье Zerospace. /24 и /44 можно анонсировать с очень небольшой физической инфраструктуры, с арендованных виртуальных машин, с партнёрских хостов или с небольшого числа колоцированных серверов. Поэтому количество IP-адресов почти ничего не говорит о запасе мощности. Клиентам нужно знать выделенную мощность, полезную мощность после резервирования, плотность охлаждения на стойку, какие ИБП и генераторы предполагает площадка и может ли одно плотное развёртывание исчерпать локальный запас провайдера. Без этой информации покупатель не отличит городской edge-узел от отказоустойчивого хостинг-региона.

Учёт оборудования так же непрозрачен. Провайдер может маршрутизировать адреса по всему миру, но по-прежнему зависеть от ограниченного пула хостов. Если Zerospace предлагает VPS или управляемые сервисы, покупателю стоит спросить, сколько продакшен-хостов стоит за каждой локацией, локальное ли хранилище или общее, как выводятся отказавшие узлы, есть ли запасные ноды в той же локации и требует ли замена мощностей заказа у стороннего хоста. Небольшое выделение IPv4 делает эффективное использование адресов вероятным; это также означает, что дефицит публичных IP может повлиять на планы миграции и расширения.

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

Реальный вопрос восстановления — кто может действовать, когда падает сессия маршрутизатора, отказывает хост, исчезает городская конечная точка или клиенту нужно срочно эвакуировать данные.

Пути отказа: маршрут, апстрим, площадка, поддержка и миграция

Первый путь отказа — доступность апстримов. У AS201801 в RIPEstat было два наблюдаемых соседа, AS57758 и AS63473, а в списке политик whois упоминался также AS20473. Если AS57758 или AS63473 потеряет сессию, результат зависит от того, переносят ли оба соседа затронутые префиксы, достаточно ли симметричен трафик-инжиниринг для обратных путей и изолирован ли сбой в одном апстриме. Если обе сессии завершаются в одном и том же месте или зависят от одной и той же локальной точки сдачи, резервирование может оказаться менее полезным, чем кажется по числу AS.

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

Второй путь отказа — авторизация и фильтрация маршрутов. RPKI действителен для IPv4-префикса /24 и для схемы IPv6 /44→/48, и это хорошо. Но клиентам стоит по-прежнему спрашивать, отслеживает ли Zerospace утечки маршрутов, недействительные анонсы, ошибки максимальной длины и дрейф геолокации. Действительный ROA может стать операционно болезненным, если провайдер позже начнёт анонсировать более специфичный маршрут за пределами максимальной длины, если апстрим неожиданно отфильтрует префикс или если городской /48 будет добавлен без соответствующей авторизации маршрута.

Текущее состояние RPKI — положительный контроль, но не замена контролю изменений.

Третий путь отказа — потеря площадки или скрытая концентрация площадок. Поскольку PeeringDB показывает ноль публичных записей о площадках, клиенты не могут независимо определить, стоят ли за несколькими городами несколько площадок, один апстрим-оверлей или реселлерский парк. Если адрес с меткой Амстердама и адрес с меткой Лондона оба зависят от одного аккаунта провайдера, одного биллингового отношения, одной команды удалённой поддержки или одного туннельного концентратора, сбой в этих отношениях может затронуть не один видимый регион.

Многогородние записи геофида следует сверять с независимыми свидетельствами о площадках, поставщиках и маршрутизации.

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

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

Установленная, доступная и купленная мощность — разные вещи

Досье Zerospace — полезный пример того, почему у облачных мощностей три слоя. Установленная мощность — это то, чем провайдер правдоподобно заявляет владение или контроль: AS201801, 185.140.53.0/24, 2a07:1a84::/44, зарегистрированная маршрутная политика и профиль в PeeringDB. Доступная сетевая мощность — это то, что присутствует в публичной маршрутизации и достижимо при действительной авторизации происхождения: один IPv4-префикс /24, восемь видимых IPv6-префиксов /48 в окне обзора, два наблюдаемых соседа и широкая видимость в RIPE RIS.

Купленная мощность — это то, что клиент реально потребляет по контракту, с привязанными условиями по вычислениям, хранилищу, каналу, поддержке и миграции.

В дистанции между этими слоями прячется риск. Клиент может увидеть десять городов в геофиде и предположить десять продакшен-регионов. Свидетельства это предположение не поддерживают. Клиент может увидеть шестнадцать IPv6-префиксов в PeeringDB и решить, что все шестнадцать активны. RIPEstat в этом окне показал восемь видимых /48, при этом некоторые /48 из whois в BGP отсутствовали. Клиент может увидеть двух наблюдаемых соседей-апстримов и предположить резервирование маршрутов. Это верно только в том случае, если два соседа независимы для префиксов клиента и домена отказов.

Клиент может увидеть действительный RPKI и предположить операционную устойчивость. RPKI помогает подлинности маршрутов, а не ремонту серверов.

Это не делает Zerospace непригодным. Это делает его провайдером, у которого покупать стоит по узкой модели доказательств. Разработчик, которому нужен небольшой маршрутизируемый сервис, IPv6-лаборатория, edge-эксперимент или некритичная хостинговая конечная точка, может счесть публичный след достаточным — при условии, что коммерческие условия соответствуют риску. Бизнес, переносящий продакшен-нагрузки, данные клиентов, системы, смежные с платежами, медицинские данные или регулируемые записи, должен требовать большего, чем публичные свидетельства о маршрутизации.

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

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

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

Локализация данных заявлена через геофид, но юридическая и операционная локализация остаются открытыми

Геофид даёт сигнал о локализации данных, но это не контракт о суверенитете данных. Он сообщает потребителям геолокации, как Zerospace хочет, чтобы интерпретировались фрагменты адресов. Он не говорит, где лежат диски, где находятся резервные копии, какая компания эксплуатирует хост, где расположены сотрудники поддержки, право какой страны регулирует сервис и какие субподрядчики могут получить доступ к данным клиентов. Это различие критично для клиентов в Европе, Азиатско-Тихоокеанском регионе и Северной Америке, которые могут прочитать Амстердам, Лондон, Гонконг, Токио или Нью-Йорк как заявление о соответствии или задержках.

Для европейских клиентов полезны нидерландская запись об организации и код страны NL в записях об адресах, но они не доказывают, что все данные клиентов остаются в Нидерландах или в Европейской экономической зоне. Сам геофид для нескольких фрагментов указывает за пределы Европы. Для клиентов в Азиатско-Тихоокеанском регионе метки Сеул, Сингапур, Гонконг, Токио и Сидней могут быть полезны с точки зрения задержек, но клиенту всё равно нужно знать, обрабатываются ли данные локально, проксируются ли через другую страну, хранятся ли резервно в другом месте и эксплуатируются ли сторонним хостинг-поставщиком.

Для клиентов в США метки Нью-Йорка и Лос-Анджелеса требуют тех же вопросов.

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

Локализация пересекается и с реагированием на сбои. Если адрес с меткой Гонконга обслуживает партнёр в Гонконге, путь ремонта может зависеть от очереди поддержки этого партнёра. Если его обслуживает виртуальный узел глобального облачного провайдера, ремонт может зависеть от аккаунта этого провайдера и статуса региона. Если он обслуживается через туннель из другого места, метка геофида может быть полезна приложениям, но не физической независимости. Ни одна из этих моделей не является автоматически неправильной. Важно раскрытие. Клиент не может строить отказоустойчивость вокруг названия города, не зная, что это название на самом деле означает.

Кто пострадает, если сервис откажет

Пострадавшие пользователи зависят от того, что Zerospace на самом деле продаёт. Публичные данные поддерживают сетевую идентичность облачного или хостингового типа, но здесь нет публичного каталога продуктов, который можно было бы независимо прочитать. Тем не менее классы зависимостей ясны. Клиенты, использующие Zerospace для хостинговых конечных точек, VPS-инстансов, edge-узлов, VPN-шлюзов, сервисов, смежных с DNS, сайтов малого бизнеса или бэкендов приложений, пострадают при отзыве маршрута, отказе апстрима, отказе сервера, потере хранилища, задержке поддержки или сбое веб-управления.

Региональные конечные пользователи заметят слой геофида первыми. Если трафик, предназначенный для Амстердама, Лондона или Стокгольма, переедет в более удалённую локацию, чувствительные к задержкам приложения могут деградировать. Если недоступны фрагменты Сеула, Сингапура, Гонконга или Токио, пользователи Азиатско-Тихоокеанского региона увидят более длинные пути или отказ сервиса. Если фрагменты Нью-Йорка или Лос-Анджелеса не маршрутизируются, когда это ожидается, пользователи Северной Америки не получат локализацию, обещанную в коммерческой схеме. Карта геофида создаёт ожидания, даже когда не доказывает мощности.

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

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

Что повысило бы оценку доказательств

Zerospace мог бы быстро повысить оценку доказательств, опубликовав датированное заявление об инфраструктуре. Самое полезное публичное заявление различало бы собственную инфраструктуру, арендованную колокацию, виртуализированные узлы и партнёрские локации. Оно сопоставляло бы каждый город из геофида с типом развёртывания там, называло бы, доступны ли клиентские вычисления в этой локации, заявляло бы, являются ли IPv4 и IPv6 продакшен-протоколами, и объясняло бы, какие апстримы несут каждый префикс. Ему не нужно раскрывать чувствительные детали; оно должно отделять маркетинговую географию от операционной зависимости.

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

RPKI должен оставаться сильной стороной. У Zerospace уже есть действительная авторизация происхождения маршрутов для рассмотренных IPv4- и IPv6-маршрутов. Будущие публичные данные должны сохранять эту дисциплину по мере появления новых /48. Если:7::/48 и:8::/48 должны стать активными городскими локациями, видимость маршрутов и валидация должны совпадать с геофидом. Если часть записей геофида зарезервирована или запланирована, провайдеру стоит прямо об этом сказать, а не позволять клиентам делать выводы о продакшен-локализациях из файла соответствия адресов.

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

Итог для операторов, которые зависят от этого провайдера

У Zerospace Cloud достаточно публичных доказательств, чтобы считать его реальной маршрутизируемой сетью, но недостаточно, чтобы считать его подтверждённой глобальной хостинг-платформой. Записи RIPE связывают AS201801, 185.140.53.0/24 и 2a07:1a84::/44 с Christian Wittenberg trading as Zerospace Cloud. RIPEstat показывает анонсируемую AS с широкой видимостью по IPv4 и IPv6. RPKI действителен для рассмотренных IPv4- и IPv6-происхождений. PeeringDB перечисляет сетевой объект Zerospace Cloud. Геофид детален и актуален настолько, чтобы поддержать серьёзные вопросы о географическом дизайне сервиса.

Предостережение столь же ясно. Адресное хозяйство IPv4 — это один префикс /24. Видимость IPv6 в окне обзора покрывает восемь /48, а не каждый /48, подразумеваемый агрегатом /44 и профилем. PeeringDB не показывает публичных записей о площадках или IX. Основной сайт во время проверки не был надёжным источником сведений о сервисе. Геофид наносит города на карту, но не доказывает наличие стоек, питания, охлаждения, оборудования, поддержки или возможностей миграции в этих городах. Текущая картина апстримов показывает двух наблюдаемых соседей, но публичные данные о маршрутизации не доказывают независимость доменов отказов.

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

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