LUNAR HOSTING LTD vend une capacité hébergée qui dépend encore des baies, du transit et des fenêtres de réparation

Résumé

• LUNAR HOSTING LTD est une société britannique active constituée le 19 avril 2026. Son AS198685 annonce actuellement deux routes IPv4 /24, l'une enregistrée avec un code pays Allemagne et un géofeed Falkenstein, l'autre avec un code pays Pays-Bas. Les observations publiques actuelles ne montrent aucune route IPv6 et un seul réseau voisin visible.
• Les preuves réseau soutiennent une conclusion limitée: une petite empreinte d'hébergement routée fonctionne sous le nom Lunar. Elles ne prouvent pas la possession d'un centre de données, d'un inventaire de serveurs, d'une alimentation redondante, d'un transit indépendant, d'une couverture de sauvegarde, d'un support doté de personnel ou d'une voie de sortie testée.
• Un acheteur doit traiter la résilience, la localisation des données et la récupérabilité comme des questions contractuelles ouvertes. Les preuves les plus importantes seraient des installations nommées, le matériel et la responsabilité en amont, des résultats de restauration testés, des conditions de disponibilité propres au service, des délais d'escalade du support et une méthode documentée pour exporter les charges de travail complètes.

Une entreprise peut obtenir un ASN plus rapidement qu'elle ne peut construire une résilience

LUNAR HOSTING LTD présente une histoire d'infrastructure condensée. La société britannique actuelle a étéconstituée le 19 avril 2026, avec le numéro de société 17166654 et un siège social au 42 Rupert Street à Londres. Le registre la décrit comme active et lui attribue deux classifications d'activité: conseil en technologies de l'information, et traitement de données, hébergement et activités connexes. L'enregistrement RIPE pour AS198685 a été créé le lendemain. En juillet, les collecteurs de routes pouvaient voir deux IPv4 /24 annoncés par ce système autonome.

Ce ne sont pas des réalisations triviales. Un numéro de système autonome permet à un opérateur d'exprimer une politique de routage sous son propre identifiant. Une route visible signifie que d'autres réseaux acceptent et propagent un chemin vers les adresses. Une autorisation d'origine de route peut indiquer aux réseaux de validation que l'AS nommé est autorisé à annoncer un préfixe. Ensemble, ces caractéristiques constituent une preuve d'exploitation plus forte qu'un nom de société, une page de réseau social ou un domaine dormant.

Elles ne représentent encore que la bordure réseau d'un service d'hébergement. Elles ne disent pas si Lunar possède un seul serveur. Elles ne montrent pas un bail pour un rack, une allocation d'énergie, des disques de rechange, des conditions de main à distance, des supports de sauvegarde, un cluster d'hyperviseurs ou un technicien d'astreinte. Elles en disent encore moins sur la machinerie commerciale entourant les machines: si un litige de facturation peut suspendre un rack, si un fournisseur peut réclamer des adresses, ou si un client peut extraire une image fonctionnelle avant la fin d'un contrat.

Cette distinction est importante car les petites sociétés d'hébergement vendent souvent un objet commercial tout en l'assemblant à partir de plusieurs objets physiques et contractuels. Le client voit un serveur privé virtuel, une machine dédiée ou un service géré. Le fournisseur peut combiner du matériel loué, de l'espace d'adressage sous-alloué, un ASN parrainé, un transit tiers, un contrat d'installation, un filtrage anti-DDoS et un panneau de facturation. Chaque composant peut être légitime et bien géré. Mais chacun a aussi sa propre date de renouvellement, son mode de défaillance et sa partie ayant le pouvoir de le déconnecter.

Les preuves publiques soutiennent donc une description étroite. Lunar est une société britannique récemment constituée, associée à un ASN récemment attribué et à une petite empreinte IPv4 visible mondialement. Elles ne soutiennent pas l'affirmation plus large que Lunar possède un centre de données, contrôle plusieurs sites indépendants ou a démontré une continuité en cas de panne. Cette affirmation plus large nécessiterait des preuves plus proches des machines et des contrats que ce que fournit la table de routage.

Il existe également une ancienne société britannique portant le même nom, numéro de société 15058184, qui a étédissoute le 14 janvier 2025. Son adresse enregistrée et sa classification d'activité diffèrent de la société active. Rien dans l'enregistrement réseau actuel n'exige que les deux sociétés soient liées, donc l'homonyme dissoute ne doit pas être utilisé pour déduire un historique, des passifs ou une continuité pour la société 17166654. L'ancre la plus sûre est le numéro de société active répété dans l'enregistrement d'organisation RIPE actuel.

Deux /24 sont une capacité visible, pas un recensement de machines

Le 12 juillet 2026, lavue des préfixes annoncés de RIPEstatlistait 144.31.136.0/24 et 94.183.224.0/24 sous AS198685. Cela représente 512 adresses IPv4 dans des blocs routables. Savue du statut de routagemontrait les deux préfixes visibles pour l'ensemble des 326 pairs IPv4 dans l'échantillon pertinent du Service d'Information de Routage RIPE. Elle ne montrait aucun espace IPv6 annoncé.

Le nombre d'adresses est utile, mais seulement dans des limites strictes. Un /24 peut supporter de nombreuses adresses clients, un nombre plus restreint de services avec traduction d'adresses réseau, des interfaces d'infrastructure, des attributions de réserve ou des adresses retenues en raison de la réputation et de la politique opérationnelle. Il peut se trouver devant un grand cluster de virtualisation ou un ensemble très restreint d'hôtes. Il peut aussi se déplacer entre fournisseurs physiques tandis que l'IP visible par le client reste inchangée.

Compter les adresses ne peut révéler les cœurs de processeur, la mémoire, le débit de stockage, la surréservation, la densité des racks ou le nombre de locataires payants.

