02 Emre Erim handelnd als Medyabim centres de données muss beweisen, ob die vermarktete Kapazität seines Rechenzentrums unter den Einschränkungen von Stromversorgung und Konnektivität überleben kann

Zusammenfassung

• Die öffentlichen Register von RIPE verleihen Medyabim eine konsistente rechtliche und Netzwerkidentität.Das RDAP-Register von RIPE für AS44922nennt MEDYABIM-AS, listet Emre Erim als administrativen und technischen Kontakt auf und enthält ORG-MIH2-RIPE mit dem Namen „Emre Erim trading as Medyabim centres de données“;das Organisationsregister von RIPEzeigt das Land TR, den Status LIR, eine Adresse in Bursa und Kontaktdaten.
• Die aktuelle Routing-Oberfläche ist real, aber schmal.Die AS-Übersicht von RIPEstatmarkiert AS44922 als angekündigt, währendder Routing-Statusein IPv4-Präfix, kein IPv6-Präfix, 256 IPv4-Adressen und einen beobachteten Nachbarn zum überprüften Zeitpunkt zeigte.Die Ansicht der angekündigten Präfixelistete nur 37.247.116.0/24 als aktuell.
• Die stärkste positive Kontrolle ist die Routenursprungssicherheit für das aktuelle /24.Die RPKI-Validierung von RIPEstat für 37.247.116.0/24 über AS44922gab gültig zurück, mit einer ROA, die AS44922 autorisiert und eine maximale Länge von /24.
• Die eigenen Seiten von Medyabim bewerben einen breiteren Betriebsfußabdruck, als die aktuelle Routing-Oberfläche von AS44922 belegt.Die Rechenzentrumsseiteerklärt dedizierte Hardware, die in den Medyabim-Racks bereit ist, langjährige Erfahrung mit Linux DirectAdmin-Servern, Serveroptionen in der Türkei und im Ausland, eine gesamte Ausgangskapazität von 50 Gbit/s, genannte Anbieterpfade wie Turk Telekom und Superonline sowie eine Überwachung des Kundenverkehrs.Die Colocation-Seiteerklärt eine Servicekontinuität von 99 % mit Bandbreite, 24/7-Support, Platzierung hinter einer Firewall, einen kostenlosen Neustart-Port und fünf IP-Adressen.
• Die öffentlichen Zusicherungen bleiben unvollständig. Die offiziellen Seiten veröffentlichen keine doppelten Stromversorgungen, Generatorlaufzeit, Kühltopologie, Brandbekämpfung, Operator-Meeting-Räume, Wartungsfenster, gemessene Failover-Ergebnisse, Einrichtungszertifizierung oder aktuelles PeeringDB-Profil. Die Domain von Medyabim löst zu 185.7.83.213 auf, während RIPEstat zeigt, dass 185.7.83.0/24 derzeit von DATAFOREST angekündigt wird und nicht von AS44922, sodass die Abhängigkeitskarten auf Kundenseite die Marke Medyabim, ihre AS44922-Grenze, den zugewiesenen Adressraum und die von Drittanbietern angekündigten Dienstoberflächen trennen müssen.

Die nützliche Frage ist nicht, ob Medyabim existiert

Es gibt eine Kategorie regionaler Hosting-Profile, bei denen die erste Pflicht darin besteht zu beweisen, dass das Unternehmen mehr ist als eine Zeile in einem Verzeichnis. Medyabim ist nicht so schwach. Das öffentliche Register enthält eine namentlich genannte natürliche Person, einen Handelsnamen, einen RIPE-Organisationseintrag, ein autonomes System, zugewiesene Adressressourcen, offizielle Dienstleistungsseiten, eine Kontaktadresse in Bursa und funktionale Produktangebote.

Das Problem ist anders: Das öffentliche Register beweist Identität und eine begrenzte Routing-Grenze, während die Marketingsprache des Unternehmens die Kunden auffordert, an eine größere Rechenzentrumsgeschichte zu glauben.

Die stärkste Identitätsquelle ist RIPE.Der RDAP-Eintrag für AS44922nennt das autonome System MEDYABIM-AS und listet die Organisation „Emre Erim trading as Medyabim centres de données“. Er listet auch Emre Erim als administrativen und technischen Kontakt mit einer Adresse in Bursa und einer Telefonnummer.Der RIPE-Organisationseintrag für ORG-MIH2-RIPEträgt denselben Handelsnamen, das Land TR, den Typ LIR, die Adresse in Bursa, Telefon, Fax, Medyabim-Maintainer-Referenzen und ein Erstellungsdatum im März 2008. Das ist viel solider als ein aus dem Web extrahierter Hosting-Verzeichniseintrag.

Die eigeneKontaktseitevon Medyabim verankert unabhängig die öffentliche Betriebsadresse. Sie beschreibt „Medyabim centres de données und Internet Hizmetleri“ und gibt Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa, mit Telefonnummern und der öffentlichen E-Mail-Adressebilgi@medyabim.com.tr. Diese Adresse stimmt eng mit der RIPE-Adresse überein. Das ist wichtig, weil die Entität nicht als gesichtsloses Cloud-Etikett präsentiert wird. Ihre öffentlichen Belege weisen auf einen in Bursa ansässigen Betreiber hin, dessen Netzwerkressourceneinträge und kommerzielle Website zumindest wechselseitig konsistent sind.

Die Unternehmensgeschichte-Seite fügt eine Selbstbeschreibung hinzu. DieÜber-uns-Seitevon Medyabim sagt, dass das Unternehmen seit 2000 im Bereich Internetdienste, Softwareprodukte und schlüsselfertige Linux-basierte Systeme tätig ist; sagt, dass es sich später auf Domain-Registrierung, Webhosting, dedizierte Server, Serververwaltung und Beratung konzentriert hat; und sagt, dass es ab 2006 ein Rechenzentrum in Bursa mit eigenen Ressourcen gebaut hat, mit einer Kapazität von über 500 Servern für eigene Server und die von Webhosting-Unternehmen. Das ist kein unabhängiger Beleg für installierte Racks oder elektrische Kapazität, aber es ist eine spezifische und überprüfbare Betriebsbehauptung.

