02 Emre Erim exerçant sous le nom Medyabim centres de données doit prouver si la capacité commercialisée de son centre de données peut survivre aux contraintes d'alimentation et de connectivité

Résumé

• Les registres publics de RIPE confèrent à Medyabim une identité juridique et réseau cohérente.Le registre RDAP de RIPE pour AS44922nomme MEDYABIM-AS, liste Emre Erim comme contact administratif et technique, et inclut ORG-MIH2-RIPE avec le nom « Emre Erim trading as Medyabim centres de données »;le registre d'organisation de RIPEaffiche le pays TR, le statut LIR, une adresse à Bursa et des coordonnées.
• La surface de routage actuelle est réelle mais étroite.L'aperçu AS de RIPEstatmarque AS44922 comme annoncé, tandis quele statut de routagemontrait un préfixe IPv4, aucun préfixe IPv6, 256 adresses IPv4 et un voisin observé à l'instantané vérifié.La vue des préfixes annoncéslistait seulement 37.247.116.0/24 comme actuel.
• Le contrôle positif le plus fort est la sécurité de l'origine de la route pour le /24 actuel.La validation RPKI de RIPEstat pour 37.247.116.0/24 via AS44922a retourné valide, avec une ROA autorisant AS44922 et une longueur maximale /24.
• Les propres pages de Medyabim commercialisent une empreinte opérationnelle plus large que ne le prouve la surface de routage actuelle d'AS44922.La page du centre de donnéesdéclare du matériel dédié prêt dans les racks Medyabim, une longue expérience avec les serveurs Linux DirectAdmin, des options de serveur en Turquie et à l'étranger, une capacité totale de sortie de 50 Gbit/s, des chemins de fournisseurs nommés tels que Turk Telekom et Superonline, et une surveillance du trafic client.La page de colocationdéclare une continuité de service à 99 % avec bande passante, support 24/7, placement derrière un pare-feu, un port de redémarrage gratuit et cinq adresses IP.
• Les assurances publiques restent incomplètes. Les pages officielles ne publient pas d'alimentations doubles, de durée de fonctionnement du générateur, de topologie de refroidissement, de suppression d'incendie, de salles de réunion opérateur, de fenêtres de maintenance, de résultats de basculement mesurés, de certification des installations ou de profil PeeringDB actuel. Le domaine de Medyabim résout en 185.7.83.213, tandis que RIPEstat montre que 185.7.83.0/24 est actuellement annoncé par DATAFOREST plutôt que par AS44922, de sorte que les cartes de dépendance côté client doivent séparer la marque Medyabim, sa frontière AS44922, l'espace d'adressage alloué et les surfaces de service annoncées par des tiers.

La question utile n'est pas de savoir si Medyabim existe

Il existe une catégorie de profils d'hébergement régionaux où le premier devoir est de prouver que l'entreprise est plus qu'une ligne dans un annuaire. Medyabim n'est pas si faible. Le registre public contient une personne physique nommée, un nom commercial, un enregistrement d'organisation RIPE, un système autonome, des ressources d'adressage allouées, des pages de service officielles, une adresse de contact à Bursa et des offres de produits fonctionnelles.

Le problème est différent: le registre public prouve l'identité et un bord de routage limité, tandis que le langage marketing de l'entreprise demande aux clients de croire en une histoire de capacité de centre de données plus large.

La source d'identité la plus solide est RIPE.L'enregistrement RDAP pour AS44922nomme le système autonome MEDYABIM-AS et liste l'organisation « Emre Erim trading as Medyabim centres de données ». Il liste également Emre Erim comme contact administratif et technique, avec une adresse à Bursa et un numéro de téléphone.L'enregistrement REST d'organisation RIPE pour ORG-MIH2-RIPEporte le même nom commercial, le pays TR, le type LIR, l'adresse de Bursa, le téléphone, le fax, les références de mainteneur Medyabim et une date de création en mars 2008. C'est beaucoup plus solide qu'une entrée d'annuaire d'hébergement extraite du web.

La proprepage de contactde Medyabim ancre indépendamment l'adresse opérationnelle publique. Elle décrit « Medyabim centres de données ve Internet Hizmetleri » et donne Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa, avec des numéros de téléphone et l'adresse e-mail publiquebilgi@medyabim.com.tr. Cette adresse correspond étroitement à l'adresse RIPE. Cela importe car l'entité n'est pas présentée comme une étiquette de cloud sans visage. Ses preuves publiques pointent vers un opérateur basé à Bursa dont les enregistrements de ressources réseau et le site web commercial sont au moins mutuellement cohérents.

La page d'histoire de l'entreprise ajoute une auto-description. Lapage à proposde Medyabim dit que l'entreprise opère depuis 2000 autour des services Internet, des produits logiciels et des systèmes clé en main basés sur Linux; dit qu'elle s'est ensuite concentrée sur l'enregistrement de domaines, l'hébergement web, les serveurs dédiés, la gestion de serveurs et le conseil; et dit qu'à partir de 2006, elle a construit un centre de données à Bursa, avec ses propres ressources, avec une capacité de plus de 500 serveurs pour ses propres serveurs et ceux des sociétés d'hébergement web. Ce n'est pas une preuve indépendante de racks installés ou de capacité électrique, mais c'est une affirmation opérationnelle spécifique et vérifiable.