La différence entre capacité installée et capacité utilisable est encore plus grande. La capacité installée est ce qui existe dans un rack ou un compte fournisseur: machines, disques, ports et logiciels sous licence. La capacité utilisable est ce qui peut être vendu sans violer les objectifs de performance, les réserves de redondance ou les hypothèses de réparation. Si dix serveurs sont installés mais que chaque client dépend du même contrôleur de stockage ou du même commutateur de tête de rack, la tolérance de panne utile peut être beaucoup plus faible que ce que suggère le nombre de serveurs.

Si chaque adresse sort par un seul chemin externe, ajouter des machines augmente la capacité de revenu sans augmenter la diversité de routage.

Lunar n'a pas publié assez de matériel vérifiable pour calculer l'une ou l'autre mesure. Il n'existe pas d'inventaire public liant les deux préfixes à des nombres d'hôtes, des générations de processeur, une conception de stockage ou une capacité de réserve réservée. Il n'existe pas de série d'utilisation publique qui montrerait si le service est vide, confortablement chargé ou proche d'une limite de ressource. Un service de données réseau secondaire,IPinfo, classifiait l'AS comme hébergement, comptait un petit ensemble de domaines hébergés et décrivait une activité autour de l'horloge lors de l'observation. Ce sont des signes utiles que les adresses transportent du trafic. Ils ne peuvent pas identifier les clients, valider les factures ou prouver que la capacité commerciale annoncée est disponible.

C'est là que l'économie de l'hébergement devient physique. Un serveur virtuel à bas coût peut être créé en quelques secondes uniquement parce que quelqu'un a acheté ou loué un châssis, l'a alimenté, connecté, installé du stockage et réservé assez de mémoire pour admettre un autre invité. L'acte marginal est numérique; la capacité en dessous ne l'est pas. Lorsqu'un fournisseur a une empreinte publique mince, un client ne peut pas substituer en toute sécurité la rapidité de provisionnement à une preuve de marge de manœuvre durable.

Une déclaration de capacité sérieuse identifierait la classe de service et sa ressource limitante. Pour un serveur virtuel, cela pourrait inclure si le CPU est dédié ou partagé, si le stockage est local ou en réseau, quelle limite d'IOPS s'applique et combien de réserve de panne d'hôte existe. Pour du matériel nu, cela inclurait l'état du stock, les objectifs de pièces de rechange et si du matériel équivalent peut être fourni sur un autre site.

Pour un service géré, cela inclurait la frontière de travail: qui patche l'hôte, qui répond en dehors des heures ouvrables, et à quelle vitesse le fournisseur agira lorsque le client ne peut pas atteindre la machine.

Sans ces divulgations, l'affirmation la plus forte est que Lunar contrôle l'origine actuelle de deux routes IPv4 visibles mondialement. C'est une capacité réseau réelle. Ce n'est pas un proxy fiable pour la capacité de calcul, la durabilité du stockage ou le nombre de pannes que le service peut absorber.

Les preuves de localisation pointent vers l'Allemagne et les Pays-Bas, avec des réserves importantes

Les deux blocs d'adresses portent des signaux de localisation différents dans les enregistrements RIPE. L'objet inetnum pour 144.31.136.0/24 étiquette le bloclunar-cloud, lui donne un code pays Allemagne et lie ungéofeed qui place le /24 à Falkenstein. L'objet inetnum pour 94.183.224.0/24 étiquette le blocLUNAR_HOSTING_LTDet lui donne un code pays Pays-Bas. Ces champs sont pertinents car ce sont des assertions spécifiques attachées aux ressources d'adresses.

Ils ne remplacent pas une adresse d'installation. Les champs de pays RIPE sont des attributs administratifs, et un géofeed est une déclaration de localisation publiée par l'opérateur destinée à améliorer la géolocalisation IP. Ni l'un ni l'autre n'établit où un disque est vissé dans un rack, où les sauvegardes sont copiées, ou d'où un administrateur peut accéder aux données clients. Le guide du NCSC sur laprotection des actifs et la résiliencesépare explicitement les pays de stockage, de traitement et de gestion de la base légale du fournisseur, du lieu de support et de la propriété du centre de données physique. Le dossier public de Lunar laisse la plupart de ces couches sans nom.

Falkenstein est suffisamment spécifique pour former une hypothèse testable: au moins certaines adresses dans 144.31.136.0/24 sont destinées à être représentées comme étant dans cette ville allemande. Ce n'est pas suffisant pour attribuer le matériel de Lunar à un opérateur d'installation particulier. Plusieurs entreprises exploitent des infrastructures dans et autour des grands sites d'hébergement européens, et une localisation IP seule n'identifie pas le propriétaire, le propriétaire du serveur ou le sous-traitant de main à distance.

L'étiquette Pays-Bas sur le second bloc est plus large et ne fournit pas d'ancrage public au niveau de la ville dans l'objet RIPE examiné pour cet article.

Les couches corporatives et web ajoutent plus de géographie sans résoudre la question physique. Lunar est enregistrée en Grande-Bretagne. Son domainelunarhost.proredirigeait verslunarcloud.rulors du test du 12 juillet, tandis que la destination présentait une page de vérification anti-DDoS. L'extrémité DNS de la vitrine n'était pas dans AS198685. Cette séparation est courante dans l'hébergement: un site de vente peut utiliser un bord protecteur même lorsque les serveurs clients utilisent les propres routes du fournisseur. Cela signifie aussi que la disponibilité continue de la page web en dit peu sur la santé des machines clientes, et qu'une panne dans AS198685 n'a pas nécessairement besoin de faire tomber le site de vente.

