Resumen
- La entidad denominada "support 3D CLOUD COMMUNICATION" es un rol de contacto RIPE, no el nombre legal verificado de un negocio de soporte. La empresa correspondiente es LLC "3D CLOUD COMMUNICATION", una sociedad de responsabilidad limitada de Kiev constituida el 9 de julio de 2025 con un capital social de 600 000 UAH y una actividad principal registrada que abarca el procesamiento de datos, alojamiento y trabajos relacionados.
- La empresa está actualmente vinculada a AS56421 y AS39755. Ambos números anteceden a la empresa por años, por lo que sus fechas de creación y sus historiales de enrutamiento antiguos no pueden presentarse como el historial operativo de la empresa. AS39755 no tenía ninguna ruta visible en la fecha de corte de la investigación. AS56421 acababa de empezar a originar un /24 IPv4 y no había demostrado origen IPv6.
- El único bloque visible,
185.243.98.0/24, también seguía siendo originado por AS48693, cuya organización sigue siendo el asignatario registrado del bloque y cuyos nombresntup.netpermanecían en el DNS inverso. Este estado de origen múltiple puede reflejar una migración autorizada, un acuerdo con un cliente o una transición. Por sí solo no prueba un incidente de enrutamiento, pero no existía una autorización pública o una autorización de origen de ruta que aclarase la relación. - A las 12:00 UTC del 10 de julio, las observaciones de rutas públicas mostraban AS56421 a través de AS41033, mientras que muchas más rutas observadas aún terminaban en AS48693. El registro RIPE enumeraba numerosas relaciones de importación previstas, pero una política de enrutamiento prevista no es lo mismo que un tránsito utilizable simultáneo. No se verificó un segundo sitio, puerto de intercambio, ruta de portador físico, capacidad de respaldo o prueba de conmutación por error para la empresa.
- La calificación de la evidencia es Débil. Existe una empresa legal real, un registro de red actual y una señal BGP muy reciente. Aún no hay suficiente evidencia pública para respaldar una plataforma en la nube orientada al cliente, localizar sus racks, medir la capacidad utilizable, verificar la resiliencia de energía y hardware, establecer la localidad de los datos o evaluar las obligaciones de restauración y migración.
Una etiqueta de soporte no es una historia empresarial
El inusual nombre público de la entidad tiene un origen sencillo. Elregistro de rol RIPEdenomina SCC86-RIPE "support 3D CLOUD COMMUNICATION" y le otorga responsabilidad administrativa a través de SP22450-RIPE. Elregistro de personaasociado identifica a Slipych Pavlo. Esos registros se crearon el 31 de diciembre de 2025. Constituyen una evidencia útil de contacto y responsabilidad, pero la palabra "soporte" no debe confundirse con un nombre comercial, un servicio de asistencia con personal o una promesa de nivel de servicio.
La identidad legal es LLC "3D CLOUD COMMUNICATION". Elregistro de empresa de Opendatabotproporciona el número de empresa ucraniano 45920348, una fecha de constitución del 9 de julio de 2025, un domicilio social en Kiev y un capital social de 600 000 UAH. Identifica a Pavlo Slipych como director, fundador y beneficiario efectivo último. Elregistro de YouControlmostraba la empresa registrada y no en liquidación cuando se actualizó el 23 de junio de 2026. La misma identidad legal es visible de forma independiente en labúsqueda de empresas de Hosting Ukraine.
Estas fechas establecen un límite esencial. Una empresa constituida en julio de 2025 no puede reclamar la vida operativa de un sistema autónomo visto por primera vez en 2011 simplemente porque el número esté ahora asociado a ella. Puede haber adquirido derechos, contratos, equipos o conocimientos de un operador anterior, pero no existe ningún registro público de transacción que establezca lo que se transfirió. La empresa actual puede evaluarse por su propia constitución, sus registros actuales y su conducta observable. El número más antiguo sigue siendo un contexto técnico relevante, no una biografía corporativa heredada.
El registro legal también limita lo que puede decirse con seguridad sobre la propiedad. La empresa se presenta como propiedad total de un solo individuo, no como una filial declarada de un grupo de alojamiento más grande. No se encontró ninguna garantía pública de empresa matriz, balance consolidado o socio de infraestructura nombrado. Los 600 000 UAH de capital social establecen un compromiso de capital formal; no revelan el efectivo disponible, los ingresos anuales, el inventario de servidores, la cobertura de seguro o la cantidad disponible durante una interrupción prolongada.
Un comprador no puede convertir el capital social en una estimación del tiempo de actividad.
Esto importa porque la responsabilidad en un pequeño negocio de servicios alojados suele estar concentrada. La misma persona puede negociar la capacidad, aprobar gastos, gestionar recursos de direcciones y encargarse de la escalación. Esto puede agilizar las decisiones, pero también puede crear un riesgo de persona clave. Los registros públicos no revelan el número de empleados, la cobertura de turnos, la profundidad de ingeniería o una lista de guardia. El rol de contacto prueba que existe un responsable. No prueba que un segundo ingeniero vaya a responder mientras el primero no está disponible.
El registro para alojamiento es evidencia de intención, no un catálogo de productos
La actividad principal registrada de la empresa es el KVED ucraniano 63.11: procesamiento de datos, alojamiento en nodos web y actividades relacionadas. Las actividades registradas adicionales incluyen programación, consultoría de tecnología de la información, gestión de equipos informáticos, edición de software y otros servicios de información. Esta es la base pública más clara para situar el negocio en la categoría de nube o alojamiento. Sigue siendo una clasificación administrativa más que una descripción de un producto en funcionamiento.
Una actividad registrada no dice si la empresa vende máquinas virtuales, servidores bare-metal, aplicaciones gestionadas, colocalización, almacenamiento de copias de seguridad o solo consultoría técnica. No nombra un hipervisor, plataforma de almacenamiento, portal de facturación, gama de sistemas operativos, asignación de ancho de banda, plazo mínimo, canal de soporte o jurisdicción del cliente. No muestra un precio, una página de pedido, una página de estado, un aviso para clientes o una política de uso aceptable.
No se identificó ningún catálogo de productos público vinculado de forma segura al número de empresa 45920348 en la fecha de corte.
La distinción es fácil de pasar por alto porque "cloud" está en el nombre de la empresa. Ladefinición de computación en la nube del NISTdescribe características como el autoservicio bajo demanda, el acceso amplio a la red, la agrupación de recursos, la elasticidad rápida y el servicio medido. La actividad legal respalda la intención de alojamiento, aunque la evidencia pública no establece esas características operativas. Un rack de servidores aprovisionados manualmente puede ser un servicio de alojamiento útil sin ser una nube elástica. A la inversa, una empresa puede revender la nube de un tercero sin poseer un rack. El nombre por sí solo no resuelve ninguno de los dos casos.
Lasinopsis y recomendaciones sobre la nube del NISTtambién distingue los acuerdos de servicio y despliegue y enfatiza la necesidad de comprender las responsabilidades del proveedor. Ese es el problema práctico aquí. Si 3D CLOUD COMMUNICATION revende capacidad, el operador subyacente puede controlar la energía, la sustitución de hardware y gran parte de la red. Si alquila racks y posee servidores, controla una porción diferente de la cadena. Si gestiona equipos de clientes, la responsabilidad cambia de nuevo. Ningún contrato público asigna esas obligaciones.
El regulador de comunicaciones ucraniano publica unregistro mensual de proveedores de redes y servicios de comunicaciones electrónicas, con la página del conjunto de datos actualizada el 2 de julio de 2026. Una empresa que planee vender transporte de internet puede necesitar una postura regulatoria diferente a la de un negocio que vende computación sobre la conectividad de otro operador. La evidencia revisada aquí no establece qué notificaciones o permisos se aplican a la oferta real de esta empresa. La conclusión segura es limitada: sus actividades corporativas permiten una hipótesis de alojamiento; no prueban lo que actualmente vende ni el carácter regulatorio del servicio.
Dos números de red antiguos llegaron dentro de una nueva identidad corporativa
Elregistro de organización RIPEpara ORG-LCC13-RIPE se creó el 31 de diciembre de 2025 y nombra a LLC "3D CLOUD COMMUNICATION" con el número de empresa 45920348. Al día siguiente, los registros de sistemas autónomos visibles para AS56421 y AS39755 se modificaron para apuntar a esa organización. Ambos conservan el nombre de ASEurolir-AS, una etiqueta que no coincide con el nuevo nombre legal. Ninguna de las discrepancias es automáticamente problemática, pero ambas muestran por qué cada campo debe leerse por fecha y función.
Elregistro actual de AS56421dice que el número se creó el 17 de febrero de 2011. Elhistorial de estado de enrutamiento de RIPEstatlo vio originar91.223.123.0/24por primera vez el 18 de febrero de 2011. La empresa no existía entonces. La fecha registra la historia del número de red, no la antigüedad de LLC 3D CLOUD COMMUNICATION.
Elregistro de AS39755tiene una fecha de creación del objeto actual en mayo de 2018, mientras que lavista de estado de RIPEstatcontiene observaciones más antiguas que terminan en julio de 2010. Los registros de registro reemitidos o reconstruidos pueden producir este tipo de cronología. El punto relevante para un cliente es más simple: lavisión general actual de AS39755lo marcó como no anunciado, y no se veía ningún prefijo actual desde él en la fecha de corte.
Poseer o patrocinar un registro de sistema autónomo puede ser útil antes de que comience el tráfico. Permite a una red definir políticas y organizar sesiones con proveedores de tránsito. Sin embargo, un ASN no es un enrutador, una fibra, un rack o un megabit de tránsito contratado. Es un identificador utilizado para expresar un dominio de enrutamiento. Laexplicación de RIPE NCC sobre los números de sistema autónomoes explícita en que un ASN soporta una política de enrutamiento externo distinta. El identificador puede estar listo mucho antes de que se instale el equipo, o permanecer registrado después de que cese el tráfico.
Por lo tanto, la empresa actual tiene dos identificadores registrados, pero solo uno con una señal operativa reciente. Esa asimetría debería influir en cualquier afirmación de resiliencia. Dos ASN no significan dos redes. No implican dos centros de datos, dos enrutadores de borde o dos contratos. La inactividad de AS39755 lo descarta como evidencia de una copia de seguridad actual. Un cliente necesitaría ver cómo se usa cada número, si ambos están configurados en equipos separados y si algún servicio puede moverse entre ellos sin renumeración o tiempo de inactividad prolongado.
Un /24 se hizo visible solo días antes de la publicación
AS56421 pasó de ser una pista de registro a una pista operativa en julio de 2026. Unobjeto de ruta RIPEque autoriza la asociación entre AS56421 y185.243.98.0/24se creó el 7 de julio. Elhistorial de enrutamiento de RIPEstat para el prefijocomenzó a ver a AS56421 como origen el 8 de julio. Esta es una evidencia inusualmente reciente: dice que el ASN controlado por la empresa había llegado al menos a parte del sistema de enrutamiento global, no que lo hubiera hecho durante meses.
A las 12:00 UTC del 10 de julio, elestado BGP de RIPEstat para el bloquecontenía 381 rutas observadas. Veintisiete terminaban en AS56421, mientras que 354 terminaban en AS48693. Los recuentos de los colectores de rutas no son una medida de cuota de mercado o de tráfico, y los colectores no representan a todas las redes. Sí muestran que el nuevo origen tenía una propagación limitada, mientras que el origen establecido seguía siendo mucho más visible en ese momento.
El prefijo contiene 256 direcciones IPv4. Incluso ese simple número debe ser acotado. Las convenciones de red y difusión, las direcciones de enrutador, las prácticas de asignación de clientes, el filtrado y la reserva pueden reducir el espacio asignable. Una dirección puede alojar muchos servicios virtuales detrás de traducción o alojamiento basado en nombres; un cliente dedicado puede consumir varias direcciones. El /24 no revela ni el número de servidores ni la capacidad vendida.
También es la longitud mínima habitual de prefijo IPv4 aceptada por gran parte de la internet global, por lo que es una unidad natural para anunciar incluso para un extremo pequeño.
No se estableció un origen IPv6 de la empresa en la fecha de corte. La evidencia solo IPv4 no hace que un servicio de alojamiento sea inutilizable, pero reduce lo que se ha demostrado. Un servicio moderno puede proporcionar IPv6 a través de una red principal, un proxy u otro acuerdo de enrutamiento sin originar su propio bloque. Simplemente no hay una base pública aquí para decir que 3D CLOUD COMMUNICATION ofrece IPv6 al cliente, gestión de doble pila o una ruta de migración probada entre familias de direcciones.
La corta ventana de observación es el hecho de capacidad más importante. Una ruta visible durante dos días puede transportar tráfico de producción, tráfico de prueba, una migración o un nuevo segmento de clientes. El enrutamiento público no revela cuál. No puede revelar el número de procesadores, la memoria, el almacenamiento, la densidad de virtualización, las unidades de rack ocupadas, el consumo de energía, el compromiso de ancho de banda o las cuentas facturables. Tratar el /24 como prueba de una infraestructura de nube confundiría la alcanzabilidad de direcciones con la capacidad de cómputo.
El mismo bloque aún tenía dos orígenes
El evento de julio no fue un reemplazo limpio en la vista pública. Lavisión general del prefijo de RIPEstatidentificó tanto a AS48693 como a AS56421 como orígenes. Una ruta anunciada desde más de un sistema autónomo se denomina comúnmente condición de origen múltiple o MOAS. Puede ser intencionada: los operadores utilizan anuncios superpuestos durante migraciones, multihoming de clientes, mitigación de DDoS e ingeniería de tráfico. También puede ser el resultado de un error o una originación no autorizada. La observación por sí sola no decide qué explicación se aplica.
Los registros de propiedad mantienen la incertidumbre abierta. Elregistro inetnum de RIPEasigna el bloque a una organización identificada como Rices Privately owned enterprise bajo el nombre de red NTS-03. Suregistro de organizaciónproporciona un registro ucraniano y un dominio de contactontup.net. Unobjeto de ruta para AS48693independiente existía desde diciembre de 2023. El objeto de ruta más reciente para AS56421 se mantenía bajo un mantenedor diferente al del registro de contacto de la empresa.
La denominación inversa también permaneció asociada a la red anterior. Lavista de bloque de IPinfolistabagw.reserved.ntup.netpara la primera dirección de puerta de enlace yfree.ntup.neten gran parte del rango en su observación indexada. El DNS inverso puede retrasarse respecto a una transferencia o arrendamiento legítimo, y las etiquetas genéricasfreeno prueban que las direcciones estén inactivas. Sin embargo, muestran que la denominación pública aún no se había reelaborado en un conjunto de servicios reconocible de 3D CLOUD COMMUNICATION.
La autorización de origen de ruta no resolvió la cuestión. Elresultado de validación RPKI de RIPEstatdevolvióunknown, sin una autorización de origen de ruta validada para la combinación AS56421 y /24. Desconocido no es inválido. Significa que las partes confiadas no tenían una declaración criptográfica en la Infraestructura de Clave Pública de Recursos que autorizara o rechazara este origen. Lavisión general de RPKI de RIPE NCCexplica cómo las autorizaciones de origen de ruta permiten a los titulares especificar qué AS puede anunciar un prefijo.
El riesgo práctico es la divergencia. Algunas redes pueden preferir la ruta a través de AS48693, otras la ruta a través de AS56421, dependiendo de la política y la longitud de la ruta. Si los dos orígenes no conducen al mismo servicio o red coordinada, los usuarios pueden llegar a destinos diferentes o perder la conectividad. Si el acuerdo es intencionado y ambas rutas convergen correctamente, puede respaldar una transición.
Una carta pública de autorización, una autorización de origen de ruta que cubra el origen previsto, un registro de prefijo actualizado y una fecha de migración clara distinguirían una transferencia controlada de una superposición no resuelta.
La política de proveedores registrada es más amplia que el transporte observado
El registro RIPE de AS56421 enumeraba un largo conjunto de relaciones de importación y exportación previstas, incluyendo AS6939, AS5577, AS202171, AS174, AS42602, AS50073, AS203142 y AS1299. El 7 de julio se actualizó de nuevo para añadir AS41033 y AS209155. Esto parece diverso sobre el papel. Sin embargo, una declaración de importación RPSL describe la política de enrutamiento declarada. No prueba que un circuito físico esté instalado, que una sesión BGP esté establecida, que un puerto esté pagado o que la ruta alternativa tenga suficiente capacidad durante un fallo.
En la fecha de corte del 10 de julio, laobservación de vecinos de RIPEstatvio un vecino del lado izquierdo: AS41033. El estado BGP específico del momento también mostró que las rutas de AS56421 pasaban a través de AS41033. Esta es una evidencia operativa de una ruta de proveedor. No es evidencia de que las ocho relaciones registradas más antiguas estuvieran activas al mismo tiempo.
AS41033 es en sí misma una red de interconexión sustancial. Suregistro de PeeringDBidentifica a D2 CLOUD COMMUNICATIONS y enumera presencia pública en intercambios e instalaciones en Kiev, Varsovia, Fráncfort, Ámsterdam y otras ubicaciones. Elsitio webdel operador presenta servicios de red. Estos hechos ayudan a caracterizar al proveedor. No ubican el enrutador de AS56421. Una sesión de cliente puede alcanzar un proveedor de área amplia desde una interconexión local sin ocupar todas las instalaciones que ese proveedor enumera.
Esta distinción es importante para la región Global asignada. Una ruta transportada por una red con alcance internacional hace que un servicio IPv4 sea accesible globalmente. No prueba que 3D CLOUD COMMUNICATION opere infraestructura global o venda en todos los mercados. La ubicación corporativa verificada es Kiev. El borde de enrutamiento verificado utilizó un proveedor conectado internacionalmente. El área de servicio, los países de contratación, las monedas de facturación, los idiomas de soporte y las opciones de ubicación de datos no se establecieron públicamente.
Un solo proveedor observado también deja una pregunta básica de recuperación. Si AS41033 retira la ruta, ¿tiene AS56421 una segunda sesión activa con capacidad independiente? El registro sugiere posibles candidatos, pero una respuesta probada requiere observaciones de rutas simultáneas o documentación del proveedor. Incluso dos rutas AS observadas pueden compartir una entrada de fibra, una sala de interconexión, un enrutador, una alimentación eléctrica o un corredor metropolitano. La diversidad lógica es valiosa; la independencia física requiere evidencia adicional.
Una dirección en Kiev no es un mapa de racks
Los registros legales y de RIPE sitúan a la empresa en la calle Idzykovsky Family 39, en Kiev. Es una dirección registrada y de contacto verificada. No es una ubicación de servidores verificada. Las direcciones corporativas pueden identificar oficinas, gestión de correo, locales comerciales compartidos o instalaciones en las que también hay equipos. Ninguno de los registros de la empresa especifica una suite, rack, jaula, asignación de energía o sala de datos.
La dirección tiene un contexto de telecomunicaciones genuino. Elsitio público de R-TELutiliza la misma dirección postal y anuncia internet para empresas y soporte 24 horas. Elregistro corporativo de R-TELtambién sitúa allí a la empresa de telecomunicaciones. Lapágina de contacto de Orionenumera la dirección para servicios de internet, mientras que elregistro de la empresa inmobiliariaidentifica una entidad en el mismo número cuyas actividades incluyen poseer o arrendar bienes raíces. Estas son señales de ubicación útiles, pero no prueban un contrato, vínculo de propiedad o infraestructura compartida con 3D CLOUD COMMUNICATION.
El edificio podría ofrecer acceso a operadores y espacio técnico, o simplemente alojar a varios inquilinos no relacionados. Una fotografía de la sala de servidores de otro operador no establecería la propiedad de las máquinas de la empresa. Una dirección postal común no establecería una ruta de fibra protegida. La evidencia necesaria es ordinaria y específica: el nombre del operador de la instalación, país y ciudad, si la empresa posee o alquila espacio de rack, límites de energía del rack, entradas de operadores, proveedores de interconexión, controles de acceso y la parte responsable de las manos remotas.
La ubicación física determina más que la latencia. Determina la red eléctrica, la logística de combustible del generador, el entorno de refrigeración, los controles de incendios, la exposición a la defensa civil, el desplazamiento de los técnicos y la ley que rige los datos almacenados. Kiev opera bajo la presión de infraestructura en tiempo de guerra. Ese contexto hace que la continuidad de la energía y la recuperación geográfica sean especialmente importantes, pero no debe utilizarse para asumir un fallo particular. La empresa no ha publicado el diseño de su sitio, la duración de la energía de respaldo o la ubicación de recuperación.
Por lo tanto, un cliente debe resistir dos errores opuestos. El primero es inferir que la dirección legal es un centro de datos y atribuir todos los activos de telecomunicaciones cercanos a la empresa. El segundo es inferir que no existe infraestructura porque no se encontró un mapa del sitio público. Los pequeños proveedores a menudo operan desde espacios alquilados sin un marketing extenso. La evaluación correcta es más limitada: un nexo operativo en Kiev es plausible y la dirección tiene asociaciones de telecomunicaciones, pero la ubicación y propiedad de los racks siguen sin verificarse.
Cada instancia alojada se asienta sobre una cadena física y contractual
Ya sea que la oferta sea un servidor privado virtual, un servidor gestionado o una instancia en la nube, la unidad visible para el cliente depende de una pila de activos finitos. En la base se encuentran un edificio, acometida eléctrica, aparamenta, baterías, generadores u otro suministro de respaldo, refrigeración, controles de incendios y seguridad física. Por encima se sitúan racks, distribución de energía, servidores, almacenamiento, conmutadores, enrutadores, óptica y cableado. El tránsito, el espacio de direcciones y el enrutamiento hacen que el sistema sea accesible.
La facturación, la monitorización, las copias de seguridad, las credenciales y los técnicos convierten la maquinaria en un servicio.
La evidencia pública de la empresa solo verifica fragmentos de esta cadena. La actividad registrada apunta al alojamiento. La observación BGP de julio apunta a un borde de red accesible. La dirección de Kiev apunta a una ubicación legal y de contacto. No verifica una sala de datos, un solo servidor, una matriz de almacenamiento o un cliente de pago. No se vinculó públicamente a la empresa ningún operador de instalaciones, proveedor de equipos, capa de virtualización, plataforma de copias de seguridad o sistema de monitorización.
Esto crea una frontera de propiedad que un contrato debe resolver. La empresa puede ser propietaria del hardware, pero alquilar el rack y la energía. Puede alquilar servidores de otro anfitrión y controlar solo el software y la facturación. Puede revender instancias virtuales y no operar ninguna máquina física. Puede proporcionar gestión para sistemas propiedad del cliente. Cada acuerdo puede ofrecer un servicio legítimo, pero cambia quién es responsable del fallo. Un fallo de energía en la instalación se escala de manera diferente a un fallo de una unidad arrendada; una disputa de tránsito es diferente a una suscripción de cliente caducada.
Los registros de prefijos añaden otra capa contractual. El bloque IPv4 visible sigue asignado a Rices Privately owned enterprise, mientras que AS56421 lo originó a través de AS41033. Ese acuerdo podría ser un uso autorizado de tipo independiente del proveedor, un arrendamiento o una transición, pero los registros públicos no indican los términos comerciales. Si el acceso al bloque depende del acuerdo de otra parte, la rescisión o disputa puede forzar la renumeración. Para los clientes que incluyen direcciones en listas blancas, publican registros DNS o vinculan licencias a IP, la renumeración puede convertirse en una interrupción del negocio.
Lo mismo ocurre con el transporte del proveedor. Si un proveedor suministra todo el tránsito utilizable actualmente, un fallo en el pago o en el contrato puede eliminar la accesibilidad incluso mientras los servidores permanecen encendidos. Si una relación de reventa suministra el hardware, los pagos atrasados pueden amenazar el acceso a la computación por separado. La factura de la nube oculta estas dependencias porque el cliente paga a una sola contraparte. La diligencia debida debe reconstruir la cadena e identificar dónde la empresa puede reparar directamente y dónde solo puede abrir un ticket con otra persona.
La capacidad instalada no es capacidad utilizable
El único activo de red cuantificado de cara a la empresa en la vista pública es un /24: 256 direcciones IPv4. No hay velocidad de puerto verificada, tasa de datos comprometida, asignación de ráfagas, almacenamiento total, número de núcleos, reserva de memoria, número de racks o asignación de energía. Incluso si esas cifras se anunciaran, cada una necesitaría interpretación. Las interfaces instaladas no son lo mismo que el margen de tráfico, y el almacenamiento bruto no es lo mismo que la capacidad protegida para el cliente.
Considere un enlace ascendente hipotético de 10 Gbps. Su etiqueta describiría la velocidad de la interfaz, no el compromiso de tránsito, el rendimiento sostenido, el límite de paquetes por segundo o la capacidad disponible después de que otro circuito falle. Un contrato de un gigabit en un puerto de diez gigabits puede congestionarse a un gigabit. Dos puertos de diez gigabits en un enrutador pueden fallar juntos. Actualmente no se puede atribuir ninguna cifra de puerto a 3D CLOUD COMMUNICATION, por lo que ni siquiera se puede hacer esta comparación elemental.
La capacidad de cómputo tiene trampas similares. Un host puede contener docenas de núcleos de procesador mientras que la sobresuscripción hace que las cargas de trabajo ocupadas compitan. El almacenamiento de aprovisionamiento fino puede mostrar mucho más espacio lógico que el medio físico. Las copias de réplica pueden mejorar la disponibilidad mientras consumen capacidad que no es vendible. Los datos de copia de seguridad pueden compartir la misma matriz o dominio de energía que la producción. Sin evidencia de utilización, reserva, dominio de fallo y restauración, un número de catálogo aún no establecería la resiliencia utilizable.
El recuento de direcciones IPv4 es especialmente débil como indicador. El alojamiento virtual puede situar muchos dominios detrás de una dirección; los servicios dedicados pueden usar una dirección por instancia; los dispositivos de red y las asignaciones de repuesto consumen otras. Lavista de prefijos anunciados de RIPEstatque muestra un /24 dice que el borde tenía una pequeña huella IPv4 enrutable. No dice nada sobre cuántas direcciones se asignaron a los clientes o si el bloque transportaba servicios de cómputo en absoluto.
Una declaración de capacidad creíble separaría los recursos instalados, encendidos, contratados, ocupados y disponibles. Para la red, eso significa velocidad de puerto, compromiso pagado, pico normal, pico en estado de fallo y diversidad de rutas. Para el cómputo, significa hosts físicos, sobrecarga reservada, política de asignación y margen restante. Para el almacenamiento, significa capacidad bruta, protegida, utilizada y restaurable. Ninguna de estas capas es pública para la empresa, por lo que el artículo no puede convertir responsablemente la nueva ruta en una afirmación de capacidad disponible para el cliente.
La primera ruta de fallo es la propia ruta
La condición MOAS de julio es la ruta de fallo observable más inmediata. Si AS48693 y AS56421 conducen intencionadamente al mismo punto final, la coordinación debe mantener ambas rutas consistentes durante la transición. Si conducen a puntos finales diferentes, la selección de ruta puede dividir a los usuarios. Una retirada accidental por parte de un origen puede mejorar o empeorar la accesibilidad dependiendo de la ruta que prefiriera una red. Sin autorización de origen de ruta, la validación criptográfica del origen no aclara el origen previsto.
Una entrada de objeto de ruta es útil, pero no es un control de seguridad completo. BGP, estandarizado en elRFC 4271, intercambia accesibilidad según la política y los atributos de ruta; no autentica de forma nativa que la organización originaria sea propietaria del prefijo. RPKI, cuya arquitectura se describe en elRFC 6480, permite a los titulares de direcciones hacer declaraciones de origen verificables. Una autorización válida no evitaría todas las fugas o cortes, pero reduciría la ambigüedad para las redes que aplican la validación de origen de ruta.
La siguiente ruta de fallo es la pérdida del proveedor. En la observación específica del momento, AS41033 era el único vecino visible para AS56421. Un fallo del enrutador, un fallo de interconexión, una suspensión comercial o un error en la política del proveedor podrían eliminar el nuevo origen. La lista más larga en el registro puede convertirse en redundancia real, pero hasta que aparezcan múltiples rutas activas y puedan transportar la carga completa, sigue siendo una política planificada o histórica en lugar de una capacidad de recuperación demostrada.
Luego viene el borde local. La evidencia pública no muestra si AS56421 se ejecuta en uno o varios enrutadores, si las sesiones de ruta terminan en chasis separados o si las configuraciones están respaldadas. Una sola fuente de alimentación fallida, una configuración corrupta, una óptica caducada o una consola inaccesible pueden anular múltiples proveedores nominales. El hardware de repuesto y el acceso fuera de banda a menudo determinan el tiempo de recuperación más que el número de operadores en un registro.
Finalmente, está la continuidad de DNS y direcciones. Los nombres inversosntup.netmás antiguos sugieren que la administración de nombres aún cruza una frontera organizativa. El DNS directo del cliente puede estar en otro lugar, pero no se identificó ningún servicio autoritativo. Durante una migración de prefijo, el DNS obsoleto, las listas blancas, los enlaces TLS, las bases de datos de geolocalización y la reputación antiabuso pueden seguir apuntando a la red anterior. El movimiento técnico solo se completa cuando esos sistemas circundantes se actualizan y los clientes saben qué cambió.
La energía, el stock de hardware y la reparación humana siguen siendo espacios en blanco
Una ruta de red puede parecer saludable mientras todos los servidores de clientes detrás de ella están indisponibles. El servicio físico depende de la energía y la refrigeración en cada rack. Ninguna declaración pública proporciona las acometidas de servicios públicos de la empresa, la configuración del SAI, la capacidad del generador, la duración del combustible, la redundancia de refrigeración o el programa de mantenimiento. La dirección compartida de Kiev no puede llenar esos campos porque los operadores cercanos pueden usar diferentes salas, acometidas y contratos.
El inventario de hardware es igualmente importante para un pequeño proveedor. Un disco fallido puede ser rutinario si existen repuestos compatibles y una réplica probada. Puede convertirse en una interrupción prolongada si un reemplazo debe cruzar una frontera, si el firmware difiere o si el único ingeniero capacitado no está disponible. La empresa no ha revelado los proveedores de servidores, la protección del almacenamiento, las proporciones de repuestos, las condiciones de manos remotas o los objetivos de reemplazo. Esto no es evidencia de que no haya repuestos; significa que el tiempo de reparación no puede estimarse públicamente.
La mano de obra de soporte es parte de la capacidad. Una CPU anunciada sigue siendo inutilizable si nadie puede recuperar un host fallido o restablecer una cuenta bloqueada. El registro de la empresa identifica a un director y los registros de RIPE identifican a una persona administrativa nombrada detrás del rol. No se encontró un total de personal, horarios de soporte, ruta de escalación o cobertura de idiomas. La etiqueta "soporte" por sí sola no puede sustituir una respuesta probada a tickets.
La facturación también pertenece al mapa de fallos. Un nuevo proveedor puede depender de facturas manuales, un procesador de pagos o un panel de revendedor. Un error de facturación puede suspender el servicio tan eficazmente como un enrutador roto. Los clientes necesitan períodos de gracia, manejo de disputas, avisos de renovación y una forma de exportar datos antes de la rescisión. Ningún término público establece esas protecciones para 3D CLOUD COMMUNICATION.
La evidencia de nivel de servicio más útil sería mundana: una dirección de soporte en el propio dominio de la empresa, definiciones de gravedad, objetivos de respuesta y restauración, reglas de aviso de mantenimiento, términos de crédito y una escalación telefónica probada. Un proveedor puede ser pequeño y aun así publicar obligaciones claras. En este caso, el contacto público basado en Outlook en las vistas de registro y el rol genérico establecen accesibilidad para la administración de la red, no un compromiso de soporte al cliente.
La redundancia necesita dominios de fallo separados
La resiliencia debe probarse capa por capa. Dos máquinas virtuales en un host no protegen contra el fallo del host ni la pérdida de energía del rack. Dos hosts en un rack pueden proteger contra un fallo de placa base, pero no contra una unidad de distribución de energía fallida. Dos racks en una sala pueden compartir refrigeración y energía del edificio. Dos sitios conectados a través de un operador pueden compartir la misma ruta. La redundancia solo existe cuando la alternativa sobrevive al fallo relevante.
No se verificó un segundo sitio de 3D CLOUD COMMUNICATION. Ningún material público nombra una región de respaldo, zona de disponibilidad, ubicación de réplica o localidad seleccionable por el cliente. AS39755 no proporciona esa evidencia porque no tenía ruta actual. La larga lista de importación de AS56421 no la proporciona porque la política de ruta no ubica el cómputo. El alcance global de AS41033 no la proporciona porque la lista de instalaciones de un proveedor no es la lista de instalaciones del cliente.
La recuperación también requiere estado. El tráfico web sin estado puede moverse rápidamente si el DNS, los certificados y el despliegue de la aplicación están preparados. Una base de datos necesita réplicas consistentes o copias de seguridad restaurables. Una máquina virtual puede necesitar imágenes de disco, claves, configuraciones de red y suficiente cómputo de repuesto en el destino. La empresa no ha publicado objetivos de punto de recuperación o tiempo de recuperación, retención de copias de seguridad, resultados de pruebas de restauración o el alcance de cualquier oferta de recuperación ante desastres.
Laevaluación de riesgos de computación en la nube de ENISAtrata la dependencia del proveedor, el manejo de datos, la continuidad del negocio y el fallo técnico como riesgos conectados. Ese marco se ajusta a este caso. Un segundo sitio solo importa si el cliente puede acceder a él, los datos están allí, el sistema de identidad funciona, el proveedor tiene autoridad para activarlo y el contrato permite el movimiento. Un marcador en un mapa por sí solo no es recuperación.
La evidencia que aumentaría la confianza incluye dos instalaciones nombradas en dominios de energía y riesgo metropolitano distintos, rutas activas a través de proveedores independientes, replicación documentada, un ejercicio de restauración reciente e instrucciones para que el cliente exporte datos. La evidencia que la aumentaría aún más incluye tiempos de recuperación medidos y la confirmación de que la capacidad de red y cómputo de la ruta de respaldo puede transportar la carga de producción. Nada de esto era público en la fecha de corte.
La localidad de los datos no puede inferirse de la dirección de la empresa
El tema asignado de soberanía de datos es relevante precisamente porque la ubicación no está resuelta. Una dirección legal en Kiev establece el nexo jurisdiccional de la empresa. No establece dónde se almacenan los datos de los clientes, las copias de seguridad, los registros o las copias de soporte. Un servidor podría estar en el mismo edificio, en otro lugar de Ucrania, en otro país europeo o en la plataforma de un subcontratista. La ruta a través de AS41033 no responde a esa pregunta: los paquetes pueden atravesar una ciudad o un país sin que los datos se almacenen allí.
Los clientes necesitan cuatro ubicaciones, no una. La primera es el sitio de cómputo principal. La segunda es el sitio de respaldo o réplica. La tercera es la ubicación desde la que los administradores pueden acceder a los datos. La cuarta es la ubicación legal de cada subcontratista que puede procesarlos o recuperarlos. Estas pueden diferir. Un contrato que solo diga que el proveedor es ucraniano deja abierta la geografía física y operativa.
La portabilidad es la otra cara de la soberanía. Un cliente debe saber si puede exportar discos virtuales, volcados de bases de datos, datos de objetos, registros y claves de cifrado en formatos utilizables. Debe saber cuánto tarda una exportación, qué límites de ancho de banda se aplican y si las tarifas o los atrasos pueden bloquear el acceso. El nuevo /24 y la superposición continua de direcciones hacen que la portabilidad de red sea particularmente concreta: un cliente no debe asumir que una IP asignada puede seguirle a otro proveedor.
Las rutas de migración también necesitan tiempo y cooperación. Los valores de tiempo de vida del DNS pueden reducirse, las réplicas pueden sembrarse y los datos pueden copiarse antes de un corte. Pero un contrato de proveedor fallido puede eliminar el tiempo necesario para un movimiento ordenado. No se encontraron términos públicos de rescisión, eliminación, depósito en garantía o exportación para 3D CLOUD COMMUNICATION. Los compradores deben tratar la salida de datos como una dependencia sin precio y no verificada hasta que se proporcionen esos términos.
La evidencia no respalda una afirmación de que los datos de los clientes estén fuera de Ucrania, ni respalda una afirmación de que permanezcan dentro. Solo respalda la necesidad de un cronograma de localidad por escrito. Ese cronograma debe identificar ciudades y países, operadores de instalaciones, geografía de respaldo, administración remota, subencargados, tiempos de eliminación y la ley que rige las disputas. Sin él, "Global" describe el alcance potencial de la red, no una oferta verificada de residencia de datos.
La economía del alojamiento concentra el riesgo en contratos que el cliente no puede ver
Los pequeños proveedores de alojamiento pueden competir comprando insumos al por mayor y añadiendo una gestión receptiva. La economía puede ser atractiva: las unidades de rack alquiladas evitan construir una instalación; los servidores alquilados reducen el gasto de capital; el tránsito y los acuerdos de direcciones pueden adquirirse de forma incremental; un equipo pequeño puede automatizar el aprovisionamiento rutinario. Los clientes pueden recibir una atención más directa de la que recibirían de una plataforma a hiperescala. Ninguna de estas ventajas requiere que el proveedor sea propietario de un edificio.
La misma estructura crea dependencia de la renovación y el margen. El alquiler del rack, la energía, el tránsito, el uso de direcciones, los arrendamientos de hardware, las licencias y la mano de obra de soporte son obligaciones recurrentes. Un proveedor puede vender capacidad solo mientras esos contratos permanezcan financiados y coordinados. Un precio introductorio bajo puede ser sostenible si la automatización y la utilización son fuertes, o frágil si omite los costos de reemplazo, respaldo y soporte. Ninguna lista de precios pública o estado financiero permite esa distinción aquí.
El capital social de 600 000 UAH no debe interpretarse como gasto en infraestructura. Puede respaldar las operaciones de inicio, pero la cifra legal no dice si compró equipos, permanece líquida o cubre alguna responsabilidad particular. La página pública de la empresa no proporcionó ingresos, activos, deuda, número de empleados o cuentas auditadas para un año operativo completo. La empresa tenía menos de un año en la fecha de corte de la investigación.
La acción técnica más reciente — originar un /24 a través de un proveedor observado — es consistente con un negocio que comienza o cambia sus operaciones de red. No es suficiente para estimar la escala. El bloque puede soportar un pequeño conjunto de servidores, una transición de red, un cliente, un entorno de prueba o inventario futuro. Los nombres inversos que dicenfreeson sugerentes pero no decisivos. Un catálogo de cara al mercado, facturas, referencias de clientes, informes de utilización o un historial de estado del servicio proporcionarían una evidencia operativa más sólida.
Para un comprador, la pregunta económica clave es quién debe seguir recibiendo pagos para que el servicio funcione. Eso incluye la instalación, la electricidad, el proveedor, la contraparte del espacio de direcciones, el arrendador de equipos, el proveedor de software y el personal de soporte. El proveedor debe poder identificar qué dependencias son prepagadas, mensuales o cancelables, y qué sucede con los datos del cliente si un contrato termina. Una sola tarifa mensual baja no es una medida de resiliencia a menos que financie esas obligaciones.
Las señales no oficiales solo son útiles cuando se indican sus límites
Varias señales públicas apuntan en una dirección coherente. La empresa eligió una actividad de alojamiento, adoptó un nombre de nube, creó contactos RIPE, se convirtió en la organización en dos registros de sistemas autónomos e inició un nuevo origen a través de un proveedor con marca de nube. Su dirección registrada es compartida por empresas de telecomunicaciones. En conjunto, estos hechos sugieren un intento de establecer o adquirir una operación de alojamiento y red en Kiev.
No pueden probar un lanzamiento de producto, una base de clientes, una flota de servidores o una tenencia de instalaciones. La superposición de direcciones no puede probar una relación con R-TEL u Orion. La lista de instalaciones del proveedor no puede probar dónde se encuentra el enrutador de la empresa. El DNS inverso no puede probar que las direcciones no estén utilizadas. Un objeto de ruta no puede probar que todas las partes comerciales relevantes aprobaron el origen. El MOAS no puede probar ni una transición benigna ni un evento hostil sin más contexto.
La secuencia de fechas es en sí misma una señal: constitución de la empresa en julio de 2025, organización y contactos RIPE a finales de diciembre, actualizaciones de ASN el 2 de enero de 2026, un objeto de ruta el 7 de julio y originación observada desde el 8 de julio. Esto parece una preparación por etapas seguida de la activación de la red. También podría reflejar una transferencia administrativa cuyo servicio comercial aún no es público. La evidencia establece la cronología, no el propósito.
Lo que resolvería la cuestión comercial es sencillo. Un sitio web controlado por la empresa debería nombrar al vendedor legal y el número de empresa, describir productos y precios, publicar términos, identificar canales de soporte, revelar ubicaciones de datos y explicar la cancelación. Lo que resolvería la cuestión de infraestructura es una declaración de instalaciones y red que identifique los límites del operador de rack, los proveedores activos, la autorización de ruta, los compromisos de puerto, IPv6, sitios de respaldo y recuperación probada.
Lo que resolvería la cuestión del estado operativo es un enrutamiento sostenido más actividad orientada al cliente a lo largo del tiempo.
Hasta que aparezcan esos materiales, la rebaja correcta es explícita. La empresa no es un nombre ficticio: es una LLC ucraniana registrada con registros de red actuales y una ruta reciente. Pero el caso público para una nube fiable orientada al cliente sigue estando incompleto. La diferencia protege tanto a los lectores como a la empresa de afirmaciones que la evidencia no puede sostener.
Un comprador debe hacer que la cadena de dependencia sea contractual
Antes de colocar una carga de trabajo de producción, un cliente debe pedir a la empresa que identifique a la parte contratante legal como LLC "3D CLOUD COMMUNICATION" y utilice el número de empresa 45920348 en el acuerdo y la factura. El acuerdo debe indicar si el servicio es reventa, alojamiento gestionado, servidor privado virtual, bare metal, colocalización u otra forma. Debe identificar qué activos posee la empresa y cuáles son suministrados por otros operadores.
El anexo de red debe indicar los prefijos del cliente, los proveedores, el AS de origen esperado, el estado de la autorización de origen de ruta y el diseño de conmutación por error. Para el /24 actualmente visible, debe explicar los anuncios concurrentes de AS48693 y AS56421, identificar la autorización del titular de las direcciones y dar una fecha de finalización si se trata de una migración. Los clientes deben saber si las direcciones son portables, cómo se maneja la renumeración y si un cambio de ruta genera un aviso.
El anexo de instalaciones debe nombrar la ciudad, el país y el operador para el servicio principal y de respaldo. Debe describir la energía del rack, la energía de respaldo, la refrigeración, el acceso físico, las manos remotas y las entradas de operadores a un nivel apropiado para la diligencia debida. Los planos de planta detallados son innecesarios; los límites de propiedad y fallo no lo son. Si solo hay un sitio, el acuerdo debe decirlo claramente y evitar implicar redundancia geográfica.
El anexo de servicio debe definir la disponibilidad, las exclusiones, el mantenimiento, la gravedad, la respuesta, la restauración, los créditos y la escalación. Debe indicar qué se respalda, con qué frecuencia, dónde residen las copias, cuánto tiempo se conservan y cómo se prueban las restauraciones. Debe decir qué fallos repara directamente la empresa y cuáles dependen de un ticket de la instalación o del proveedor. También debe abordar la pérdida de un ingeniero nombrado.
El anexo de salida debe ser tan detallado como el pedido. Los clientes necesitan formatos de imagen de máquina y exportación de datos, límites de rendimiento y tarifas, retención después de la cancelación, confirmación de eliminación, acceso durante disputas y asistencia durante la migración. Deben conservar sus propias copias de seguridad y credenciales independientes. Un servicio del que no se puede salir de manera predecible no está totalmente controlado por el cliente, independientemente de lo fácil que fuera su compra.
Finalmente, la evidencia debe actualizarse después de la transición de enrutamiento de julio. La visibilidad sostenida del origen, la eliminación o explicación del origen más antiguo, una autorización de origen de ruta válida, un tránsito alternativo activo y una denominación inversa consistente mejorarían materialmente la confianza en la red. Una página de producto pública, términos legales e historial de estado mejorarían la confianza comercial. La evidencia de instalaciones y restauración mejoraría la confianza en la resiliencia. Cada una cierra una brecha diferente; ninguna puede sustituir a todas las demás.
La calificación honesta es un borde activo con evidencia de servicio débil
Hay más aquí que un nombre en un catálogo de empresas. LLC 3D CLOUD COMMUNICATION está activa en los registros corporativos ucranianos. Tiene una actividad principal relacionada con el alojamiento. Sus registros de organización y contacto RIPE son coherentes con la identidad legal. AS56421 comenzó a aparecer como origen de un bloque IPv4 a través de un proveedor observado inmediatamente antes de la publicación. Estos son hechos significativos.
Los hechos se quedan cortos respecto a la implicación comercial más fuerte del titular. No se verificó ninguna oferta orientada al cliente vinculada a la empresa. No se estableció ningún rack, servidor, plataforma de almacenamiento, centro de datos, velocidad de puerto, segundo sitio o compromiso de soporte. El único bloque visible permaneció en un estado de origen múltiple, asignado a otra organización, con estado RPKI desconocido y denominación inversa más antigua. El segundo ASN registrado estaba inactivo. El área de servicio y la geografía de datos permanecieron sin especificar.
Esa combinación respalda una calificación de evidencia de red Débil, no una conclusión de que la empresa está inactiva. Es un operador legal joven con un borde recién activo y una gran brecha de divulgación. La ruta puede madurar, la transición de direcciones puede completarse y puede surgir material comercial. A fecha del 10 de julio de 2026, los compradores deben tratar la capacidad alojada, la redundancia y el servicio global como afirmaciones que requieren prueba directa.
La lección física es más amplia pero específica de la empresa en sus detalles. Un nombre de nube puede registrarse en un día; un ASN puede ser anterior a su titular actual por quince años; un /24 puede aparecer a través de un proveedor de tránsito en horas. El alojamiento fiable lleva más tiempo porque requiere que la energía, el hardware, los repuestos, los contratos, las personas, las copias de seguridad y las salidas ensayadas funcionen juntos. Para support 3D CLOUD COMMUNICATION, esas dependencias son la sustancia que aún está por demostrar.