La question n'est donc pas « y a-t-il un Medyabim? ». La question est « sur quelles parties de la capacité commercialisée par Medyabim un client peut-il compter lorsque l'alimentation, le refroidissement, le routage, le support ou la dépendance en amont défaillent? ». Pour un acheteur de centre de données ou de colocation, l'identité n'est que la première porte. Le test le plus difficile est la capacité récupérable: le matériel, l'alimentation des racks, le refroidissement, la fibre, le routage et les processus humains qui restent disponibles lors d'une panne.

AS44922 est visible, mais sa surface de route publique actuelle est petite

RIPEstat confirme qu'AS44922 est annoncé.Le point de terminaison d'aperçu ASétiquette le détenteur « MEDYABIM-AS Emre Erim trading as Medyabim centres de données » et marque la ressource comme annoncée à l'instantané vérifié. C'est la conclusion réseau positive. Medyabim a un bord de système autonome public que le système de routage peut voir.

L'échelle de ce bord est modeste.Le point de terminaison du statut de routagede RIPEstat montrait un préfixe IPv4, 256 adresses IPv4, zéro préfixe IPv6 et un voisin observé.Le point de terminaison des préfixes annoncéslistait 37.247.116.0/24 comme annonce actuelle d'AS44922.Le point de terminaison des voisins ASNmontrait un seul voisin gauche observé, AS16276.L'aperçu AS de RIPEstat pour AS16276identifie ce voisin comme OVH SAS.

Cela ne signifie pas que Medyabim a seulement 256 clients, un seul rack ou un seul service. Le BGP public ne voit pas les VLAN privés, le stock de revendeurs, l'hébergement fourni par des adresses de fournisseur, l'inventaire des serveurs, les interconnexions clients ou les surfaces web externalisées. Mais cela signifie que le bord visible d'AS44922 n'est pas un backbone public large, multi-préfixe et multi-voisin au moment de la vérification. Si un acheteur évalue Medyabim comme une dépendance de centre de données, la carte BGP publique seule ne prouve pas une résilience multi-opérateur.

La vue de cohérence de routage AS de RIPEstatrend l'écart plus net. Elle listait 37.247.116.0/24 comme présent à la fois dans BGP et dans le whois/IRR de RIPE. Elle listait également 37.247.117.0/24 et 2a03:400::/32 comme présents dans le whois/IRR mais pas dans BGP au moment de la vérification. La même vue de cohérence montrait d'anciens pairs d'import/export whois AS9121 et AS53667 non vus dans BGP, tandis qu'AS16276 était vu dans BGP mais pas dans la politique d'import/export whois. C'est un type de dérive normal dans les enregistrements de routage plus anciens, mais c'est exactement pourquoi un client devrait demander des diagrammes actuels au lieu de se fier au texte de politique de registre historique.

Le contrôle positif est RPKI. La route actuelle d'AS44922, 37.247.116.0/24, a passéla vérification de validation RPKI de RIPEstatcomme valide. Cela importe car l'autorisation d'origine de route est l'un des rares contrôles publics qu'un acheteur d'hébergement peut vérifier sans voir de documents d'installation privés. Une ROA valide ne prouve pas l'alimentation, le refroidissement ou le basculement. Cela montre que l'origine AS44922 visible actuelle n'est pas laissée comme une revendication d'origine de route inconnue dans la couche de validation publique.

La conclusion de route est donc étroite et utile. AS44922 est réel. Sa route IPv4 visible actuelle est valide RPKI. Sa surface amont observée est mince. Ses preuves IPv6 ne sont pas actuellement annoncées. Ses enregistrements de politique de routage publics sont des preuves publiques limitées pour prouver la diversité des opérateurs ou le basculement. Un client ne devrait pas traiter cela comme un réseau fantôme, ni comme un réseau de centre de données résilient prouvé.

IPv6 et les preuves de préfixes dormants nécessitent une dégradation

Medyabim a des preuves de registre IPv6. L'enregistrement de recherche RIPE pour2a03:400::/32montre une allocation 2a03:400::/29 sous TR-MEDYABIM-20110107 et une entrée route6 pour 2a03:400::/32 avec origine AS44922. Cela semble solide jusqu'à ce qu'on le compare à la visibilité de routage actuelle.

Le point de terminaison d'aperçu de préfixe de RIPEstat pour 2a03:400::/32marquait le préfixe comme non annoncé au moment de la vérification.La vue du statut de routagesignalait aucune origine actuelle, zéro pair RIS le voyant, et un dernier événement vu pour AS44922 le 1er avril 2026. Ce n'est pas en soi une conclusion d'échec. Certains clients peuvent ne pas acheter de service IPv6; certains opérateurs peuvent avoir des plans IPv6 dormants; certains blocs d'adresses sont détenus pour une utilisation ultérieure. Mais cela change ce qui peut être prouvé publiquement. Un fournisseur de centre de données dont les pages officielles actuelles commercialisent des services d'hébergement et de serveur mais dont le bord AS visible n'a actuellement aucune annonce IPv6 devrait être interrogé sur le support IPv6, son indisponibilité, sa disponibilité sélective ou sa fourniture via un autre fournisseur.