Die Frage ist also nicht „Gibt es ein Medyabim?“. Die Frage ist: „Auf welche Teile der von Medyabim vermarkteten Kapazität kann ein Kunde zählen, wenn Strom, Kühlung, Routing, Support oder die Upstream-Abhängigkeit ausfallen?“. Für einen Rechenzentrums- oder Colocation-Käufer ist die Identität nur die erste Tür. Der schwierigste Test ist die wiederherstellbare Kapazität: die Hardware, die Stromversorgung der Racks, die Kühlung, die Glasfaser, das Routing und die menschlichen Prozesse, die bei einem Ausfall verfügbar bleiben.

AS44922 ist sichtbar, aber seine aktuelle öffentliche Routing-Oberfläche ist klein

RIPEstat bestätigt, dass AS44922 angekündigt wird.Der AS-Überblick-Endpunktkennzeichnet den Inhaber „MEDYABIM-AS Emre Erim trading as Medyabim centres de données“ und markiert die Ressource zum überprüften Zeitpunkt als angekündigt. Das ist die positive Netzwerkerkenntnis. Medyabim hat eine öffentliche autonome Systemgrenze, die das Routing-System sehen kann.

Der Maßstab dieser Grenze ist bescheiden.Der Routing-Status-Endpunktvon RIPEstat zeigte ein IPv4-Präfix, 256 IPv4-Adressen, null IPv6-Präfixe und einen beobachteten Nachbarn.Der Endpunkt für angekündigte Präfixelistete 37.247.116.0/24 als aktuelle Ankündigung von AS44922.Der ASN-Nachbarn-Endpunktzeigte einen einzelnen beobachteten linken Nachbarn, AS16276.Der AS-Überblick von RIPEstat für AS16276identifiziert diesen Nachbarn als OVH SAS.

Das bedeutet nicht, dass Medyabim nur 256 Kunden, ein einzelnes Rack oder einen einzigen Dienst hat. Das öffentliche BGP sieht keine privaten VLANs, Reseller-Bestände, Hosting über Anbieteradressen, Serverinventar, Kundeninterkonnektionen oder ausgelagerte Web-Oberflächen. Aber es bedeutet, dass die sichtbare Grenze von AS44922 zum Zeitpunkt der Überprüfung kein breites, multi-präfixes, multi-nachbarliches öffentliches Backbone ist. Wenn ein Käufer Medyabim als Rechenzentrumsabhängigkeit bewertet, beweist die öffentliche BGP-Karte allein keine Multi-Operator-Resilienz.

Die AS-Routing-Konsistenzansicht von RIPEstatmacht die Lücke noch deutlicher. Sie listete 37.247.116.0/24 als sowohl in BGP als auch im whois/IRR von RIPE vorhanden. Sie listete auch 37.247.117.0/24 und 2a03:400::/32 als im whois/IRR vorhanden, aber zum Zeitpunkt der Überprüfung nicht in BGP. Dieselbe Konsistenzansicht zeigte alte whois-Import/Export-Peers AS9121 und AS53667, die nicht in BGP gesehen wurden, während AS16276 in BGP, aber nicht in der whois-Import/Export-Policy gesehen wurde. Das ist eine normale Art von Drift in älteren Routing-Aufzeichnungen, aber es ist genau der Grund, warum ein Kunde aktuelle Diagramme anfordern sollte, anstatt sich auf historischen Registry-Policy-Text zu verlassen.

Die positive Kontrolle ist RPKI. Die aktuelle Route von AS44922, 37.247.116.0/24, hatden RPKI-Validierungscheck von RIPEstatals gültig bestanden. Das ist wichtig, weil die Routenursprungsautorisierung eine der wenigen öffentlichen Kontrollen ist, die ein Hosting-Käufer überprüfen kann, ohne private Einrichtungsdokumente zu sehen. Eine gültige ROA beweist nicht Strom, Kühlung oder Failover. Sie zeigt, dass die aktuell sichtbare AS44922-Ursprungsion nicht als unbekannter Routenursprung in der öffentlichen Validierungsebene belassen wird.

Die Routenerkenntnis ist also schmal und nützlich. AS44922 ist real. Seine aktuelle sichtbare IPv4-Route ist RPKI-gültig. Seine beobachtete Upstream-Oberfläche ist dünn. Seine IPv6-Belege werden derzeit nicht angekündigt. Seine öffentlichen Routing-Policy-Aufzeichnungen sind begrenzte öffentliche Belege für die Operator-Diversität oder das Failover. Ein Kunde sollte dies weder als Geisternetz noch als bewiesenes resilientes Rechenzentrumsnetz behandeln.

IPv6 und ruhende Präfix-Belege erfordern eine Herabstufung

Medyabim hat IPv6-Registry-Belege. Der RIPE-Sucheintrag für2a03:400::/32zeigt eine Zuweisung von 2a03:400::/29 unter TR-MEDYABIM-20110107 und einen route6-Eintrag für 2a03:400::/32 mit Ursprung AS44922. Das sieht solide aus, bis man es mit der aktuellen Routing-Sichtbarkeit vergleicht.

Der RIPEstat-Präfix-Überblick-Endpunkt für 2a03:400::/32markierte das Präfix zum Zeitpunkt der Überprüfung als nicht angekündigt.Die Routing-Statusansichtmeldete keinen aktuellen Ursprung, keine RIS-Peers, die es sehen, und ein letztes Ereignis für AS44922 am 1. April 2026. Das ist an sich keine Fehlerkonklusion. Manche Kunden kaufen möglicherweise keinen IPv6-Dienst; manche Betreiber haben ruhende IPv6-Pläne; manche Adressblöcke werden für die spätere Nutzung gehalten. Aber es ändert, was öffentlich bewiesen werden kann. Ein Rechenzentrumsanbieter, dessen aktuelle offizielle Seiten Hosting- und Serverdienste bewerben, dessen sichtbare AS-Grenze jedoch derzeit keine IPv6-Ankündigungen hat, sollte nach IPv6-Unterstützung, Nichtverfügbarkeit, selektiver Verfügbarkeit oder Bereitstellung über einen anderen Anbieter gefragt werden.

