Resumen
- Hosting-27 Hosting-27 LTD no es una empresa visible solo en registros de enrutamiento. Lapágina principal de Hosting27.comen activo anuncia alojamiento y servicios en la nube búlgaros, lapágina de contactoofrece una dirección en Sofía, teléfono y correos electrónicos de soporte, elárea de clienteexpone un portal de inicio de sesión y facturación, y lapágina de tickets de soportedescribe un departamento de soporte que trabaja todos los días. Esa superficie de ventas pública es real, pero por sí sola no prueba dónde se encuentran los servidores ni cómo se reparan las interrupciones.
- La identidad de red es concreta y compacta. Elobjeto AS42347 de la base de datos RIPEnombra a Hosting-27, vincula el AS conORG-HA629-RIPE, enumera a Hosting-27 LTD como organización, indica país BG, número de registro 204354361 y una dirección en Sofía, y registra importaciones y exportaciones con AS57344 y AS31083. Elinetnum 217.174.144.0 - 217.174.144.255y elobjeto de ruta 217.174.144.0/24de RIPE vinculan el bloque IPv4 visible a Hosting-27 y AS42347.
- La vista de ruta en vivo es más limitada que el menú de marketing. Lavisión general de ASde RIPEstat mostró AS42347 anunciado el 12 de julio de 2026, y su vista deestado de enrutamientomostró un prefijo IPv4 visible, 256 direcciones IPv4, sin IPv6 visible y un vecino observado. La vista devecinos ASNde RIPEstat identificó a ese vecino como AS57344, y lavisión general de AS57344identifica a AS57344 como Telehouse EAD. Un segundo par, AS31083 Telepoint, aparece en la política de registro de AS42347 pero no en la vista de consistencia BGP actual.
- El grado operativo es medio calificado, no fuerte. Las páginas de productos paraalojamiento compartido,Cloud VPS,Cloud VPS gestionado,nube privadayKubernetesmuestran una oferta amplia de capacidad alojada. La evidencia pública no muestra una sala de centro de datos con nombre, cantidad de armarios, diseño de energía, inventario de hardware, condiciones de retención de copias de seguridad para clientes, tránsito dual activo, servicio IPv6 o una ruta de portabilidad documentada.
La superficie de servicio es visible, pero debe leerse desde el rack hacia afuera
No debe confundirse a Hosting-27 Hosting-27 LTD con un registro vacío de números de Internet. El sitio público Hosting27.com está en línea, datado por sus propios metadatos de cabecera y páginas visibles, y construido como un escaparate de alojamiento en funcionamiento. Lapágina principalpresenta la marca como proveedor de servicios de alojamiento y nube. Dirige a los compradores hacia alojamiento WordPress, clústeres Kubernetes, nube privada, Cloud VPS, Cloud VPS gestionado, alojamiento para revendedores, dominios, un área de cliente, facturas y tickets de soporte. La navegación no es un marcador de posición abandonado de una sola página; es una superficie minorista de alojamiento con niveles de productos, botones de pedido, un área de cuenta estilo WHMCS y un portal de soporte.
Esto hace que la investigación sea más exigente, no menos. Cuando una empresa vende alojamiento web o servidores en la nube, la dependencia del cliente no es la página web. La dependencia es la pila oculta bajo la factura: un nodo anfitrión, un backend de almacenamiento, conmutación, enrutadores, existencias de IPv4, tránsito ascendente, energía, refrigeración, manos remotas, estado de facturación, manejo de abusos y un equipo de soporte con autoridad para actuar. El material público de Hosting27 describe varios productos orientados al cliente, pero no identifica la instalación o instalaciones detrás de ellos.
No dice si Hosting-27 opera sus propios racks, alquila espacio en armarios, depende de otro operador de centro de datos búlgaro o revende capacidad ensamblada por un proveedor relacionado.
El menú de productos importa porque indica a los clientes qué tipo de sistema físico debería existir. Lapágina de alojamiento compartidoanuncia tres tamaños de plan con 20 GB, 50 GB y 165 GB de espacio, cPanel, sitios ilimitados, buzones ilimitados, certificados SSL gratuitos, CDN, ayuda para migración, múltiples versiones de PHP y copias de seguridad de un mes. Lapágina de alojamiento WordPressanuncia niveles similares de 20 GB, 50 GB y 165 GB, añade gestión de WordPress y promete ayuda para migrar sitios WordPress. Lapágina de alojamiento para revendedoresofrece planes de 40 GB, 75 GB y 130 GB con acceso WHM, tráfico ilimitado y cuentas ilimitadas. Estos no son lemas abstractos de nube. Son afirmaciones de que existen hosts físicos o virtuales compartidos, que se pueden crear cuentas en ellos y que las migraciones y las copias de seguridad son parte de la promesa del servicio.
El menú de nube eleva las apuestas. Lapágina de Cloud VPSanuncia instancias de una a cuatro CPUs virtuales, de 1 GB a 6 GB de RAM, de 30 GB a 85 GB de almacenamiento todo SSD, copias de seguridad diarias, un panel de gestión, OpenStack, KVM y Ceph. También vende direcciones IP adicionales, copias de seguridad adicionales del sistema y bloques de administración de sistemas de treinta minutos. Lapágina de Cloud VPS gestionadoanuncia servidores gestionados con panel de control, soporte técnico, copias de seguridad diarias, monitorización las 24 horas y migración gratuita. Lapágina de nube privadava más allá, describiendo una oferta de centro de datos virtual basada en OpenStack con almacenamiento definido por software, una reclamación de nivel de servicio del 99,99 por ciento, una red doblemente asegurada y servicios API como Cinder, Nova, Heat, Glance, Magnum, Neutron y Keystone. Lapágina de Kubernetesdescribe ayuda para instalar, configurar y mantener un entorno Kubernetes de alta disponibilidad y dice que el servicio cubre infraestructura, redes y balanceadores de carga como una de sus capas.
Esas páginas le dan a Hosting27 una superficie de ventas pública más fuerte que muchas redes de alojamiento pequeñas. También crean una brecha de evidencia mayor. Un vendedor de VPS de un solo nodo puede fallar silenciosamente.
Un vendedor de OpenStack, Ceph, nube privada y Kubernetes debe responder más: cuántos nodos físicos están disponibles, cómo se aísla la replicación de almacenamiento, si los componentes del plano de control tienen dominios de fallo independientes, dónde residen las copias de seguridad, qué grupo de direcciones sirve a los clientes, qué enrutador lleva la ruta y quién puede reparar el sistema cuando falla la capa física.
El punto de partida más seguro no es, por tanto, ni el descarte ni la confianza ciega. Hosting-27 tiene un sitio web visible y un AS visible. El registro público respalda la existencia de una operación de alojamiento búlgara. No respalda una conclusión sólida sobre la capacidad de nube instalada, la recuperación multisitio o la independencia del proveedor.
El registro RIPE le da a Hosting-27 un borde de red pequeño pero real
La evidencia de infraestructura más clara está en la base de datos RIPE y RIPEstat. Elregistro aut-num de RIPE para AS42347nombra al AS "Hosting-27", enumera a Hosting-27 LTD a través de ORG-HA629-RIPE, registra el estado ASSIGNED, indica creación el 24 de agosto de 2017 y última modificación el 7 de abril de 2021, y registra políticas de importación y exportación para AS57344 y AS31083. Elregistro de organizaciónvinculado nombra a Hosting-27 LTD, país BG, número de registro 204354361, tipo de organización OTHER, una dirección en Sofía en Todor Aleksandrov 133, y un contacto de abuso en GLAC2-RIPE. Fue creado en agosto de 2017 y modificado por última vez en mayo de 2026.
La asignación IPv4 es igualmente explícita. Elinetnum de RIPE para 217.174.144.0 - 217.174.144.255utiliza el nombre de red Hosting-27, país BG, organización ORG-HA629-RIPE y estado ASSIGNED PA. Elobjeto de ruta de RIPE para 217.174.144.0/24describe Hosting27 y autoriza el origen AS42347. La vista deprefijos anunciadosde RIPEstat mostró 217.174.144.0/24 visible en la ventana de dos semanas que finalizaba el 12 de julio de 2026. Su vista deestado de enrutamientomostró un prefijo IPv4, 256 direcciones IPv4 y visibilidad IPv4 completa en 326 de 326 pares RIPE RIS en el momento de la consulta.
Ese /24 no es solo un registro pasivo. El propio dominio Hosting27.com se resuelve dentro del mismo bloque. Lavista de cadena DNS de RIPEstat para hosting27.comresolvió hosting27.com a 217.174.144.181, asoció inversamente esa dirección con shared-11.cpaneler.com, y enumeró servidores de nombres autoritativos incluyendo ns1-pns.hosting27.com y ns2-pns.hosting27.com. Elregistro RDAP de dominio para hosting27.commuestra el dominio registrado el 12 de julio de 2013, con vencimiento el 12 de julio de 2027, con PublicDomainRegistry.com como registrador y servidores de nombres bajo hosting27.com. El sitio web visible, DNS y prefijo enrutado se alinean, por tanto, en torno a la misma huella de red pública.
El conjunto de direcciones es pequeño. Un /24 contiene 256 direcciones IPv4 antes de contar interfaces de enrutador, hosts de infraestructura, servidores de nombres, IPs de alojamiento compartido, asignaciones de clientes, direcciones libres y capacidad reservada. Eso es suficiente para un negocio de alojamiento real, especialmente si muchos clientes de alojamiento compartido se encuentran detrás de hosts virtuales basados en nombre y si los planes de VPS pequeños pueden compartir hosts sin que cada uno reciba múltiples direcciones públicas. No es suficiente para inferir una gran capacidad instalada.
Una oferta de nube privada, una oferta de Kubernetes, cuentas de revendedor, VPS gestionado y alojamiento compartido se pueden vender desde un conjunto de direcciones públicas compacto si se utilizan direccionamiento interno, NAT, alojamiento virtual y una asignación cuidadosa. También se pueden sobrevender si la planificación es laxa. La ruta pública no distingue esos casos.
También hay un segundo objeto de ruta que debe manejarse con cuidado. La vista deconsistencia de enrutamiento de ASde RIPEstat enumera 45.151.89.0/24 como presente en whois pero no en BGP para AS42347 en el momento de la consulta. Unabúsqueda en RIPE para 45.151.89.0/24muestra un objeto de ruta para AS42347, pero el inetnum pertenece a Geytit OOD, no a Hosting-27 LTD, y la ruta no formaba parte del conjunto anunciado visible actual. Esto significa que es posible que se preparara una política de ruta para otro conjunto, o que la ruta estuviera inactiva, reservada, histórica o no visible en el momento de la consulta. No debe contarse como capacidad disponible para clientes de Hosting-27 a menos que la evidencia BGP y comercial actual lo respalde.
El borde de red es, por tanto, real pero de alcance limitado: un AS visible, un /24 IPv4 visible, un objeto de ruta válido, un sitio web activo dentro del bloque y sin prefijo IPv6 visible para AS42347 en la vista de ruta de RIPEstat.
La oficina, el sitio web y el nombre del contrato no equivalen a una sala de datos verificada
El rastro de direcciones públicas es útil, pero no identifica un centro de datos. Lapágina de contactode Hosting27 indica Sofía, bulevar Todor Aleksandrov 133, piso 2, además de un número de teléfono y direcciones de correo electrónico de soporte y ventas. El registro de organización RIPE para Hosting-27 LTD da una dirección coincidente en Todor Aleksandrov 133. Elregistro de organización RIPE de Geytit OODtambién utiliza Todor Aleksandrov 133 y aparece como organización patrocinadora en el registro AS42347. Estos registros son significativos para el contacto y la administración del registro. No prueban que los servidores de los clientes se encuentren en ese edificio, que Hosting-27 posea racks allí o que la empresa tenga acceso directo a la infraestructura de energía y conexión cruzada.
Los términos legales públicos añaden otro límite. Lapágina de condiciones generalesde Hosting27 incrusta un PDF, y lostérminos del PDFestablecen que las condiciones del servicio regulan el alojamiento compartido, los certificados SSL, el registro de dominios, los servidores virtuales y los servidores virtuales gestionados a través del sitio Hosting27.com. El PDF nombra a Cloud Systems OOD como proveedor en los términos búlgaros y da un número de registro de empresa diferente. Este artículo no trata esto como un hallazgo de relación corporativa. Lo trata como una cuestión de diligencia para el comprador: la marca, la organización RIPE, el LIR patrocinador, los términos web y el emisor de facturas deben alinearse antes de que un cliente trate el servicio como un contrato de infraestructura fiable.
Este límite importa durante un fallo, no solo durante la contratación. Si una máquina virtual falla a las 02:00, el cliente necesita saber qué entidad controla la cola de soporte, qué entidad posee o alquila el hardware, quién puede autorizar manos remotas, quién puede reemplazar una unidad, quién controla la sesión del enrutador, quién factura el servicio y quién puede preservar los datos si se disputa la facturación.
Un desajuste entre la marca, el titular del AS y el proveedor del contrato no es inherentemente malo; muchos grupos de alojamiento utilizan vehículos legales separados para los recursos de direcciones, los contratos con clientes, las instalaciones y las operaciones. Pero los materiales públicos revisados aquí no explican esa estructura. Los clientes deben preguntar directamente.
Los términos también dejan claro que el servicio alojado es una oferta limitada, no una garantía de que cada cliente reciba un entorno completamente independiente. El PDF dice que el alojamiento compartido implica que los clientes comparten recursos comunes del servidor, como velocidad, RAM y conectividad de red, con otros usuarios. Su sección de servidor virtual gestionado describe la administración de un servidor virtualmente separado con panel de control, soporte las 24 horas, recursos garantizados no compartidos con otras aplicaciones de clientes, monitorización, reacción a problemas y copias de seguridad periódicas.
Ese es un lenguaje útil para entender las clases de servicio previstas. Pero aún deja sin aclarar en la vista pública el tiempo de restauración, la ubicación de las copias de seguridad, la retención de instantáneas, la replicación externa, el formato de exportación del cliente y las compensaciones por interrupción.
El encuadre de "centro de datos virtual" de la página de nube privada es especialmente importante de calificar. Un cliente que lea esa frase puede imaginar una zona de centro de datos dedicada. La página en sí describe una abstracción de OpenStack: redes creadas por el cliente, enrutadores, balanceadores de carga y servicios de almacenamiento. Esas son características del plano de control virtual. Siguen residiendo en nodos físicos, discos, tarjetas de red, conmutadores de la parte superior del rack, alimentaciones eléctricas y enlaces de tránsito.
Sin una instalación nombrada o una declaración de arquitectura, la afirmación debe tratarse como una oferta de plano de control de nube, no como prueba de un sitio físico separado.
La dependencia de upstream visible es Telehouse, mientras que Telepoint es una posibilidad de política
El panorama de rutas es sencillo en el punto de observación actual. La vista devecinos ASNde RIPEstat para AS42347 informó de un vecino único en el último momento disponible: AS57344. Lavisión general de AS para AS57344de RIPEstat identifica AS57344 como TELEHOUSE-AS Telehouse EAD. Elaut-num AS57344de RIPE muestra a Telehouse con una amplia política de upstream e intercambio, que incluye a Arelion, Cogent, GTT, Level 3, Liberty Global, NTT, Orange, PCCW, RETN, Seabone, Tata, Telxius y varias fábricas de intercambio. Elregistro de AS57344 en PeeringDBdescribe a Telehouse con alcance global, soporte IPv6, muchas presencias de intercambio y entradas de instalaciones.
Esa amplitud de Telehouse ayuda a explicar cómo el /24 de Hosting-27 puede ser visible desde colectores globales. No convierte automáticamente a Hosting-27 en multi-homed. La dependencia inmediata observada para AS42347 sigue siendo un vecino. Si la ruta AS42347 se transporta solo a través de Telehouse en el borde activo, entonces un problema del lado de Telehouse, un problema de sesión, un filtro de ruta, un incidente de instalación, un problema de conexión cruzada, una retención comercial o una ventana de mantenimiento pueden afectar a todos los clientes que utilizan el prefijo visible de Hosting-27.
Los colectores de rutas públicos pueden pasar por alto rutas de respaldo privadas, sesiones temporalmente inactivas o acuerdos que se activan solo durante un fallo. Pero la carga recae en el proveedor para demostrar dicha redundancia, porque la vista BGP pública actual no lo hace.
AS31083 es el segundo nombre que debe manejarse con precisión. El aut-num RIPE de AS42347 enumera políticas de importación y exportación con AS31083, y lavisión general de AS31083de RIPEstat identifica AS31083 como Telepoint Ltd. Elaut-num AS31083de RIPE muestra a Telepoint conectado a varios upstreams, y elregistro de Telepointen PeeringDB informa de un perfil más pequeño de alcance europeo. Pero la vista de consistencia de enrutamiento de AS de RIPEstat muestra a AS31083 como presente en la política whois y no presente en BGP para AS42347 en el momento de la consulta. Eso significa que la política de registro por sí sola no debe describirse como diversidad activa.
La ausencia de PeeringDB para Hosting-27 refuerza la necesidad de cautela. Unaconsulta a PeeringDB para AS42347no devolvió ningún objeto de red público. Muchas redes pequeñas operan sin un perfil en PeeringDB, por lo que la ausencia no es un fallo. Pero significa que no hay una lista pública de instalaciones de Hosting-27, lista de intercambios, página de looking-glass, estimación de tráfico, política de peering o perfil de NOC en ese directorio. El único rastro de interconexión pública es la política RIPE, los colectores de rutas y las identidades de los upstreams observados o registrados.
El resultado de seguridad de origen de ruta es positivo. Lavalidación RPKI para 217.174.144.0/24de RIPEstat informa de un ROA válido para AS42347 originando el /24 exacto con longitud máxima /24. Eso ayuda a las redes que aplican la validación de origen de ruta a aceptar la ruta como autorizada. No protege contra fallos de host, fallos de almacenamiento, mala configuración del enrutador, facturas de upstream impagadas, compromiso del panel de control o bloqueo de cuenta de cliente. RPKI responde quién puede originar el prefijo, no si el servicio de alojamiento puede recuperarse.
Para los compradores, la cuestión de diligencia en el tránsito es práctica: ¿es Telehouse el upstream activo para todos los servicios de Hosting27, es AS31083 una entrada de política en espera o histórica, puede cualquiera de los caminos transportar la carga de trabajo del cliente durante el mantenimiento, y se anuncian las rutas desde entregas físicamente separadas o desde la misma sala y cadena de dependencia?
Las características de nube anunciadas no equivalen a capacidad instalada, utilizable o recuperable
La economía del alojamiento premia el uso compartido eficiente. El alojamiento compartido vende disco, correo y gestión de sitios agrupando muchas cuentas de clientes en uno o más servidores. El alojamiento VPS vende porciones de CPU virtual, RAM y almacenamiento de hosts más grandes. El VPS gestionado añade mano de obra de soporte, monitorización y administración. La nube privada añade una capa de orquestación y una promesa más fuerte de control del cliente. Kubernetes añade otra capa de orquestación por encima. Cada capa puede ser real y, sin embargo, depender de un pequeño número de nodos físicos.
Las páginas de Hosting27 hacen afirmaciones amplias que son plausibles para un pequeño proveedor búlgaro, pero imposibles de dimensionar desde el exterior. Los planes de alojamiento compartido anuncian sitios, buzones y tráfico ilimitados, pero esas son reglas del plan, no capacidad infinita. El servicio sigue dependiendo de CPU, RAM, IO de almacenamiento, límites de inodos, reglas de uso justo, control de spam y manejo de abusos.
Los planes de revendedor anuncian tráfico y cuentas ilimitados, pero los límites de almacenamiento son de 40 GB, 75 GB y 130 GB; la restricción real puede ser el rendimiento de IO, la reputación del correo saliente, la densidad de cuentas o el rendimiento del host compartido antes de que se agote el disco bruto.
Las páginas de VPS son más concretas porque enumeran valores de CPU virtual, RAM y SSD. Un plan Cloud VPS de 1 vCPU, 1 GB de RAM, 30 GB de SSD y un plan de 4 vCPU, 6 GB de RAM, 85 GB de SSD pueden aprovisionarse desde un clúster OpenStack modesto. Pero una tabla de planes no muestra cuántas instancias se pueden vender sin contención, cuántos nodos existen, si la CPU está sobresuscrita, cómo se ajusta la replicación de almacenamiento, si Ceph abarca dominios de energía independientes, o si las copias de seguridad se almacenan en el mismo sistema físico que deben proteger.
La página dice que Ceph mantiene los datos replicados en varios lugares; un cliente aún necesita saber si esos lugares son discos separados, chasis separados, racks separados o instalaciones separadas.
El lenguaje de nivel de servicio del 99,99 por ciento de la página de nube privada debe tratarse como una afirmación a verificar, no como prueba del estado operativo alcanzado. Cuatro nueves de disponibilidad solo permiten una pequeña cantidad de tiempo de inactividad al año, y requieren tanto disciplina de arquitectura como de operaciones: energía redundante, rutas de red redundantes, almacenamiento cuidadosamente gestionado, recuperación probada del plano de control, gestión de cambios, monitorización y un equipo de soporte capaz de actuar rápidamente.
El sitio público no publica el documento de SLA, el calendario de créditos, el método de medición, las exclusiones, el tratamiento del mantenimiento planificado o el historial de incidentes que permitirían a un comprador evaluar esa promesa.
La cantidad de direcciones limita algunos casos de uso. Un cliente que necesite muchas direcciones IPv4 públicas, separación del servicio de correo, compatibilidad heredada con SSL basado en IP, aislamiento anti-abuso o puntos finales de VPN debe preguntar cuánto IPv4 está realmente disponible. El recuento de 256 direcciones IPv4 deRIPEstatno es lo mismo que 256 IPs de cliente vendibles. Algunas son consumidas por infraestructura, DNS, alojamiento compartido, gestión, reservas y asignaciones de clientes. Se venden IPs adicionales en la página de Cloud VPS, lo que hace que el conjunto sea operativamente importante. Si los problemas de abuso o de listas negras afectan a una parte del /24, el pequeño conjunto de direcciones puede dificultar la recuperación.
IPv6 es otra carencia. Las páginas de productos públicos de Hosting27 revisadas aquí no hacen una promesa fuerte de IPv6, y RIPEstat no muestra espacio IPv6 anunciado visible para AS42347 en el momento de la consulta. Un cliente que necesite alojamiento con IPv6 no debe inferirlo de la palabra nube. Debe solicitar una dirección IPv6 de prueba, cobertura SLA, manejo de firewall, DNS inverso, evidencia de enrutamiento y si el soporte IPv6 está disponible en alojamiento compartido, VPS, nube privada y Kubernetes de la misma manera que IPv4.
La conclusión de capacidad del artículo es, por tanto, conservadora: Hosting27 vende un conjunto real de productos de alojamiento y nube, y AS42347 da a esos productos un borde de red público real. Pero no hay evidencia pública que traduzca el menú de planes en nodos instalados, capacidad libre disponible, diseño multisitio o imágenes recuperables por el cliente.
Las reclamaciones de soporte y copias de seguridad son útiles, pero la autoridad de reparación es la cuestión central
La evidencia de soporte es mejor que el silencio. Lapágina de contactode Hosting27 enumera direcciones de soporte, incluyendo buzones de soporte y devops, y una dirección de ventas separada. Lapágina de tickets de soportedice que los clientes que no puedan resolver un problema en la documentación pueden enviar una solicitud al departamento correspondiente. Describe el soporte como funcionando todos los días sin interrupción y las consultas de ventas como procesadas de lunes a viernes de 09:00 a 18:00. Labase de conocimientotiene categorías para cPanel, Virtualmin, servidores VPS, WordPress, dominios y alojamiento compartido. Lapágina de anuncioscontiene un anuncio más antiguo de 2018 sobre el sitio web, lo que al menos muestra que el portal de clientes ha sido parte de la superficie de servicio durante años.
Estas son señales operativas útiles. No son suficientes para responder al riesgo de la ventana de reparación. La distinción más importante es entre un canal de soporte que recibe tickets y un equipo de operaciones con autoridad sobre el componente que falla. Si el fallo es una configuración de cPanel, el servicio de asistencia del proveedor puede solucionarlo rápidamente.
Si el fallo es un disco muerto, un conmutador fallado, un problema de alimentación eléctrica, un problema de quórum en el clúster de almacenamiento, un filtro de ruta upstream o una cuenta de facturación bloqueada, la reparación depende de quién controla el hardware, el acceso a las instalaciones, las sesiones de ruta y los permisos contractuales.
Los términos generales también son útiles pero incompletos para la planificación de incidentes. El PDF dice que los servidores virtuales gestionados incluyen soporte técnico las 24 horas, monitorización y reacción a problemas, copias de seguridad periódicas y la capacidad de alojar aplicaciones de clientes. Dice que el alojamiento compartido incluye soporte técnico y deja claro que los usuarios comparten recursos. Las páginas públicas anuncian adicionalmente copias de seguridad diarias en Cloud VPS y Cloud VPS gestionado, copias de seguridad de un mes en alojamiento compartido y migración gratuita para algunos planes. Eso es valioso.
Pero aún deja las preguntas prácticas abiertas: ¿están las copias de seguridad en el mismo clúster o fuera de él, cuántas generaciones existen, puede un cliente restaurar por autoservicio, se puede exportar una imagen de VM, qué sucede después de la suspensión de la cuenta y cuál es el tiempo de restauración objetivo?
La promesa de migración también es más limitada de lo que parece. Hosting27 dice que puede mover una cuenta de alojamiento o un sitio WordPress de forma gratuita. Eso ayuda durante la incorporación. No crea necesariamente una ruta de salida. Un cliente que se vaya más tarde puede necesitar una copia de seguridad completa de cPanel, un volcado de base de datos, archivos de zona DNS, buzones, imagen de disco de VM, instantánea de almacenamiento en bloque, datos de objetos, manifiestos de Kubernetes, imágenes de contenedores, secretos y renumeración de IP.
El sitio público no describe formatos de exportación, ventanas de retención, tarifas de migración después de la cancelación o si los clientes pueden sacar imágenes de OpenStack.
El manejo de abusos importa porque los proveedores de alojamiento viven y mueren por la reputación compartida. El registro de organización RIPE para Hosting-27 dirige el abuso aGLAC2-RIPE, un contacto de abuso de GateIT. Esa es una ruta de abuso de registro, no necesariamente la misma que un servicio de asistencia minorista. Un cliente que ejecute correo, comercio electrónico o APIs públicas debe preguntar quién gestiona el DNS inverso, quién maneja la reparación de listas negras, quién decide si una cuenta comprometida causa una suspensión más amplia y si los problemas de reputación de IP pueden aislarse dentro del /24.
La postura de soporte público es, por tanto, lo suficientemente creíble como para contarla, pero no lo suficientemente detallada como para eliminar el riesgo operativo. Los compradores deben probar el servicio de tickets antes de mover cargas de trabajo importantes, solicitar una ruta de contacto para incidentes y pedir condiciones escritas de copia de seguridad y exportación en lugar de confiar en la taquigrafía de la página de planes.
La localidad de los datos no se establece con una dirección búlgara o una IP búlgara
La superficie búlgara de Hosting27 es relevante. El sitio web está en búlgaro, la página de contacto da detalles de Sofía, la organización y dirección RIPE son búlgaras, el ASN está en la región RIPE y el bloque IPv4 visible está registrado con país BG. Para clientes con usuarios búlgaros, una factura búlgara, soporte en el idioma local y latencia a Sofía o redes regionales pueden ser razones para considerar el servicio. Para clientes con requisitos regulatorios o contractuales de localidad de datos, esas señales son solo el comienzo.
El contexto búlgaro y de la UE hace que la distinción sea importante. La descripción general de la Comisión Europea delmarco legal de protección de datos de la UEexplica el régimen de protección de datos a escala de la UE. Su página sobreresponsables y encargados del tratamientoexplica la distinción entre la parte que decide cómo se tratan los datos personales y una parte que los trata por cuenta de otra. La página decláusulas contractuales tipode la Comisión cubre las herramientas de transferencia de datos para situaciones fuera del Espacio Económico Europeo. LaComisión de Protección de Datos Personalesde Bulgaria es la autoridad nacional de control. Este artículo no es asesoramiento legal, pero esas referencias públicas muestran por qué la ubicación de la infraestructura, el acceso al soporte y la geografía de las copias de seguridad no son detalles cosméticos.
Una dirección IP búlgara no prueba que todos los datos permanezcan en Bulgaria. Las copias de seguridad del alojamiento compartido podrían almacenarse en otra instalación. La monitorización podría realizarse desde otro lugar. Un ticket de soporte podría incluir datos personales. Un panel de control podría depender de software de terceros o autenticación externa. Una función de CDN podría colocar intencionalmente contenido estático en otros países. Un servicio de registro de dominios necesariamente interactúa con registros y registradores fuera del nodo de alojamiento.
Un cliente de nube privada puede crear redes y volúmenes en una consola de aspecto búlgaro mientras algunos componentes de gestión o copia de seguridad residen en otro lugar.
Las preguntas de diligencia adecuadas son, por tanto, concretas. ¿Dónde está el nodo de computación principal? ¿Dónde se almacenan las instantáneas y las copias de seguridad? ¿Está el personal de soporte y los administradores remotos dentro de la UE? ¿Ofrece el proveedor un acuerdo de tratamiento de datos? ¿Qué entidad legal es el encargado del tratamiento para los servicios de alojamiento? ¿Nombra el contrato a la misma parte que factura al cliente? Si los datos salen de Bulgaria o del EEE, ¿qué mecanismo de transferencia se aplica? ¿Qué sucede si el cliente solicita la eliminación o exportación?
¿Qué registros se guardan y durante cuánto tiempo?
Estas preguntas no son una sospecha especial hacia Hosting-27. Son normales para cualquier pequeño proveedor de nube o alojamiento que comercializa la localidad. La evidencia pública aquí respalda un área de servicio búlgara y un borde enrutado búlgaro. No prueba una arquitectura completa de residencia de datos búlgara.
Las rutas de fallo a probar son el rack, el upstream, el inventario de hardware, el soporte, la facturación y la migración
La primera ruta de fallo es el rack. Si un servidor de alojamiento compartido o un host VPS falla, ¿quién toca la máquina? Un cliente debe preguntar dónde está el rack, quién es el propietario del hardware del host, cómo está protegida la energía, si hay nodos de repuesto, si el almacenamiento es local o distribuido y si un nodo fallido puede evacuarse sin cambiar la IP del cliente. El sitio web público afirma tener copias de seguridad y características de nube, pero no nombra la instalación física, el armario, el proveedor de manos remotas o el plan de hardware de repuesto.
La segunda ruta es el tránsito upstream. RIPEstat ve actualmente AS42347 a través de AS57344. El proveedor debería poder decir si la ruta tiene un segundo upstream activo, si Telepoint está activo, en espera o es histórico, si la ruta de respaldo se prueba, si se monitoriza la validación de origen de ruta y si los clientes reciben aviso antes del mantenimiento de la red. Un resultado RPKI válido es bueno. No es lo mismo que un segundo camino.
La tercera ruta es el inventario de hardware y almacenamiento. Las ofertas de VPS y nube privada dependen de la relación entre los planes vendidos y la computación, RAM, IO de disco y replicación de almacenamiento disponibles. Un cliente debe preguntar si los recursos anunciados están garantizados, si la CPU está sobresuscrita, si Ceph abarca hosts separados o racks separados, cuántos fallos se pueden tolerar y si hay suficiente capacidad de repuesto para restaurar un host durante un período de mucha actividad.
La página pública nombra OpenStack, KVM y Ceph, pero esos nombres pueden describir desde un pequeño clúster hasta un entorno multi-rack más grande.
La cuarta ruta es la escalada de soporte. Hosting27 expone páginas de soporte, ventas, base de conocimiento y tickets. El comprador debería probar la calidad de la respuesta, preguntar quién está de guardia, identificar la ruta de emergencia para una VM caída y preguntar si el soporte puede llegar directamente a los operadores de red e instalaciones. Una respuesta de ventas no es lo mismo que la autoridad para incidentes.
La quinta ruta es la continuidad de facturación y legal. Los términos del PDF del sitio web nombran a Cloud Systems OOD como proveedor, mientras que RIPE nombra a Hosting-27 LTD como la organización de red. Los clientes deben preguntar qué parte firma el contrato, qué parte factura, qué parte controla la suspensión del servicio y qué parte es responsable de la exportación y eliminación después de la cancelación. Si la cuenta se suspende por facturación o abuso, el cliente debe saber cuánto tiempo permanecen recuperables los datos.
La sexta ruta es la migración. Para el alojamiento compartido, la ruta de salida debe incluir copia de seguridad de cPanel, DNS, buzones y bases de datos. Para WordPress, debe incluir archivos, base de datos, redirecciones y sincronización de DNS. Para VPS, debe incluir exportación de imagen de disco, formato de instantánea, renumeración de IP y actualizaciones de firewall. Para nube privada y Kubernetes, debe incluir volúmenes, redes, balanceadores de carga, manifiestos, secretos y registros de imágenes.
Hosting27 comercializa la migración de entrada gratuita, pero el material público no publica una promesa completa de portabilidad de salida.
La séptima ruta es la reputación de la dirección. Un /24 compacto puede ser eficiente, pero da menos margen para aislar a clientes comprometidos. Los problemas de correo, proxy, escaneo y abuso pueden llevar a listas de bloqueo, filtrado upstream o suspensiones internas. Los clientes con cargas de trabajo de correo o transaccionales deben solicitar control de DNS inverso, procedimiento de respuesta a abusos, política de limpieza de listas negras y si las direcciones IP adicionales provienen del mismo conjunto 217.174.144.0/24.
Estos no son problemas teóricos. Son los modos de fallo ordinarios ocultos bajo el alojamiento de bajo coste: un rack al que no se puede llegar, una sesión upstream que desaparece, un clúster de almacenamiento que pierde el quórum, una copia de seguridad que existe pero no se puede restaurar rápidamente, una cola de tickets que no puede llegar a la instalación y un cliente que descubre demasiado tarde que mudarse significa reconstruir todo en torno a nuevas direcciones IP.
Qué haría que la evidencia fuera sólida
Hosting-27 Hosting-27 LTD tiene suficiente evidencia pública para un perfil operativo real: el sitio web está en línea, el portal de clientes está en línea, las páginas de productos son específicas, la ruta es visible, el dominio se resuelve dentro del bloque IPv4 visible de la empresa, la organización RIPE está actualizada y la autorización de origen de ruta es válida. Eso es materialmente más sólido que una empresa cuyo único rastro es un registro de AS obsoleto.
La evidencia pública no es lo suficientemente sólida para una dependencia de infraestructura de alta confianza sin una diligencia directa.
Un perfil más sólido incluiría una página legal actualizada que alinee la marca, la organización RIPE y el proveedor contratante; una declaración de instalación que nombre al operador del centro de datos o explique el acuerdo de alojamiento; un SLA con términos de medición y crédito; una página de estado o archivo de incidentes; objetivos explícitos de retención y restauración de copias de seguridad; disponibilidad de IPv6 si se ofrece; un segundo upstream activo o una explicación por escrito de la política de ruta de Telepoint; formatos de exportación para datos de VPS y nube privada; y un procedimiento claro de abuso y reputación de IP.
El conjunto probable de clientes debería escalonarse según el riesgo. Un pequeño sitio web búlgaro, un servidor de pruebas, un sitio WordPress no crítico o un VPS experimental pueden evaluar Hosting27 mediante pruebas de servicio ordinarias: contratar un plan pequeño, probar el soporte, comprobar la latencia, restaurar una copia de seguridad y verificar la cancelación. Un sistema crítico para el negocio no debería confiar solo en la tabla de planes. Debería obtener respuestas por escrito sobre las instalaciones, las copias de seguridad, la diversidad de tránsito, la contratación legal y la portabilidad de datos antes de migrar a producción.
La lectura final es equilibrada. Hosting-27 Hosting-27 LTD es visible como un vendedor búlgaro de capacidad alojada con AS42347 y una plataforma Hosting27.com en vivo. Su historia operativa pública no está vacía. Pero los hechos decisivos de infraestructura permanecen detrás de la capa de ventas.
Hasta que esos hechos se divulguen o se verifiquen en un contrato con el cliente, Hosting27 debe entenderse como un proveedor búlgaro compacto de alojamiento y servicios en la nube cuya promesa al cliente aún depende de racks no vistos, tránsito visible a través de Telehouse, existencias finitas de IPv4, mano de obra de soporte, contratos con proveedores y ventanas de reparación.