Résumé

  • Le catalogue commercial d'almazcloud.network promet une interconnexion physique directe avec Yandex, Sberbank et Rostelecom dès 499 dollars par mois et par port 10G (couverture antérieure de BTW), tandis que les collecteurs de routage décrivent un réseau de trois préfixes /24 origines, deux annoncés, 512 adresses IPv4, sans aucun pair observé (IPregistry).
  • Aucune source publique récupérée ne montre le site web, l'autorité DNS ou le service de messagerie d'almazcloud.network fonctionnant sur l'espace d'adresses d'AS210328 ; aucune ne montre non plus d'hébergement tiers vérifiable. La question de l'auto-cohérence opérationnelle reste ouverte — et l'absence de trace est elle-même un signal.
  • L'espace d'adresses annoncé est enregistré au nom de tiers : 77.91.65.0/24 à IP-FI/Foton Telecom, 185.136.15.0/24 et 185.218.138.0/24 à Vlad Cojuhari, selon les miroirs du registre (IPregistry, IPIP.NET).
  • L'ancrage sociétaire cité dans l'objet RIPE (OGRN 1196501003357) correspond, selon l'agrégateur audit-it.ru, à une microentreprise d'aquaculture marine de Sakhalin à deux employés et sans chiffre d'affaires en 2025 — un profil difficilement compatible avec un opérateur revendiquant 10-20 Gbps et trois sites moscovites.
  • L'état RPKI est lui-même partiel : deux ROA valides couvrent 77.91.65.0/24 et 185.136.15.0/24, tandis que 185.218.138.0/24 est NOT-FOUND pour cet origine (IPregistry).

Un réseau qui vend de la connectivité devrait, en principe, être visible sur le réseau qu'il vend. C'est le test le plus simple de l'auto-cohérence opérationnelle : l'opérateur d'un service d'interconnexion utilise-t-il lui-même l'infrastructure qu'il commercialise ? Pour AS210328, la réponse mesurable est qu'on ne peut pas le démontrer — et que tout ce qu'on peut observer penche dans l'autre sens.

Ce que le catalogue promet

Le site de l'opérateur se présente comme « DIAMOND (en russe ALMAZ) », un « tout nouveau fournisseur progressif de services cloud », et liste cinq gammes de produits tarifiés : CLOUD CONNECT à partir de 499 dollars par mois et par port physique 10G, décrit comme une « connexion physique de peering directe vers Yandex, Sberbank, ROSTELECOM et certains autres fournisseurs cloud bien connus » ; BGP ANNOUNCEMENTS à partir de 99 dollars par mois par préfixe annoncé ; NO-BGP GRE TUNNEL à partir de 99 dollars par mois par tranche de 100 Mbps ; CORPORATE CLOUD VPN à partir de 9 dollars par mois et par utilisateur ; et CLOUD RESELLING à partir de 99 dollars par mois par cloud connecté (couverture antérieure de BTW). Des boîtes mail de contact sont publiées, dont une adresse générale et des adresses d'abuse pour le domaine.

Il s'agit donc d'une proposition de revente : vendre de l'annonce BGP, des tunnels et un accès prétendument direct aux plus grands réseaux russes. Rien dans les extraits récupérés du site ne décrit de capacité de calcul propre, de liste de sites, de références clients ou de document SLA.

Ce que la table de routage mesure

Les collecteurs indépendants s'accordent sur un portrait très différent. Hurricane Electric recense trois préfixes /24 d'origine IPv4 (77.91.65.0/24, 185.136.15.0/24, 185.218.138.0/24), dont deux annoncés et deux couverts par des ROA RPKI valides, 512 adresses IPv4 d'origine, aucune IPv6, et trois voisins observés — AS202425, AS201814 et AS48693 — tous de type transit (IPregistry). ping.pe confirme les trois préfixes et le statut RPKI VALID, VALID, NOT-FOUND (IPregistry). La console rpki-client confirme que seuls deux ROA existent sous AS210328, et aucun pour 185.218.138.0/24 (IPregistry).

Le voisinage compte zéro pair et zéro client en aval : AS210328 achète du transit et n'en vend à personne d'observable. Pour un opérateur dont le produit phare est le « peering direct », c'est une contradiction mesurable : un réseau sans pairs observés ne peut pas, par définition, fournir une session de peering directe à Yandex, Sberbank ou Rostelecom depuis ses propres préfixes.

Un espace d'adresses qui n'appartient pas au vendeur