Die Tabelle der ruhenden IPv4-Präfixe ist ebenfalls gemischt. Das RIPE-Suchergebnis für37.247.117.0/24zeigt NET-MEDYABIM-DC5 und einen RIPE-Route-Eintrag mit Ursprung AS44922, der im Juni 2025 erstellt wurde. Dennoch wurde es vom RIPEstat-Konsistenzcheck nicht im aktuellen BGP gesehen. Das könnte reservierte Kapazität, eine geplante Migration, eine kürzlich zurückgezogene Route, einen Backup-Bereich oder einfach ungenutzten Adressraum darstellen. Die öffentlichen Belege können zwischen diesen Erklärungen nicht wählen.

Die wichtige Unterscheidung ist zwischen zugewiesener Kapazität und betrieblicher Kapazität. Eine RIPE-Zuweisung, ein Route-Eintrag oder eine Adresszuweisung kann administrative Kontrolle oder Vorbereitung zeigen. Das beweist nicht, dass der Adressbereich heute Kunden bedient, über mehrere Betreiber erreichbar ist oder bei einem Ausfall aktiviert werden kann.

Ein Käufer, der wiederherstellbare Kapazität benötigt, sollte Medyabim fragen, welche Präfixe in Produktion sind, welche reserviert, welche zu anderen Ursprüngen migriert, welche kundengerichtet, welche für die Verwaltung reserviert und welche durch getestete DDoS-, Firewall- und RPKI-Prozesse abgedeckt sind.

Die eigenen Dienstleistungsseiten von Medyabim sind konkret, veröffentlichen aber keine Einrichtungsresilienz

DieRechenzentrumsseitevon Medyabim ist detaillierter als eine generische Hosting-Startseite. Sie sagt, dass Modelle für dedizierte Server nach Zahlungseingang ausgeliefert werden und die Hardware in den Medyabim-Racks bereit ist. Sie sagt, dass Medyabim über 15 Jahre Erfahrung mit dedizierten Linux-Servern hat und DirectAdmin seit 2003 aktiv einsetzt. Sie sagt, dass das Unternehmen mit eigener Serverhardware in der Türkei dient, während dedizierte Serverdienste je nach Bedarf in der Türkei oder im Ausland gewählt werden können. Sie beschreibt auch eine „hohe Leitungskapazität“ und Hochverfügbarkeit als Grund, schnell echte Serverhardware anzubieten.

Dieselbe Seite macht eine große Konnektivitätsaussage. Sie sagt, dass die Haupt-Internetverbindungen des Rechenzentrums ausgewählt wurden, um schnellen Zugriff aus der Türkei und der Welt zu bieten, nennt Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent Communications, AMS-IX und ECIX Düsseldorf und erklärt eine gesamte Ausgangsleitungskapazität von 50.000 Mbit, also 50 Gbit/s. Sie sagt, dass Kunden dedizierter Server in ein Netzwerkmanagement-Panel gehen können, um ihren eigenen Verkehr 24/7 zu überwachen, und sagt, dass das Rechenzentrum Netzwerkhardware von Foundry Networks und HP Procurve verwendet.

Das sind nützliche Belege, aber sie müssen als vom Unternehmen veröffentlichtes Marketing- und Betriebstext gelesen werden, nicht als Live-Operator-Audit. Die Seite legt nicht offen, welche der genannten Anbieter aktuelle physische Träger, welche Transit-Anbieter, welche Peering- oder Route-Beziehungen, welche historische Transit-Optionen, welche die türkischen Dienste unterstützen und welche die Platzierung im Ausland unterstützen. Sie zeigt keinen Einrichtungs-Meeting-Raum, diversen Fasereingang, Interkonnektionskarte oder Live-Port-Inventar.

Das öffentliche BGP zeigte zum Zeitpunkt der Überprüfung einen beobachteten AS44922-Nachbarn, keine öffentlich sichtbare Karte jedes Anbieternamens auf der Seite.

Die Seite ist noch dünner in Bezug auf die Einrichtungstechnik. Sie veröffentlicht keine doppelten Stromversorgungen, USV-Kapazität, Batterielaufzeit, Generator-Kraftstoffdauer, Kühlungsredundanz, Brandbekämpfungsklasse, Bodenlast, Rack-Dichte, physische Sicherheitsschichten, Wartungsfensterregeln oder Disaster-Recovery-Übungen. Diese Auslassungen beweisen nicht, dass die Kontrollen nicht existieren. Viele kleine Anbieter veröffentlichen diese Details nicht. Aber ein Kunde, der die Rechenzentrumsresilienz bewertet, sollte diese Kontrollen nicht allein aus dem Wort „Rechenzentrum“ ableiten.

DieColocation-Seitevon Medyabim fügt kundenorientierte Betriebsbehauptungen hinzu. Sie sagt, dass Medyabim eine Verfügbarkeits- oder Servicekontinuitätsgarantie von 99 % mit Bandbreite für seinen Colocation-Dienst bietet; sagt, dass Unternehmen mit Servern im Medyabim-Rechenzentrum rund um die Uhr Unternehmens-Support erhalten können; sagt, dass Verkehrsstatistiken online eingesehen werden können; sagt, dass die Server hinter einer Firewall stehen; sagt, dass ein kostenloser Neustart-Port zugewiesen wird; sagt, dass die zugewiesene Verbindung dediziert und unbegrenzt ist; und sagt, dass fünf IP-Adressen kostenlos für Server im Rechenzentrum zugewiesen werden.

Das sind echte Servicebehauptungen, und sie spezifizieren die Fragen, die Käufer stellen sollten, bevor sie sich auf den Dienst verlassen. Eine Servicekontinuitätszusage von 99 % ist nicht dasselbe wie eine moderne Hochverfügbarkeits-SLA, und 99 % kann immer noch eine signifikante Ausfallzeit pro Jahr bedeuten. Ein Neustart-Port ist nur nützlich, wenn die Stromverteilung, der Remote-Zugriff, die Konsolenanmeldeinformationen und die Support-Prozeduren den Vorfall überleben. Die Firewall-Platzierung kann Kunden schützen, kann aber auch zu einem gemeinsamen Engpass werden.