Le tableau des préfixes IPv4 dormants est également mitigé. Le résultat de recherche RIPE pour37.247.117.0/24montre NET-MEDYABIM-DC5 et une entrée de route RIPE avec origine AS44922 créée en juin 2025. Pourtant, la vérification de cohérence RIPEstat ne l'a pas vue dans le BGP actuel. Cela pourrait représenter une capacité réservée, une migration planifiée, une route récemment retirée, une plage de sauvegarde ou simplement un espace d'adressage inutilisé. Les preuves publiques ne peuvent pas choisir parmi ces explications.

La distinction importante est entre capacité allouée et capacité opérationnelle. Une allocation RIPE, une entrée de route ou une assignation d'adresse peut montrer un contrôle administratif ou une préparation. Cela ne prouve pas que la plage d'adresses dessert des clients aujourd'hui, est accessible via plusieurs opérateurs, ou peut être activée lors d'une panne.

Un acheteur qui a besoin de capacité récupérable devrait demander à Medyabim quels préfixes sont en production, lesquels sont réservés, lesquels sont migrés vers d'autres origines, lesquels sont orientés client, lesquels sont réservés à la gestion, et lesquels sont couverts par des processus DDoS, pare-feu et RPKI testés.

Les propres pages de service de Medyabim sont concrètes, mais elles ne publient pas la résilience des installations

Lapage du centre de donnéesde Medyabim est plus détaillée qu'une page d'accueil d'hébergement générique. Elle indique que les modèles de serveurs dédiés sont livrés après validation du paiement et que le matériel est prêt dans les racks Medyabim. Elle dit que Medyabim a plus de 15 ans d'expérience avec les serveurs dédiés Linux et utilise activement DirectAdmin depuis 2003. Elle dit que l'entreprise sert avec son propre matériel serveur basé en Turquie, tandis que les services de serveurs dédiés peuvent être choisis en Turquie ou à l'étranger selon la demande. Elle décrit également une « capacité de ligne élevée » et une haute disponibilité comme raison d'offrir rapidement du matériel serveur réel.

La même page fait une grande déclaration de connectivité. Elle dit que les principales connexions Internet du centre de données ont été choisies pour fournir un accès rapide depuis la Turquie et le monde, nomme Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent Communications, AMS-IX et ECIX Duesseldorf, et déclare une capacité totale de sortie de ligne de 50 000 Mbit, soit 50 Gbit/s. Elle dit que les clients de serveurs dédiés peuvent entrer dans un panneau de gestion réseau pour surveiller leur propre trafic 24/7 et dit que le centre de données utilise du matériel réseau Foundry Networks et HP Procurve.

Ce sont des preuves utiles, mais elles doivent être lues comme un texte marketing et opérationnel publié par l'entreprise, pas comme un audit d'opérateur en direct. La page ne divulgue pas lesquels des fournisseurs nommés sont des transporteurs physiques actuels, lesquels sont des fournisseurs de transit, lesquels sont des relations de peering ou de route, lesquels sont des options de transit historiques, lesquels soutiennent les services turcs, et lesquels soutiennent le placement à l'étranger. Elle ne montre pas de salle de réunion d'installation, d'entrée de fibre diversifiée, de carte d'interconnexion ou d'inventaire de ports en direct.

Le BGP public au moment de la vérification montrait un voisin AS44922 observé, pas une carte visible publiquement de chaque nom de fournisseur sur la page.

La page est encore plus mince sur l'ingénierie des installations. Elle ne publie pas d'alimentations doubles, de capacité UPS, de durée de batterie, de durée de carburant du générateur, de redondance de refroidissement, de classe de suppression d'incendie, de charge au sol, de densité de rack, de couches de sécurité physique, de règles de fenêtre de maintenance ou d'exercices de reprise après sinistre. Ces omissions ne prouvent pas que les contrôles n'existent pas. De nombreux petits fournisseurs ne publient pas ces détails.

Mais un client évaluant la résilience d'un centre de données ne devrait pas supposer ces contrôles à partir du mot « centre de données ».

Lapage de colocationde Medyabim ajoute des affirmations opérationnelles orientées client. Elle dit que Medyabim offre une garantie de disponibilité ou de continuité de service de 99 % avec bande passante pour son service de colocation; dit que les entreprises avec des serveurs dans le centre de données Medyabim peuvent recevoir un support entreprise 24/7; dit que les statistiques de trafic peuvent être observées en ligne; dit que les serveurs sont derrière un pare-feu; dit qu'un port de redémarrage gratuit sera attribué; dit que la connexion attribuée est dédiée et non limitée; et dit que cinq adresses IP sont attribuées gratuitement pour les serveurs dans le centre de données.

Ce sont de véritables affirmations de service, et elles spécifient les questions que les acheteurs devraient poser avant de se fier au service. Une promesse de continuité de service à 99 % n'est pas la même chose qu'un SLA de haute disponibilité moderne, et 99 % peut encore permettre une quantité significative de temps d'arrêt sur un an. Un port de redémarrage n'est utile que si la distribution d'alimentation, l'accès à distance, les identifiants de console et les procédures de support survivent à l'incident. Le placement du pare-feu peut protéger les clients, mais il peut aussi devenir un goulot d'étranglement partagé.