Pour un client britannique traitant des données personnelles, la bonne question n'est pas simplement: « Le fournisseur est-il britannique? » Les directives mises à jour de l'ICO sur lestransferts internationauxdemandent aux organisations de comprendre les entités juridiques, contrats et flux d'informations distincts impliqués. Un accès à distance par une organisation étrangère distincte peut être important même si les octets restent sur un serveur en Europe. Inversement, le trafic transitant simplement par un autre pays n'est pas automatiquement un transfert restreint. La carte factuelle doit inclure le stockage, la sauvegarde, l'administration et le support.

Les deux préfixes étiquetés par pays de Lunar font de la localisation des données une question de diligence raisonnable de premier ordre, et non un argument de vente résolu. Les preuves nécessaires sont concrètes: le pays d'installation sélectionné pour chaque service, si l'emplacement peut changer, où se trouvent les répliques et l'accès de support, quels sous-traitants peuvent toucher au système, quel préavis accompagne un déménagement, et ce qu'il advient des copies résiduelles après résiliation. Une facture nommant une région n'est utile que si les dispositions techniques et contractuelles l'appliquent.

La frontière de propriété est au centre du risque

Les enregistrements RIPE actuels montrent que le réseau de Lunar dépend de ressources et d'organisations extérieures à l'entreprise elle-même. AS198685 est une attribution parrainée. Les deux blocs IPv4 sont de l'espace agrégable par le fournisseur plutôt qu'une allocation directe clairement documentée détenue en propre par Lunar. L'objet 144.31.136.0/24 est marqué comme espace agrégable par le fournisseur sous-alloué; l'objet 94.183.224.0/24 est un espace agrégable par le fournisseur attribué. Ces étiquettes ne rendent pas le service inférieur.

Elles montrent que l'utilisation continue dépend de relations commerciales et de registre en amont.

Cette dépendance est visible dans l'historique des routes. Avant qu'AS198685 ne devienne l'origine stable observée, les mêmes /24 sont apparus sous d'autres origines à différents moments. L'historique de 144.31.136.0/24 montre plusieurs changements d'origine avant la route Lunar. L'historique de 94.183.224.0/24 est encore plus actif en 2026, avec de multiples origines précédant l'annonce actuelle d'AS198685. La location d'adresses et la réémission sont courantes dans un marché où la rareté des IPv4 a rendu les blocs précieux et portables.

Pour les clients, la question opérationnelle est de savoir si les droits du fournisseur d'utiliser les adresses durent au moins aussi longtemps que le service qu'ils sous-tendent.

L'objet publicaut-numdéclare des arrangements d'import et d'export avec AS212743 et AS213529. Pourtant, lavue des voisins observés de RIPEstatmontrait un voisin actuel, AS202413, pour la date d'examen. Les déclarations de politique de registre et les chemins observés répondent à des questions différentes et peuvent changer à des vitesses différentes. Le décalage n'est pas une preuve de défaut. C'est une preuve qu'un enregistrement statique ne doit pas être lu comme une carte topologique en direct.

C'est la pile de propriété pratique qu'un client doit comprendre. Lunar peut posséder le contrat client et exploiter AS198685. Une autre partie peut parrainer l'AS. Une ou plusieurs parties peuvent fournir les blocs d'adresses. Une autre peut fournir le transit. Une société d'installation peut contrôler l'alimentation, le refroidissement et l'accès physique. Un loueur de matériel peut posséder les serveurs. Un fournisseur de mitigation peut protéger le site web public ou le trafic de service. Chaque couche peut avoir le droit de suspendre le service si sa propre facture, sa politique d'abus ou son contrat est violé.

Les pires défaillances dans cette structure ne sont pas toujours techniques. Un disque peut être remplacé. Une fibre peut être réparée. Un litige avec un fournisseur peut refuser l'accès physique au fournisseur ou retirer des adresses avec peu de temps pour une migration ordonnée. Un petit opérateur peut être techniquement compétent et tout de même avoir un faible pouvoir de négociation avec un propriétaire ou un loueur. C'est pourquoi la preuve de l'existence corporative et la preuve du contrôle de route doivent être rejointes par une preuve de droits du fournisseur durables.

Les clients n'ont pas besoin que chaque terme commercial soit divulgué publiquement. Ils ont besoin d'assurances contractuelles qui correspondent aux dépendances: un préavis avant la migration d'adresse ou d'installation lorsque cela est possible; une réponse définie si un fournisseur résilie le service; un accès continu aux données client pendant une sortie ordonnée; et un compte clair de la partie responsable de l'équipement, de l'alimentation, du transit et de l'intervention physique. Un fournisseur incapable de nommer ces frontières laisse le client supporter des risques qu'il ne peut pas surveiller.

La sécurité de routage est un signal positif, mais la diversité de chemin n'est pas démontrée

Les deux préfixes observés avaient des autorisations d'origine de route valides pour AS198685 lors de la vérification via RIPEstat. Pour144.31.136.0/24, le résultat de validation nommait AS198685 comme l'origine valide tout en traitant plusieurs autres origines possibles comme invalides sous l'autorisation actuelle. Pour94.183.224.0/24, l'autorisation valide pointait également vers AS198685. C'est un contrôle utile. Les réseaux effectuant une validation d'origine de route peuvent rejeter une annonce dont l'origine entre en conflit avec l'AS autorisé, réduisant ainsi une classe de mauvaise émission accidentelle ou malveillante.

La validité de l'origine de route ne dit pas que le chemin est redondant, court ou non congestionné. Elle valide la relation entre un préfixe et l'AS d'origine, pas la séquence complète des réseaux transportant le trafic. Elle n'empêche pas une route correctement émise de disparaître parce qu'un routeur perd de l'alimentation, qu'une facture de transit reste impayée ou que la seule session externe est réinitialisée. Elle ne sécurise pas non plus le serveur derrière l'adresse.