Fünf IP-Adressen können für einfaches Hosting ausreichen, aber das sagt nichts über die Portabilität des gerouteten Subnetzes oder das Failover aus. Die Seite gibt den Kunden Dinge, nach denen sie fragen können, nicht einen vollständigen Resilienznachweis.

Die offizielle Website beweist die Angebotsbreite, nicht die wiederherstellbare Kapazität

Die öffentliche Angebotsbreite ist groß. DieSeite der Webhosting-Paketevon Medyabim bewirbt Hosting-Pakete mit Webspace, Traffic, FTP, MySQL, Webmail, DirectAdmin, optionalem SSL, E-Mail-Backup-Produkten, einem zusätzlichen IP-Dienst pro Server, einem 300-GB-Server-Backup-Dienst, unbegrenztem 24/7-FTP-Transfer, automatischen wöchentlichen und monatlichen Backups, erweiterten Statistiken, Spam-Filterung und einem Transfer-Bericht. IhreReseller-Seitebietet Reseller-Pakete mit Webspace, POP3-E-Mail-Kontingenten, monatlichem Traffic, MySQL-Datenbanken, türkischem Control-Panel, Webmail, optionaler DNS-Kontrolle, SSL-Optionen, Spam-Filtern und Traffic-Berichten.

Die VDS-Seiteerklärt virtuelle dedizierte Server als logisch getrennte Server auf physischer Hardware und listet die Funktionen der VDS-Pakete auf.Die Control-Panel-Informationsseitesagt, dass DirectAdmin auf den Servern installiert wird, wenn der Server im Medyabim-Rechenzentrum ist, beschreibt eine proaktive Serververwaltung, Sicherheitskonfiguration und Überwachung von Spam-Blacklists und sagt, dass PHP, MySQL, Linux, ionCube und DirectAdmin auf allen Servern installiert und konfiguriert sind.

Zusammengenommen zeigen diese Seiten, dass Medyabim einen klassischen Small-Provider-Stack verkauft: Domains, Shared Hosting, Reseller-Hosting, VDS, dedizierte Server, Colocation, E-Mail-Speicher, SSL, Backup und verwalteten Linux/DirectAdmin-Support. Diese Mischung schafft zwei Arten von Abhängigkeiten. Eine ist physisch: Racks, Strom, Kühlung, Uplinks, Firewalls, Neustart-Ports, Ersatzserver und Technikerzugang. Die andere ist administrativ: Kundenportal, Abrechnung, Kontostatus, Support-Tickets, Domain-Kontrolle, DNS, E-Mail und Backup-Prozesse.

Das öffentliche Angebot sagt dem Käufer nicht, welche Abhängigkeiten in derselben Fehlerdomäne liegen. Ein Kunde könnte ein Webhosting-Paket kaufen, dessen Website, E-Mail, Backups, DNS und Ticket-Zugang alle von denselben Systemen des Anbieters abhängen. Ein Reseller könnte vom Control-Panel und den E-Mail-Systemen von Medyabim abhängen, auch wenn die Endkunden nur die Reseller-Marke sehen. Ein dedizierter Server-Kunde könnte einen Remote-Neustart haben, aber dennoch einen Techniker benötigen, wenn die Maschine nicht startet, ein Disk-Controller ausfällt oder die Firewall-Policy den Recovery-Zugriff blockiert.

Ein Colocation-Kunde könnte den Server besitzen, aber dennoch vom Gebäude, Strom, Uplink, der Firewall und der Support-Antwort von Medyabim abhängen.

Deshalb reicht die installierte Kapazität nicht aus. Die Behauptung der Über-uns-Seite von über 500 Servern und die Aussage der Rechenzentrumsseite über eine Ausgangskapazität von 50 Gbit/s beschreiben eine mögliche Größenordnung. Die wiederherstellbare Kapazität fragt, was passiert, nachdem eine Stromversorgung, ein USV-Pfad, ein Switch, eine Firewall, ein Uplink, ein Authentifizierungspfad oder ein Support-Kanal ausfällt. Die öffentlichen Seiten beantworten das nicht.

Die eigene DNS-Oberfläche von Medyabim zeigt außerhalb von AS44922

Eine der aufschlussreichsten Kontrollen ist die eigene Domain von Medyabim. Ein öffentlicher DNS-Query für medyabim.com.tr zeigte, dass der Apex und der Name www zu 185.7.83.213 auflösen, dass mail.medyabim.com.tr ebenfalls zu 185.7.83.213 auflöst, dass die Nameserver ns1.medyabim.com und ns2.medyabim.com sind und dass ein SPF-Eintrag auf 37.247.112.0/24 und 185.7.83.0/24 verweist. Diese DNS-Fakten müssen als betriebsnahe Belege behandelt werden, da sie zeigen, wie Medyabim seine eigene Dienstoberfläche dem Internet präsentiert.

RIPEstat ändert dann die Interpretation.Der Präfix-Überblick für 185.7.83.0/24zeigte das Präfix angekündigt von AS58212, undder Routing-Status-Endpunkt für 185.7.83.0/24listete den aktuellen Ursprung AS58212, während er bemerkte, dass das Präfix erstmals 2012 von AS44922 gesehen wurde und zuletzt zum überprüften Zeitpunkt von AS58212 gesehen wurde.Der AS-Überblick von RIPEstat für AS58212identifiziert diesen Ursprung als DATAFOREST dataforest GmbH. Ebenso zeigteder Präfix-Überblick für 37.247.112.0/24den aktuellen Ursprung AS29141, und seinAS-Überblick für AS29141identifiziert Bradler & Krantz GmbH & Co. KG.

Das bedeutet nicht, dass Medyabim seinen Dienst falsch darstellt. Der Adressraum kann zugewiesen, gemietet, migriert, über Transit-Anbieter geroutet, im Ausland gehostet oder für Legacy-Dienste verwendet werden. Die RIPE-Suchergebnisse für Medyabim zeigen mehrere Adressblöcke mit der Bezeichnung Medyabim, darunter 37.247.115.0/24, 37.247.118.0/24, 185.7.82.0/24 und 185.7.83.0/24, von denen einige derzeit durch öffentliches Routing anderen Ursprungs-ASNs zugewiesen sind. Die richtige Schlussfolgerung ist kein Skandal; es ist eine Abhängigkeitskartierung.