Les descriptions de préfixes dans les collecteurs et les miroirs du registre attribuent l'espace annoncé à des tiers : 77.91.65.0/24 est décrit comme IP-FI/Foton Telecom, 185.136.15.0/24 comme Vlad Cojuhari — un miroir le décrit comme « Telepatiya Ltd », une entité liée au Kazakhstan (IPIP.NET) — et 185.218.138.0/24 également à Vlad Cojuhari (IPregistry). L'objet RIPE lui-même est sans ambiguïté sur le cadre administratif : aut-num AS210328, as-name ALMAZ, organisation ORG-ZA238-RIPE (AO ALMAZ, RU, reg-nr 1196501003357), sponsoring-org ORG-DNJ1-RIPE, créée le 21 décembre 2021 et modifiée pour la dernière fois le 21 août 2026, avec une politique d'import/export limitée à AS48693 (IPIP.NET, IP2Location).

Acheter de l'espace d'adresses enregistré au nom de tiers et le revendre sous forme d'annonces BGP est une activité connue — mais c'est précisément l'activité d'un courtier, pas celle d'un opérateur d'infrastructure. Le catalogue lui-même le confirme : BGP ANNOUNCEMENTS est un produit de revente d'annonces, pas un produit de capacité.

L'ancrage sociétaire : une microentreprise d'aquaculture

L'agrégateur de registres sociétaires russes audit-it.ru associe le numéro OGRN 1196501003357 — celui cité comme reg-nr dans l'objet RIPE ORG-ZA238-RIPE — à la société AO « ALMAZ » de Ioujno-Sakhalinsk, dans l'oblast de Sakhalin, immatriculée le 6 mai 2019, dont l'activité principale est l'aquaculture marine (code OKVED 03.21), dirigée par Khan Marina Menkhoevna, avec un effectif moyen de deux employés en 2024 et 2025, aucun chiffre d'affaires en 2025 (14,6 millions de RUB en 2024), une perte nette de 883 000 RUB en 2025 et le statut de microentreprise au régime simplifié (selon l'agrégateur audit-it.ru).

Il faut être précis sur ce que cette source prouve et ne prouve pas : il s'agit d'un agrégateur, pas d'un extrait EGRUL primaire, et la correspondance entre le numéro cité dans le RIPE et cette entité pourrait être un artefact. Mais si la correspondance est correcte, l'ancrage juridique d'un réseau prétendant 10-20 Gbps de trafic et trois points de présence à Moscou serait une ferme piscicole de deux personnes à 6 000 kilomètres des sites revendiqués.

L'auto-référence manquante

Le test le plus direct de l'auto-cohérence consiste à vérifier si l'opérateur consomme son propre produit : le site web, les serveurs DNS et les boîtes mail publiées sur almazcloud.network devraient, idéalement, être servis depuis l'espace d'adresses d'AS210328. Aucune source récupérée dans cette enquête ne le montre. Aucune ne montre non plus d'hébergement tiers identifiable : les couches DNS, messagerie et certificats n'ont pas pu être vérifiées directement dans cette passe, et cette limite est explicite. Ce que l'on peut affirmer, c'est que rien dans l'ensemble d'évidence — site de l'opérateur, PeeringDB, registre, collecteurs de routage, validateurs RPKI — ne place les services publiés de l'opérateur sur le réseau qu'il vend (BTW, IP2Location).

La fiche PeeringDB 19111, maintenue par l'opérateur lui-même, illustre le problème inverse : elle revendique un trafic de 10-20 Gbps, trois installations moscovites (Berzarina Data Center, IXcellerate MOS1, Moscow M9) et une portée régionale — mais elle déclare zéro préfixe IPv4 et zéro préfixe IPv6, en contradiction directe avec les trois /24 observés, et ses champs substantiels datent du 27 juillet 2022 (BTW). Une fiche auto-déclarée qui se contredit elle-même sur le point le plus vérifiable de tous — le nombre de préfixes — ne peut pas servir de preuve de capacité.

Ce qu'un acheteur peut vérifier

Pour un acheteur de connectivité ou de calcul à bas coût — y compris des charges de travail d'IA sensibles au prix — la liste de vérification se déduit directement de ce cas : demander les numéros de préfixes et vérifier l'origine réelle dans plusieurs collecteurs ; vérifier les ROA RPKI par préfixe ; comparer les descriptions d'enregistrement des préfixes avec le nom du vendeur ; demander une session de test réelle vers les réseaux prétendument interconnectés ; et chercher la trace de l'opérateur lui-même sur son propre réseau. Chacun de ces tests, appliqué à AS210328, produit un résultat défavorable ou indéterminé.

La conclusion n'est pas qu'aucun service ne peut être livré — un tunnel GRE et une annonce BGP peuvent techniquement fonctionner depuis n'importe quel petit réseau. La conclusion est que le produit vendu n'est pas mesurable par les moyens publics dont dispose un acheteur, et que la seule chose que la table de routage certifie est sa petitesse.