Le principal avertissement de résilience est le voisin unique observé. RIPEstat comptait un seul AS adjacent unique et IPinfo décrivait indépendamment AS198685 comme une souche monorattachée. Les mesures peuvent manquer des interconnexions privées ou des sessions de sauvegarde qui sont inactives, et un opérateur peut avoir plusieurs circuits physiques vers un réseau de transit. Même avec ces réserves, la vue publique ne démontre pas de diversité amont indépendante. L'absence d'un enregistrement réseau PeeringDB supprime un autre lieu commun où les opérateurs divulguent les installations, les points d'échange et la politique de peering.

La distinction entre deux liens et deux destins importe. Deux câbles vers le même routeur amont peuvent tomber ensemble. Deux routeurs dans la même pièce peuvent perdre la même alimentation. Deux opérateurs peuvent louer le même conduit. Deux adresses dans des /24 différents peuvent toujours se terminer sur le même hôte. La vraie diversité nécessite une séparation à chaque couche pertinente: chemin physique, routeur, réseau amont, domaine d'alimentation, installation et équipe d'exploitation. Une table de routage peut exposer une partie de cette structure, mais pas la totalité.

Les objectifs demultihébergement de sitedu Groupe de travail sur l'ingénierie Internet décrivent les pannes que la redondance est censée survivre: coupures physiques, pannes de routeur, pannes de session de routage, pannes de fournisseur et pannes d'échange. Par rapport à cette norme, les preuves publiques de Lunar établissent une joignabilité mais pas une continuité. Il n'y a aucune preuve visible que le trafic bascule vers un deuxième fournisseur de transit indépendant, ni un test publié montrant combien de temps prend la convergence et si les sessions existantes survivent.

L'absence d'IPv6 est une contrainte séparée. Elle ne rend pas un service d'hébergement IPv4 inutilisable, et de nombreux clients fonctionnent encore confortablement en IPv4. Elle signifie que l'empreinte réseau publique n'est pas double pile et que les clients ayant besoin d'IPv6 natif ne peuvent pas déduire une route à partir de l'enregistrement ASN. Elle concentre également tout l'adressage de service publiquement observé dans deux blocs IPv4 rares dont les conditions de fournisseur sont importantes.

La conclusion appropriée est équilibrée. Lunar a fait quelque chose de positif en autorisant ses origines actuelles et en maintenant les deux routes globalement visibles. Cela réduit un risque de routage. Les mêmes preuves ne démontrent pas un deuxième chemin indépendant, et la topologie observée actuelle suggère qu'une panne amont ou d'un réseau adjacent reste un événement de mode commun significatif.

Une panne de rack transforme une promesse virtuelle en matériel

La virtualisation change l'unité vendue, pas la physique en dessous. Un client peut acheter vCPU, RAM et stockage au mois, mais ces ressources résident toujours sur des processeurs, des modules de mémoire, des disques, des cartes réseau et des commutateurs. Leur continuité dépend de l'alimentation, du refroidissement, des micrologiciels, des hyperviseurs et de la capacité d'une personne à atteindre un composant défaillant.

Lunar n'a pas identifié publiquement si la capacité client se trouve sur des serveurs possédés, des machines dédiées louées, des serveurs virtuels imbriqués ou un mélange. Chaque modèle produit un chemin de défaillance différent. Les serveurs possédés donnent à l'opérateur plus de contrôle sur la configuration et les pièces de rechange, mais nécessitent du capital et de la logistique. Le matériel loué peut accélérer l'expansion mais laisse le moment du remplacement et l'accès au fournisseur.

La virtualisation imbriquée peut rendre la capacité très flexible tout en ajoutant un autre plan de contrôle et un autre fournisseur dont les limites peuvent être invisibles pour le client final.

Considérons une panne d'un seul hôte. Si les disques clients sont locaux et qu'il n'y a pas de réplique en direct, chaque invité sur cet hôte reste indisponible jusqu'à ce que la machine soit réparée ou que ses disques soient déplacés. Si le stockage est partagé, le calcul peut être redémarré ailleurs, mais le stockage partagé devient une concentration de risque plus importante. Si des répliques existent dans le même rack, une panne d'alimentation du rack ou du commutateur de tête de rack peut désactiver les deux copies.

Si des répliques existent dans une autre installation, la récupération est plus solide, mais le retard de réplication, la bande passante et l'orchestration déterminent la quantité de données et de temps perdue.

Les mots « sauvegarde » et « instantané » sont particulièrement faciles à surévaluer. Un instantané sur le même système de stockage peut aider à annuler une erreur client mais peut ne pas survivre à une perte de stockage. Une sauvegarde dans le même compte administratif peut être supprimée par les mêmes identifiants compromis. Une réplique peut fidèlement copier une corruption. Les conseils de résilience du NCSC recommandent la capacité de revenir à un état connu bon et soulignent que la conception du service, plutôt qu'un crédit de disponibilité, prévient la perte.

Une affirmation utile nécessite donc un objectif de point de récupération, un objectif de temps de récupération, une isolation du domaine de panne principal et la preuve que les restaurations ont été testées.

Le stock de matériel est une autre contrainte cachée. Un fournisseur peut avoir de la capacité de calcul de rechange mais pas de disque, d'alimentation ou de carte réseau compatible sur place. Le remplacement peut alors dépendre d'un coursier, des douanes, d'un entrepôt du fournisseur et d'une fenêtre d'accès à l'installation. Pour un opérateur nouvellement constitué avec une base matérielle non divulguée, il n'existe aucune preuve publique de pièces de rechange en stock ou de délais de remplacement garantis.

Les clients doivent distinguer un objectif de réponse au support, qui peut signifier seulement qu'un ticket est accusé réception, d'un objectif de réparation ou de restauration.