Wenn das Web, die E-Mail oder die DNS-Oberflächen von Medyabim von Präfixen abhängen, die derzeit von anderen Netzwerken angekündigt werden, dann müssen die Kunden wissen, welche Teile ihres Dienstes auf AS44922 liegen, welche auf externem Ursprungs-Adressraum und welche im Ausland sind. Das ist wichtig für die Fehleranalyse. Wenn AS44922 ein Problem hat, könnte die öffentliche Website oder die Support-E-Mail von Medyabim immer noch über einen anderen Anbieter erreichbar sein. Wenn der externe Ursprungspfad ein Problem hat, könnte die Markenoberfläche von Medyabim ausfallen, selbst wenn die Bursa-Route AS44922 aktiv bleibt.

Wenn ein Kunde eine „Türkei“-Platzierung kauft, aber Support, Backup, DNS oder E-Mail-Abhängigkeit woanders liegen, muss der Kunde dies im Servicedesign gekennzeichnet haben.

Der breitere Punkt ist, dass DNS und BGP unterschiedliche Geschichten erzählen. Die Markendomäne kann online sein, während die AS-Grenze schmal ist. Ein RIPE-Inhaber kann zugewiesene Adressbereiche haben, die derzeit nicht von seiner eigenen ASN angekündigt werden. Ein Anbieter kann Hosting verkaufen, während er für Teile seines eigenen Stacks von Drittanbieter-Routenursprungen abhängt. Keiner dieser Fakten ist disqualifizierend. Sie alle bedeuten, dass die Fehleranalyse präzise sein muss.

Das Schweigen auf PeeringDB ist wichtig, weil die Seite viele Pfade nennt

PeeringDB ist ein freiwilliges Verzeichnis, daher ist das Fehlen einer Netzwerkentität kein Beweis dafür, dass einem Netzwerk die Interkonnektion fehlt. Dennoch ist es für Medyabim wichtig, weil die offizielle Rechenzentrumsseite viele Konnektivitätsbeziehungen und eine Aussage über eine gesamte Ausgangskapazität von 50 Gbit/s nennt.Eine PeeringDB-API-Abfrage für ASN 44922gab zum Zeitpunkt der Suche keine Netzwerkentität zurück. Das entfernt eine öffentliche Quelle, die sonst die Austauschpräsenz, Einrichtungspräsenz, Peering-Policy, Verkehrsverhältnisse, informativen Präfixe und selbst gemeldete Interkonnektionsstandorte zeigen könnte.

Ohne PeeringDB-Profil bleibt ein Käufer mit den RIPE/RDAP-Einträgen, den RIPEstat-BGP-Beobachtungen, den eigenen Seiten von Medyabim, DNS und der Vertragssprache zurück. Das ist machbar, aber nicht ausreichend, um einen diversifizierten Zugang zu Operator-Meeting-Räumen zu beweisen. Das öffentliche BGP zeigte AS16276 als den aktuell beobachteten Nachbarn. Die Rechenzentrumsseite von Medyabim nennt Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent, AMS-IX und ECIX Düsseldorf. Dieser Artikel kann diese Ebenen nicht allein aus öffentlichen Belegen in eine aktuelle physische Topologie integrieren.

Die richtige Beschaffungsfrage ist nicht, ob jeder genannte Anbieter falsch ist. Es ist, ob der aktuelle Produktionsdienst mehr als einen unabhängig bereitgestellten Pfad hat und ob diese Pfade signifikant diversifiziert sind. Gibt es mehrere aktive kostenpflichtige Transit-Anbieter für den Kundendienst, oder nur einen sichtbaren Upstream? Sind einige Namen historisch? Werden einige Routen über einen Upstream-Anbieter, einen Reseller oder eine entfernte Interkonnektion bereitgestellt? Hat die Einrichtung in Bursa diversen Fasereingang? Sind die türkischen und europäischen Pfade physisch getrennt?

Wie viel Verkehr kann der überlebende Pfad bei einem Ausfall bewältigen? Ist der Firewall-Pfad redundant, und ist der Neustart-Port-Pfad unabhängig vom Produktionskunden-Routing?

Die öffentlichen Belege können diese Fragen nicht beantworten. Sie können die Notwendigkeit identifizieren, sie zu stellen. Eine 50-Gbit/s-Aussage ist eine Kapazitätsannahme, bis es Belege für aktuelle Ports, Verträge, Auslastungsspielraum und Failover gibt. Genannte Anbieterlogos oder -texte sind nicht gleichbedeutend mit Routendiversität. Ein einzelner beobachteter AS-Nachbar ist kein Beweis für Single-Homing, aber es reicht aus, um eine direkte Bestätigung zu fordern.

Der Dienstleistungsvertrag überträgt das Risiko auf den Kunden

DerDienstleistungsvertragvon Medyabim ist wichtig, weil er zeigt, wie öffentliche technische Zusagen auf vertragliches Risiko treffen. Der Vertrag besagt, dass Medyabim die bestellten Dienste nach Zahlung und Annahme bereitstellt, aber er legt auch die Verantwortung auf die Kunden für Kontoinformationen, gehostete Inhalte, rechtliche Compliance, Steuern und Dienstnutzung. Wichtiger für die Resilienz besagt er, dass die Backup- und Datenspeicherungspflichten des Kunden beim Kunden liegen, sofern im Vertragstext nicht anders angegeben, während er sagt, dass Medyabim regelmäßig Kundendaten sichert und pflegt, aber nicht für Fehler, Verluste oder Schäden verantwortlich ist, die aus Dienstunterbrechungen oder Datenverlust resultieren.

Diese Kombination ist in Hosting-Verträgen üblich, aber folgenreich. Die öffentlichen Hosting-Seiten mögen automatische wöchentliche und monatliche Backups, optionale Backup-Dienste, Verkehrsberichte und verwalteten Support bewerben. Der Dienstleistungsvertrag kann dennoch die Haftung des Anbieters einschränken, wenn der Kunde den richtigen Backup- und Wiederherstellungsprozess nicht gekauft oder konfiguriert hat.

