LUNAR HOSTING LTD продаёт хостинговые мощности, которые по-прежнему зависят от стоек, транзита и окон ремонта

Резюме

• LUNAR HOSTING LTD — действующая британская компания, учреждённая 19 апреля 2026 года. Её AS198685 в настоящее время анонсирует два IPv4-префикса /24: один зарегистрирован с кодом страны Германии и геофидом Фалькенштейна, другой — с кодом страны Нидерландов. Текущие публичные наблюдения не показывают IPv6-маршрутов и лишь одного видимого соседнего оператора.
• Сетевые данные поддерживают ограниченный вывод: под именем Lunar работает небольшой маршрутизируемый хостинговый след. Они не доказывают владения дата-центром, парком серверов, резервным электропитанием, независимым транзитом, резервным копированием, укомплектованной поддержкой или проверенным путём выхода.
• Покупателю следует рассматривать устойчивость, локализацию данных и восстанавливаемость как открытые контрактные вопросы. Наиболее важными доказательствами были бы названные площадки, ответственность за оборудование и вышестоящих операторов, протестированные результаты восстановления, условия доступности по конкретным услугам, сроки эскалации поддержки и документированный способ выгрузки полных рабочих нагрузок.

Компания может получить ASN быстрее, чем построить устойчивость

LUNAR HOSTING LTD представляет сжатую историю инфраструктуры. Текущая британская компания былаучреждена 19 апреля 2026 года, номер компании 17166654, зарегистрированный офис — 42 Rupert Street в Лондоне. Реестр описывает её как действующую и присваивает ей два вида деятельности: консультирование в области информационных технологий, а также обработку данных, хостинг и сопутствующие виды деятельности. Запись RIPE для AS198685 была создана на следующий день. К июлю коллекторы маршрутов видели два префикса IPv4 /24, анонсируемых этой автономной системой.

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

Но это лишь сетевой край хостинг-услуги. Они не говорят, владеет ли Lunar хотя бы одним сервером. Они не показывают аренды стойки, выделенную мощность, запасные диски, условия remote hands, носители резервных копий, кластер гипервизоров или дежурного техника. Они тем более не говорят о коммерческой машине вокруг машин: может ли спор о счете приостановить работу стойки, может ли поставщик отозвать адреса и может ли клиент выгрузить рабочую копию до завершения контракта.

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

Публичные данные поэтому поддерживают узкое описание. Lunar — недавно учреждённая британская хостинговая компания, связанная с недавно назначенным ASN и небольшим глобально видимым IPv4-следом. Они не поддерживают более широкое утверждение, что Lunar владеет дата-центром, управляет несколькими независимыми площадками или продемонстрировала непрерывность при сбоях. Для такого утверждения нужны доказательства ближе к машинам и контрактам, чем те, что даёт таблица маршрутизации.

Существует и более старая британская компания с тем же названием, номер 15058184, которая былаликвидирована 14 января 2025 года. Её зарегистрированный адрес и виды деятельности отличаются от действующей компании. Ничто в текущих сетевых записях не требует связи между этими двумя компаниями, поэтому по ликвидированному тёзке нельзя делать выводы об истории, обязательствах или преемственности компании 17166654. Самый безопасный якорь — номер действующей компании, повторённый в текущей организационной записи RIPE.

Два /24 — это видимая мощность, а не перепись машин

12 июля 2026 годапредставление announced-prefixes в RIPEstatперечисляло 144.31.136.0/24 и 94.183.224.0/24 у AS198685. Это 512 IPv4-адресов в маршрутизируемых блоках. Егопредставление routing-statusпоказывало оба префикса видимыми для всех 326 пиров IPv4 в соответствующей выборке RIPE Routing Information Service. Анонсированного IPv6-пространства оно не показывало.

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

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

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

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

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

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

Без этих раскрытий самое сильное утверждение таково: Lunar контролирует текущее происхождение двух глобально видимых IPv4-маршрутов. Это реальная сетевая мощность. Но она не является надёжным показателем вычислительной мощности, долговечности хранилища или числа отказов, которые сервис способен поглотить.