Cinq adresses IP peuvent suffire pour un hébergement simple, mais cela ne dit rien sur la portabilité du sous-réseau routé ou le basculement. La page donne aux clients des éléments à demander, pas une preuve complète de résilience.

Le site officiel prouve l'étendue de l'offre, pas la capacité récupérable

L'étendue de l'offre publique est large.La page des packs d'hébergement webde Medyabim fait la publicité de packs d'hébergement avec espace web, trafic, FTP, MySQL, webmail, DirectAdmin, SSL optionnel, produits de sauvegarde e-mail, un service IP supplémentaire par serveur, un service de sauvegarde de serveur de 300 Go, transfert FTP 24/7 illimité, sauvegardes automatiques hebdomadaires et mensuelles, statistiques avancées, filtrage anti-spam et un rapport de transfert. Sapage revendeurpropose des packs revendeur avec espace web, quotas e-mail POP3, trafic mensuel, bases de données MySQL, panneau de contrôle turc, webmail, contrôle DNS optionnel, options SSL, filtres anti-spam et rapports de trafic.

La page VDSexplique les serveurs dédiés virtuels comme des serveurs logiquement séparés sur du matériel physique et liste les fonctionnalités des packs VDS.La page d'information du panneau de contrôledit que DirectAdmin est installé sur les serveurs lorsque le serveur est dans le DC Medyabim, décrit une gestion proactive des serveurs, une configuration de sécurité et une surveillance des listes noires de spam, et dit que PHP, MySQL, Linux, ionCube et DirectAdmin sont installés et configurés sur tous les serveurs.

Pris ensemble, ces pages montrent que Medyabim vend une pile classique de petit fournisseur: domaines, hébergement partagé, hébergement revendeur, VDS, serveurs dédiés, colocation, stockage e-mail, SSL, sauvegarde et support géré Linux/DirectAdmin. Ce mélange crée deux types de dépendances. L'une est physique: racks, alimentation, refroidissement, liaisons montantes, pare-feu, ports de redémarrage, serveurs de rechange et accès technicien. L'autre est administrative: portail client, facturation, statut du compte, tickets de support, contrôle des domaines, DNS, e-mail et processus de sauvegarde.

L'offre publique ne dit pas à l'acheteur quelles dépendances sont dans le même domaine de panne. Un client pourrait acheter un pack d'hébergement web dont le site web, l'e-mail, les sauvegardes, le DNS et l'accès aux tickets dépendent tous des mêmes systèmes du fournisseur. Un revendeur pourrait dépendre du panneau de contrôle et des systèmes e-mail de Medyabim même si les clients finaux ne voient que la marque du revendeur.

Un acheteur de serveur dédié pourrait avoir un redémarrage à distance mais aurait toujours besoin d'un technicien si la machine ne démarre pas, si un contrôleur de disque tombe en panne, ou si la politique du pare-feu bloque l'accès de récupération. Un client de colocation pourrait posséder le serveur mais dépendre toujours du bâtiment, de l'alimentation, de la liaison montante, du pare-feu et de la réponse du support de Medyabim.

C'est pourquoi la capacité installée ne suffit pas. L'affirmation de la page à propos de plus de 500 serveurs et la déclaration de la page du centre de données d'une capacité de sortie de 50 Gbit/s décrivent une échelle possible. La capacité récupérable demande ce qui se passe après qu'une alimentation, un chemin UPS, un commutateur, un pare-feu, une liaison montante, un chemin d'authentification ou un canal de support disparaît. Les pages publiques ne répondent pas à cela.

La propre surface DNS de Medyabim pointe en dehors d'AS44922

L'un des contrôles les plus révélateurs est le propre domaine de Medyabim. Une requête DNS publique pour medyabim.com.tr a montré que l'apex et le nom www résolvent en 185.7.83.213, que mail.medyabim.com.tr résout également en 185.7.83.213, que les serveurs de noms sont ns1.medyabim.com et ns2.medyabim.com, et qu'un enregistrement SPF référence 37.247.112.0/24 et 185.7.83.0/24. Ces faits DNS doivent être traités comme des preuves adjacentes aux opérations car ils montrent comment Medyabim présente sa propre surface de service à Internet.

RIPEstat change ensuite l'interprétation.L'aperçu de préfixe pour 185.7.83.0/24montrait le préfixe annoncé par AS58212, etle point de terminaison du statut de routage pour 185.7.83.0/24listait l'origine actuelle AS58212, tout en notant que le préfixe avait été vu pour la première fois depuis AS44922 en 2012 et avait été vu pour la dernière fois à l'instantané vérifié depuis AS58212.L'aperçu AS de RIPEstat pour AS58212identifie cette origine comme DATAFOREST dataforest GmbH. De même,l'aperçu de préfixe pour 37.247.112.0/24montrait l'origine actuelle AS29141, et sonaperçu AS pour AS29141identifie Bradler & Krantz GmbH & Co. KG.

Cela ne signifie pas que Medyabim dénature son service. L'espace d'adressage peut être attribué, loué, migré, routé par des fournisseurs de transit, hébergé à l'étranger ou utilisé pour des services hérités. Les résultats de recherche RIPE pour Medyabim montrent plusieurs blocs d'adresses étiquetés Medyabim, y compris 37.247.115.0/24, 37.247.118.0/24, 185.7.82.0/24 et 185.7.83.0/24, dont certains sont actuellement attribués par le routage public à d'autres ASN d'origine. La conclusion correcte n'est pas un scandale; c'est une cartographie des dépendances.