La maintenance introduit des versions planifiées du même risque. Les changements de micrologiciel, les remplacements de commutateurs et les travaux d'alimentation peuvent être inoffensifs lorsque la capacité est vidée et que les chemins redondants sont prouvés. Ils peuvent devenir des pannes lorsque le chemin de sauvegarde n'a pas transporté la charge de production ou que les invités ne peuvent pas se déplacer en raison d'une incompatibilité de stockage ou de processeur. Lunar n'a pas publié de politique de maintenance, de période de préavis ou de fenêtre d'urgence maximale qui pourrait être vérifiée pour cette revue.

La conclusion au niveau du rack n'est donc pas que les machines de Lunar sont peu fiables; leur identité n'est pas assez publique pour juger. C'est que la promesse de service ne peut pas être séparée de dépendances physiques non vérifiées. Tant que l'entreprise ne nomme pas son modèle d'installation, sa responsabilité matérielle, sa politique de pièces de rechange et sa conception de restauration, les clients doivent supposer qu'un défaut peut nécessiter une main-d'œuvre tierce et que le temps de récupération n'est pas établi par la vitesse du panneau de contrôle.

Une panne de transit peut isoler des serveurs en bonne santé

Un serveur peut être alimenté, refroidi et fonctionner correctement tout en étant inaccessible à chaque client. C'est le risque définissant de la dépendance au transit. L'hôte exécute toujours des instructions, mais la route qui donne son sens à son adresse a disparu ou s'est dégradée.

Pour AS198685, les collecteurs de routes publics ont vu un réseau adjacent. Cela rend plusieurs scénarios importants. La session BGP pourrait se réinitialiser. Le voisin pourrait retirer les préfixes de Lunar. Une interconnexion physique pourrait échouer. Le fournisseur amont pourrait subir une congestion ou un défaut de routage interne. Une réponse à un déni de service pourrait jeter le trafic légitime avec une attaque. Un problème contractuel pourrait amener le fournisseur amont à suspendre le service. Le résultat pour un utilisateur final est similaire dans chaque cas: l'IP cesse de répondre ou devient inutilisablement lente.

Deux /24 annoncés ne résolvent pas ce problème si les deux sortent par le même voisin. Ni une autorisation d'origine de route valide. Un second bloc peut aider avec la gestion des adresses et les transitions de fournisseur, mais la redondance provient d'un chemin alternatif viable transportant ou prêt à transporter la route. Les observations publiques ne montrent pas ce chemin alternatif.

Il existe des atténuations possibles que la vue publique ne verrait pas. Lunar pourrait maintenir une session de sauvegarde froide, utiliser des tunnels vers un second réseau, acheter plusieurs circuits au même fournisseur, ou organiser une réémission d'urgence. Chacune peut réduire certains risques. Chacune nécessite également des tests. Une route froide peut prendre du temps à se propager. Un tunnel peut traverser le même opérateur défaillant. Un second circuit peut entrer dans le bâtiment par le même conduit.

Une réémission d'urgence peut entrer en conflit avec les filtres de route ou les autorisations actuelles si elle n'a pas été préparée à l'avance.

Les clients doivent également comprendre la protection contre les dénis de service comme un chemin avec sa propre capacité et ses propres règles. Le bord anti-DDoS du domaine web public protège la vitrine observée lors de cette revue, mais cela ne prouve pas que les deux préfixes de service client reçoivent la même protection. Le nettoyage peut être toujours actif, activé à la demande ou limité par type d'attaque et volume contractuel. Un fournisseur peut rester joignable sur son site de support pendant que les adresses client sont mises à null-route. L'inverse peut également se produire.

Les défaillances de performance sont plus subtiles qu'un retrait total. Un seul amont peut rester visible pour les collecteurs de routes tout en subissant une perte de paquets sur un chemin régional. Les clients dans un pays peuvent voir une latence sévère tandis que d'autres voient un service normal. L'existence de la route ne mesure pas la qualité de l'application, et une seule trace de globe oculaire globale n'est pas un historique au niveau du service.

Des preuves utiles incluraient des sondes diverses, la perte et la latence dans le temps, les enregistrements d'incidents et la capacité de déplacer le trafic lorsqu'un chemin se dégrade sans disparaître complètement.

La question la plus révélatrice pour Lunar n'est pas: « Avez-vous un réseau redondant? » C'est: « Quelles pannes exactes la conception actuelle peut-elle survivre sans changer les IP des clients, et quand chaque basculement a-t-il été testé sous charge pour la dernière fois? » Une réponse crédible nommerait des fournisseurs de transit indépendants, des handoffs physiques, des installations, des politiques de route et la convergence attendue. En l'absence de cette réponse, la topologie visible à un voisin doit être traitée comme un risque de concentration.

La main-d'œuvre de support fait partie de l'infrastructure

L'hébergement est souvent décrit à travers les machines car les machines sont comptables. Lors d'un incident, la main-d'œuvre devient la ressource rare. Quelqu'un doit classifier le défaut, décider s'il s'agit d'une configuration client ou d'une infrastructure fournisseur, contacter l'installation, autoriser un redémarrage, remplacer du matériel, changer une route, restaurer une sauvegarde, communiquer le statut et empêcher une récupération précipitée d'aggraver les dégâts.

La page des dirigeants de Companies House listait un seul administrateur actif pour Lunar au moment de l'examen. Cela ne dit rien de définitif sur le personnel; une entreprise peut employer des personnes, utiliser des sous-traitants ou partager les opérations avec un autre service. Cela signifie que les registres corporatifs publics ne révèlent pas un large banc de direction. Le site de service n'a pas produit de rotation du personnel vérifiable, de description du centre d'opérations réseau ou de carte d'escalade lors de cette recherche.