Данные о локации указывают на Германию и Нидерланды, но с важными оговорками

Два адресных блока несут разные сигналы локации в записях RIPE. Объект inetnum для 144.31.136.0/24 называет блокlunar-cloud, присваивает ему код страны Германии и связываетгеофид, помещающий /24 в Фалькенштейн. Объект inetnum для 94.183.224.0/24 называет блокLUNAR_HOSTING_LTDи присваивает ему код страны Нидерландов. Эти поля важны, потому что это конкретные утверждения, привязанные к адресным ресурсам.

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

Фалькенштейна достаточно, чтобы сформировать проверяемую гипотезу: по крайней мере часть адресов 144.31.136.0/24 предполагается представлять как расположенную в этом немецком городе. Этого недостаточно, чтобы приписывать оборудование Lunar какому-либо конкретному оператору площадки. Несколько компаний эксплуатируют инфраструктуру в крупных европейских хостинг-локациях и вокруг них, и один лишь IP не идентифицирует арендодателя, владельца сервера или подрядчика remote hands. Метка Нидерландов на втором блоке шире и в просмотренном для этой статьи объекте RIPE не даёт публичного якоря на уровне города.

Корпоративный и веб-слои добавляют географии, не разрешая физический вопрос. Lunar зарегистрирована в Британии. Её доменlunarhost.proпри проверке 12 июля перенаправлял наlunarcloud.ru, а конечный адрес показывал страницу проверки anti-DDoS. DNS-конечная точка витрины не находилась в AS198685. Такое разделение обыденно для хостинга: сайт продаж может использовать защитный край, даже когда клиентские серверы ходят по собственным маршрутам провайдера. Это также означает, что доступность веб-страницы мало говорит о здоровье клиентских машин, а сбой в AS198685 не обязан выводить из строя сайт продаж.

Для британского клиента, работающего с персональными данными, правильный вопрос не просто «Британский ли провайдер?». Обновлённоеруководство ICO по международным передачампросит организации понимать отдельные юридические лица, контракты и информационные потоки. Удалённый доступ со стороны отдельной зарубежной организации может иметь значение, даже если байты остаются на сервере в Европе. И наоборот, простой транзит трафика через другую страну — не обязательно то же самое, что ограниченная передача. Фактическая карта должна включать хранение, резервное копирование, администрирование и поддержку.

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

Граница собственности — центр риска

Текущие записи RIPE показывают, что сеть Lunar опирается на ресурсы и организации за пределами самой компании. AS198685 — спонсорское назначение. Два блока IPv4 — провайдер-агрегируемое пространство, а не прямое выделение, документированно принадлежащее Lunar. Объект 144.31.136.0/24 помечен как субадресуемое провайдер-агрегируемое пространство; объект 94.183.224.0/24 — как назначенное провайдер-агрегируемое пространство. Эти метки не делают сервис худшим. Они показывают, что дальнейшее использование зависит от вышестоящих коммерческих и регистратурных отношений.

Эта зависимость видна в истории маршрутов. Прежде чем AS198685 стала стабильным наблюдаемым источником, те же /24 в разное время появлялись под другими источниками. История 144.31.136.0/24 показывает несколько смен источника до маршрута Lunar. История 94.183.224.0/24 в 2026 году ещё активнее: множественные источники предшествовали текущему анонсу AS198685. Аренда адресов и повторная смена источника распространены на рынке, где дефицит IPv4 сделал блоки ценными и переносимыми. Для клиентов операционный вопрос — действуют ли права провайдера на использование адресов по крайней мере столько же, сколько услуга, которую они обеспечивают.

Публичный объектaut-numобъявляет договорённости импорта и экспорта с AS212743 и AS213529. Тем не менеепредставление наблюдаемых соседей в RIPEstatпоказывало на дату проверки одного текущего соседа — AS202413. Декларации политики в реестре и наблюдаемые пути отвечают на разные вопросы и могут меняться с разной скоростью. Расхождение — не доказательство дефекта. Это свидетельство того, что статическую запись не следует читать как живую карту топологии.