Si le web, l'e-mail ou les surfaces DNS de Medyabim dépendent de préfixes actuellement annoncés par d'autres réseaux, alors les clients doivent savoir quelles parties de leur service sont sur AS44922, quelles parties sont sur un espace d'adressage d'origine externe, et quelles parties sont à l'étranger. Cela importe pour l'analyse des pannes. Si AS44922 a un problème, le site web public ou l'e-mail de support de Medyabim pourrait encore être accessible via un autre fournisseur. Si le chemin d'origine externe a un problème, la surface de la marque Medyabim pourrait échouer même si la route Bursa AS44922 reste active.

Si un client achète un placement « Turquie » mais que le support, la sauvegarde, le DNS ou la dépendance e-mail se trouve ailleurs, le client a besoin que cela soit marqué dans la conception du service.

Le point plus large est que DNS et BGP racontent des histoires différentes. Le domaine de la marque peut être en ligne tandis que le bord AS est étroit. Un détenteur RIPE peut avoir des plages d'adresses allouées non actuellement annoncées par son propre ASN. Un fournisseur peut vendre de l'hébergement tout en dépendant d'origines de route tierces pour certaines parties de sa propre pile. Aucun de ces faits n'est disqualifiant. Tous signifient que l'analyse des pannes doit être précise.

Le silence sur PeeringDB importe car le site nomme de nombreux chemins

PeeringDB est un annuaire volontaire, donc l'absence d'une entité réseau n'est pas la preuve qu'un réseau manque d'interconnexion. Pourtant, cela importe pour Medyabim car la page officielle du centre de données nomme de nombreuses relations de connectivité et une déclaration de capacité totale de sortie de 50 Gbit/s.Une requête API PeeringDB pour ASN 44922n'a retourné aucune entité réseau au moment de la recherche. Cela supprime une source publique qui pourrait autrement montrer la présence d'échange, la présence d'installation, la politique de peering, les ratios de trafic, les préfixes informatifs et les emplacements d'interconnexion auto-déclarés.

Sans profil PeeringDB, un acheteur se retrouve avec les enregistrements RIPE/RDAP, les observations BGP RIPEstat, les propres pages de Medyabim, le DNS et le langage contractuel. C'est réalisable, mais ce n'est pas suffisant pour prouver un accès diversifié aux salles de réunion des opérateurs. Le BGP public montrait AS16276 comme le voisin observé actuel. La page du centre de données de Medyabim nomme Turk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent, AMS-IX et ECIX Duesseldorf. Cet article ne peut pas concilier ces couches en une topologie physique actuelle à partir des seules preuves publiques.

La bonne question d'approvisionnement n'est pas de savoir si chaque fournisseur nommé est faux. C'est de savoir si le service de production actuel a plus d'un chemin approvisionné indépendamment et si ces chemins sont significativement diversifiés. Y a-t-il plusieurs fournisseurs de transit payants actifs pour le service client, ou un seul amont visible? Certains noms sont-ils historiques? Certaines routes sont-elles livrées via un fournisseur en amont, un revendeur ou une interconnexion distante? L'installation de Bursa a-t-elle des entrées de fibre diversifiées? Les chemins turcs et européens sont-ils physiquement séparés?

Quelle quantité de trafic le chemin survivant peut-il supporter lors d'une panne? Le chemin du pare-feu est-il redondant, et le chemin du port de redémarrage est-il indépendant du routage de production client?

Les preuves publiques ne peuvent pas répondre à ces questions. Elles peuvent identifier la nécessité de les poser. Une déclaration de 50 Gbit/s est une hypothèse de capacité jusqu'à ce qu'il y ait des preuves de ports actuels, de contrats, de marge d'utilisation et de basculement. Les logos ou textes de fournisseurs nommés ne sont pas équivalents à une diversité de routes. Un seul voisin AS observé n'est pas une preuve de mono-hébergement, mais c'est suffisant pour exiger une confirmation directe.

Le contrat de service transfère le risque au client

Lecontrat de servicede Medyabim est important car il montre comment les promesses techniques publiques rencontrent le risque contractuel. Le contrat stipule que Medyabim fournira les services commandés après paiement et acceptation, mais il place également la responsabilité sur les clients pour les identifiants de compte, le contenu hébergé, la conformité légale, les taxes et l'utilisation du service. Plus important pour la résilience, il dit que les obligations de sauvegarde et de stockage des données du client appartiennent au client sauf indication contraire dans le texte du contrat, tout en disant que Medyabim sauvegarde et maintient régulièrement les données des clients mais n'est pas responsable des erreurs, pertes ou dommages résultant d'interruptions de service ou de perte de données.

Cette combinaison est courante dans les contrats d'hébergement, mais elle est lourde de conséquences. Les pages d'hébergement publiques peuvent faire la publicité de sauvegardes automatiques hebdomadaires et mensuelles, de services de sauvegarde optionnels, de rapports de trafic et de support géré. Le contrat de service peut toujours limiter la responsabilité du fournisseur si le client n'a pas acheté ou configuré le bon processus de sauvegarde et de restauration.

