Resumen
- Los registros públicos de RIPE otorgan a Medyabim una identidad legal y de red consistente. Elregistro RDAP de RIPE para AS44922nombra a MEDYABIM-AS, lista a Emre Erim como contacto administrativo y técnico, e incluye ORG-MIH2-RIPE con el nombre "Emre Erim que opera como Medyabim centros de datos"; elregistro de organización de RIPEmuestra el país TR, estado LIR, una dirección en Bursa y datos de contacto.
- La superficie de enrutamiento actual es real pero limitada. Lavisión general de AS de RIPEstatmarcó a AS44922 como anunciado, mientras que elestado de enrutamientomostró un prefijo IPv4, ningún prefijo IPv6, 256 direcciones IPv4 y un vecino observado en la instantánea verificada. Lavista de prefijos anunciadoslistó solo 37.247.116.0/24 como actual.
- El control positivo más fuerte es la seguridad de origen de ruta para el /24 actual. Lavalidación RPKI de RIPEstat para 37.247.116.0/24 a través de AS44922devolvió válido, con un ROA que autoriza a AS44922 y una longitud máxima /24.
- Las propias páginas de Medyabim comercializan una huella operativa más amplia de lo que la superficie de ruta actual de AS44922 demuestra. Lapágina del centro de datosafirma tener hardware dedicado listo en racks de Medyabim, larga experiencia con servidores Linux DirectAdmin, opciones de servidor en Turquía y en el extranjero, una capacidad total de salida de 50 Gbit/s, rutas de proveedores nombradas como Türk Telekom y Superonline, y monitoreo de tráfico de clientes. Lapágina de colocaciónafirma un 99% de continuidad del servicio con ancho de banda, soporte 24/7, ubicación detrás de un cortafuegos, un puerto de reinicio gratuito y cinco direcciones IP.
- Las garantías públicas siguen siendo incompletas. Las páginas oficiales no publican alimentaciones de energía duales, tiempo de funcionamiento del generador, topología de refrigeración, supresión de incendios, salas de encuentro de operadores, ventanas de mantenimiento, resultados de conmutación por error medidos, certificación de instalaciones ni un perfil actual de PeeringDB. El dominio propio de Medyabim se resuelve a 185.7.83.213, mientras que RIPEstat muestra que 185.7.83.0/24 es actualmente anunciado por DATAFOREST en lugar de AS44922, por lo que los mapas de dependencia del lado del cliente deben separar la marca Medyabim, su borde AS44922, el espacio de direcciones asignado y las superficies de servicio anunciadas por terceros.
La pregunta útil no es si Medyabim existe
Existe una categoría de perfiles de hosting regional donde el primer deber es demostrar que la empresa es más que una línea en un directorio. Medyabim no es tan débil. El registro público contiene una persona natural nombrada, un nombre comercial, un registro de organización RIPE, un sistema autónomo, recursos de direccionamiento asignados, páginas de servicio oficiales, una dirección de contacto en Bursa y ofertas de productos funcionales.
El problema es diferente: el registro público demuestra identidad y un borde de enrutamiento limitado, mientras que el lenguaje de marketing de la empresa pide a los clientes creer una historia de capacidad de centro de datos más amplia.
La fuente de identidad más sólida es RIPE. Elregistro RDAP para AS44922nombra al sistema autónomo MEDYABIM-AS y lista la organización "Emre Erim que opera como Medyabim centros de datos". También lista a Emre Erim como contacto administrativo y técnico, con una dirección en Bursa y un número de teléfono. Elregistro REST de organización RIPE para ORG-MIH2-RIPElleva el mismo nombre comercial, país TR, tipo LIR, dirección en Bursa, teléfono, fax, referencias de mantenedor de Medyabim y fecha de creación en marzo de 2008. Esto es mucho más sólido que una entrada de directorio de hosting obtenida por web scraping.
La propiapágina de contactode Medyabim ancla de forma independiente la dirección operativa pública. Describe "Medyabim centros de datos ve Internet Hizmetleri" y da la dirección Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa, con números de teléfono y la dirección de correo electrónico pública[email protected]. Esta dirección coincide estrechamente con la dirección de RIPE. Esto importa porque la entidad no se presenta como una etiqueta de nube sin rostro. Su evidencia pública apunta a un operador con sede en Bursa cuyos registros de recursos de red y sitio web comercial son al menos mutuamente consistentes.
La página de historia de la empresa añade autodescripción. Lapágina acerca dede Medyabim dice que la empresa ha operado desde 2000 en torno a servicios de Internet, productos de software y sistemas llave en mano basados en Linux; dice que luego se centró en registro de dominios, hosting web, servidores dedicados, gestión de servidores y consultoría; y dice que a partir de 2006 construyó un centro de datos en Bursa, con sus propios recursos, con una capacidad de más de 500 servidores para sus propios servidores y los de empresas de hosting. Esto no es una prueba independiente de racks instalados o capacidad eléctrica, pero es una afirmación operativa específica y comprobable.
Por lo tanto, la pregunta no es "¿existe Medyabim?". La pregunta es "¿en qué partes de la capacidad comercializada por Medyabim puede confiar un cliente cuando fallan la energía, la refrigeración, el enrutamiento, el soporte o la dependencia ascendente?". Para un comprador de centro de datos o colocación, la identidad es solo la primera puerta. La prueba más difícil es la capacidad recuperable: el hardware, la energía del rack, la refrigeración, la fibra, el enrutamiento y los procesos humanos que permanecen disponibles durante una interrupción.
AS44922 es visible, pero su superficie de ruta pública actual es pequeña
RIPEstat confirma que AS44922 está anunciado. Elpunto final de visión general de ASetiqueta al titular "MEDYABIM-AS Emre Erim trading as Medyabim centros de datos" y marca el recurso como anunciado en la instantánea verificada. Esa es la conclusión de red positiva. Medyabim tiene un borde de sistema autónomo público que el sistema de enrutamiento puede ver.
La escala de ese borde es modesta. Elpunto final de estado de enrutamientode RIPEstat mostró un prefijo IPv4, 256 direcciones IPv4, cero prefijos IPv6 y un vecino observado. Elpunto final de prefijos anunciadoslistó 37.247.116.0/24 como el anuncio actual de AS44922. Elpunto final de vecinos ASNmostró un solo vecino izquierdo observado, AS16276. Lavisión general de AS de RIPEstat para AS16276identifica a ese vecino como OVH SAS.
Esto no significa que Medyabim tenga solo 256 clientes, un solo rack o un solo servicio. BGP público no ve VLANs privadas, stock de revendedores, hosting direccionado por proveedor, inventario de servidores, interconexiones de clientes o superficies web subcontratadas. Pero sí significa que el borde visible de AS44922 no es una columna vertebral pública amplia, con múltiples prefijos y múltiples vecinos en el momento de la verificación. Si un comprador evalúa a Medyabim como una dependencia de centro de datos, el mapa BGP público por sí solo no demuestra resiliencia multioperador.
Lavista de consistencia de enrutamiento AS de RIPEstathace más evidente la brecha. Listó 37.247.116.0/24 como presente tanto en BGP como en RIPE WHOIS/IRR. También listó 37.247.117.0/24 y 2a03:400::/32 como presentes en WHOIS/IRR pero no en BGP en el momento de la verificación. La misma vista de consistencia mostró peers antiguos de importación/exportación WHOIS AS9121 y AS53667 no vistos en BGP, mientras que AS16276 fue visto en BGP pero no en la política de importación/exportación WHOIS. Esto es un tipo normal de desviación en registros de enrutamiento antiguos, pero es exactamente por lo que un cliente debería pedir diagramas actuales en lugar de confiar en texto de política de registro histórico.
La verificación positiva es RPKI. La ruta actual de AS44922, 37.247.116.0/24, pasó laverificación RPKI de RIPEstatcomo válida. Esto importa porque la autorización de origen de ruta es una de las pocas comprobaciones públicas que un comprador de hosting puede verificar sin ver documentos privados de la instalación. Un ROA válido no prueba energía, refrigeración o conmutación por error. Muestra que el origen visible actual de AS44922 no se deja como una reclamación de origen de ruta desconocida en la capa de validación pública.
Por lo tanto, la conclusión de la ruta es limitada y útil. AS44922 es real. Su ruta IPv4 visible actual es RPKI válida. Su superficie ascendente observada es delgada. Su evidencia IPv6 no está actualmente anunciada. Sus registros de política de enrutamiento público son evidencia pública limitada para demostrar diversidad de operadores o conmutación por error. Un cliente no debe tratar esto como una red fantasma, ni como una red de centro de datos resiliente probada.
La evidencia de prefijos IPv6 e inactivos requiere una rebaja
Medyabim tiene evidencia de registro IPv6. El registro de búsqueda RIPE para2a03:400::/32muestra una asignación 2a03:400::/29 bajo TR-MEDYABIM-20110107 y una entrada route6 para 2a03:400::/32 con origen AS44922. Esto parece sólido hasta que se compara con la visibilidad de enrutamiento actual.
Elpunto final de visión general de prefijo de RIPEstat para 2a03:400::/32marcó el prefijo como no anunciado en el momento de la verificación. Lavista de estado de enrutamientoinformó que no hay origen actual, cero peers de RIS lo ven, y un último evento visto para AS44922 el 1 de abril de 2026. Esto no es una conclusión de falla en sí misma. Algunos clientes pueden no comprar servicio IPv6; algunos operadores pueden tener planes IPv6 inactivos; algunos bloques de direcciones se mantienen para uso futuro. Pero cambia lo que se puede probar públicamente. Se debe preguntar a un proveedor de centro de datos cuyas páginas oficiales actuales comercializan servicios de hosting y servidores pero cuyo borde AS visible no tiene anuncio IPv6 actual sobre el soporte IPv6, su falta de disponibilidad, disponibilidad selectiva o provisión a través de otro proveedor.
El panorama de prefijos IPv4 inactivos también es mixto. El resultado de búsqueda RIPE para37.247.117.0/24muestra NET-MEDYABIM-DC5 y una entrada de ruta RIPE con origen AS44922 creada en junio de 2025. Sin embargo, la verificación de consistencia de RIPEstat no lo vio en BGP actual. Esto podría representar capacidad reservada, una migración planificada, una ruta retirada recientemente, un rango de respaldo o simplemente espacio de direcciones no utilizado. La evidencia pública no puede elegir entre esas explicaciones.
La distinción importante es entre capacidad asignada y capacidad operativa. Una asignación RIPE, una entrada de ruta o una asignación de dirección pueden mostrar control administrativo o preparación. No demuestra que el rango de direcciones sirva a clientes hoy, sea alcanzable a través de múltiples operadores, o pueda activarse durante una interrupción.
Un comprador que necesita capacidad recuperable debe preguntar a Medyabim qué prefijos están en producción, cuáles están reservados, cuáles se han migrado a otros orígenes, cuáles están orientados al cliente, cuáles son solo de gestión y cuáles están cubiertos por procesos probados de DDoS, cortafuegos y RPKI.
Las páginas de servicio propias de Medyabim son concretas, pero no publican resiliencia de instalaciones
Lapágina del centro de datosde Medyabim es más detallada que una página de aterrizaje genérica de hosting. Dice que los modelos de servidores dedicados se entregan después de la validación del pago y que el hardware está listo en los racks de Medyabim. Dice que Medyabim tiene más de 15 años de experiencia con servidores dedicados Linux y utiliza activamente DirectAdmin desde 2003. Dice que la empresa sirve con su propio hardware de servidor basado en Turquía, mientras que los servicios de servidor dedicado se pueden elegir en Turquía o en el extranjero según la demanda. También describe "capacidad de línea alta" y alta disponibilidad como una razón para ofrecer rápidamente hardware de servidor real.
La misma página hace una gran afirmación de conectividad. Dice que las conexiones principales de Internet del centro de datos se eligieron para proporcionar acceso rápido desde Turquía y el mundo, nombra a Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent Communications, AMS-IX y ECIX Duesseldorf, y afirma una capacidad total de salida de línea de 50.000 Mbit, es decir, 50 Gbit/s. Dice que los clientes de servidores dedicados pueden ingresar a un panel de gestión de red para monitorear su propio tráfico 24/7 y dice que el centro de datos utiliza hardware de red Foundry Networks y HP Procurve.
Esta es evidencia útil, pero debe leerse como texto de marketing y operativo publicado por la empresa, no como una auditoría de operadores en vivo. La página no revela cuáles de los proveedores nombrados son operadores físicos actuales, cuáles son proveedores de tránsito, cuáles son relaciones de peering o ruta, cuáles son opciones de tránsito históricas, cuáles apoyan servicios turcos y cuáles apoyan la colocación en el extranjero. No muestra una sala de encuentro de instalaciones, entrada de fibra diversa, mapa de interconexión o inventario de puertos en vivo.
BGP público en el momento de la verificación mostró un vecino AS44922 observado, no un mapa visible públicamente de cada nombre de proveedor en la página.
La página es aún más escasa en ingeniería de instalaciones. No publica alimentaciones de energía duales, capacidad UPS, tiempo de funcionamiento de batería, tiempo de funcionamiento de combustible del generador, redundancia de refrigeración, clase de supresión de incendios, carga de piso, densidad de rack, capas de seguridad física, reglas de ventana de mantenimiento o simulacros de recuperación de desastres. Estas omisiones no prueban que los controles no existan. Muchos proveedores pequeños no publican tales detalles.
Pero un cliente que evalúa la resiliencia de un centro de datos no debe asumir estos controles a partir de la palabra "centro de datos".
Lapágina de colocaciónde Medyabim añade afirmaciones operativas orientadas al cliente. Dice que Medyabim ofrece una garantía de disponibilidad o continuidad del servicio del 99% con ancho de banda para su servicio de colocación; dice que las empresas con servidores en el centro de datos de Medyabim pueden recibir soporte empresarial 24/7; dice que las estadísticas de tráfico se pueden observar en línea; dice que los servidores están detrás de un cortafuegos; dice que se asignará un puerto de reinicio gratuito; dice que la conexión asignada es dedicada y no limitada; y dice que se asignan cinco direcciones IP de forma gratuita para servidores en el centro de datos.
Estas son afirmaciones de servicio reales, y especifican las preguntas que los compradores deben hacer antes de confiar en el servicio. Una promesa de continuidad del servicio del 99% no es lo mismo que un SLA moderno de alta disponibilidad, y el 99% aún puede permitir una cantidad significativa de tiempo de inactividad durante un año. Un puerto de reinicio es útil solo si la distribución de energía, el acceso remoto, las credenciales de consola y los procedimientos de soporte sobreviven al incidente. La colocación del cortafuegos puede proteger a los clientes, pero también puede convertirse en un cuello de botella compartido.
Cinco direcciones IP pueden ser suficientes para hosting simple, pero no dicen nada sobre la portabilidad de subred enrutada o la conmutación por error. La página da a los clientes elementos para preguntar, no una prueba completa de resiliencia.
El sitio oficial demuestra la amplitud de la oferta, no la capacidad recuperable
La amplitud de la oferta pública es amplia. Lapágina de paquetes de hosting webde Medyabim anuncia paquetes de hosting con espacio web, tráfico, FTP, MySQL, webmail, DirectAdmin, SSL opcional, productos de respaldo de correo electrónico, un servicio de respaldo de servidor de 300 GB, transferencia FTP ilimitada 24/7, respaldos automáticos semanales y mensuales, estadísticas avanzadas, filtrado antispam y un informe de transferencia. Supágina de revendedorofrece paquetes de revendedor con espacio web, cuotas de correo POP3, tráfico mensual, bases de datos MySQL, panel de control turco, webmail, control DNS opcional, opciones SSL, filtros antispam e informes de tráfico.
Lapágina VDSexplica los servidores virtuales dedicados como servidores separados lógicamente en hardware físico y lista las características de los paquetes VDS. Lapágina de información del panel de controldice que DirectAdmin está instalado en los servidores cuando el servidor está en el DC de Medyabim, describe la gestión proactiva del servidor, la configuración de seguridad y el monitoreo de listas negras de spam, y dice que PHP, MySQL, Linux, ionCube y DirectAdmin están instalados y configurados en todos los servidores.
En conjunto, estas páginas muestran que Medyabim vende una pila clásica de proveedor pequeño: dominios, hosting compartido, hosting para revendedores, VDS, servidores dedicados, colocación, almacenamiento de correo electrónico, SSL, respaldo y soporte gestionado Linux/DirectAdmin. Esta mezcla crea dos tipos de dependencias. Una es física: racks, energía, refrigeración, enlaces ascendentes, cortafuegos, puertos de reinicio, servidores de repuesto y acceso de técnicos. La otra es administrativa: portal del cliente, facturación, estado de la cuenta, tickets de soporte, controles de dominio, DNS, correo electrónico y procesos de respaldo.
La oferta pública no le dice al comprador qué dependencias están en el mismo dominio de falla. Un cliente podría comprar un paquete de hosting web cuyo sitio web, correo electrónico, respaldos, DNS y acceso a tickets dependen todos de los mismos sistemas del proveedor. Un revendedor podría depender del panel de control y los sistemas de correo electrónico de Medyabim aunque los clientes finales solo vean la marca del revendedor.
Un comprador de servidor dedicado podría tener reinicio remoto pero aún necesitar un técnico si la máquina no pasa el POST, falla un controlador de disco o la política del cortafuegos bloquea el acceso de recuperación. Un cliente de colocación podría ser dueño del servidor pero aún depender del edificio, la energía, el enlace ascendente, el cortafuegos y la respuesta de soporte de Medyabim.
Por eso la capacidad instalada no es suficiente. La afirmación de la página acerca de más de 500 servidores y la afirmación de la página del centro de datos de 50 Gbit/s de capacidad de salida describen una escala posible. La capacidad recuperable pregunta qué sucede después de que fallan una alimentación de energía, una trayectoria UPS, un conmutador, un cortafuegos, un enlace ascendente, una trayectoria de autenticación o un canal de soporte. Las páginas públicas no responden eso.
La superficie DNS propia de Medyabim apunta fuera de AS44922
Una de las verificaciones más reveladoras es el propio dominio de Medyabim. Una consulta DNS pública para medyabim.com.tr mostró que el ápice y el nombre www se resuelven a 185.7.83.213, que mail.medyabim.com.tr también se resuelve a 185.7.83.213, que los servidores de nombres son ns1.medyabim.com y ns2.medyabim.com, y que un registro SPF referencia 37.247.112.0/24 y 185.7.83.0/24. Estos hechos DNS deben tratarse como evidencia adyacente a las operaciones porque muestran cómo Medyabim presenta su propia superficie de servicio a Internet.
RIPEstat luego cambia la interpretación. Lavisión general de prefijo para 185.7.83.0/24mostró el prefijo anunciado por AS58212, y elpunto final de estado de enrutamiento para 185.7.83.0/24listó el origen actual AS58212, al tiempo que señaló que el prefijo se había visto por primera vez desde AS44922 en 2012 y se había visto por última vez en la instantánea verificada desde AS58212. Lavisión general de AS de RIPEstat para AS58212identifica ese origen como DATAFOREST dataforest GmbH. Del mismo modo, lavisión general de prefijo para 37.247.112.0/24mostró el origen actual AS29141, y suvisión general de AS para AS29141identifica a Bradler & Krantz GmbH & Co. KG.
Esto no significa que Medyabim tergiverse su servicio. El espacio de direcciones puede estar asignado, arrendado, migrado, enrutado por proveedores de tránsito, alojado en el extranjero o utilizado para servicios heredados. Los resultados de búsqueda RIPE para Medyabim muestran varios bloques de direcciones etiquetados como Medyabim, incluyendo 37.247.115.0/24, 37.247.118.0/24, 185.7.82.0/24 y 185.7.83.0/24, algunos de los cuales son actualmente atribuidos por el enrutamiento público a otros ASN de origen. La conclusión correcta no es escándalo; es mapeo de dependencias.
Si las superficies web, de correo electrónico o DNS de Medyabim dependen de prefijos actualmente anunciados por otras redes, entonces los clientes necesitan saber qué partes de su servicio están en AS44922, qué partes están en espacio de direcciones originado externamente y qué partes están en el extranjero. Esto importa para el análisis de interrupciones. Si AS44922 tiene un problema, el sitio web público de Medyabim o el correo de soporte aún podrían ser alcanzables a través de otro proveedor.
Si la trayectoria de origen externo tiene un problema, la superficie de la marca Medyabim podría fallar incluso si la ruta de AS44922 en Bursa se mantiene activa. Si un cliente compra una ubicación en "Turquía" pero el soporte, respaldo, DNS o dependencia de correo electrónico se encuentra en otro lugar, el cliente necesita que eso esté marcado en el diseño del servicio.
El punto más amplio es que DNS y BGP cuentan historias diferentes. El dominio de la marca puede estar en línea mientras el borde AS es estrecho. Un titular RIPE puede tener rangos de direcciones asignados no anunciados actualmente por su propio ASN. Un proveedor puede vender hosting mientras depende de orígenes de ruta de terceros para partes de su propia pila. Ninguno de estos hechos es descalificador. Todos significan que el análisis de fallas debe ser preciso.
El silencio en PeeringDB importa porque el sitio nombra muchos caminos
PeeringDB es un directorio voluntario, por lo que la ausencia de una entidad de red no es prueba de que una red carezca de interconexión. Sin embargo, importa para Medyabim porque la página oficial del centro de datos nombra muchas relaciones de conectividad y una afirmación de capacidad total de salida de 50 Gbit/s. Unaconsulta a la API de PeeringDB para ASN 44922no devolvió ninguna entidad de red en el momento de la búsqueda. Esto elimina una fuente pública que de otro modo podría mostrar presencia de intercambio, presencia de instalaciones, política de peering, ratios de tráfico, prefijos informativos y ubicaciones de interconexión autodeclaradas.
Sin un perfil de PeeringDB, un comprador se queda con registros RIPE/RDAP, observaciones BGP de RIPEstat, las propias páginas de Medyabim, DNS y lenguaje contractual. Eso es manejable, pero no es suficiente para probar el acceso diverso a las salas de encuentro de operadores. BGP público mostró a AS16276 como el vecino observado actual. La página del centro de datos de Medyabim nombra a Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent, AMS-IX y ECIX Duesseldorf. Este artículo no puede conciliar esas capas en una topología física actual a partir de evidencia pública únicamente.
La pregunta correcta de adquisición no es si cada proveedor nombrado es falso. Es si el servicio de producción actual tiene más de una trayectoria aprovisionada de forma independiente y si esas trayectorias son significativamente diversas. ¿Hay múltiples proveedores de tránsito pagados activos para el servicio al cliente, o un único upstream visible? ¿Algunos nombres nombrados son históricos? ¿Algunas rutas se entregan a través de un proveedor upstream, un revendedor o una interconexión remota? ¿Tiene la instalación de Bursa entradas de fibra diversas? ¿Están separadas físicamente las rutas turcas y europeas?
¿Cuánto tráfico puede soportar la trayectoria superviviente durante una interrupción? ¿Es redundante la trayectoria del cortafuegos y es independiente la trayectoria del puerto de reinicio del enrutamiento de producción del cliente?
La evidencia pública no puede responder estas preguntas. Puede identificar la necesidad de hacerlas. Una afirmación de 50 Gbit/s es una suposición de capacidad hasta que haya evidencia de puertos actuales, contratos, margen de utilización y conmutación por error. Los logotipos o texto de proveedores nombrados no equivalen a diversidad de rutas. Un vecino AS observado único no es prueba de homing único, pero es suficiente para exigir confirmación directa.
El contrato de servicio traslada el riesgo al cliente
Elcontrato de serviciode Medyabim es importante porque muestra cómo las promesas técnicas públicas se encuentran con el riesgo contractual. El contrato dice que Medyabim proporcionará los servicios solicitados después del pago y la aceptación, pero también responsabiliza a los clientes por las credenciales de la cuenta, el contenido alojado, el cumplimiento legal, los impuestos y el uso del servicio. Más importante para la resiliencia, dice que las obligaciones de respaldo y almacenamiento de datos del cliente pertenecen al cliente a menos que se indique lo contrario en el texto del contrato, al tiempo que dice que Medyabim realiza copias de seguridad y mantiene los datos del cliente regularmente, pero no es responsable por errores, pérdidas o daños que surjan de interrupciones del servicio o pérdida de datos.
Esta combinación es común en los contratos de hosting, pero está cargada de consecuencias. Las páginas de hosting públicas pueden anunciar copias de seguridad automáticas semanales y mensuales, servicios de respaldo opcionales, informes de tráfico y soporte gestionado. El contrato de servicio aún puede limitar la responsabilidad del proveedor si el cliente no compró o configuró el proceso de copia de seguridad y restauración correcto.
Por lo tanto, un cliente debe preguntar por el alcance exacto de la copia de seguridad, la retención, las pruebas de restauración, el tiempo de restauración, el aislamiento de la copia de seguridad y si las copias de seguridad residen en la misma instalación, red del proveedor, plano de control de la cuenta o dominio de falla.
El mismo contrato otorga a Medyabim derechos de suspensión por problemas de pago, contenido ilegal, spam y otras violaciones del contrato. Esto es esperado para un proveedor de hosting que protege su red. También significa que la continuidad del servicio depende del estado administrativo además de los sistemas físicos. Un cliente puede perder el servicio por falta de pago, manejo de abuso, incidente de spam, bloqueo de cuenta, pérdida de credenciales o disputa de soporte incluso cuando los racks y las rutas están saludables.
Para cargas de trabajo críticas, la facturación, los contactos de abuso y los procedimientos de escalamiento son controles operativos, no detalles administrativos.
Lapágina de ayuda del sistema de soportede Medyabim y lapágina de ayuda en líneamuestran una postura de soporte orientada a tickets. La página del centro de datos dice que el soporte telefónico está disponible durante el horario laboral, de 09:00 a 18:00, y fuera de ese horario los clientes pueden comunicarse con el proveedor a través de un sistema de tickets y correo electrónico 24/7. La página de colocación dice que las empresas con servidores en el centro de datos de Medyabim pueden recibir soporte empresarial 24/7. Estas declaraciones deben convertirse en procedimientos de incidentes antes de que un cliente confíe en el servicio: quién puede llamar, quién puede abrir tickets de emergencia, si hay escalamiento telefónico fuera de horario y cómo distingue el proveedor los incidentes de reinicio, red, hardware, cortafuegos, DNS y abuso.
La energía y la refrigeración son los mayores puntos ciegos públicos
La misión de esta divulgación es una revisión de infraestructura de centro de datos, y la principal dependencia física es la energía, la refrigeración, el acceso a la sala de encuentro de fibra, las operaciones de las instalaciones y los permisos locales. Las páginas públicas de Medyabim ofrecen algunas afirmaciones de tipo de instalación, pero no suficientes detalles de ingeniería para respaldar una calificación de confianza alta en resiliencia. La página acerca de dice que la empresa construyó un centro de datos en Bursa con una capacidad de más de 500 servidores con sus propios recursos.
La página del centro de datos dice que el hardware está listo en los racks de Medyabim y la empresa utiliza su propio hardware de servidor. La página de colocación dice que los servidores están detrás de un cortafuegos, tienen estadísticas de tráfico y reciben un puerto de reinicio gratuito.
Estas declaraciones aún dejan la instalación física casi no observada. No hay afirmación pública de alimentaciones de energía duales. No hay topología UPS publicada ni tiempo de funcionamiento de batería. No hay cantidad de generadores, capacidad de combustible o contrato de reabastecimiento. No hay diseño de redundancia de refrigeración. No hay detalles sobre detección de humo, supresión de incendios o detección de fugas de agua. No hay plano de planta o certificación de instalaciones. No hay declaración sobre entradas de fibra diversa o diseño de sala de encuentro.
No hay política de ventana de mantenimiento que distinga entre trabajo planificado, de emergencia y solicitado por el cliente. No hay historial público de incidentes que muestre recuperación medida.
Para un proveedor pequeño en Bursa, parte de este silencio es comprensible. Publicar demasiados detalles de las instalaciones puede crear un riesgo de seguridad. Los operadores más pequeños también pueden depender de instalaciones ascendentes, salas alquiladas, arreglos de energía de grado de oficina, o colocaciones mixtas locales y en el extranjero. Pero el riesgo para el cliente sigue siendo el mismo. Una afirmación de "capacidad de más de 500 servidores" no equivale a capacidad de energía utilizable después de que falla una trayectoria de distribución.
Una afirmación de "alta disponibilidad" no equivale a tiempo de funcionamiento de generador probado. Un "puerto de reinicio" no sustituye al acceso remoto a la consola, discos de repuesto, procedimientos de intercambio en caliente o disponibilidad de técnicos.
La prueba práctica es separar cuatro capacidades. La capacidad instalada es lo que el proveedor construyó o dice que puede alojar. La capacidad vendida es lo que los clientes ya utilizan. La capacidad utilizable es lo que queda después de la carga normal, límites térmicos, reservas de energía, mantenimiento y sobresuscripción. La capacidad recuperable es lo que queda después de una falla de componente. Las páginas públicas generalmente describen la capacidad instalada. Los clientes necesitan capacidad utilizable y recuperable.
La evidencia pública actual de Medyabim no puede resolver esta cuestión. Solo puede establecer la demanda de evidencia: diagramas de energía, tiempo de funcionamiento de UPS y generador, diseño de refrigeración, política de densidad de rack, controles de incendio y agua, diversidad de entrada de operadores, historial de mantenimiento, procedimiento de manos remotas, política de piezas de repuesto y al menos un ejercicio documentado de conmutación por error o restauración.
Quién se ve afectado cuando Medyabim falla
Los usuarios afectados no son solo los titulares de cuentas directas de Medyabim. Un proveedor que vende dominios, hosting, paquetes de revendedor, VDS, servidores dedicados, colocación, almacenamiento de correo electrónico y respaldos puede encontrarse bajo muchos servicios posteriores. Un paquete de revendedor puede soportar decenas o cientos de sitios web pequeños cuyos propietarios pueden no saber que Medyabim existe. Un servidor dedicado puede alojar una aplicación empresarial, una base de datos, un portafolio de agencia, un servicio de correo electrónico o una tienda en línea.
Un cliente de colocación puede ser dueño del hardware pero depender de Medyabim para energía, acceso al rack, trayectoria del cortafuegos, monitoreo de tráfico y control de reinicio.
La trayectoria de falla tampoco es unidimensional. Un evento de energía puede detener servidores incluso si las rutas ascendentes están saludables. Un evento de refrigeración puede forzar un apagado o reducir la densidad de rack permitida. Una falla de un solo cortafuegos puede aislar a muchos clientes a la vez. Una falla de un solo proveedor upstream puede afectar a AS44922 si no hay una trayectoria alternativa activa para el prefijo relevante. Una falla de soporte o tickets puede ralentizar la recuperación incluso si la instalación está intacta.
Una falla de DNS o correo electrónico en espacio de direcciones originado externamente puede hacer que sea más difícil contactar a Medyabim mientras el tráfico de producción en otro lugar sigue funcionando. Una suspensión contractual o por abuso puede eliminar el servicio sin una falla física.
Es por eso que el descubrimiento de DNS es importante. Si el dominio público de la marca y el servicio de correo electrónico utilizan 185.7.83.213 bajo un prefijo actualmente anunciado por DATAFOREST, y si el SPF referencia un prefijo 37.247.112.0/24 actualmente anunciado por Bradler & Krantz, entonces los clientes no deben asumir que "red Medyabim" significa un AS, una ciudad, una instalación o una jurisdicción. El servicio puede ser más resiliente porque algunos componentes están fuera de AS44922. También puede ser más complejo porque la propiedad del incidente cruza límites de proveedores.
Las personas que necesitan respuestas son equipos de adquisiciones, agencias web, operadores de revendedores, propietarios de pequeñas empresas, administradores de sistemas, oficiales de cumplimiento y respondedores de incidentes. Necesitan saber si un servicio alojado en Medyabim tiene una segunda trayectoria, una prueba de restauración reciente, un canal de soporte fuera de banda, copias de seguridad actuales, acceso de transferencia de dominio, exportación de DNS, continuidad de correo electrónico y una autorización de origen de ruta. Estas preguntas no son hostiles.
Son el trabajo mínimo necesario para convertir una relación de hosting en una dependencia de infraestructura que pueda sobrevivir a un mal día.
Lo que los clientes deben pedir a Medyabim que demuestre
Primero, solicitar un mapa de red actual. Debe identificar AS44922, 37.247.116.0/24, cualquier prefijo AS44922 reservado o inactivo como 37.247.117.0/24, cualquier plan IPv6 para 2a03:400::/32 o la asignación más amplia, y cualquier servicio de cliente enrutado bajo AS29141, AS58212 u otros orígenes. Debe identificar si AS16276 es el único proveedor upstream activo para la ruta AS44922, si otros proveedores están activos a través de acuerdos privados o no observados, y si los nombres de proveedores en la página del centro de datos son actuales, históricos, indirectos o específicos de producto.
Segundo, solicitar resiliencia de instalaciones. La respuesta debe incluir alimentaciones de energía, diseño UPS, tiempo de funcionamiento de batería, tiempo de funcionamiento de generador, redundancia de refrigeración, límites de densidad de rack, seguridad física, controles de incendio y agua, ventanas de mantenimiento, disponibilidad de manos remotas, política de piezas de repuesto, y qué cubre realmente la afirmación de continuidad de colocación del 99%. Si el servicio está en Bursa, preguntar qué dependencias de edificio y servicios públicos existen.
Si el servicio está en el extranjero, preguntar qué país, qué instalación, qué proveedor y qué condiciones legales se aplican.
Tercero, solicitar evidencia de conmutación por error a nivel de cliente. Medyabim debería poder mostrar qué sucede cuando falla un proveedor upstream, falla un cortafuegos, un servidor pierde energía, falla un disco, el cliente no puede acceder al portal, la cola de soporte está ocupada, la cuenta se marca por abuso, o el cliente necesita una migración de emergencia. Las páginas públicas mencionan monitoreo de tráfico, copias de seguridad, puertos de reinicio y tickets. El comprador necesita saber cómo se comportan estas herramientas durante una interrupción.
Cuarto, solicitar controles de datos y salida. La página de hosting menciona copias de seguridad automáticas semanales y mensuales, respaldo opcional, productos de respaldo de correo electrónico y un servicio de respaldo de servidor. El contrato de servicio limita la responsabilidad de Medyabim por interrupciones de servicio y pérdida de datos a menos que se indique lo contrario en el contrato.
Los clientes deben exigir pruebas de restauración, alcance de la copia de seguridad, retención, estado fuera del sitio, cifrado, control de acceso, proceso de exportación, proceso de transferencia de dominio, exportación de DNS y continuidad de correo electrónico.
Quinto, solicitar prueba de que se puede contactar al soporte cuando el sitio web o el correo electrónico habitual no están disponibles. La página de contacto proporciona números de teléfono y correos electrónicos. La página del centro de datos describe soporte telefónico durante el horario laboral y soporte por tickets/correo electrónico fuera de horario. Los clientes críticos deben exigir escalamiento de emergencia nombrado, contactos autenticados, un procedimiento telefónico fuera de banda y una forma de autorizar manos remotas sin depender únicamente del portal normal.
Un paquete de evidencia razonable no tendría que revelar planos de planta sensibles. Medyabim podría proporcionar un anexo específico del cliente que indique qué instalación sirve a la carga de trabajo, qué prefijos y ASN de origen se utilizan, qué servicios DNS y de correo electrónico están en juego, qué proveedores upstream están activos, qué componentes son puntos únicos de falla y qué servicios están fuera de Turquía.
Podría proporcionar un diagrama unifilar redactado que separe los servidores del cliente, el cortafuegos compartido, el controlador de reinicio, el destino de respaldo, el portal de soporte, el DNS autoritativo y el sitio web público. También podría proporcionar fechas recientes de pruebas de generadores, mantenimiento de UPS, mantenimiento de refrigeración, pruebas de conmutación por error upstream, pruebas de restauración de copias de seguridad y cambios de origen de ruta. Estos artefactos responderían a la pregunta operativa sin exponer nombres de clientes o configuraciones de seguridad sensibles.
El mismo anexo debe distinguir entre hosting estándar, colocación y servidores dedicados. En hosting compartido, el comprador depende de las elecciones de plataforma y la política de copias de seguridad de Medyabim. En hosting para revendedores, los clientes posteriores pueden depender de Medyabim incluso cuando compran a otra marca. Para servidores dedicados, el comprador puede controlar el sistema operativo pero no el rack, el enrutador, la trayectoria de energía o las piezas de repuesto.
En colocación, el comprador puede ser dueño del servidor pero aún depende de Medyabim para el edificio, la energía, el acceso de soporte y el borde de red. Estas diferencias determinan quién actúa primero durante una interrupción.
La calificación de evidencia
Medyabim obtiene una calificación de evidencia de red pública Media, con una rebaja por evidencia de instalaciones y resiliencia. La capa de identidad es sólida para un proveedor pequeño: los registros RIPE RDAP y de organización RIPE vinculan AS44922 y ORG-MIH2-RIPE a Emre Erim que opera como Medyabim centros de datos, y la dirección en Bursa coincide con la página de contacto de Medyabim. La capa de ruta actual de AS44922 también es real: RIPEstat marca el AS como anunciado, lista 37.247.116.0/24 como actual, muestra visibilidad completa de RIS IPv4 en la instantánea verificada y valida la ruta bajo RPKI.
La calificación no puede ser Alta porque la evidencia operativa se reduce inmediatamente después de eso. RIPEstat mostró solo un /24 IPv4 actual, ningún anuncio IPv6 actual y un vecino AS44922 observado. PeeringDB no devolvió ninguna entidad de red para AS44922. La vista de consistencia de RIPEstat mostró una entrada de ruta IPv4 y una entrada route6 IPv4 que no estaban actuales en BGP. La superficie DNS propia de Medyabim apunta a espacio de direcciones actualmente anunciado por otras redes.
Las páginas oficiales de Medyabim publican afirmaciones de servicio útiles pero no publican la evidencia de energía, refrigeración, sala de encuentro de operadores, mantenimiento y conmutación por error necesaria para confiar en la capacidad del centro de datos comercializado bajo estrés.
La conclusión práctica no es rechazar a Medyabim. La evidencia respalda a un operador genuino de hosting y centro de datos con sede en Bursa con registros RIPE de larga data, un borde AS visible, páginas de servicio oficiales y una oferta al cliente concreta. Tampoco es la conclusión aceptar las afirmaciones de más de 500 servidores y 50 Gbit/s como prueba de resiliencia. Los clientes deben tratar estas afirmaciones como hipótesis a validar a través de diagramas de operadores actuales, evidencia de instalaciones, mapeo de prefijos, comprobaciones RPKI, pruebas de restauración y procedimientos de soporte específicos del contrato.
La huella pública de Medyabim es más fuerte donde nombra identidad, servicios y una ruta actual. Es más débil donde un cliente más necesita evidencia durante una interrupción: alimentaciones de energía, refrigeración, diversidad física de fibra, redundancia activa de operadores, IPv6 actual, escalamiento de soporte, copias de seguridad, salida y recuperación probada. Ahí es exactamente donde la diligencia debida debe concentrarse antes de colocar cargas de trabajo críticas detrás de la marca.