Вот практический стек собственности, который нужно понимать клиенту. Lunar может владеть клиентским контрактом и эксплуатировать AS198685. Другая сторона может спонсировать AS. Одна или несколько сторон могут предоставлять адресные блоки. Другая может обеспечивать транзит. Компания-владелец площадки может контролировать питание, охлаждение и физический доступ. Лизингодатель оборудования может владеть серверами. Провайдер защиты может защищать публичный сайт или трафик услуги. Каждый слой может иметь право приостановить сервис, если нарушены его собственные счета, политика по злоупотреблениям или контракт.

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

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

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

Оба наблюдаемых префикса при проверке через RIPEstat имели валидные авторизации происхождения маршрута для AS198685. Для144.31.136.0/24результат валидации называл AS198685 валидным источником, а несколько других возможных источников — невалидными согласно текущей авторизации. Для94.183.224.0/24валидная авторизация также указывала на AS198685. Это полезный контроль. Сети, выполняющие проверку происхождения маршрута, могут отклонять анонсы, чей источник противоречит авторизованной AS, снижая один класс случайных или вредоносных искажений происхождения маршрута.

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

Главное предупреждение об устойчивости — единственный наблюдаемый сосед. RIPEstat насчитал один уникальный смежный AS, а IPinfo независимо описал AS198685 как стаб с единственным вышестоящим оператором. Измерения могут не видеть частные соединения или резервные сессии в простое, и оператор может иметь несколько физических цепей к одной транзитной сети. Даже с этими оговорками публичная картина не демонстрирует независимого разнообразия вышестоящих операторов. Отсутствие записи в PeeringDB убирает ещё одно распространённое место, где операторы раскрывают площадки, точки обмена и политику пиринга.

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

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

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

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

Отказ стойки превращает виртуальное обещание обратно в железо

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

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

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

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

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

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

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

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

Сбой транзита может изолировать исправные серверы

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

Для AS198685 публичные коллекторы маршрутов видели одну смежную сеть. Это делает важными несколько сценариев. Сессия BGP может сброситься. Сосед может отозвать префиксы Lunar. Физическое кросс-соединение может отказать. Вышестоящий оператор может столкнуться с перегрузкой или внутренним сбоем маршрутизации. Реагирование на DDoS-атаку может отбрасывать легитимный трафик вместе с атакой. Контрактный вопрос может заставить вышестоящего оператора приостановить сервис. Результат для конечного пользователя в каждом случае похож: IP перестаёт отвечать или становится непозволительно медленным.

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

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

Клиентам также нужно понимать защиту от DDoS как путь с собственной ёмкостью и правилами. Защитный край anti-DDoS публичного домена защищает витрину, наблюдавшуюся в ходе этого обзора, но не доказывает, что два клиентских префикса получают ту же защиту. Очистка трафика может быть всегда включённой, активируемой по требованию или ограниченной по типу атаки и законтрактованному объёму. Провайдер может оставаться достижимым на сайте поддержки, пока клиентские адреса не маршрутизируются (null-routed). Возможно и обратное.

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

Самый показательный вопрос для Lunar — не «Есть ли у вас резервные сети?», а «Какие именно отказы текущая конструкция переживает без смены клиентских IP, и когда каждый переключатель в последний раз тестировался под нагрузкой?» Убедительный ответ назвал бы независимых транзитных провайдеров, физические стыки, площадки, политики маршрутов и ожидаемую конвергенцию. При отсутствии такого ответа видимую топологию с одним соседом следует считать концентрацией риска.

Труд поддержки — часть инфраструктуры

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

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

Скудные раскрытия важнее всего вне обычных часов. Автоматический монитор может обнаружить отказ хоста немедленно, но восстановление всё равно зависит от полномочий и доступа. Может ли первый реагирующий изменить маршрут? Может ли этот человек войти на площадку или поручить remote hands? Доступен ли второй инженер для проверки разрушительной команды хранилища? Принимает ли вышестоящий оператор срочные запросы круглосуточно? Общается ли с клиентами тот же человек, который устраняет сбой?

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

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

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

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