Un client devrait donc demander la portée exacte de la sauvegarde, la rétention, les tests de restauration, le temps de restauration, l'isolement de la sauvegarde et si les sauvegardes se trouvent dans la même installation, le réseau du fournisseur, le plan de contrôle du compte ou le domaine de panne.

Le même contrat donne à Medyabim des droits de suspension pour problèmes de paiement, contenu illégal, spam et autres violations contractuelles. C'est attendu pour un fournisseur d'hébergement protégeant son réseau. Cela signifie également que la continuité du service dépend de l'état administratif ainsi que des systèmes physiques. Un client peut perdre le service en raison d'un non-paiement, d'un traitement d'abus, d'un incident de spam, d'un verrouillage de compte, d'identifiants perdus ou d'un différend de support même lorsque les racks et les routes sont sains.

Pour les charges de travail critiques, la facturation, les contacts d'abus et les procédures d'escalade sont des contrôles opérationnels, pas des détails administratifs.

Lapage d'aide du système de supportet lapage d'aide en lignede Medyabim montrent une posture de support orientée tickets. La page du centre de données dit que le support téléphonique est disponible pendant les heures de bureau, de 09h00 à 18h00, et en dehors de ces heures, les clients peuvent joindre le fournisseur via un système de tickets et de support e-mail 24/7. La page de colocation dit que les entreprises avec des serveurs dans le centre de données Medyabim peuvent recevoir un support entreprise 24/7. Ces déclarations devraient être converties en procédures d'incident avant qu'un client ne fasse confiance au service: qui peut appeler, qui peut ouvrir des tickets d'urgence, s'il y a une escalade téléphonique en dehors des heures de bureau, et comment le fournisseur distingue les incidents de redémarrage, réseau, matériel, pare-feu, DNS et abus.

L'alimentation et le refroidissement sont les plus grands angles morts publics

La mission de cette enquête est un examen de l'infrastructure du centre de données, et la principale dépendance physique est l'alimentation, le refroidissement, l'accès à la salle de réunion fibre, les opérations de l'installation et les permis locaux. Les pages publiques de Medyabim donnent quelques affirmations de type installation mais pas assez de détails techniques pour soutenir un niveau de confiance élevé en matière de résilience. La page à propos dit que l'entreprise a construit un centre de données à Bursa avec une capacité de plus de 500 serveurs avec ses propres ressources.

La page du centre de données dit que le matériel est prêt dans les racks Medyabim et que l'entreprise utilise son propre matériel serveur. La page de colocation dit que les serveurs sont derrière un pare-feu, ont des statistiques de trafic et reçoivent un port de redémarrage gratuit.

Ces déclarations laissent toujours l'installation physique presque inobservée. Il n'y a aucune affirmation publique d'alimentations doubles. Il n'y a pas de topologie UPS publiée ou de durée de batterie. Il n'y a pas de nombre de générateurs, de capacité en carburant ou de contrat de ravitaillement. Il n'y a pas de conception de redondance de refroidissement. Il n'y a pas de détail sur la détection de fumée, d'incendie ou de fuite d'eau. Il n'y a pas de plan d'étage ou de certification de l'installation. Il n'y a pas de déclaration sur les entrées de fibre diversifiées ou la conception de la salle de réunion.

Il n'y a pas de politique de fenêtre de maintenance distinguant les travaux planifiés, d'urgence et demandés par le client. Il n'y a pas d'historique d'incident public montrant une récupération mesurée.

Pour un petit fournisseur de Bursa, une partie de ce silence est compréhensible. Publier trop de détails sur l'installation peut créer un risque de sécurité. Les petits opérateurs peuvent également compter sur des installations en amont, des salles louées, des arrangements d'alimentation de qualité bureau, ou des placements mixtes de serveurs locaux et à l'étranger. Mais le risque pour le client reste le même. Une déclaration de « capacité de plus de 500 serveurs » n'est pas équivalente à une capacité électrique utilisable après la défaillance d'un chemin de distribution.

Une déclaration de « haute disponibilité » n'est pas équivalente à une durée de fonctionnement testée du générateur. Un « port de redémarrage » ne remplace pas l'accès à la console à distance, les disques de rechange, les procédures d'échange à chaud ou la disponibilité du technicien.

Le test pratique consiste à séparer quatre capacités. La capacité installée est ce que le fournisseur a construit ou dit pouvoir héberger. La capacité vendue est ce que les clients utilisent déjà. La capacité utilisable est ce qui reste après la charge normale, les limites thermiques, les réserves d'alimentation, la maintenance et le sur-abonnement. La capacité récupérable est ce qui reste après une défaillance de composant. Les pages publiques décrivent généralement la capacité installée. Les clients ont besoin de capacité utilisable et récupérable.

Les preuves publiques actuelles de Medyabim ne peuvent pas trancher cette question. Elles peuvent seulement établir la demande de preuves: diagrammes d'alimentation, durée de vie UPS et générateur, conception de refroidissement, politique de densité de rack, contrôles d'incendie et d'eau, diversité d'entrée opérateur, historique de maintenance, procédure d'assistance à distance, politique de pièces de rechange et au moins un exercice documenté de basculement ou de restauration.