La divulgation mince importe le plus en dehors des heures normales. Un moniteur automatisé peut détecter un hôte défaillant immédiatement, mais la restauration dépend toujours de l'autorité et de l'accès. Le premier intervenant peut-il changer une route? Cette personne peut-elle entrer dans l'installation ou donner des instructions à une main à distance? Un second ingénieur est-il disponible pour examiner une commande de stockage destructive? Le fournisseur amont accepte-t-il les demandes urgentes 24h/24? La communication client est-elle assurée par la même personne qui répare le défaut?

Les petites équipes peuvent exploiter des services fiables en réduisant les variations, en automatisant les actions de routine, en documentant les contacts fournisseurs et en achetant un support d'installation solide. Elles peuvent aussi devenir surchargées lorsque plusieurs clients signalent le même incident, car le volume de tickets augmente juste au moment où le travail technique devient le plus urgent. Une première réponse en une heure n'est pas la même chose qu'une restauration en une heure.

Une affirmation de support continu n'a de sens que si elle identifie le canal, l'objectif de réponse, le niveau d'escalade et les activités couvertes.

Le traitement des abus est une autre dépendance de main-d'œuvre pour un réseau d'hébergement. L'enregistrement RIPE publie un contact d'abus, ce qui est une route publique nécessaire pour les signalements. Les adresses d'hébergement attirent des plaintes allant des sites web compromis au scan et aux litiges de droits d'auteur. Un mauvais traitement peut endommager la réputation de l'adresse ou provoquer une suspension amont; un traitement trop agressif peut déconnecter un client innocent. L'opérateur a besoin de suffisamment de personnel et de preuves pour prendre des décisions rapides et proportionnées.

Le support de facturation peut devenir un support opérationnel lorsque l'accès au service est automatisé. Un renouvellement échoué, un drapeau de fraude ou une erreur de fournisseur de paiement peut suspendre un serveur même si chaque composant technique est sain. Les clients doivent savoir si les données restent récupérables après une suspension, combien de temps elles sont conservées, si un appel suspend la suppression, et comment une erreur de facturation urgente est escaladée. Ces politiques sont particulièrement importantes lorsque la capacité publique du fournisseur et la chaîne de propriété ne sont pas bien documentées.

Leprincipe de sécurité opérationnelledu NCSC traite la gestion des vulnérabilités, la surveillance, la réponse aux incidents et la gestion des changements comme des propriétés du service. Ce cadrage est utile ici: les personnes et les décisions font partie du produit hébergé. Les enregistrements réseau publics de Lunar montrent des adresses et des routes, mais aucune preuve publique équivalente n'établit encore les délais de correctifs, la notification d'incident, le préavis de changement ou la profondeur du support.

La migration est la voie de récupération pour les pannes que le fournisseur ne peut pas réparer

Toute évaluation d'hébergement atteint finalement la question de sortie. La redondance essaie de maintenir un service en fonctionnement à l'intérieur du fournisseur. La portabilité permet au client de récupérer lorsque le fournisseur, la relation fournisseur ou l'arrangement commercial lui-même est le composant défaillant.

La portabilité est plus que le téléchargement de fichiers. Un service en fonctionnement peut inclure des disques virtuels, des données d'objet, un état relationnel, des zones DNS, des certificats, des règles de pare-feu, des réseaux privés, des IP assignées, un historique de surveillance, des journaux d'accès, des identifiants d'automatisation et une documentation connue uniquement des personnes qui l'ont construit. Plus ces éléments restent piégés dans un panneau de contrôle propriétaire ou un compte fournisseur inaccessible, plus une migration prend du temps.

Lunar n'a pas publié de spécification d'exportation vérifiable pour l'empreinte de service examinée. On ignore donc si un client peut obtenir une image disque complète, quels formats sont supportés, si les exportations volumineuses entraînent des frais de transfert, à quelle vitesse un compte résilié est effacé, ou si un serveur défaillant peut encore être exporté. On ignore également si les adresses IP des clients sont portables.

Étant donné que les préfixes visibles sont de l'espace agrégable par le fournisseur fourni par d'autres parties, un petit client typique doit supposer que l'IP assignée reste chez le fournisseur sauf indication contraire du contrat.

Cette hypothèse a des conséquences. Déplacer un serveur web vers une nouvelle adresse peut nécessiter des changements DNS, des vérifications de certificats, des mises à jour de pare-feu, des changements de liste blanche et du temps pour l'expiration des caches. Déplacer un service de messagerie peut perturber la réputation de l'expéditeur et le DNS inverse. Déplacer une application dont les partenaires ont codé en dur l'IP peut prendre plus de temps que de déplacer son disque. Un fournisseur peut rendre le calcul portable tandis que l'adresse reste le verrou le plus fort.

La conception de migration la plus sûre commence avant un incident. Les clients peuvent conserver les définitions d'infrastructure en dehors du fournisseur, maintenir des copies indépendantes des clés de chiffrement et de l'accès DNS, exporter régulièrement les données d'application, et tester la restauration sur un deuxième environnement. Ces actions sont des responsabilités du client, pas des substituts à la clarté du fournisseur. Selon lemodèle de responsabilité partagéedu NCSC, les devoirs de sécurité et de disponibilité dépendent du modèle de service et doivent être compris par les deux parties.

Un test de sortie doit être chronométré et complet. La mesure pertinente n'est pas la rapidité avec laquelle un fichier peut être téléchargé, mais combien de temps il faut pour restaurer un service fonctionnel ailleurs avec une perte de données acceptable. Le test doit inclure l'ensemble de données réaliste le plus volumineux, les dépendances telles que DNS et certificats, et une validation par quelqu'un d'autre que la personne qui a conçu le déploiement original. Si cela n'a jamais été fait, la portabilité reste une aspiration.