Ein Kunde sollte daher den genauen Backup-Umfang, die Aufbewahrung, die Wiederherstellungstests, die Wiederherstellungszeit, die Backup-Isolation und ob sich die Backups in derselben Einrichtung, im Netzwerk des Anbieters, im Kontrollplan des Kontos oder in der Fehlerdomäne befinden, erfragen.

Derselbe Vertrag gibt Medyabim Suspendierungsrechte bei Zahlungsproblemen, illegalen Inhalten, Spam und anderen Vertragsverletzungen. Das ist für einen Hosting-Anbieter, der sein Netzwerk schützt, zu erwarten. Es bedeutet auch, dass die Dienstkontinuität vom administrativen Status sowie von den physischen Systemen abhängt. Ein Kunde kann den Dienst aufgrund von Nichtzahlung, Missbrauchsbehandlung, Spam-Vorfall, Kontosperrung, verlorenen Anmeldeinformationen oder Support-Streitigkeit verlieren, selbst wenn die Racks und Routen gesund sind.

Für kritische Arbeitslasten sind Abrechnung, Missbrauchskontakte und Eskalationsverfahren betriebliche Kontrollen, keine administrativen Details.

DieSupport-System-Hilfeseiteund dieOnline-Hilfeseitevon Medyabim zeigen eine ticketorientierte Support-Haltung. Die Rechenzentrumsseite sagt, dass telefonischer Support während der Geschäftszeiten von 09:00 bis 18:00 Uhr verfügbar ist und Kunden außerhalb dieser Zeiten den Anbieter über ein 24/7-Ticket- und E-Mail-Support-System erreichen können. Die Colocation-Seite sagt, dass Unternehmen mit Servern im Medyabim-Rechenzentrum rund um die Uhr Unternehmens-Support erhalten können. Diese Aussagen sollten in Vorfallverfahren umgewandelt werden, bevor ein Kunde dem Dienst vertraut: Wer kann anrufen, wer kann Notfall-Tickets öffnen, gibt es telefonische Eskalation außerhalb der Geschäftszeiten und wie unterscheidet der Anbieter zwischen Neustart-, Netzwerk-, Hardware-, Firewall-, DNS- und Missbrauchsvorfällen.

Strom und Kühlung sind die größten öffentlichen blinden Flecken

Der Auftrag dieser Untersuchung ist eine Prüfung der Rechenzentrumsinfrastruktur, und die wichtigste physische Abhängigkeit ist Strom, Kühlung, Fasereinrichtungszugang, Einrichtungsbetrieb und lokale Genehmigungen. Die öffentlichen Seiten von Medyabim geben einige einrichtungsartige Behauptungen ab, aber nicht genug technische Details, um ein hohes Vertrauen in die Resilienz zu unterstützen. Die Über-uns-Seite sagt, dass das Unternehmen ein Rechenzentrum in Bursa mit einer Kapazität von über 500 Servern mit eigenen Ressourcen gebaut hat.

Die Rechenzentrumsseite sagt, dass die Hardware in den Medyabim-Racks bereit ist und das Unternehmen eigene Serverhardware verwendet. Die Colocation-Seite sagt, dass die Server hinter einer Firewall stehen, Verkehrsstatistiken haben und einen kostenlosen Neustart-Port erhalten.

Diese Aussagen lassen die physische Einrichtung dennoch fast unbeobachtet. Es gibt keine öffentliche Behauptung von doppelten Stromversorgungen. Es gibt keine veröffentlichte USV-Topologie oder Batterielaufzeit. Es gibt keine Generatoranzahl, Kraftstoffkapazität oder Tankvertrag. Es gibt kein Kühlungsredundanzdesign. Es gibt keine Details zur Rauch-, Feuer- oder Wasserleckerkennung. Es gibt keinen Grundriss oder Einrichtungszertifizierung. Es gibt keine Aussage zu diversem Fasereingang oder Meeting-Raum-Design. Es gibt keine Wartungsfensterpolitik, die zwischen geplanten, Notfall- und kundenangeforderten Arbeiten unterscheidet.

Es gibt keine öffentliche Vorfallshistorie, die gemessene Wiederherstellung zeigt.

Für einen kleinen Anbieter in Bursa ist ein Teil dieses Schweigens verständlich. Zu viele Details über die Einrichtung zu veröffentlichen, kann ein Sicherheitsrisiko darstellen. Kleine Betreiber können auch auf Upstream-Einrichtungen, gemietete Räume, büroqualitative Stromvereinbarungen oder gemischte Platzierungen lokaler und ausländischer Server angewiesen sein. Aber das Risiko für den Kunden bleibt gleich. Eine Aussage über „über 500 Server Kapazität“ ist nicht gleichbedeutend mit nutzbarer elektrischer Kapazität nach dem Ausfall eines Verteilungspfades.

Eine Aussage über „Hochverfügbarkeit“ ist nicht gleichbedeutend mit getesteter Generatorlaufzeit. Ein „Neustart-Port“ ersetzt nicht den Remote-Konsolenzugriff, Ersatzfestplatten, Hot-Swap-Verfahren oder Technikerverfügbarkeit.

Der praktische Test besteht darin, vier Kapazitäten zu trennen. Die installierte Kapazität ist das, was der Anbieter gebaut hat oder zu hosten vorgibt. Die verkaufte Kapazität ist das, was die Kunden bereits nutzen. Die nutzbare Kapazität ist das, was nach normaler Last, thermischen Grenzen, Stromreserven, Wartung und Überbuchung übrig bleibt. Die wiederherstellbare Kapazität ist das, was nach einem Komponentenausfall übrig bleibt. Die öffentlichen Seiten beschreiben in der Regel die installierte Kapazität. Kunden benötigen nutzbare und wiederherstellbare Kapazität.

Die aktuellen öffentlichen Belege von Medyabim können diese Frage nicht entscheiden. Sie können nur die Nachfrage nach Belegen begründen: Stromlaufpläne, USV- und Generatorlaufzeit, Kühlungsdesign, Rack-Dichte-Politik, Feuer- und Wasserschutz, Operator-Eingangsdiversität, Wartungshistorie, Remote-Support-Verfahren, Ersatzteilpolitik und mindestens eine dokumentierte Failover- oder Wiederherstellungsübung.

