Resumen
- LUNAR HOSTING LTD es una empresa británica activa constituida el 19 de abril de 2026. Su AS198685 origina actualmente dos rutas IPv4 /24, una registrada con una etiqueta de país Alemania y una geolocalización en Falkenstein, la otra con una etiqueta de país Países Bajos. Las observaciones públicas actuales no muestran rutas IPv6 y solo una red vecina visible.
- La evidencia de red respalda una conclusión limitada: una pequeña huella de alojamiento enrutado está operando bajo el nombre Lunar. No prueba la propiedad de un centro de datos, inventario de servidores, energía redundante, tránsito independiente, cobertura de respaldo, personal de soporte o una ruta de salida probada.
- Un comprador debe tratar la resiliencia, la localidad de los datos y la recuperabilidad como preguntas contractuales abiertas. La evidencia más importante serían las instalaciones nombradas, el hardware y la responsabilidad upstream, los resultados de restauración probados, los términos de disponibilidad específicos del servicio, los tiempos de escalado del soporte y un método documentado para exportar cargas de trabajo completas.
Una empresa puede obtener un ASN más rápido de lo que puede construir resiliencia
LUNAR HOSTING LTD presenta una historia de infraestructura comprimida. La empresa británica actual fueconstituida el 19 de abril de 2026, con el número de empresa 17166654 y una oficina registrada en 42 Rupert Street en Londres. El registro la describe como activa y le asigna dos clasificaciones comerciales: consultoría de tecnología de la información, y procesamiento de datos, alojamiento y actividades relacionadas. El registro RIPE para AS198685 se creó al día siguiente. Para julio, los colectores de rutas podían ver dos /24 IPv4 originados por ese sistema autónomo.
Estos no son logros triviales. Un número de sistema autónomo permite a un operador expresar una política de enrutamiento bajo su propio identificador. Una ruta visible significa que otras redes están aceptando y propagando un camino hacia las direcciones. Una autorización de origen de ruta puede decir a las redes validadoras que el AS nombrado está autorizado para originar un prefijo. En conjunto, estas características son una evidencia operativa más sólida que un nombre de empresa, una página de redes sociales o un dominio inactivo.
Sin embargo, siguen siendo solo el borde de red de un servicio de alojamiento. No dicen si Lunar posee un solo servidor. No muestran un arrendamiento de un rack, una asignación de energía, discos de repuesto, condiciones de manos remotas, medios de respaldo, un clúster de hipervisores o un técnico de guardia. Dicen aún menos sobre la maquinaria comercial detrás de las máquinas: si una disputa de factura puede suspender un rack, si un proveedor puede reclamar direcciones, o si un cliente puede extraer una imagen funcional antes de que finalice un contrato.
Esta distinción importa porque las pequeñas empresas de alojamiento a menudo venden un objeto comercial mientras lo ensamblan a partir de varios objetos físicos y contractuales. El cliente ve un servidor virtual privado, una máquina dedicada o un servicio gestionado. El proveedor puede estar combinando hardware alquilado, espacio de direcciones subasignado, un ASN patrocinado, tránsito de terceros, un contrato de instalación, filtrado anti-DDoS y un panel de facturación. Cada componente puede ser legítimo y ejecutarse de manera competente.
Pero cada uno también tiene su propia fecha de renovación, modo de fallo y parte con el poder de desconectarlo.
Por lo tanto, la evidencia pública respalda una descripción estrecha. Lunar es una empresa británica recientemente constituida, asociada a un ASN asignado recientemente y una pequeña huella IPv4 globalmente visible. No respalda la afirmación mayor de que Lunar posee un centro de datos, controla múltiples sitios independientes o ha demostrado continuidad bajo fallos. Esa afirmación mayor requeriría evidencia más cercana a las máquinas y contratos de lo que proporciona la tabla de enrutamiento.
También existe una empresa británica más antigua con el mismo nombre, número de empresa 15058184, que fuedisuelta el 14 de enero de 2025. Su dirección registrada y clasificación comercial difieren de la empresa activa. Nada en el registro de red actual requiere que las dos empresas estén conectadas, por lo que el homónimo disuelto no debe usarse para inferir historia, responsabilidades o continuidad de la empresa 17166654. El ancla más segura es el número de empresa activo repetido en el registro de organización RIPE actual.
Dos /24 son capacidad visible, no un censo de máquinas
El 12 de julio de 2026, lavista de prefijos anunciados de RIPEstatlistaba 144.31.136.0/24 y 94.183.224.0/24 bajo AS198685. Eso son 512 direcciones IPv4 en bloques enrutables. Suvista de estado de enrutamientomostraba ambos prefijos visibles para los 326 pares IPv4 en la muestra relevante del Servicio de Información de Enrutamiento de RIPE. No mostraba espacio IPv6 anunciado.
El recuento de direcciones es útil, pero solo dentro de límites estrictos. Un /24 puede soportar muchas direcciones de clientes, un número menor de servicios de traducción de direcciones de red, interfaces de infraestructura, asignaciones de repuesto o direcciones retenidas debido a la reputación y la política operativa. Puede estar frente a un gran clúster de virtualización o un conjunto muy pequeño de hosts. También puede moverse entre proveedores físicos mientras la IP enfrentada al cliente permanece sin cambios.
Contar direcciones no puede revelar núcleos de procesador, memoria, rendimiento de almacenamiento, sobresuscripción, densidad de racks o el número de inquilinos que pagan.
La diferencia entre capacidad instalada y utilizable es aún mayor. La capacidad instalada es lo que existe en un rack o cuenta de proveedor: máquinas, discos, puertos y software con licencia. La capacidad utilizable es lo que se puede vender sin violar objetivos de rendimiento, reservas de redundancia o supuestos de reparación. Si hay diez servidores instalados pero cada cliente depende del mismo controlador de almacenamiento o switch de top-of-rack, la tolerancia a fallos útil puede ser mucho menor de lo que sugiere el recuento de servidores.
Si cada dirección sale por una sola ruta externa, agregar máquinas aumenta la capacidad de ingresos sin aumentar la diversidad de rutas.
Lunar no ha publicado suficiente material verificable para calcular ninguna de las dos medidas. No hay un inventario público que vincule los dos prefijos con recuentos de hosts, generaciones de procesadores, diseño de almacenamiento o capacidad de repuesto reservada. No hay una serie de utilización pública que muestre si el servicio está vacío, cómodamente cargado o funcionando cerca de un límite de recursos. Un servicio secundario de datos de red,IPinfo, clasificó el AS como alojamiento, contó un pequeño conjunto de dominios alojados y describió actividad durante todo el día cuando se observó. Esos son signos útiles de que las direcciones llevan tráfico. No pueden identificar clientes, validar facturas o probar que la capacidad comercial anunciada está disponible.
Aquí es donde la economía del alojamiento se vuelve física. Un servidor virtual de bajo costo puede crearse en segundos solo porque alguien previamente compró o alquiló un chasis, lo alimentó, lo conectó, instaló almacenamiento y reservó suficiente memoria para admitir otro invitado. El acto marginal es digital; la capacidad subyacente no lo es. Cuando un proveedor tiene una huella pública delgada, un cliente no puede sustituir de manera segura la velocidad de aprovisionamiento por evidencia de margen sostenido.
Una declaración seria de capacidad identificaría la clase de servicio y su recurso limitante. Para un servidor virtual, eso podría incluir si la CPU es dedicada o compartida, si el almacenamiento es local o en red, qué límite de IOPS se aplica y cuánta reserva para fallos de host existe. Para metal desnudo, incluiría el estado del stock, los objetivos de piezas de repuesto y si se puede proporcionar hardware equivalente en otro sitio.
Para servicio gestionado, incluiría el límite de mano de obra: quién parchea el host, quién responde fuera del horario laboral, y con qué rapidez actuará el proveedor cuando el cliente no pueda alcanzar la máquina.
Sin esas divulgaciones, la afirmación más sólida es que Lunar controla el origen actual de dos rutas IPv4 globalmente visibles. Esa es una capacidad de red real. No es un proxy fiable para la capacidad de cómputo, la durabilidad del almacenamiento o el número de fallos que el servicio puede absorber.
La evidencia de ubicación apunta a Alemania y los Países Bajos, con importantes salvedades
Los dos bloques de direcciones llevan diferentes señales de localidad en los registros RIPE. El objeto inetnum para 144.31.136.0/24 etiqueta el bloquelunar-cloud, le asigna un código de país Alemania y vincula unageolocalización que sitúa el /24 en Falkenstein. El objeto inetnum para 94.183.224.0/24 etiqueta el bloqueLUNAR_HOSTING_LTDy le asigna un código de país Países Bajos. Estos campos son relevantes porque son afirmaciones específicas adjuntas a los recursos de direcciones.
No son un sustituto de una dirección de instalación. Los campos de país de RIPE son atributos administrativos, y una geolocalización es una declaración de ubicación publicada por el operador destinada a mejorar la geolocalización IP. Ninguno establece dónde está atornillado un disco en un rack, dónde se copian las copias de seguridad, o desde dónde un administrador puede acceder a los datos del cliente. La guía deprotección de activos y resilienciadel NCSC separa explícitamente los países de almacenamiento, procesamiento y gestión de la base legal del proveedor, la ubicación del soporte y la propiedad del centro de datos físico. El registro público de Lunar deja la mayoría de esas capas sin nombre.
Falkenstein es lo suficientemente específico como para formar una hipótesis comprobable: al menos algunas direcciones en 144.31.136.0/24 están destinadas a ser representadas como en esa ciudad alemana. No es suficiente para atribuir el hardware de Lunar a ningún operador de instalación en particular. Varias empresas operan infraestructura en y alrededor de las principales ubicaciones de alojamiento europeas, y una ubicación IP por sí sola no identifica al propietario, al dueño del servidor o al contratista de manos remotas.
La etiqueta de Países Bajos en el segundo bloque es más amplia y no proporciona un anclaje público a nivel de ciudad en el objeto RIPE revisado para este artículo.
Las capas corporativa y web añaden más geografía sin resolver la cuestión física. Lunar está registrada en Gran Bretaña. Su dominiolunarhost.proredirigía alunarcloud.rucuando se probó el 12 de julio, mientras que el destino presentaba una página de verificación anti-DDoS. El endpoint DNS del escaparate no estaba en AS198685. Esta separación es común en el alojamiento: un sitio de ventas puede usar un borde protector incluso cuando los servidores de los clientes usan las rutas propias del proveedor. También significa que la disponibilidad continua de la página web dice poco sobre la salud de las máquinas de los clientes, y una interrupción en AS198685 no necesita derribar el sitio de ventas.
Para un cliente del Reino Unido que maneja información personal, la pregunta correcta no es simplemente: "¿El proveedor es británico?" La guía detransferencias internacionalesactualizada de la ICO pide a las organizaciones que comprendan las entidades legales separadas, los contratos y los flujos de información involucrados. El acceso remoto por parte de una organización extranjera separada puede ser relevante incluso si los bytes permanecen en un servidor en Europa. Por el contrario, el tráfico que simplemente transita por otro país no es automáticamente lo mismo que una transferencia restringida. El mapa fáctico debe incluir almacenamiento, copia de seguridad, administración y soporte.
Los dos prefijos con etiquetas de país de Lunar hacen de la localidad de los datos un problema de diligencia debida de primer orden, no un punto de venta resuelto. La evidencia necesaria es concreta: el país de la instalación seleccionada para cada servicio, si la ubicación puede cambiar, dónde residen las réplicas y el acceso de soporte, qué subcontratistas pueden tocar el sistema, qué aviso acompaña a un movimiento, y qué sucede con las copias residuales después de la terminación. Una factura que nombra una región es útil solo si los arreglos técnicos y contractuales la hacen cumplir.
El límite de propiedad es el centro del riesgo
Los registros RIPE actuales muestran que la red de Lunar depende de recursos y organizaciones más allá de la propia empresa. AS198685 es una asignación patrocinada. Los dos bloques IPv4 son espacio agregable por proveedor en lugar de una asignación directa claramente documentada propiedad absoluta de Lunar. El objeto 144.31.136.0/24 está marcado como espacio agregable por proveedor subasignado; el objeto 94.183.224.0/24 es espacio agregable por proveedor asignado. Estas etiquetas no hacen que el servicio sea inferior. Muestran que el uso continuo depende de relaciones comerciales y de registro upstream.
Esa dependencia es visible en el historial de rutas. Antes de que AS198685 se convirtiera en el origen estable observado, los mismos /24 aparecieron bajo otros orígenes en diferentes momentos. El historial de 144.31.136.0/24 muestra varios cambios de origen antes de la ruta de Lunar. El historial de 94.183.224.0/24 es aún más activo en 2026, con múltiples orígenes precediendo al anuncio actual de AS198685. El arrendamiento de direcciones y la re-originación son comunes en un mercado donde la escasez de IPv4 ha hecho que los bloques sean valiosos y portátiles.
Para los clientes, la pregunta operativa es si los derechos del proveedor para usar las direcciones duran al menos tanto como el servicio que sustentan.
El objeto públicoaut-numdeclara acuerdos de importación y exportación con AS212743 y AS213529. Sin embargo, lavista de vecinos observados de RIPEstatmostró un vecino actual, AS202413, para la fecha de revisión. Las declaraciones de política del registro y las rutas observadas responden a diferentes preguntas y pueden cambiar a diferentes velocidades. El desajuste no es prueba de un fallo. Es evidencia de que un registro estático no debe leerse como un mapa de topología en vivo.
Esta es la pila de propiedad práctica que un cliente necesita entender. Lunar puede ser propietario del contrato del cliente y operar AS198685. Otra parte puede patrocinar el AS. Una o más partes pueden suministrar los bloques de direcciones. Otra puede proporcionar tránsito. Una empresa de instalaciones puede controlar la energía, la refrigeración y el acceso físico. Un arrendador de hardware puede ser propietario de los servidores. Un proveedor de mitigación puede proteger el sitio web público o el tráfico del servicio. Cada capa puede tener derecho a suspender el servicio si su propia factura, política de abuso o contrato se incumple.
Los peores fallos en esta estructura no son siempre técnicos. Un disco puede reemplazarse. Una fibra puede repararse. Una disputa de proveedor puede negar al proveedor el acceso físico o eliminar direcciones con poco tiempo para una migración ordenada. Un operador pequeño puede ser técnicamente competente y aun así tener un poder de negociación débil con un propietario o arrendador. Por eso la prueba de existencia corporativa y la prueba de control de ruta deben unirse a la prueba de derechos duraderos del proveedor.
Los clientes no necesitan que todos los términos comerciales se divulguen públicamente. Necesitan garantías contractuales que se correspondan con las dependencias: aviso antes de la migración de direcciones o instalaciones cuando sea factible; una respuesta definida si un proveedor termina el servicio; acceso continuo a los datos del cliente durante una salida ordenada; y una cuenta clara de qué parte es responsable del equipo, la energía, el tránsito y la intervención física. Un proveedor que no puede nombrar esos límites deja al cliente asumiendo riesgos que no puede monitorear.
La seguridad de ruta es una señal positiva, pero la diversidad de caminos no está demostrada
Ambos prefijos observados tenían autorizaciones de origen de ruta válidas para AS198685 cuando se verificaron a través de RIPEstat. Para144.31.136.0/24, el resultado de validación nombró a AS198685 como el origen válido mientras trataba varios otros orígenes posibles como inválidos bajo la autorización actual. Para94.183.224.0/24, la autorización válida también apuntaba a AS198685. Este es un control valioso. Las redes que realizan validación de origen de ruta pueden rechazar un anuncio cuyo origen entre en conflicto con el AS autorizado, reduciendo una clase de mala originación accidental o maliciosa.
La validez del origen de ruta no dice que el camino sea redundante, corto o sin congestión. Valida la relación entre un prefijo y el AS de origen, no la secuencia completa de redes que transportan el tráfico. No evita que una ruta correctamente originada desaparezca porque un enrutador pierde energía, una factura de tránsito queda impaga o la única sesión externa se reinicia. Tampoco asegura el servidor detrás de la dirección.
La principal advertencia de resiliencia es el único vecino observado. RIPEstat contó un AS adyacente único e IPinfo describió independientemente AS198685 como un stub monohomed. Las mediciones pueden perder interconexiones privadas o sesiones de respaldo que están inactivas, y un operador puede tener múltiples circuitos físicos hacia una red de tránsito. Incluso con esas salvedades, la vista pública no demuestra una diversidad upstream independiente. La ausencia de un registro de red de PeeringDB elimina otro lugar común donde los operadores divulgan instalaciones, puntos de intercambio y política de interconexión.
La distinción entre dos enlaces y dos destinos importa. Dos cables al mismo enrutador upstream pueden fallar juntos. Dos enrutadores en la misma sala pueden perder la misma alimentación eléctrica. Dos operadores pueden arrendar el mismo conducto. Dos direcciones en diferentes /24 pueden terminar en el mismo host. La diversidad real requiere separación en cada capa relevante: ruta física, enrutador, red upstream, dominio de energía, instalación y equipo operativo. Una tabla de rutas puede exponer parte de esa estructura, pero no toda.
Los objetivos demultihoming de sitiodel Grupo de Trabajo de Ingeniería de Internet describen los fallos que la redundancia pretende sobrevivir: cortes físicos, fallos de enrutador, fallos de sesión de enrutamiento, fallos de proveedor y fallos de intercambio. Frente a ese estándar, la evidencia pública de Lunar establece accesibilidad pero no continuidad. No hay prueba visible de que el tráfico se transfiera a un segundo proveedor de tránsito independiente, ni una prueba publicada que muestre cuánto tiempo toma la convergencia y si las sesiones existentes sobreviven.
La falta de IPv6 es una restricción separada. No hace que un servicio de alojamiento IPv4 sea inutilizable, y muchos clientes aún operan cómodamente en IPv4. Significa que la huella de red pública no es de doble pila y que los clientes que necesitan IPv6 nativo no pueden inferir una ruta del registro ASN. También concentra todo el direccionamiento de servicio observado públicamente en dos bloques IPv4 escasos cuyos términos de proveedor importan.
La conclusión apropiada es equilibrada. Lunar ha hecho algo positivo al autorizar sus orígenes actuales y mantener ambas rutas globalmente visibles. Eso reduce un riesgo de enrutamiento. La misma evidencia no demuestra un segundo camino independiente, y la topología observada actual sugiere que un fallo upstream o de red adyacente sigue siendo un evento de modo común material.
Un fallo de rack convierte una promesa virtual de nuevo en hardware
La virtualización cambia la unidad vendida, no la física subyacente. Un cliente puede comprar vCPU, RAM y almacenamiento por mes, pero esos recursos residen en procesadores, módulos de memoria, discos, tarjetas de red y conmutadores. Su continuidad depende de la alimentación eléctrica, refrigeración, firmware, hipervisores y la capacidad de una persona para alcanzar un componente fallado.
Lunar no ha identificado públicamente si la capacidad del cliente está en servidores propios, máquinas dedicadas alquiladas, servidores virtuales anidados o una mezcla. Cada modelo produce una ruta de fallo diferente. Los servidores propios dan al operador más control sobre la configuración y los repuestos, pero requieren capital y logística. El hardware alquilado puede acelerar la expansión, pero deja el tiempo de reemplazo y el acceso con el proveedor. La virtualización anidada puede hacer que la capacidad sea muy flexible al tiempo que añade otro plano de control y otro proveedor cuyos límites pueden ser invisibles para el cliente final.
Considere un fallo de un solo host. Si los discos del cliente son locales y no hay réplica en vivo, cada invitado en ese host permanece no disponible hasta que la máquina sea reparada o sus discos sean movidos. Si el almacenamiento es compartido, el cómputo puede reiniciarse en otro lugar, pero el almacenamiento compartido se convierte en una mayor concentración de riesgo. Si existen réplicas en el mismo rack, un fallo de energía del rack o del switch de top-of-rack puede deshabilitar ambas copias.
Si existen réplicas en otra instalación, la recuperación es más sólida, pero el retraso de replicación, el ancho de banda y la orquestación determinan cuántos datos y tiempo se pierden.
Las palabras "copia de seguridad" y "instantánea" son particularmente fáciles de sobrevalorar. Una instantánea en el mismo sistema de almacenamiento puede ayudar a deshacer un error del cliente, pero puede no sobrevivir a una pérdida de almacenamiento. Una copia de seguridad en la misma cuenta administrativa puede ser eliminada por las mismas credenciales comprometidas. Una réplica puede copiar fielmente la corrupción. La guía de resiliencia del NCSC recomienda la capacidad de volver a un estado bueno conocido y enfatiza que el diseño del servicio, no un crédito de disponibilidad, previene la pérdida.
Por lo tanto, una afirmación útil necesita un objetivo de punto de recuperación, un objetivo de tiempo de recuperación, aislamiento del dominio de fallo principal y evidencia de que las restauraciones han sido probadas.
El stock de hardware es otra restricción oculta. Un proveedor puede tener capacidad de cómputo de repuesto, pero ningún disco, fuente de alimentación o tarjeta de red compatible en el sitio. El reemplazo puede depender entonces de un mensajero, aduanas, un almacén del proveedor y una ventana de acceso a la instalación. Para un operador recién constituido con una base de hardware no divulgada, no hay evidencia pública de repuestos en stock o tiempos de reemplazo garantizados. Los clientes deben distinguir un objetivo de respuesta de soporte, que puede significar solo que un ticket es reconocido, de un objetivo de reparación o restauración.
El mantenimiento introduce versiones planificadas del mismo riesgo. Los cambios de firmware, reemplazos de conmutadores y trabajos de energía pueden ser inofensivos cuando la capacidad está drenada y las rutas redundantes están probadas. Pueden convertirse en interrupciones cuando la ruta de respaldo no ha transportado carga de producción o cuando los invitados no pueden moverse debido a incompatibilidad de almacenamiento o procesador. Lunar no ha publicado una política de mantenimiento, período de aviso o ventana de emergencia máxima que pueda verificarse para esta revisión.
Por lo tanto, la conclusión a nivel de rack no es que las máquinas de Lunar no sean fiables; su identidad no es lo suficientemente pública para juzgar. Es que la promesa del servicio no puede separarse de dependencias físicas no verificadas. Hasta que la empresa nombre su modelo de instalación, responsabilidad de hardware, política de repuestos y diseño de restauración, los clientes deben asumir que un fallo puede requerir mano de obra de terceros y que el tiempo de recuperación no está establecido por la velocidad del panel de control.
El fallo de tránsito puede aislar servidores saludables
Un servidor puede estar encendido, refrigerado y funcionando correctamente mientras es inalcanzable para cada cliente. Ese es el riesgo definitorio de la dependencia del tránsito. El host aún ejecuta instrucciones, pero la ruta que da significado a su dirección ha desaparecido o se ha degradado.
Para AS198685, los colectores de rutas públicas vieron una red adyacente. Esto hace que varios escenarios sean importantes. La sesión BGP podría reiniciarse. El vecino podría retirar los prefijos de Lunar. Una interconexión física podría fallar. El upstream podría experimentar congestión o un fallo de enrutamiento interno. Una respuesta de denegación de servicio podría descartar tráfico legítimo junto con un ataque. Un problema contractual podría hacer que el upstream suspenda el servicio. El resultado para un usuario final es similar en cada caso: la IP deja de responder o se vuelve inutilizablemente lenta.
Dos /24 anunciados no resuelven ese problema si ambos salen por el mismo vecino. Tampoco la validación de origen de ruta. Un segundo bloque puede ayudar con la gestión de direcciones y las transiciones de proveedor, pero la redundancia proviene de una ruta alternativa viable que transporta o está lista para transportar la ruta. Las observaciones públicas no muestran esa ruta alternativa.
Existen posibles mitigaciones que la vista pública no vería. Lunar podría mantener una sesión de respaldo en frío, usar túneles hacia una segunda red, comprar múltiples circuitos del mismo proveedor, o acordar una re-originación de emergencia. Cada una puede reducir algún riesgo. Cada una también necesita pruebas. Una ruta fría puede tardar en propagarse. Un túnel puede atravesar el mismo operador fallido. Un segundo circuito puede entrar al edificio por el mismo conducto. La re-originación de emergencia puede entrar en conflicto con los filtros de ruta o las autorizaciones actuales si no se preparó con antelación.
Los clientes también necesitan entender la protección contra denegación de servicio como un camino con su propia capacidad y reglas. El borde anti-DDoS del dominio web público protege el escaparate observado durante esta revisión, pero no prueba que los dos prefijos de servicio al cliente reciban la misma protección. La depuración puede estar siempre activa, activada a pedido o limitada por tipo de ataque y volumen contratado. Un proveedor puede permanecer accesible en su sitio de soporte mientras las direcciones de los clientes son null-routed. Lo contrario también puede ocurrir.
Los fallos de rendimiento son más sutiles que la retirada total. Un solo upstream puede permanecer visible para los colectores de rutas mientras sufre pérdida de paquetes en una ruta regional. Los clientes en un país pueden ver latencia severa mientras otros ven servicio normal. La existencia de la ruta no mide la calidad de la aplicación, y un solo trazado de espejo global no es un historial a nivel de servicio. La evidencia útil incluiría sondas diversas, pérdida y latencia a lo largo del tiempo, registros de incidentes y la capacidad de mover tráfico cuando un camino se degrada sin desaparecer por completo.
La pregunta más reveladora para Lunar no es: "¿Tiene redes redundantes?" Es: "¿Qué fallos exactos puede sobrevivir el diseño actual sin cambiar las IP de los clientes, y cuándo se probó por última vez cada conmutación por error bajo carga?" Una respuesta creíble nombraría proveedores de tránsito independientes, handoffs físicos, instalaciones, políticas de ruta y convergencia esperada. En ausencia de esa respuesta, la topología visible de un vecino debe tratarse como un riesgo de concentración.
La mano de obra de soporte es parte de la infraestructura
El alojamiento a menudo se describe a través de máquinas porque las máquinas son contables. Durante un incidente, la mano de obra se convierte en el recurso escaso. Alguien tiene que clasificar el fallo, decidir si es configuración del cliente o infraestructura del proveedor, contactar con la instalación, autorizar un reinicio, reemplazar hardware, cambiar una ruta, restaurar una copia de seguridad, comunicar el estado y evitar que una recuperación apresurada empeore el daño.
La página de oficiales de Companies House listaba un director activo para Lunar en el momento de la revisión. Eso no dice nada definitivo sobre la dotación de personal; una empresa puede emplear personas, usar contratistas o compartir operaciones con otro servicio. Significa que los registros corporativos públicos no revelan un amplio banquillo de liderazgo. El sitio de servicio no proporcionó un horario de personal público verificable, una descripción del centro de operaciones de red o un mapa de escalado durante esta investigación.
La divulgación escasa importa más fuera del horario normal. Un monitor automatizado puede detectar un host fallido inmediatamente, pero la restauración aún depende de la autoridad y el acceso. ¿Puede el primer respondedor cambiar una ruta? ¿Puede esa persona entrar a la instalación o instruir a manos remotas? ¿Hay un segundo ingeniero disponible para revisar un comando de almacenamiento destructivo? ¿El upstream acepta solicitudes urgentes las 24 horas? ¿La comunicación con el cliente es manejada por la misma persona que repara el fallo?
Los equipos pequeños pueden operar servicios fiables reduciendo la variación, automatizando acciones rutinarias, documentando contactos de proveedores y comprando un sólido soporte de instalación. También pueden verse abrumados cuando varios clientes reportan el mismo incidente, porque el volumen de tickets aumenta justo cuando el trabajo técnico se vuelve más urgente. Una primera respuesta de una hora no es lo mismo que una restauración en una hora. Una afirmación de soporte continuo es significativa solo si identifica el canal, el objetivo de respuesta, el nivel de escalado y las actividades cubiertas.
El manejo de abusos es otra dependencia de mano de obra para una red de alojamiento. El registro RIPE publica un contacto de abuso, que es una ruta pública necesaria para los informes. Las direcciones de alojamiento atraen quejas que van desde sitios web comprometidos hasta escaneo y disputas de derechos de autor. Un manejo deficiente puede dañar la reputación de la dirección o provocar una suspensión upstream; un manejo demasiado agresivo puede desconectar a un cliente inocente. El operador necesita suficiente personal y evidencia para tomar decisiones oportunas y proporcionadas.
El soporte de facturación puede convertirse en soporte operativo cuando el acceso al servicio está automatizado. Una renovación fallida, un flag de fraude o un error del proveedor de pagos puede suspender un servidor incluso si cada componente técnico está sano. Los clientes necesitan saber si los datos siguen siendo recuperables después de la suspensión, cuánto tiempo se retienen, si una apelación pausa la eliminación, y cómo se escala un error de facturación urgente. Estas políticas son especialmente importantes cuando la capacidad pública y la cadena de propiedad del proveedor no están bien documentadas.
Elprincipio de seguridad operativadel NCSC trata la gestión de vulnerabilidades, monitoreo, respuesta a incidentes y gestión de cambios como propiedades del servicio. Ese marco es útil aquí: las personas y las decisiones son parte del producto alojado. Los registros de red públicos de Lunar muestran direcciones y rutas, pero ninguna evidencia pública equivalente establece aún tiempos de parcheo, notificación de incidentes, aviso de cambios o profundidad de soporte.
La migración es la ruta de recuperación para fallos que el proveedor no puede arreglar
Cada evaluación de alojamiento llega eventualmente a la cuestión de salida. La redundancia intenta mantener un servicio funcionando dentro del proveedor. La portabilidad permite al cliente recuperarse cuando el proveedor, la relación con el proveedor o el acuerdo comercial en sí mismo es el componente fallido.
La portabilidad es más que descargar archivos. Un servicio en funcionamiento puede incluir discos virtuales, datos de objetos, estado relacional, zonas DNS, certificados, reglas de firewall, redes privadas, IPs asignadas, historial de monitoreo, registros de acceso, credenciales de automatización y documentación conocida solo por las personas que lo construyeron. Cuantos más de esos elementos permanezcan atrapados en un panel de control propietario o en una cuenta de proveedor inaccesible, más tiempo lleva la migración.
Lunar no ha publicado una especificación de exportación verificable para la huella de servicio revisada. Por lo tanto, se desconoce si un cliente puede obtener una imagen de disco completa, qué formatos son compatibles, si las exportaciones grandes incurren en cargos por transferencia, con qué rapidez se borra una cuenta terminada, o si un servidor fallido aún puede exportarse. También se desconoce si las direcciones IP del cliente son portables.
Dado que los prefijos visibles son espacio agregable por proveedor suministrado a través de otras partes, un cliente pequeño típico debe asumir que la IP asignada permanece con el proveedor a menos que el contrato diga lo contrario.
Esa suposición tiene consecuencias. Mover un servidor web a una nueva dirección puede requerir cambios de DNS, verificaciones de certificados, actualizaciones de firewall, cambios en listas de permitidos y tiempo para que los cachés expiren. Mover un servicio de correo puede interrumpir la reputación del remitente y el DNS inverso. Mover una aplicación que los socios han codificado a una IP puede llevar más tiempo que mover su disco. Un proveedor puede hacer que el cómputo sea portable mientras la dirección sigue siendo el bloqueo más fuerte.
El diseño de migración más seguro comienza antes de un incidente. Los clientes pueden mantener definiciones de infraestructura fuera del proveedor, mantener copias independientes de claves de cifrado y acceso DNS, exportar datos de aplicación regularmente, y probar la restauración en un segundo entorno. Esas acciones son responsabilidades del cliente, no sustitutos de la claridad del proveedor. Bajo elmodelo de responsabilidad compartidadel NCSC, los deberes de seguridad y disponibilidad dependen del modelo de servicio y deben ser entendidos por ambas partes.
Una prueba de salida debe ser cronometrada y completa. La medida relevante no es la rapidez con que se puede descargar un archivo, sino cuánto tiempo lleva restaurar un servicio funcional en otro lugar con una pérdida de datos aceptable. La prueba debe incluir el conjunto de datos realista más grande, dependencias como DNS y certificados, y validación por alguien que no sea la persona que diseñó el despliegue original. Si nunca se ha hecho, la portabilidad sigue siendo una aspiración.
El fallo del contrato del proveedor merece su propio escenario. Si Lunar pierde un rack, un proveedor de direcciones o un acuerdo de tránsito, ¿puede recuperar los datos del cliente y mover los servicios antes de la terminación? ¿Tiene un período de cura contractual? ¿Pueden los clientes contactar con la instalación subyacente, o eso violaría los límites de seguridad y comerciales? ¿Las copias de seguridad se mantienen bajo una cuenta separada que sobrevive a la disputa del proveedor principal? Los registros públicos no responden a estas preguntas, pero la estructura de recursos en capas las hace materiales.
Para los clientes, la ruta de migración es el límite último de la dependencia. Un precio mensual bajo puede ser racional incluso con una redundancia modesta cuando la carga de trabajo es fácil de recrear en otro lugar. El mismo servicio puede ser un mal negocio para datos únicos o un endpoint público codificado si la salida lleva semanas. La evidencia actual de Lunar no es lo suficientemente sólida para valorar ese riesgo para el cliente; solo los términos del servicio y una prueba de restauración pueden hacerlo.
La soberanía de datos es un mapa de control, no una bandera en una IP
La huella de Lunar cruza varias señales administrativas: una empresa británica, un bloque con etiqueta Alemania y una geolocalización en Falkenstein, un bloque con etiqueta Países Bajos y un destino web bajo el dominio de código de país ruso. Ninguno de esos hechos por sí solo identifica la jurisdicción que gobierna cada copia de los datos del cliente.
La soberanía de datos comienza con la ubicación pero se extiende al control. Un disco puede estar en Alemania mientras el personal de soporte en otro país puede abrir su consola de gestión. Una copia de seguridad puede copiarse a una segunda región. Los registros pueden ir a un servicio de monitoreo en otro lugar. Un proveedor de facturación puede tener datos de identidad y pago del cliente en otra jurisdicción. Un revendedor británico constituido puede contratar con un proveedor de infraestructura no británico. Cada relación cambia qué organización puede acceder a la información y qué proceso legal puede alcanzarla.
La ICO hace una distinción útil entre transferencia y tránsito. Los paquetes enrutados a través de otro país no son necesariamente una transferencia restringida si la información viaja entre organizaciones del Reino Unido sin ser accedida o almacenada allí. Hacer que la información personal sea accesible a una organización extranjera separada puede ser una transferencia incluso sin una copia masiva. Por eso los traceroutes y la geolocalización IP no pueden completar una evaluación legal. Los contratos y el diseño de acceso importan.
El material público de Lunar no identifica una cadena de procesadores, países de soporte, ubicaciones de respaldo o controles de residencia seleccionables por el cliente. Las etiquetas de Alemania y Países Bajos deben tratarse, por lo tanto, como pistas. Un cliente que busca un resultado de residencia particular debe exigir que la orden de servicio nombre la ubicación seleccionada, restrinja los movimientos y el acceso remoto, identifique los subprocesadores, describa la geografía de la copia de seguridad y proporcione aviso de cambios. Los mismos términos deben cubrir metadatos y registros, no solo el almacenamiento primario.
El cifrado cambia la exposición pero no elimina cada problema de localidad. Las claves en manos del cliente pueden reducir la capacidad del proveedor para leer los datos almacenados, siempre que las instantáneas, registros y memoria se traten de manera consistente. No mantiene una aplicación disponible durante una interrupción de la instalación, y no hace que una transferencia no declarada sea aceptable por sí misma. También puede hacer imposible la recuperación si la custodia de claves es deficiente. La ubicación, el acceso, el cifrado y la recuperabilidad deben analizarse juntos.
La ausencia de IPv6 nativo no determina directamente la soberanía, pero ilustra el punto más amplio: la característica del servicio debe observarse y contratarse, no inferirse de una etiqueta en la nube. De la misma manera, un número de empresa del Reino Unido no convierte cada servidor en una región del Reino Unido, y una geolocalización alemana no prueba una administración exclusivamente alemana.
Los clientes sin datos regulados o sensibles pueden aceptar razonablemente una amplia flexibilidad de ubicación a cambio de precio o rendimiento. Los clientes con deberes de residencia legales, contractuales o impuestos por el cliente necesitan un mayor estándar de prueba. En la actualidad, la huella pública de Lunar no proporciona esa prueba. Proporciona suficiente información para saber qué preguntas deben responderse antes de tratar el servicio como local a cualquier jurisdicción.
Qué movería la calificación de evidencia
La visibilidad de ruta de Lunar es más fuerte que su perfil público general. La empresa está activa, AS198685 está anunciado, dos /24 son visibles y ambos orígenes actuales se validan bajo autorización de origen de ruta. Esos hechos justifican describir una pequeña huella de red en vivo. La calificación sigue siendo Débil porque la evidencia no alcanza las capas físicas, contractuales y de recuperación del servicio.
Varias divulgaciones mejorarían materialmente la confianza. Primero sería una declaración de ubicación y propiedad que nombre los países y operadores de instalaciones utilizados para cada clase de servicio, distinguiendo el equipo propio de los servidores alquilados. No necesita revelar números de rack o diagramas sensibles a la seguridad. Debería identificar quién controla la energía, la refrigeración, las manos remotas y el hardware de reemplazo.
Segundo sería una declaración de red actual. Debería explicar si AS198685 tiene uno o múltiples upstreams independientes, si las rutas físicas y los enrutadores de borde son diversos, qué prefijos reciben protección contra denegación de servicio, y si IPv6 nativo está planificado o disponible a través de otro servicio. Una entrada pública en PeeringDB y objetos de política RIPE consistentes harían la topología más fácil de verificar, aunque las rutas observadas aún serían necesarias.
Tercero serían términos de disponibilidad y mantenimiento específicos del servicio. Un documento útil definiría qué cuenta como no disponible, el punto de medición, los eventos excluidos, el aviso para trabajo planificado, el tratamiento del mantenimiento de emergencia, los objetivos de respuesta de soporte y la compensación. Los créditos por sí solos no crean resiliencia, pero los términos precisos muestran lo que el proveedor está dispuesto a medir.
Cuarto sería evidencia de recuperación: alcance de la copia de seguridad, aislamiento, retención, controles del cliente, objetivos de punto de recuperación y tiempo de recuperación, y resultados de pruebas de restauración fechadas. La versión más sólida separaría los fallos de host, rack y sitio y declararía qué niveles de servicio sobreviven a cada uno. Una declaración de que existen copias de seguridad, sin un resultado de restauración, sería solo una pequeña mejora.
Quinto serían términos de portabilidad. Los clientes deben conocer los formatos de exportación disponibles, los límites y cargos de transferencia, la retención después de la suspensión, el momento de la eliminación, el acceso durante la terminación y si las direcciones IP pueden moverse. Un ejercicio de migración documentado a otro proveedor convertiría una promesa de salida abstracta en evidencia operativa.
Finalmente, Lunar podría publicar una cuenta concisa de proveedores y jurisdicciones: la entidad legal que contrata con el cliente, la entidad que opera la red, las categorías de subcontratistas de infraestructura y soporte, y los países desde los cuales los datos del cliente pueden ser almacenados o accedidos. Esto ayudaría a los clientes a conciliar la empresa británica con las etiquetas de red de Alemania y Países Bajos.
Ninguna de estas solicitudes asume que un proveedor joven o pequeño no es sólido. Los operadores pequeños pueden ofrecer soporte cercano, productos simples y buen valor. El punto es alinear la afirmación con la evidencia. Hoy, la red visible prueba más que un mero registro pero menos que una nube resiliente. La lectura más defendible es que LUNAR HOSTING LTD vende capacidad en la parte superior de una cadena cuyos racks, tránsito, mano de obra de reparación y derechos de proveedor permanecen en gran medida fuera de la vista pública.
La decisión de compra debe seguir la tolerancia de la carga de trabajo a la incertidumbre
Para un servidor de desarrollo fácilmente reconstruible, un relé temporal o un nodo de borde replicado, la pequeña huella pública de Lunar puede ser un riesgo aceptable si el precio y la experiencia de servicio directo son buenos. El cliente puede mantener datos autoritativos en otro lugar, automatizar el reemplazo y tratar un cambio de dirección como rutinario. En ese caso de uso, los detalles públicos faltantes son una razón para limitar la exposición en lugar de rechazar el servicio por completo.
Para la única copia de datos comerciales, un sistema de producción sensible a la latencia, información personal regulada o un endpoint público que no puede cambiar rápidamente, la misma incertidumbre tiene un costo diferente. Un solo vecino observado, redundancia de sitio no verificada, stock de repuesto desconocido y ruta de exportación no documentada se convierten en parte del propio riesgo del sistema. El cliente necesitaría evidencia contractual directa y copias de seguridad independientes antes de confiar en el servicio.
Las preguntas relevantes son concretas. ¿Qué entidad legal firma el pedido? ¿Qué instalación y país contienen los datos primarios y las copias de seguridad? ¿Quién es el propietario del servidor? ¿Qué sucede si falla el host, rack, ruta o proveedor? ¿Qué ruta es genuinamente independiente? ¿Con qué rapidez puede actuar un ingeniero autorizado? ¿Qué estado exacto se puede exportar? ¿Cuánto tiempo se retienen los datos después de la suspensión? ¿Cuándo se completó la última restauración completa y cuánto tiempo tomó?
Las respuestas deben ser consistentes con el registro público. Si un servicio se vende como ubicado en Alemania, la declaración de instalación y copia de seguridad debe alinearse con la geolocalización de Falkenstein o explicar por qué no. Si el proveedor afirma tener tránsito diverso, las observaciones de ruta actuales deberían mostrar eventualmente más de un vecino viable, o el proveedor debería explicar el diseño de respaldo. Si una afirmación de disponibilidad depende de múltiples sitios, la arquitectura del servicio debe identificar los dominios de fallo y el comportamiento de replicación.
Los clientes también deben monitorear el cambio. La empresa actual y ASN tienen solo meses de antigüedad. Los orígenes de direcciones, vecinos, destinos web y relaciones con proveedores ya han cambiado en un período corto. Eso puede reflejar la construcción normal de una red joven. También significa que una evaluación hecha una vez envejecerá rápidamente. La visibilidad de rutas, autorizaciones, términos de servicio y capacidad de exportación deben revisarse en la renovación y después de cualquier movimiento anunciado.
El juicio final es deliberadamente limitado. LUNAR HOSTING LTD tiene suficiente evidencia actual para ser tratada como más que una empresa de papel: su sistema autónomo origina espacio de direcciones globalmente visible, los orígenes están autorizados y las mediciones secundarias ven actividad similar al alojamiento. Aún no tiene suficiente evidencia pública para tratar la capacidad ofrecida como multisitio, conectada independientemente o demostrablemente recuperable.
Esa brecha es el centro de la historia. La capacidad alojada se siente abstracta solo mientras cada dependencia funciona. Un fallo de rack la convierte en hardware. Una retirada de ruta la convierte en tránsito. Un fallo de disco la convierte en stock de repuesto. Un incidente no respondido la convierte en mano de obra. Un acuerdo de proveedor terminado la convierte en derecho contractual. Una exportación no probada la convierte en bloqueo del cliente. La red pública de Lunar es visible; la resiliencia detrás de ella aún no es lo suficientemente visible.