Миграция — путь восстановления при сбоях, которые провайдер не может устранить

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

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

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

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

Самая безопасная конструкция миграции начинается до инцидента. Клиенты могут хранить определения инфраструктуры вне провайдера, поддерживать независимые копии ключей шифрования и доступа к DNS, регулярно выгружать данные приложений и тестировать восстановление во второй среде. Это обязанности клиента, а не замена ясности провайдера. В рамкахмодели разделённой ответственности NCSCобязанности по безопасности и доступности зависят от модели сервиса, и обе стороны должны их понимать.

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

Отказ провайдерского контракта заслуживает собственного сценария. Если Lunar теряет стойку, поставщика адресов или транзитное соглашение, может ли она вытащить клиентские данные и переместить услуги до расторжения? Есть ли договорной период исправления? Могут ли клиенты связаться с нижележащей площадкой, или это нарушило бы границы безопасности и коммерческие границы? Хранятся ли резервные копии в отдельном аккаунте, который переживает спор с основным поставщиком? Публичные записи не отвечают на эти вопросы, но слоистая структура ресурсов делает их существенными.

Для клиентов путь миграции — предельный ограничитель зависимости. Низкая помесячная цена может быть рациональной даже при скромной избыточности, если рабочую нагрузку легко воссоздать в другом месте. Тот же сервис может быть плохой сделкой для уникальных данных или прописанной публичной конечной точки, если выход занимает недели. Текущие данные Lunar недостаточно сильны, чтобы клиент сам оценил этот риск; это могут сделать только условия сервиса и тест восстановления.

Суверенитет данных — карта контроля, а не флаг на IP

След Lunar пересекает несколько административных сигналов: британскую компанию, блок с меткой Германии и геофидом Фалькенштейна, блок с меткой Нидерландов и веб-адрес под российским национальным доменом верхнего уровня. Ни один из этих фактов по отдельности не определяет юрисдикцию, управляющую каждой копией клиентских данных.

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

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

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

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

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

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

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

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

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

Второе — актуальное сетевое заявление. Оно должно объяснять, есть ли у AS198685 один или несколько независимых вышестоящих операторов, разнесены ли физические пути и краевые маршрутизаторы, какие префиксы получают защиту от DDoS и планируется ли нативный IPv6 или он доступен через другой сервис. Публичная запись PeeringDB и непротиворечивые объекты политики RIPE упростили бы проверку топологии, хотя наблюдаемые маршруты всё равно были бы нужны.

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

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

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

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

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

Решение о покупке должно следовать за терпимостью нагрузки к неопределённости

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

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

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

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

Клиентам также следует следить за изменениями. Нынешним компании и ASN всего несколько месяцев. Источники адресов, соседи, веб-назначения и отношения с поставщиками уже менялись за короткий период. Это может отражать нормальное строительство молодой сети. Это также означает, что однажды сделанная оценка быстро устаревает. Видимость маршрутов, авторизации, условия сервиса и возможности выгрузки следует перепроверять при продлении и после любого объявленного переезда.

Финальное суждение намеренно ограничено. У LUNAR HOSTING LTD достаточно текущих доказательств, чтобы считать её чем-то большим, чем фирма-пустышка: её автономная система анонсирует глобально видимое адресное пространство, источники авторизованы, а вторичные измерения видят хостинговую активность. Публичных доказательств того, что предлагаемая мощность является мультиплощадочной, независимо подключённой или демонстративно восстанавливаемой, пока недостаточно.

Этот разрыв — центр истории. Хостинговые мощности кажутся абстрактными, только пока работают все зависимости. Отказ стойки делает их железом. Отзыв маршрута — транзитом. Отказавший диск — складскими запасами. Без ответа на инцидент — трудом. Расторгнутое соглашение с поставщиком — контрактным правом. Непроверенная выгрузка — заложником клиента. Публичная сеть Lunar видима; устойчивость за ней пока видна недостаточно.