La défaillance du contrat fournisseur mérite son propre scénario. Si Lunar perd un rack, un fournisseur d'adresses ou un accord de transit, peut-il récupérer les données client et déplacer les services avant la résiliation? Dispose-t-il d'une période de guérison contractuelle? Les clients peuvent-ils contacter l'installation sous-jacente, ou cela violerait-il les frontières de sécurité et commerciales? Les sauvegardes sont-elles détenues sous un compte séparé qui survit au litige avec le fournisseur principal? Les registres publics ne répondent pas à ces questions, mais la structure de ressources en couches les rend pertinentes.

Pour les clients, le chemin de migration est la limite ultime de la dépendance. Un prix mensuel bas peut être rationnel même avec une redondance modeste lorsque la charge de travail est facile à recréer ailleurs. Le même service peut être un mauvais marché pour des données uniques ou un point de terminaison public codé en dur si la sortie prend des semaines. Les preuves actuelles de Lunar ne sont pas assez solides pour évaluer ce risque pour le client; seuls les conditions de service et un test de restauration peuvent le faire.

La souveraineté des données est une carte de contrôle, pas un drapeau sur une IP

L'empreinte Lunar traverse plusieurs signaux administratifs: une société britannique, un bloc étiqueté Allemagne avec un géofeed Falkenstein, un bloc étiqueté Pays-Bas et une destination web sous le domaine de code pays russe. Aucun de ces faits n'identifie à lui seul la juridiction régissant chaque copie des données client.

La souveraineté des données commence par l'emplacement mais s'étend au contrôle. Un disque peut se trouver en Allemagne tandis que le personnel de support dans un autre pays peut ouvrir sa console de gestion. Une sauvegarde peut être copiée vers une seconde région. Les journaux peuvent aller vers un service de surveillance ailleurs. Un fournisseur de facturation peut détenir les données d'identité et de paiement du client dans une autre juridiction. Un revendeur britannique constitué en société peut contracter avec un fournisseur d'infrastructure non britannique.

Chaque relation change quelle organisation peut accéder aux informations et quel processus légal peut les atteindre.

L'ICO fait une distinction utile entre transfert et transit. Les paquets routés via un autre pays ne sont pas nécessairement un transfert restreint si les informations circulent entre organisations britanniques sans y être accédées ou stockées. Rendre les informations personnelles accessibles à une organisation étrangère distincte peut être un transfert même sans copie en masse. C'est pourquoi les traceroutes et la géolocalisation IP ne peuvent pas compléter une évaluation légale. Les contrats et la conception d'accès sont importants.

Le matériel public de Lunar n'identifie pas de chaîne de sous-traitants, de pays de support, d'emplacements de sauvegarde ou de contrôles de résidence sélectionnables par le client. Les étiquettes Allemagne et Pays-Bas sont donc mieux traitées comme des pistes. Un client cherchant un résultat de résidence particulier devrait exiger que le bon de commande nomme l'emplacement choisi, restreigne les déménagements et l'accès à distance, identifie les sous-traitants, décrive la géographie des sauvegardes et fournisse un préavis de changements.

Les mêmes conditions devraient couvrir les métadonnées et les journaux, pas seulement le stockage primaire.

Le chiffrement change l'exposition mais n'efface pas chaque problème de localité. Les clés détenues par le client peuvent réduire la capacité du fournisseur à lire les données stockées, à condition que les instantanés, les journaux et la mémoire soient traités de manière cohérente. Cela ne maintient pas une application disponible pendant une panne d'installation, et cela ne rend pas un transfert non déclaré acceptable en soi. Cela peut aussi rendre la récupération impossible si la garde des clés est mauvaise. L'emplacement, l'accès, le chiffrement et la récupérabilité doivent être analysés ensemble.

L'absence d'IPv6 natif ne détermine pas directement la souveraineté, mais elle illustre le point plus large: la caractéristique du service doit être observée et contractée, non inférée à partir d'une étiquette cloud. De la même manière, un numéro de société britannique ne transforme pas chaque serveur en une région britannique, et un géofeed allemand ne prouve pas une administration exclusivement allemande.

Les clients sans données réglementées ou sensibles peuvent raisonnablement accepter une large flexibilité de localisation en échange du prix ou de la performance. Les clients avec des obligations de résidence légales, contractuelles ou imposées par leurs clients ont besoin d'un niveau de preuve plus élevé. Actuellement, l'empreinte publique de Lunar ne fournit pas cette preuve. Elle fournit cependant assez d'informations pour savoir quelles questions doivent être répondues avant que le service ne soit traité comme local à une juridiction particulière.

Ce qui pourrait améliorer la qualité des preuves

La visibilité de route de Lunar est plus forte que son profil public général. L'entreprise est active, AS198685 est annoncé, deux /24 sont visibles et les deux origines actuelles sont validées sous autorisation d'origine de route. Ces faits justifient de décrire une petite empreinte réseau en direct. Le niveau reste Faible car les preuves n'atteignent pas les couches physiques, contractuelles et de récupération du service.

Plusieurs divulgations amélioreraient matériellement la confiance. En premier lieu, une déclaration de localisation et de propriété qui nomme les pays et les opérateurs d'installation utilisés pour chaque classe de service, tout en distinguant l'équipement possédé des serveurs loués. Elle n'a pas besoin de révéler les numéros de rack ou des diagrammes sensibles à la sécurité. Elle devrait identifier qui contrôle l'alimentation, le refroidissement, les mains à distance et le matériel de remplacement.

En deuxième lieu, une déclaration réseau actuelle. Elle devrait expliquer si AS198685 a un ou plusieurs fournisseurs amont indépendants, si les chemins physiques et les routeurs de bord sont diversifiés, quels préfixes reçoivent une protection anti-DDoS, et si l'IPv6 natif est prévu ou disponible via un autre service. Une entrée publique PeeringDB et des objets de politique RIPE cohérents rendraient la topologie plus facile à vérifier, bien que les routes observées seraient toujours nécessaires.