Qui est affecté lorsque Medyabim tombe en panne

Les utilisateurs concernés ne sont pas seulement les titulaires de compte directs de Medyabim. Un fournisseur qui vend des domaines, de l'hébergement, des packs revendeur, des VDS, des serveurs dédiés, de la colocation, du stockage e-mail et des sauvegardes peut se retrouver sous de nombreux services en aval. Un pack revendeur peut supporter des dizaines ou des centaines de petits sites web dont les propriétaires peuvent ne pas savoir que Medyabim existe. Un serveur dédié peut héberger une application d'entreprise, une base de données, un portefeuille d'agence, un service e-mail ou une boutique en ligne.

Un client de colocation peut posséder le matériel mais dépendre de Medyabim pour l'alimentation, l'accès au rack, le chemin du pare-feu, la surveillance du trafic et le contrôle du redémarrage.

Le chemin de défaillance n'est pas non plus unidimensionnel. Un événement d'alimentation peut arrêter les serveurs même si les routes en amont sont saines. Un événement de refroidissement peut forcer un arrêt ou réduire la densité de rack autorisée. Une défaillance de pare-feu unique peut isoler de nombreux clients à la fois. Une défaillance de fournisseur amont unique peut affecter AS44922 si aucun chemin alternatif n'est actif pour le préfixe concerné. Une défaillance de support ou de ticket peut ralentir la récupération même si l'installation est intacte.

Une défaillance DNS ou e-mail sur un espace d'adressage d'origine externe peut rendre Medyabim plus difficile à contacter pendant que le trafic de production ailleurs fonctionne encore. Une suspension contractuelle ou pour abus peut supprimer le service sans défaut physique.

C'est pourquoi la découverte DNS importe. Si le domaine de marque public et le service e-mail utilisent 185.7.83.213 sous un préfixe actuellement annoncé par DATAFOREST, et si le SPF référence un préfixe 37.247.112.0/24 actuellement annoncé par Bradler & Krantz, alors les clients ne devraient pas supposer que le « réseau Medyabim » signifie un AS, une ville, une installation ou une juridiction. Le service peut être plus résilient car certains composants se trouvent en dehors d'AS44922. Il peut aussi être plus complexe car la propriété des incidents traverse les frontières des fournisseurs.

Les personnes qui ont besoin de réponses sont les équipes d'approvisionnement, les agences web, les opérateurs revendeurs, les propriétaires de petites entreprises, les administrateurs système, les responsables de conformité et les intervenants en cas d'incident. Ils doivent savoir si un service hébergé par Medyabim dispose d'un deuxième chemin, d'un test de restauration récent, d'un canal de support hors bande, de sauvegardes actuelles, d'un accès au transfert de domaine, d'une exportation DNS, d'une continuité e-mail et d'une autorisation d'origine de route. Ces questions ne sont pas hostiles.

Elles sont le travail minimum nécessaire pour transformer une relation d'hébergement en une dépendance d'infrastructure qui peut survivre à une mauvaise journée.

Ce que les clients devraient demander à Medyabim de prouver

Premièrement, demandez une carte réseau actuelle. Elle devrait identifier AS44922, 37.247.116.0/24, les préfixes AS44922 réservés ou dormants tels que 37.247.117.0/24, les plans IPv6 pour 2a03:400::/32 ou l'allocation plus large, et les services clients routés sous AS29141, AS58212 ou d'autres origines. Elle devrait identifier si AS16276 est le seul fournisseur amont actif pour la route AS44922, si d'autres fournisseurs sont actifs via des accords privés ou non observés, et si les noms de fournisseurs sur la page du centre de données sont actuels, historiques, indirects ou spécifiques à un produit.

Deuxièmement, demandez la résilience des installations. La réponse devrait inclure les alimentations, la conception UPS, la durée de la batterie, la durée de fonctionnement du générateur, la redondance de refroidissement, les limites de densité des racks, la sécurité physique, les contrôles d'incendie et d'eau, les fenêtres de maintenance, la disponibilité de l'assistance à distance, la politique de pièces de rechange, et ce que couvre réellement la déclaration de continuité de colocation à 99 %. Si le service est à Bursa, demandez quelles dépendances de bâtiment et de services publics existent.

Si le service est à l'étranger, demandez quel pays, quelle installation, quel fournisseur et quelles conditions juridiques s'appliquent.

Troisièmement, demandez des preuves de basculement au niveau client. Medyabim devrait être en mesure de montrer ce qui se passe lorsqu'un fournisseur amont tombe en panne, qu'un pare-feu tombe en panne, qu'un serveur perd de l'alimentation, qu'un disque tombe en panne, que le client ne peut pas atteindre le portail, que la file d'attente de support est occupée, que le compte est signalé pour abus, ou que le client a besoin d'une migration d'urgence. Les pages publiques mentionnent la surveillance du trafic, les sauvegardes, les ports de redémarrage et les tickets. L'acheteur doit savoir comment ces outils se comportent lors d'une panne.

Quatrièmement, demandez des contrôles sur les données et la sortie. La page d'hébergement mentionne des sauvegardes automatiques hebdomadaires et mensuelles, une sauvegarde optionnelle, des produits de sauvegarde e-mail et un service de sauvegarde de serveur. Le contrat de service limite la responsabilité de Medyabim pour les interruptions de service et la perte de données sauf indication contraire dans le contrat.