Wer betroffen ist, wenn Medyabim ausfällt

Die betroffenen Nutzer sind nicht nur die direkten Medyabim-Kontoinhaber. Ein Anbieter, der Domains, Hosting, Reseller-Pakete, VDS, dedizierte Server, Colocation, E-Mail-Speicher und Backups verkauft, kann viele nachgelagerte Dienste unterstützen. Ein Reseller-Paket kann Dutzende oder Hunderte kleiner Websites unterstützen, deren Eigentümer möglicherweise nicht wissen, dass Medyabim existiert. Ein dedizierter Server kann eine Geschäftsanwendung, eine Datenbank, ein Agenturportfolio, einen E-Mail-Dienst oder einen Online-Shop hosten.

Ein Colocation-Kunde kann die Hardware besitzen, aber für Strom, Rack-Zugang, Firewall-Pfad, Verkehrsüberwachung und Neustartkontrolle von Medyabim abhängig sein.

Der Fehlerpfad ist auch nicht eindimensional. Ein Stromereignis kann Server zum Absturz bringen, selbst wenn die Upstream-Routen gesund sind. Ein Kühlungsereignis kann eine Abschaltung erzwingen oder die zulässige Rack-Dichte reduzieren. Ein einzelner Firewall-Ausfall kann viele Kunden gleichzeitig isolieren. Ein einzelner Upstream-Anbieterausfall kann AS44922 betreffen, wenn kein alternativer Pfad für das betreffende Präfix aktiv ist. Ein Support- oder Ticket-Ausfall kann die Wiederherstellung verlangsamen, selbst wenn die Einrichtung intakt ist.

Ein DNS- oder E-Mail-Ausfall auf externem Ursprungsadressraum kann es schwieriger machen, Medyabim zu kontaktieren, während der Produktionsverkehr anderswo noch läuft. Eine vertragliche oder Missbrauchssuspendierung kann den Dienst ohne physischen Defekt entfernen.

Deshalb ist die DNS-Erkennung wichtig. Wenn die öffentliche Markendomäne und der E-Mail-Dienst 185.7.83.213 unter einem derzeit von DATAFOREST angekündigten Präfix verwenden und der SPF auf ein Präfix 37.247.112.0/24 verweist, das derzeit von Bradler & Krantz angekündigt wird, dann sollten Kunden nicht annehmen, dass das „Medyabim-Netzwerk“ eine einzige ASN, Stadt, Einrichtung oder Gerichtsbarkeit bedeutet. Der Dienst kann widerstandsfähiger sein, weil einige Komponenten außerhalb von AS44922 liegen. Er kann auch komplexer sein, weil die Vorfallverantwortung über Anbietergrenzen hinweggeht.

Die Personen, die Antworten benötigen, sind Beschaffungsteams, Webagenturen, Reseller-Betreiber, Kleinunternehmer, Systemadministratoren, Compliance-Beauftragte und Vorfallreaktionsmitarbeiter. Sie müssen wissen, ob ein von Medyabim gehosteter Dienst einen zweiten Pfad, einen kürzlichen Wiederherstellungstest, einen Out-of-Band-Support-Kanal, aktuelle Backups, Domain-Transferzugriff, DNS-Export, E-Mail-Kontinuität und Routenursprungsautorisierung hat. Diese Fragen sind nicht feindselig.

Sie sind die Mindestarbeit, die erforderlich ist, um eine Hosting-Beziehung in eine Infrastrukturabhängigkeit zu verwandeln, die einen schlechten Tag überleben kann.

Was Kunden von Medyabim verlangen sollten, um zu beweisen

Erstens, fordern Sie eine aktuelle Netzwerkkarte an. Sie sollte AS44922, 37.247.116.0/24, reservierte oder ruhende AS44922-Präfixe wie 37.247.117.0/24, IPv6-Pläne für 2a03:400::/32 oder die breitere Zuweisung und unter AS29141, AS58212 oder anderen Ursprüngen geroutete Kundendienste identifizieren. Sie sollte identifizieren, ob AS16276 der einzige aktive Upstream-Anbieter für die AS44922-Route ist, ob andere Anbieter über private oder nicht beobachtete Vereinbarungen aktiv sind und ob die Anbieternamen auf der Rechenzentrumsseite aktuell, historisch, indirekt oder produktspezifisch sind.

Zweitens, fordern Sie die Einrichtungsresilienz an. Die Antwort sollte die Stromversorgungen, das USV-Design, die Batterielaufzeit, die Generatorlaufzeit, die Kühlungsredundanz, die Rack-Dichtegrenzen, die physische Sicherheit, die Feuer- und Wasserschutz, die Wartungsfenster, die Remote-Support-Verfügbarkeit, die Ersatzteilpolitik und was die 99%-Colocation-Kontinuitätsaussage tatsächlich abdeckt, umfassen. Wenn der Dienst in Bursa ist, fragen Sie, welche Gebäude- und Versorgungsabhängigkeiten bestehen. Wenn der Dienst im Ausland ist, fragen Sie, welches Land, welche Einrichtung, welcher Anbieter und welche rechtlichen Bedingungen gelten.

Drittens, fordern Sie Failover-Nachweise auf Kundenebene an. Medyabim sollte in der Lage zu sein zu zeigen, was passiert, wenn ein Upstream-Anbieter ausfällt, eine Firewall ausfällt, ein Server Strom verliert, eine Festplatte ausfällt, der Kunde das Portal nicht erreichen kann, die Support-Warteschlange besetzt ist, das Konto wegen Missbrauchs gemeldet wird oder der Kunde eine Notfall-Migration benötigt. Die öffentlichen Seiten erwähnen Verkehrsüberwachung, Backups, Neustart-Ports und Tickets. Der Käufer muss wissen, wie sich diese Werkzeuge bei einem Ausfall verhalten.

