Résumé

  • L'objet RIPE ORG-ZA238-RIPE, titulaire de l'AS210328 commercialisé sous la marque « DIAMOND » via almazcloud.network, publie le numéro d'enregistrement russe 1196501003357 ; les agrégateurs de registre du commerce relient ce numéro à une AO ALMAZ de Sakhaline spécialisée en pisciculture marine, non à un opérateur de cloud moscovite.
  • Les collecteurs de routage indépendants n'observent aucun peering direct avec Yandex, Sberbank ou Rostelecom — seulement trois fournisseurs de transit et aucun pair ou client observé — ce qui contredit directement l'offre commerciale du site de l'opérateur.
  • Le préfixe 185.218.138.0/24 est annoncé par trois AS distincts sans ROA couvrant l'AS210328, une dispute multi-origine documentée par des observateurs tiers.
  • La marche à suivre pour un acheteur : vérifier l'entité juridique derrière le reg-nr avant tout paiement, exiger un ROA couvrant tout préfixe annoncé, et traiter les chiffres de trafic auto-déclarés comme des déclarations, non des mesures.

Une chaîne d'identité qui s'arrête au mauvais endroit

Toute relation commerciale en routage repose sur une chaîne d'identité : un nom de domaine, un objet RIPE, un numéro d'enregistrement d'entreprise, une personne physique responsable. Pour l'AS210328, cette chaîne existe sur le papier mais ne se referme pas. L'objet organisation ORG-ZA238-RIPE, reflété par des miroirs indépendants de la base RIPE, se nomme AO ALMAZ, pays RU, avec reg-nr 1196501003357 (IPIP.net). Le numéro d'enregistrement est précisément ce qui devrait permettre de relier l'objet registre à une personne morale réelle.

Or les agrégateurs du registre russe consultés pour ce reportage décrivent l'entité portant l'INN/OGRN 1196501003357 comme une AO ALMAZ basée à Ioujno-Sakhalinsk, active dans la pisciculture marine, avec environ deux salariés, une directrice dénommée Khan Marina Menkhoevna et un chiffre d'affaires d'environ 14,6 millions de roubles en 2024 (audit-it.ru; dela.pravo.tech). Ce profil ne correspond pas à l'opérateur de « cloud » moscovite vendu sous la marque DIAMOND sur almazcloud.network (site de l'opérateur).

La frontière de la preuve doit être dite clairement : ce rapprochement repose sur des agrégateurs tiers et n'a pas pu être confirmé auprès des registres étatiques EGRUL/FNS primaires. Deux explications restent ouvertes — une erreur de saisie dans l'objet RIPE, ou un objet organisation relié à la mauvaise entité. Dans les deux cas, le contrôle défaillant est le même : aucun mécanisme systématique n'oblige un opérateur à prouver que le reg-nr qu'il publie correspond réellement à l'entreprise qui exploite le réseau.

Ce que les observateurs indépendants voient — et ne voient pas

Le site de l'opérateur propose cinq produits tarifés, dont des « BGP Announcements » à partir de 99 dollars par mois et par préfixe et un « Cloud Connect » à 499 dollars par port 10G, en revendiquant un peering physique direct avec Yandex, Sberbank et Rostelecom (site de l'opérateur). Les collecteurs de routage racontent une autre histoire. Hurricane Electric observe trois préfixes IPv4 d'origine (77.91.65.0/24, 185.136.15.0/24, 185.218.138.0/24), dont deux validés RPKI, exactement trois relations amont (AS202425 IPV, AS201814 MEVSPACE, AS48693 Rices) et aucun pair ni client observé (bgp.he.net). Un agrégateur commercial, mis à jour le 21 août 2026, indique que l'AS210328 n'a aucun accord de peering direct et ne dessert aucun réseau aval (IPregistry). Aucune adjacence vers Yandex, Sberbank ou Rostelecom n'apparaît dans les observations.

La dispute multi-origine sur 185.218.138.0/24

Le préfixe 185.218.138.0/24 est annoncé par trois AS distincts — AS209630 (LLC VASH KREDIT BANK), AS205997 (Vlad Cojuhari) et AS210328 (AO ALMAZ) — alors que son enregistrement est attribué à Vlad Cojuhari, partie distincte de l'opérateur de l'AS210328 (bgp.he.net). La console de validation rpki-client montre exactement deux ROA pour l'AS210328, couvrant 77.91.65.0/24 et 185.136.15.0/24, et aucun pour 185.218.138.0/24, marqué NOT-FOUND par ping.pe (console rpki-client AS210328; ping.pe). Notamment, l'AS205997 détient également un ROA sur 185.136.15.0/24, un préfixe que l'AS210328 couvre aussi — le chevauchement porte donc sur deux des trois préfixes de l'opérateur (console rpki-client AS205997).

Les miroirs publics divergent sur l'état présent du réseau : IPinfo classe l'AS210328 comme inactif, sans adresses et sans pairs, avec une fiche non rafraîchie depuis décembre 2021 (IPinfo), tandis que d'autres agrégateurs reproduisent des instantanés de 2021 à deux préfixes (TheIpAPI; IPtrace; Robtex). Cette divergence est elle-même un signal : la réputation d'un ASN se construit souvent sur des miroirs périmés, et un acheteur qui ne consulte que l'un d'eux peut croire qu'il achète un réseau — ou l'inverse — sur la base de données vieilles de quatre ans.

Ce que la fiche PeeringDB prouve et ne prouve pas

PeeringDB porte indépendamment la même identité — organisation AO ALMAZ, « ALMAZ (DIAMOND) CLOUD NETWORK », site almazcloud.network — mais sa fiche 19111 est matériellement périmée (champs substantiels mis à jour le 27 juillet 2022) et affiche zéro préfixe, avec un trafic auto-déclaré de 10 à 20 Gbit/s (PeeringDB). Les installations listées existent, dont le Berzarina Data Center opéré par Selectel à Moscou (PeeringDB fac 9865); cela prouve que les identifiants d'installations ne sont pas inventés, pas que le réseau y est présent ni qu'il y peer.

Le remède praticable

Pour un acheteur, la vérification est à portée de main. D'abord, résoudre le reg-nr publié dans l'objet RIPE et comparer l'entité obtenue à l'activité annoncée — ici, une pisciculture de Sakhaline contre un cloud moscovite aurait dû arrêter la transaction. Ensuite, exiger un ROA couvrant chaque préfixe annoncé, et refuser tout préfixe sans couverture ou en dispute multi-origine. Enfin, exiger une preuve de peering datée et vérifiable — un accord, une entrée IXP, une mesure — plutôt qu'un chiffre de trafic auto-déclaré. Le rôle ZAN42-RIPE publie un contact d'abus avec une mention indiquant ne répondre qu'en russe (IPGeolocation.io), ce qui borne déjà l'engagement réciproque attendu.

Pour le système des registres, la question est structurelle : le reg-nr est un champ libre, jamais recoupé. Tant qu'aucun recoupement automatisé n'existe, le nom d'entreprise dans un objet RIPE reste une déclaration, pas une vérification.

Sources