Les clients devraient exiger des tests de restauration, la portée de la sauvegarde, la rétention, le statut hors site, le chiffrement, le contrôle d'accès, le processus d'exportation, le processus de transfert de domaine, l'exportation DNS et la continuité e-mail.

Cinquièmement, demandez la preuve que le support peut être joint lorsque le site web ou l'e-mail habituel est indisponible. La page de contact donne des numéros de téléphone et des e-mails. La page du centre de données décrit le support téléphonique pendant les heures de bureau et le support par ticket/e-mail en dehors des heures. Les clients critiques devraient exiger une escalade d'urgence nommée, des contacts authentifiés, une procédure téléphonique hors bande et un moyen d'autoriser l'assistance à distance sans dépendre uniquement du portail normal.

Un dossier de preuves raisonnable n'aurait pas à révéler des plans d'étage sensibles. Medyabim pourrait fournir une annexe spécifique au client indiquant quelle installation dessert la charge de travail, quels préfixes et ASN d'origine sont utilisés, quels services DNS et e-mail sont en jeu, quels fournisseurs amont sont actifs, quels composants sont des points uniques de défaillance, et quels services sont en dehors de la Turquie.

Il pourrait fournir un schéma unifilaire expurgé séparant les serveurs clients, le pare-feu partagé, le contrôleur de redémarrage, la cible de sauvegarde, le portail de support, le DNS faisant autorité et le site web public. Il pourrait également fournir des dates récentes pour les tests de générateur, la maintenance UPS, la maintenance de refroidissement, les tests de basculement amont, les tests de restauration de sauvegarde et les changements d'origine de route. Ces artefacts répondraient à la question opérationnelle sans exposer les noms des clients ou les configurations de sécurité sensibles.

La même annexe devrait distinguer l'hébergement standard de la colocation et des serveurs dédiés. Dans l'hébergement partagé, l'acheteur dépend des choix de plateforme et de la politique de sauvegarde de Medyabim. Dans l'hébergement revendeur, les clients en aval peuvent dépendre de Medyabim même lorsqu'ils achètent auprès d'une autre marque. Pour les serveurs dédiés, l'acheteur peut contrôler le système d'exploitation mais pas le rack, le routeur, le chemin d'alimentation ou les pièces de rechange.

En colocation, l'acheteur peut posséder le serveur mais dépend toujours de Medyabim pour le bâtiment, l'alimentation, l'accès au support et le bord réseau. Ces différences déterminent qui agit en premier lors d'une panne.

L'évaluation des preuves

Medyabim obtient une note publique de preuves réseau Moyenne, avec une dégradation pour les preuves d'installation et de résilience. La couche d'identité est solide pour un petit fournisseur: les enregistrements RDAP de RIPE et d'organisation RIPE lient AS44922 et ORG-MIH2-RIPE à Emre Erim trading as Medyabim centres de données, et l'adresse de Bursa correspond à la page de contact de Medyabim. La couche de route AS44922 actuelle est également réelle: RIPEstat marque l'AS comme annoncée, liste 37.247.116.0/24 comme actuelle, montre une visibilité IPv4 RIS complète à l'instantané vérifié, et valide la route sous RPKI.

La note ne peut pas être Élevée car les preuves opérationnelles s'amincissent immédiatement après. RIPEstat montrait seulement un /24 IPv4 actuel, aucune annonce IPv6 actuelle et un voisin AS44922 observé. PeeringDB n'a retourné aucune entité réseau pour AS44922. La vue de cohérence RIPEstat montrait une entrée de route IPv4 et une entrée route6 qui n'étaient pas actuelles dans BGP. La propre surface DNS de Medyabim pointe vers un espace d'adressage actuellement annoncé par d'autres réseaux.

Les pages officielles de Medyabim publient des affirmations de service utiles mais ne publient pas les preuves d'alimentation, de refroidissement, de salle de réunion opérateur, de maintenance et de basculement nécessaires pour faire confiance à la capacité commercialisée du centre de données sous contrainte.

La conclusion pratique n'est pas de rejeter Medyabim. Les preuves soutiennent un véritable opérateur d'hébergement et de centre de données basé à Bursa avec des enregistrements RIPE de longue date, un bord AS visible, des pages de service officielles et une offre client concrète. La conclusion n'est pas non plus d'accepter les affirmations de plus de 500 serveurs et 50 Gbit/s comme preuve de résilience.

Les clients devraient traiter ces affirmations comme des hypothèses à valider à travers des diagrammes d'opérateur actuels, des preuves d'installation, une cartographie des préfixes, des vérifications RPKI, des tests de restauration et des procédures de support spécifiques au contrat.

L'empreinte publique de Medyabim est la plus forte là où elle nomme l'identité, les services et une route actuelle. Elle est la plus faible là où un client a le plus besoin de preuves lors d'une panne: alimentations, refroidissement, diversité physique de la fibre, redondance active des opérateurs, IPv6 actuel, escalade du support, sauvegardes, sortie et récupération testée. C'est exactement là où la diligence raisonnable devrait se concentrer avant de placer des charges de travail critiques derrière la marque.