Viertens, fordern Sie Kontrollen über Daten und Ausstieg an. Die Hosting-Seite erwähnt automatische wöchentliche und monatliche Backups, optionales Backup, E-Mail-Backup-Produkte und einen Server-Backup-Dienst. Der Dienstleistungsvertrag beschränkt die Haftung von Medyabim für Dienstunterbrechungen und Datenverlust, sofern im Vertrag nicht anders angegeben. Kunden sollten Wiederherstellungstests, Backup-Umfang, Aufbewahrung, Offsite-Status, Verschlüsselung, Zugangskontrolle, Exportprozess, Domain-Transferprozess, DNS-Export und E-Mail-Kontinuität verlangen.

Fünftens, fordern Sie den Nachweis, dass der Support erreichbar ist, wenn die übliche Website oder E-Mail nicht verfügbar ist. Die Kontaktseite gibt Telefonnummern und E-Mails an. Die Rechenzentrumsseite beschreibt telefonischen Support während der Geschäftszeiten und Ticket-/E-Mail-Support außerhalb der Geschäftszeiten. Kritische Kunden sollten eine benannte Notfall-Eskalation, authentifizierte Kontakte, ein Out-of-Band-Telefonverfahren und eine Möglichkeit zur Autorisierung des Remote-Supports verlangen, ohne sich ausschließlich auf das normale Portal zu verlassen.

Eine vernünftige Beweismappe müsste keine sensiblen Grundrisse offenlegen. Medyabim könnte eine kundenspezifische Anlage bereitstellen, die angibt, welche Einrichtung die Arbeitslast bedient, welche Präfixe und Ursprungs-ASNs verwendet werden, welche DNS- und E-Mail-Dienste betroffen sind, welche Upstream-Anbieter aktiv sind, welche Komponenten Single Points of Failure sind und welche Dienste außerhalb der Türkei liegen. Es könnte ein bereinigtes Einliniendiagramm bereitstellen, das Kundenserver, gemeinsame Firewall, Neustart-Controller, Backup-Ziel, Support-Portal, autoritativen DNS und die öffentliche Website trennt.

Es könnte auch aktuelle Daten für Generatortests, USV-Wartung, Kühlungswartung, Upstream-Failover-Tests, Backup-Wiederherstellungstests und Routenursprungsänderungen bereitstellen. Diese Artefakte würden die Betriebsfrage beantworten, ohne Kundennamen oder sensible Sicherheitskonfigurationen offenzulegen.

Dieselbe Anlage sollte Standard-Hosting von Colocation und dedizierten Servern unterscheiden. Bei Shared Hosting hängt der Käufer von den Plattformentscheidungen und der Backup-Politik von Medyabim ab. Bei Reseller-Hosting können nachgelagerte Kunden von Medyabim abhängen, selbst wenn sie von einer anderen Marke kaufen. Bei dedizierten Servern kann der Käufer das Betriebssystem kontrollieren, aber nicht das Rack, den Router, den Strompfad oder die Ersatzteile. Bei Colocation kann der Käufer den Server besitzen, aber dennoch von Medyabim für Gebäude, Strom, Support-Zugang und die Netzwerkgrenze abhängen.

Diese Unterschiede bestimmen, wer bei einem Ausfall zuerst handelt.

Die Beweisbewertung

Medyabim erhält eine öffentliche Netzwerkbeweisnote von Mittel, mit einer Herabstufung für Einrichtungs- und Resilienzbelege. Die Identitätsschicht ist für einen kleinen Anbieter stark: Die RDAP-Einträge von RIPE und der RIPE-Organisationseinrag verknüpfen AS44922 und ORG-MIH2-RIPE mit Emre Erim, handelnd als Medyabim centres de données, und die Adresse in Bursa stimmt mit der Kontaktseite von Medyabim überein.

Die aktuelle AS44922-Route-Schicht ist ebenfalls real: RIPEstat markiert die AS als angekündigt, listet 37.247.116.0/24 als aktuell, zeigt eine vollständige IPv4-RIS-Sichtbarkeit zum überprüften Zeitpunkt und validiert die Route unter RPKI.

Die Note kann nicht Hoch sein, weil die Betriebsbelege unmittelbar danach dünner werden. RIPEstat zeigte nur ein aktuelles /24 IPv4, keine aktuelle IPv6-Ankündigung und einen beobachteten AS44922-Nachbarn. PeeringDB gab keine Netzwerkentität für AS44922 zurück. Die RIPEstat-Konsistenzansicht zeigte einen IPv4-Route-Eintrag und einen route6-Eintrag, die nicht im aktuellen BGP waren. Die eigene DNS-Oberfläche von Medyabim zeigt auf Adressraum, der derzeit von anderen Netzwerken angekündigt wird.

Die offiziellen Seiten von Medyabim veröffentlichen nützliche Servicebehauptungen, aber nicht die Strom-, Kühlungs-, Operator-Meeting-Raum-, Wartungs- und Failover-Belege, die notwendig sind, um der vermarkteten Rechenzentrumskapazität unter Belastung zu vertrauen.

Die praktische Schlussfolgerung ist nicht, Medyabim abzulehnen. Die Belege unterstützen einen echten Hosting- und Rechenzentrumsbetreiber in Bursa mit langjährigen RIPE-Einträgen, einer sichtbaren AS-Grenze, offiziellen Dienstleistungsseiten und einem konkreten Kundenangebot. Die Schlussfolgerung ist auch nicht, die Behauptungen von über 500 Servern und 50 Gbit/s als Resilienznachweis zu akzeptieren. Kunden sollten diese Behauptungen als Annahmen behandeln, die durch aktuelle Betreiberdiagramme, Einrichtungsbelege, Präfixkartierung, RPKI-Checks, Wiederherstellungstests und vertragsspezifische Supportverfahren validiert werden müssen.

Der öffentliche Fußabdruck von Medyabim ist am stärksten, wo er Identität, Dienste und eine aktuelle Route nennt. Er ist am schwächsten, wo ein Kunde bei einem Ausfall am meisten Beweise benötigt: Stromversorgungen, Kühlung, physische Faserdiversität, aktive Betreiberredundanz, aktuelle IPv6, Support-Eskalation, Backups, Ausstieg und getestete Wiederherstellung. Genau dort sollte die Due Diligence ansetzen, bevor kritische Arbeitslasten hinter der Marke platziert werden.