En troisième lieu, des conditions de disponibilité et de maintenance propres au service. Un document utile définirait ce qui est considéré comme indisponible, le point de mesure, les événements exclus, le préavis pour les travaux planifiés, le traitement de la maintenance d'urgence, les objectifs de réponse du support et le recours. Les crédits seuls ne créent pas de résilience, mais des conditions précises montrent ce que le fournisseur est prêt à mesurer.

En quatrième lieu, des preuves de récupération: périmètre de sauvegarde, isolement, conservation, contrôles client, objectifs de point de récupération et de temps de récupération, et résultats de tests de restauration datés. La version la plus forte séparerait les pannes d'hôte, de rack et de site et indiquerait quels niveaux de service survivent à chacune. Une déclaration selon laquelle des sauvegardes existent, sans résultat de restauration, ne serait qu'une petite amélioration.

En cinquième lieu, des conditions de portabilité. Les clients devraient connaître les formats d'exportation disponibles, les limites et frais de transfert, la conservation après suspension, les délais de suppression, l'accès pendant la résiliation et si les adresses IP peuvent être déplacées. Un exercice de migration documenté vers un autre fournisseur transformerait une promesse de sortie abstraite en preuve opérationnelle.

Enfin, Lunar pourrait publier un bref compte fournisseur et juridiction: l'entité légale contractant avec le client, l'entité exploitant le réseau, les catégories de sous-traitants d'infrastructure et de support, et les pays à partir desquels les données client peuvent être stockées ou accessibles. Cela aiderait les clients à concilier la société britannique avec les étiquettes réseau Allemagne et Pays-Bas.

Aucune de ces demandes ne suppose qu'un fournisseur jeune ou petit est fragile. Les petits opérateurs peuvent offrir un support proche, des produits simples et un bon rapport qualité-prix. Le but est d'aligner l'affirmation avec les preuves. Aujourd'hui, le réseau visible prouve plus qu'une simple inscription mais moins qu'un cloud résilient. La lecture la plus défendable est que LUNAR HOSTING LTD vend de la capacité au sommet d'une chaîne dont les baies, le transit, la main-d'œuvre de réparation et les droits des fournisseurs restent largement en dehors de la vue publique.

La décision d'achat doit suivre la tolérance de la charge de travail à l'incertitude

Pour un serveur de développement facile à reconstruire, un relais temporaire ou un nœud périphérique répliqué, la petite empreinte publique de Lunar peut être un risque acceptable si le prix et l'expérience de service direct sont bons. Le client peut conserver les données faisant autorité ailleurs, automatiser le remplacement et traiter un changement d'adresse comme routinier. Dans ce cas d'usage, les détails publics manquants sont une raison de limiter l'exposition plutôt que de rejeter le service complètement.

Pour la seule copie de données d'entreprise, un système de production sensible à la latence, des informations personnelles réglementées ou un point de terminaison public qui ne peut pas changer rapidement, la même incertitude a un coût différent. Un seul voisin observé, une redondance de site non vérifiée, un stock de pièces de rechange inconnu et un chemin d'exportation non documenté deviennent partie du risque propre du système. Le client aurait besoin de preuves contractuelles directes et de sauvegardes indépendantes avant de se fier au service.

Les questions pertinentes sont concrètes. Quelle entité légale signe la commande? Quelle installation et quel pays contiennent les données primaires et les sauvegardes? Qui possède le serveur? Que se passe-t-il si l'hôte, le rack, la route ou le fournisseur tombe en panne? Quel chemin est vraiment indépendant? À quelle vitesse un ingénieur autorisé peut-il agir? Quel état exact peut être exporté? Combien de temps les données sont-elles conservées après suspension? Quand une restauration complète a-t-elle été effectuée pour la dernière fois et combien de temps a-t-elle pris?

Les réponses doivent être cohérentes avec le dossier public. Si un service est vendu comme localisé en Allemagne, la déclaration d'installation et de sauvegarde devrait être alignée avec le géofeed Falkenstein ou expliquer pourquoi elle ne l'est pas. Si le fournisseur revendique un transit diversifié, les observations de route actuelles devraient éventuellement montrer plus d'un voisin viable ou le fournisseur devrait expliquer la conception de veille. Si une affirmation de disponibilité dépend de multiples sites, l'architecture de service devrait identifier les domaines de panne et le comportement de réplication.

Les clients devraient également surveiller les changements. La société actuelle et l'ASN n'ont que quelques mois. Les origines d'adresses, les voisins, les destinations web et les relations fournisseurs ont déjà changé sur une courte période. Cela peut refléter une construction normale d'un jeune réseau. Cela signifie aussi qu'une évaluation faite une fois vieillira rapidement. La visibilité des routes, les autorisations, les conditions de service et la capacité d'exportation devraient être revérifiées au renouvellement et après tout déménagement annoncé.

Le jugement final est délibérément limité. LUNAR HOSTING LTD a suffisamment de preuves actuelles pour être traitée comme plus qu'une société de papier: son système autonome annonce de l'espace d'adressage globalement visible, les origines sont autorisées et des mesures secondaires voient une activité de type hébergement. Elle n'a pas encore assez de preuves publiques pour traiter la capacité offerte comme multisite, connectée indépendamment ou démontrablement récupérable.

Cet écart est le centre de l'histoire. La capacité hébergée semble abstraite seulement tant que chaque dépendance fonctionne. Une panne de rack la rend matérielle. Un retrait de route la rend transit. Un disque défaillant la rend stock de pièces. Un incident sans réponse la rend main-d'œuvre. Une résiliation de contrat fournisseur la rend droit des contrats. Une exportation non testée la rend verrouillage client. Le réseau public de Lunar est visible; la résilience derrière lui n'est pas encore assez visible.