Resumen
- AS131316 tenía siete anuncios IPv4 visibles que cubrían 2,048 direcciones el 15 de julio de 2026. PeeringDB listaba conexiones de intercambio operativas de 10 Gbps en Melbourne y Perth, y una conexión de 1 Gbps en EdgeIX en Melbourne, mientras que RIPE RIS veía la red a través de 325 de 326 peers IPv4.
- La hoja actual de cloud dedicado comienza en A$200 más GST y promete un VPS basado en CWP con cómputo, almacenamiento y red redundantes. No identifica una instalación cloud, un segundo sitio de cómputo, el número de racks, la distribución de almacenamiento, el diseño de energía, el grupo de hosts de respaldo, el objetivo de recuperación ni el resultado de una conmutación por error probada.
- El mismo documento de producto de cuatro páginas proporciona dos descripciones de recursos diferentes: al menos 2 vCPU, 8 GB de RAM y 50 GB de SSD cerca del principio, luego un VPS de 6 núcleos, 16 GB de RAM y 150 GB de SSD en su resumen final. Un cliente necesita la cotización y el programa de servicio para determinar lo que realmente está reservado.
- La operación de red actual está bien respaldada, pero la resiliencia de la capacidad alojada no lo está. La evaluación justa es Media para la red visible y Débil para la evidencia pública de redundancia cloud física, capacidad de respaldo utilizable y restauración del cliente.
El número más claro está en el borde de la red, no dentro del cloud
Slnet Hosting tiene una huella de red pública más sustancial de lo que su nombre compacto podría sugerir. A las 08:00 UTC del 15 de julio de 2026, la vista de estado de enrutamiento de RIPEstat para AS131316 contaba siete prefijos IPv4, 2,048 direcciones anunciadas, cinco vecinos observados y visibilidad desde 325 de 326 peers IPv4 de RIS. La primera ruta observada data de julio de 2011. No es un registro inactivo mantenido en un estante. Es un sistema autónomo de larga duración cuyas rutas eran casi universalmente visibles para los recolectores en esa instantánea.
El registro de interconexión también es específico. El perfil de PeeringDB mantenido por el operador lista un puerto de 10 Gbps en IX Australia Melbourne, un segundo puerto de 10 Gbps en IX Australia Perth y un puerto de 1 Gbps en EdgeIX Melbourne. Las tres entradas están marcadas como operativas e incluyen direcciones de intercambio IPv4 e IPv6. La propia lista de participantes de EdgeIX muestra independientemente a Screw Loose Software, AS131316, en una conexión de 1 Gbps. Esos registros establecen un borde de red este-oeste australiano creíble.
No establecen la capacidad del cloud vendido a un cliente. Un puerto de intercambio es un lugar donde una red puede intercambiar tráfico. No es un recuento de hipervisores, una garantía de replicación de almacenamiento, una reserva de energía ni una prueba de que la carga de trabajo de un cliente pueda reiniciarse en la otra ciudad. Sumar 10, 10 y 1 en un titular de 21 Gbps sería aritméticamente fácil y operativamente engañoso. Los puertos están en diferentes intercambios, pueden servir a diferentes tráficos y pueden estar limitados por tránsito, política de enrutamiento, enlaces internos, puertos de servidores o la propia carga de trabajo.
El número de hosting orientado al cliente proviene de un documento diferente. La hoja de servicio de Cloud Dedicado de Screwloose IT de diciembre de 2025 anuncia un contenedor VPS desde A$200 más GST al mes. Dice que la plataforma incluye redundancia subyacente en cómputo, almacenamiento y red. Sin embargo, no nombra el centro de datos, el número de salas o racks independientes, la ubicación de la copia de respaldo, el tiempo de recuperación, el punto de recuperación ni la prueba de conmutación por error más reciente.
Esa brecha define la historia. Slnet puede probar un borde enrutado vivo. Puede probar que existe un producto de hosting actual. El registro público no une esas dos capas en un diseño de recuperación verificable.
Slnet es el nombre de la red dentro de un negocio de servicios australiano más amplio
Los nombres alrededor de AS131316 deben desenredarse antes de juzgar la propiedad. El registro de sistema autónomo de APNIC llama a la redSLNET-AU, la describe como Slnet Hosting e identifica al registrante como Screw Loose Software. El registro ha estado activo desde el 7 de junio de 2011 y se modificó por última vez en septiembre de 2024. PeeringDB usa Screw Loose Software como nombre de la organización y ScrewlooseIT como nombre alternativo.
El sitio web comercial actual usa Screwloose IT. Sus documentos de cliente muestran ABN 59 160 395 479. El registro de ABN del gobierno australiano identifica ese número como Australian Client Services Pty. Ltd., una empresa privada activa, y lista Screwloose IT y Hostone entre sus nombres comerciales registrados. En otras palabras, Slnet Hosting se entiende mejor como la identidad pública de enrutamiento y hosting asociada con un negocio australiano más amplio de TI gestionada, telecomunicaciones y cloud. No debe tratarse como una empresa legalmente verificada por separado simplemente porque el ASN tiene una etiqueta distinta.
La historia de primera parte proporciona un contexto útil. La página de empresa de Screwloose IT dice que invirtió en una presencia en centros de datos en 2009 y comenzó a ofrecer Hosted Exchange, hosting de sitios web y aplicaciones web, servidores cloud y escritorios cloud. Dice que el negocio entró en telecomunicaciones en 2013 y luego obtuvo una presencia en Australia Occidental a través de Host One. Un anuncio separado de Host One dice que la adquisición tuvo efecto el 1 de enero de 2022 y añadió un equipo en Perth y tres horas más de soporte cada día mediante la cooperación entre Perth y Melbourne.
Esas dos páginas no presentan una cronología perfectamente alineada: una historia sitúa la expansión en Australia Occidental en 2018, mientras que el anuncio de adquisición da 2022. La discrepancia no borra la red visible ni el ABN actual. Sí significa que la fecha exacta y la estructura legal de la integración de Host One deben provenir de registros corporativos y contratos, no de una cronología de marketing.
La página de contacto ahora lista oficinas en Osborne Park, Mulgrave, Milton y Bondi. Estas son valiosas señales de soporte y área de servicio. No son direcciones de centros de datos. Una oficina puede albergar ingenieros y personal de cuentas mientras los servidores del cliente están en una instalación de terceros en otro lugar. Ninguna de las oficinas debe ser trazada como un sitio cloud sin una declaración de instalación separada.
Este límite de propiedad importa durante una interrupción. Australian Client Services puede controlar la relación con el cliente, la configuración de la plataforma, sus propios servidores, la política de rutas de AS131316 y la escalada. Un operador de coubicación controla el acceso al edificio, la distribución de energía y las manos remotas. Los operadores de tránsito e intercambio controlan otras partes de la ruta. El cliente controla el diseño de la aplicación, las copias independientes y la capacidad de moverse. El nombre en la factura no puede eliminar esas otras dependencias.
Dos productos de hosting exponen dos modelos de capacidad muy diferentes
La literatura de producto actual describe tanto hosting compartido como un contenedor cloud dedicado. La hoja de servicio de Website Hosting precio el hosting web compartido en A$15 más GST al mes. Proporciona una cuenta CWP, una dirección pública compartida y una pila común Apache o Nginx, PHP y MariaDB o MySQL. La CPU, la memoria y la entrada/salida de disco se comparten entre los clientes. El documento advierte expresamente que el uso intensivo de un cliente puede afectar a otros, que algunos ajustes no se pueden cambiar a nivel de cuenta y que la reputación del correo electrónico se comparte.
Eso es un acuerdo de hosting compartido directo. El proveedor mantiene la disponibilidad del servidor compartido, los servicios comunes, la seguridad de línea base y la salud del servidor. El cliente o desarrollador mantiene el sitio, el código, los plugins, los temas, el uso de la base de datos y las cuentas administrativas. Los parches del SO, la reparación de CWP, el trabajo de rendimiento, la eliminación de malware, la reparación del sitio y la mayoría de las restauraciones están fuera del plan de A$15. La migración y la restauración que no sea por fallo del servidor se pueden adquirir como servicios profesionales.
El producto dedicado mueve el límite pero no lo elimina. La hoja de Cloud Dedicado describe un contenedor VPS con una dirección estática dedicada, asignación de ancho de banda dedicada y aislamiento a nivel de root. Promete al menos 2 vCPU, 8 GB de RAM y 50 GB de almacenamiento SSD, dimensionados a través de una cotización formal. También lista un firewall de aplicaciones web, reglas de ModSecurity, protecciones FirewallD o CSF, detección de ataques, registro, monitoreo y reinicios automáticos de servicios cuando sea necesario.
El proveedor acepta la responsabilidad de mantener el VPS disponible, hacer que la CPU, RAM y almacenamiento asignados funcionen, mantener su infraestructura cloud y mantener activos los controles de seguridad de línea base. Pero la tarifa no incluye parches del sistema operativo, actualizaciones de CWP, mejoras de la pila del servidor, ajuste de rendimiento, endurecimiento más fuerte, solución de problemas del sitio o respuesta a incidentes para una violación a nivel de servidor.
La restauración de un sitio comprometido está fuera del alcance, y la restauración desde una copia de seguridad está incluida solo cuando la necesidad surge de una falla del servidor.
Esto no es una crítica de un contrato inusual. El hosting a menudo se divide en capas de instalación, plataforma, sistema y aplicación. El punto importante es que la página de ventas actual llama a la oferta de Screwloose un servicio cloud profesional y dice que especialistas locales proporcionan soporte continuo, mientras que las hojas de inclusiones formales dibujan una línea más estrecha alrededor de la tarifa base de hosting. Un comprador debe decidir si quiere un contenedor aislado, un sistema operativo gestionado, una aplicación gestionada o los tres.
La factura puede parecer un servicio cloud único mientras que la recuperación cruza varias responsabilidades con precios separados.
Las descripciones de 2 núcleos y 6 núcleos no pueden definir ambas un solo mínimo estándar
La hoja dedicada contiene un problema de especificación concreta. La sección 2 dice que cada entorno dedicado incluirá al menos 2 núcleos vCPU, 8 GB de RAM y 50 GB de almacenamiento SSD. La sección 6, en la página final, resume el plan como un VPS dedicado de 6 núcleos, 16 GB de RAM y 150 GB de SSD. El documento no explica si la configuración más grande es un ejemplo, un plan revisado, un remanente específico del cliente o el producto estándar real.
Esto importa porque la contabilidad de capacidad comienza con la unidad vendida. Si el contenedor base reserva dos núcleos virtuales y 8 GB, su densidad de host y economía de precio difieren de un servicio de seis núcleos y 16 GB. Un disco de 50 GB crea una carga diferente de copia de seguridad, instantánea y migración que 150 GB. La frase "a partir de" ya deja espacio para cotizaciones; el resumen contradictorio hace que la cotización sea esencial en lugar de complementaria.
Un cliente no debe resolver la discrepancia a su favor. Debe pedir un programa de servicio firmado que indique si la CPU es compartida, limitada, ampliable o fija; si "núcleo" significa vCPU o núcleo físico; si la memoria está reservada; si el almacenamiento es local o distribuido; si se incluyen 50 GB o 150 GB; y si la dirección estática proviene de AS131316. También debe preguntar qué significa "asignación de ancho de banda dedicada" en megabits por segundo, si es una velocidad de puerto o una tasa comprometida, y qué controles de congestión o uso justo se aplican.
La discrepancia también limita cualquier estimación de capacidad instalada. Los datos de enrutamiento público proporcionan 2,048 direcciones, pero una dirección no equivale a un VPS y muchas direcciones pueden servir a enrutadores, hosts compartidos, redes de clientes o asignaciones inactivas. Las hojas de producto proporcionan recursos por cuenta, pero ningún recuento de hosts. PeeringDB proporciona velocidades de puerto, pero ninguna capacidad de tejido orientado al servidor.
La declaración de capacidad defendible es por lo tanto estrecha. Slnet tiene un patrimonio de direcciones enrutadas real y conectividad de intercambio declarada. Screwloose vende al menos un nivel de hosting compartido y un nivel de VPS cotizado. El número total de servidores, núcleos virtuales, terabytes, racks y pedidos disponibles sigue sin divulgarse.
Siete rutas IPv4 válidas muestran operación actual, no cómputo de repuesto
El patrimonio de rutas es inusualmente ordenado. La respuesta de prefijos anunciados de RIPEstat mostró estas siete rutas continuamente visibles durante la ventana observada del 1 al 15 de julio:103.4.122.0/24,103.4.123.0/24,103.50.12.0/24,103.50.13.0/24,103.100.199.0/24,103.114.34.0/24y103.172.76.0/23. Juntos contienen 2,048 direcciones IPv4.
Los registros de APNIC revelan la historia detrás del conjunto. Los registros de103.4.122.0/24y103.4.123.0/24llevan el nombre SLNET.103.50.13.0/24está registrado a Hostone Pty Ltd.103.114.34.0/24nombra a Screw Loose Software. La asignación103.172.76.0/23nombra a Australian Client Services Pty Ltd. Otro /24 visible se extrae de un bloque registrado a Bottle Communications. Estas etiquetas son consistentes con una red ensamblada a través de nombres operativos y tenencias de direcciones adquiridas o relacionadas, pero no prueban por sí mismas el contrato actual que rige cada bloque.
Las siete verificaciones de origen devolvieron válido en RIPEstat cuando se probaron contra AS131316. Por ejemplo, la validación de103.172.76.0/23encontró una autorización de origen de ruta coincidente con una longitud máxima de /23. RPKI válido es valioso: permite a las redes participantes rechazar un origen no autorizado para la ruta cubierta. No mantiene el enrutador autorizado encendido, evita una mala política, añade ancho de banda o restaura un servidor fallido.
El borde público tampoco tenía espacio IPv6 originado en la instantánea de RIPE. Eso es notable porque cada entrada de intercambio en PeeringDB incluye una interfaz IPv6. Una dirección IPv6 en una LAN de intercambio muestra que el enrutador puede participar allí; no es lo mismo que originar prefijos IPv6 de cliente. Un comprador que necesita IPv6 nativo debe pedir una asignación específica del servicio y probarla, en lugar de inferir la disponibilidad de las filas de intercambio.
Las siete rutas son evidencia sólida de que el operador permanece activo. No pueden decirle a un comprador cuántas direcciones están libres, cuánto inventario de servidores hay detrás de ellas, si los grupos de direcciones de Perth y Melbourne se asignan a cómputos separados, o si la dirección de un cliente puede moverse durante una falla del sitio.
Tres filas de intercambio no son un mapa de ruta físico
PeeringDB etiqueta las conexiones de intercambio de 10 Gbps en Melbourne y Perth como operativas, y la entrada más nueva de EdgeIX Melbourne se actualizó en marzo de 2026. La vista de participantes de WA-IX de Packet Clearing House también lista AS131316 en27.106.192.207, proporcionando corroboración independiente de la identidad de intercambio en Perth. La red está claramente representada en ambas ciudades.
Lo que está ausente es igualmente importante. La API de PeeringDB no devuelve registros de instalaciones para AS131316. Eso no prueba que la red no posea racks ni alquile coubicación. PeeringDB se automantiene y está incompleto. Significa solo que el perfil público no identifica los edificios en los que se encuentran los enrutadores o sistemas de hosting de Slnet. Los nombres de intercambio identifican tejidos metropolitanos, no suites exactas, alimentaciones eléctricas o rutas de cable.
Una conexión de intercambio se puede entregar de varias maneras. Un enrutador puede estar en una de las instalaciones listadas del intercambio. Un operador puede extender la LAN de intercambio sobre transporte a otro edificio. Un revendedor puede proporcionar una conexión virtual. Un solo puerto físico puede llevar varios servicios lógicos. Sin un registro de instalación o declaración del operador, una fila de intercambio debe tratarse como presencia metropolitana lógica con una velocidad de puerto declarada, no una ruta dibujada a través de un edificio nombrado.
La misma precaución se aplica a la geolocalización de direcciones. IPinfo coloca direcciones AS131316 respondientes en Melbourne y Perth y observó una ruta corta reciente a103.172.76.1desde una sonda en Perth. Esa es una señal de mercado útil. Las bases de datos de geolocalización pueden basarse en registros, latencia, enrutamiento y envíos de operadores, y pueden ser incorrectas a nivel de edificio o incluso de ciudad. Un resultado de sonda muestra un punto final de red respondiendo con baja latencia desde una ubicación; no muestra el rack que contiene los discos del cliente.
Las oficinas de Screwloose no pueden llenar el vacío. Una oficina de soporte en Osborne Park no es automáticamente el sitio del enrutador de WA-IX. Una oficina en Mulgrave no es automáticamente el cloud de Melbourne. La declaración de 2009 sobre una presencia en centros de datos establece que la empresa entró en infraestructura alojada, pero no nombra una instalación actual. La adquisición de Host One respalda un negocio y una huella de red en Australia Occidental, pero no afirma que los contenedores VPS se repliquen entre Perth y Melbourne.
El mapa que se puede dibujar responsablemente tiene dos nodos de red a nivel de ciudad, Melbourne y Perth, más cuatro oficinas comerciales. No puede incluir una instalación cloud exacta, una ruta de datos del cliente o una línea de conmutación por error entre ciudades. Esas siguen siendo preguntas de adquisición.
La redundancia debe estar vinculada a un dominio de falla
"Redundancia de infraestructura subyacente" suena completo porque nombra cómputo, almacenamiento y red. Para hacer la frase operativa, cada capa necesita un componente independiente y una falla definida que pretende soportar.
La redundancia de cómputo puede significar un host físico de repuesto, un clúster que puede reiniciar un contenedor, migración en vivo, o simplemente múltiples fuentes de alimentación en un chasis. Esos diseños tienen diferentes resultados. Un host de repuesto puede absorber una falla solo si tiene suficiente CPU, memoria, acceso a almacenamiento y configuración de red compatible. La migración en vivo ayuda durante el mantenimiento planificado pero puede no ayudar después de una falla repentina del host o del almacenamiento. Dos hosts en el mismo rack aún comparten la energía del rack y la conmutación.
La redundancia de almacenamiento puede significar discos en espejo, RAID, volúmenes replicados, instantáneas o copias de seguridad. El espejo puede sobrevivir una falla de disco pero copia la corrupción inmediatamente. Una instantánea puede proteger contra un cambio equivocado mientras permanece en la misma matriz. La replicación puede mejorar la disponibilidad mientras preserva la misma dependencia del operador y la cuenta. Una copia de seguridad se vuelve útil solo cuando se puede restaurar con las aplicaciones, configuraciones, credenciales y configuración de red necesarias para reanudar el servicio.
La redundancia de red puede significar enlaces duales, dos conmutadores, dos enrutadores, upstreams separados o entradas de edificio físicamente diversas. Los tres puertos de intercambio de PeeringDB crean opciones útiles, y la vista de vecinos de RIPEstat observó Kinetix Networks, Simtronic, Hurricane Electric y dos vecinos de menor confianza. Pero la adyacencia BGP observada no revela contratos, participación de tráfico, rutas de fibra ni si se probó la conmutación por error. Dos upstreams lógicos pueden compartir una misma cola de operador o dominio de energía.
La redundancia de energía no se describe en absoluto en la hoja de hosting. El material público no indica el número de alimentaciones de servicios públicos, la topología del UPS, el tiempo de funcionamiento del generador, la densidad de potencia del rack ni si el equipo de Slnet utiliza alimentaciones A y B. Estos son normalmente hechos a nivel de instalación y pueden estar disponibles bajo confidencialidad, pero no pueden inferirse de una conexión de intercambio.
La pregunta relevante del cliente no es "¿Es redundante?" Es "¿Qué fallos individuales puede sobrevivir este servicio sin acción del cliente, y qué sucede después de dos fallos relacionados?" Una respuesta útil nombra los hosts primario y secundario, la copia de almacenamiento, el rack y la instalación, el desencadenante del reinicio, el intervalo de pérdida de datos esperado, el tiempo de restauración esperado y el último ejercicio exitoso. Ningún documento público de Slnet proporciona esa cadena.
La primera ruta de falla comienza dentro del VPS
Una aplicación alojada en Slnet puede fallar mientras AS131316 permanece perfectamente visible. El sistema operativo invitado puede colgarse. Un sistema de archivos lleno puede detener una base de datos. Un componente de CWP sin parche puede verse comprometido. Un plugin del sitio puede agotar la memoria. Un certificado puede expirar. En estos casos, los enrutadores, la energía de la instalación y el host físico pueden estar todos saludables.
La hoja de servicio dedicado dibuja este límite claramente. El proveedor monitorea la accesibilidad básica y mantiene activas las herramientas de firewall de línea base, pero los parches del sistema operativo, las actualizaciones de CWP, las mejoras de la pila web, el ajuste proactivo y el endurecimiento más fuerte no están incluidos. La recuperación de compromisos a nivel de sitio también está fuera de la tarifa base. Un cliente que pensaba que "hosting cloud profesional" incluía administración de sistemas gestionada podría descubrir la diferencia durante el incidente.
La segunda ruta de falla es el host. Un procesador, módulo de memoria, placa base, tarjeta de red, unidad, controlador o fuente de alimentación puede fallar. El registro público no revela cuántos hosts existen, si los discos del cliente son locales, si un clúster puede reiniciar un contenedor en otro lugar, cuánta memoria reservada se mantiene libre, o si hay piezas de repuesto en el sitio. El reinicio automático del servicio es útil para un proceso bloqueado; no es evidencia de que un chasis fallido pueda ser reemplazado dentro de un objetivo.
La tercera ruta es el almacenamiento compartido o el grupo de servidores. Un VPS dedicado puede tener recursos invitados reservados mientras aún comparte matrices de almacenamiento, conmutadores y sistemas de control con otros contenedores. Una cuenta de hosting compartido va más allá: la hoja de producto dice explícitamente que los clientes comparten CPU, memoria y entrada/salida de disco, y un usuario intensivo puede afectar a otros. La presión de capacidad puede aparecer como páginas lentas, consultas de base de datos retrasadas o correo fallido antes de que aparezca como una interrupción completa.
La cuarta ruta es el rack y la instalación. Un interruptor, unidad de distribución de energía, evento de refrigeración, restricción de acceso o error de mantenimiento puede afectar a varios hosts a la vez. La redundancia dentro de un chasis hace poco si ambas fuentes de alimentación usan la misma alimentación. Un host de repuesto en el mismo rack puede no estar disponible durante una interrupción del rack. Sin un segundo dominio de falla nombrado, la afirmación pública de redundancia debe tratarse como local a una arquitectura no revelada.
Ninguno de estos riesgos prueba una operación deficiente. Definen la evidencia que un comprador serio necesita. Los documentos actuales de Slnet establecen responsabilidades y características del producto. No publican historial de fallos, métricas de estado o resultados de restauración cronometrados que mostrarían cómo se comportan las capas bajo estrés.
Las copias de seguridad se prometen en marketing y se asignan al cliente en los términos
La página de servicios cloud de Screwloose dice que el cloud siempre está respaldado y pone la redundancia en el centro de la solución. El material de migración más amplio recomienda copias inmutables, tiempo de recuperación acordado y objetivos de punto de recuperación, restauraciones de prueba rutinarias y planes de reversión. Estas son prácticas sensatas.
Los documentos legales y de producto son más condicionales. Los Términos y Condiciones Generales establecen que el cliente es el único responsable de hacer copias de seguridad y asegurar los datos conectados o suministrados con el servicio. La hoja dedicada excluye restaurar un sitio web desde una copia de seguridad a menos que la necesidad surja de una falla del servidor. La hoja compartida limita de manera similar las restauraciones incluidas y hace que otras restauraciones sean facturables.
Esas declaraciones pueden coexistir si el servicio mantiene copias de infraestructura mientras el cliente sigue siendo responsable de la recuperación del negocio. Pero los documentos públicos no definen la distinción. No indican la frecuencia de las copias de seguridad, la retención, el cifrado, la inmutabilidad, la ubicación, el medio, la separación de cuentas, el ancho de banda de restauración ni el momento de eliminación. No dicen si "siempre respaldado" se aplica a cada VPS, solo a compromisos gestionados, o solo a algunas clases de datos.
La guía de evaluación de Essential Eight del Centro Australiano de Ciberseguridad distingue entre tener copias y probar la restauración. Pregunta si los datos, aplicaciones y configuraciones pueden restaurarse a un punto común en el tiempo y si se ha ejercitado la recuperación total o parcial. Esa distinción es directamente relevante aquí. Una copia de disco sin la configuración correcta de CWP, el estado de la base de datos, DNS, claves y reglas de firewall puede no recrear un servicio funcional.
Un cliente de Slnet debe pedir dos respuestas. Primero, ¿qué copia mantiene el proveedor para recuperarse de su propio fallo de host o almacenamiento? Segundo, ¿qué copia puede recuperar el cliente de forma independiente si el proveedor, la cuenta o la instalación no están disponibles? La segunda copia debe incluir datos y suficiente configuración para reconstruir en otra plataforma. Debe probarse fuera de la cuenta de hosting principal.
Sin esas respuestas, la interpretación más segura es conservadora: la redundancia del proveedor puede mejorar la disponibilidad normal, pero el cliente sigue siendo dueño de la continuidad. Esa también es la posición más consistente con los términos generales publicados.
La diversidad de rutas ayuda solo cuando el servidor es accesible desde el borde
Las relaciones de red observadas de AS131316 reducen la posibilidad de que una adyacencia lógica sea todo el borde público. RIPEstat vio dos vecinos de alta potencia a la izquierda, AS134143 y AS55707, más Hurricane Electric y dos relaciones inciertas. PeeringDB muestra participación en servidores de ruta en los tres intercambios. Las autorizaciones de origen de ruta pública cubren los siete prefijos visibles. Esta es una postura de enrutamiento más fuerte que un host pequeño con un bloque de direcciones asignado por el proveedor y sin AS independiente.
Sin embargo, cada control de red responde una pregunta limitada. RPKI ayuda a otras redes a distinguir un origen autorizado. No evita que Slnet retire una ruta o anuncie una ruta incorrecta. Un servidor de ruta de intercambio ayuda a establecer muchos pares de manera eficiente, pero no es un sustituto del tránsito pagado a todo Internet. Un puerto de 10 Gbps puede transportar tráfico de intercambio local mientras que el tráfico del cliente a otro destino utiliza una ruta de tránsito más pequeña o congestionada. Un borde en Perth y un borde en Melbourne pueden depender de un plano de control interno o un contrato de proveedor.
Los Términos Generales reconocen directamente el límite del proveedor. Permiten a Screwloose usar y variar una mezcla de infraestructura propia y de terceros, dicen que el servicio puede depender de equipos y acuerdos de terceros, y permiten la terminación cuando un tercero deja de suministrar un servicio necesario. También rechazan la responsabilidad, en la medida permitida por la ley, por fallas de infraestructura de red de terceros.
Para un cliente alojado, la resiliencia de la ruta debe probarse desde la carga de trabajo hacia afuera. ¿El VPS tiene doble conexión a enrutadores de borde separados? ¿Están esos enrutadores en el mismo edificio? ¿Aparece el prefijo del cliente a través de ambas relaciones de tránsito? ¿Puede una ruta moverse entre ciudades sin mover el servidor? ¿La mitigación de DDoS introduce otra dependencia? ¿Hay una consola fuera de banda cuando la ruta pública falla?
IPv6 merece su propia prueba. Las interfaces de intercambio de PeeringDB son de doble pila, pero RIPEstat no vio prefijos IPv6 originados el 15 de julio. Un cliente no debe asumir que su VPS tiene IPv6 enrutado globalmente simplemente porque el enrutador de borde tiene una dirección de intercambio. El pedido debe indicar el prefijo asignado, el origen y el límite de soporte.
El registro de red pública de Slnet es lo suficientemente bueno para hacer preguntas precisas. No es lo suficientemente detallado para responderlas en nombre del operador.
La reparación depende de las personas, el alcance y el reloj
Screwloose presenta el soporte local como un diferenciador. La página cloud dice que los especialistas gestionan la migración y el soporte continuo y que el horario de la mesa de ayuda es de lunes a viernes, de 9 a 17 horas. El anuncio de adquisición de Host One dice que los equipos de Perth y Melbourne extienden la cobertura de soporte diario en tres horas. La página de contacto actual lista la misma ventana de oficina entre semana en cuatro ciudades.
El SLA de Servicios de TI Gestionados publicado añade detalle para los clientes que compran ese servicio. El soporte remoto y por correo electrónico regular funciona de 9 a 17 horas, hora de Australia Occidental. Las llamadas fuera de horario se reenvían a un móvil cuando es posible y se manejan con el mejor esfuerzo, con un servicio de contestación externo como respaldo. Los incidentes urgentes tienen un objetivo de respuesta de cero a cuatro horas hábiles, mientras que las prioridades media y baja pueden tomar más tiempo. El primer domingo de cada mes está reservado para mantenimiento del sistema con aviso si se espera una interrupción.
Ese SLA no es automáticamente el SLA de hosting. Rige un acuerdo de TI gestionada nombrado y puede ser reemplazado por un programa específico del cliente. La hoja de VPS dedicado ofrece monitoreo básico pero no publica prioridad de incidentes, tiempo de reconocimiento, objetivo de restauración, crédito de servicio ni compromiso de ingeniero 24 horas para el producto de hosting en sí.
El procedimiento de quejas proporciona escalamiento para fallos, servicio, acuerdos y facturación. Promete reconocimiento inmediato cuando un representante responde por teléfono y reconocimiento dentro de dos días hábiles para correos electrónicos o mensajes grabados, seguido de escalamiento a gerente si es necesario. Esta es una ruta útil de derechos del cliente. No es un canal de reparación de emergencia y no debe confundirse con uno.
Cuando un host falla a las 2 a.m. del sábado, los hechos decisivos son prácticos: ¿el monitoreo página a un ingeniero; puede ese ingeniero acceder al hipervisor y al almacenamiento; hay manos remotas en la instalación; hay hardware compatible en el sitio; quién puede autorizar una conmutación por error; y cómo se actualiza al cliente? Una mesa de ayuda de lunes a viernes puede coexistir con recuperación automatizada e ingeniería de guardia, pero los documentos públicos de hosting no definen ese acuerdo.
El trabajo de soporte es capacidad. Un ingeniero puede manejar un reinicio rutinario. Un evento de instalación o ruta puede producir muchas llamadas simultáneas, requerir escalamiento de proveedores y consumir las mismas personas que se comunican con los clientes. La superficie nacional de oficinas de Slnet es una señal positiva. El tamaño del equipo, la profundidad de la guardia y los procedimientos de aumento siguen sin revelarse.
La facturación y los contratos de proveedores pueden detener un servidor saludable
No todas las interrupciones comienzan con hardware roto. Los Términos Generales de Screwloose le permiten restringir, suspender o terminar el servicio cuando se debe dinero. También permiten la terminación si un tercero requerido deja de suministrar servicio. Estas cláusulas crean dos rutas de falla no técnicas: la cuenta del cliente y la cadena de proveedores del proveedor.
Una suspensión por facturación puede hacer que un VPS saludable sea inalcanzable. Una factura disputada, una tarjeta vencida o un error administrativo pueden llegar al mismo síntoma orientado al cliente que una falla del enrutador. Los términos proporcionan una ruta de disputa de facturación y requieren que se paguen los montos no disputados. No indican si la exportación de datos de emergencia permanece disponible durante una disputa o suspensión.
La ruta del proveedor es igualmente importante. Slnet puede poseer enrutadores y servidores mientras alquila espacio en rack, energía, fibra, tránsito o manos remotas. Un contrato de instalación, una factura de operador o un retiro comercial pueden forzar una migración sin que falle ningún equipo. El uso propio de Screwloose de infraestructura de terceros es explícito en sus términos. Los materiales públicos no nombran la instalación cloud ni los proveedores, por lo que los clientes no pueden evaluar la concentración, la duración del contrato o las opciones de reemplazo solo desde el sitio web.
La historia de Host One muestra por qué la continuidad comercial importa. Las operaciones y el espacio de direcciones de Australia Occidental aparecen dentro de la huella actual de AS131316, pero las páginas públicas ofrecen diferentes fechas para la integración. Eso no señala un problema presente. Ilustra cómo las combinaciones de negocios pueden mover personas, direcciones y servicios de clientes a través de límites organizativos mientras el nombre de la red permanece estable.
La protección relevante es un contrato que separe el acceso a los datos de una disputa de cuenta, defina el aviso antes de un retiro planificado, indique cuánto tiempo se retienen los datos después de la terminación y requiera asistencia razonable para la migración. Un cliente también debe mantener actualizados los datos de contacto, métodos de pago y contactos de escalamiento fuera del entorno alojado. Si la única bóveda de contraseñas, sistema de correo electrónico o portal de soporte está alojado en el servicio afectado, la recuperación administrativa se vuelve más difícil.
La economía del cloud a menudo hace que estas dependencias sean invisibles durante la operación normal. El cliente paga una cantidad mensual, mientras que el proveedor paga a varios proveedores y asigna personal finito. La continuidad depende de que cada eslabón permanezca disponible o sea reemplazable dentro de la tolerancia del cliente.
La portabilidad se detiene en la dirección a menos que el contrato diga lo contrario
El manual de migración al cloud de Screwloose de 2026 recomienda inventario, perfilado de rendimiento, objetivos de recuperación, copias inmutables, grupos piloto, migraciones por fases, sincronización delta y una ruta de retroceso probada. También dice que las cargas de trabajo y las copias de seguridad deben permanecer en regiones australianas cuando la localidad importa. Este es un consejo de migración sólido.
Las hojas de inclusiones de hosting hacen de la migración una actividad paga o de alcance separado. La migración de hosting compartido puede atraer cargos de servicios profesionales. La hoja dedicada dice que la gestión de aplicaciones pertenece al cliente o desarrollador. Eso significa que un traslado de Slnet a otro proveedor puede requerir tanto cooperación de infraestructura como trabajo de aplicación.
Las direcciones IP son especialmente claras. La cláusula 12 de los Términos Generales dice que una dirección se emite solo por el plazo del servicio, el derecho del cliente a usarla termina al finalizar, y Screwloose controla el enrutamiento asociado y la delegación de DNS. Por lo tanto, un cliente normal no puede asumir que una dirección estática de AS131316 seguirá a su VPS a otro lugar.
Las consecuencias se extienden más allá de DNS. Los socios pueden tener en la lista blanca la dirección antigua. La reputación del correo electrónico puede adjuntarse a ella. Los registros de seguridad, certificados, reglas de firewall, sistemas de pago y API remotas pueden depender de ella. Los clientes de hosting compartido enfrentan un límite de reputación adicional porque la hoja de servicio dice que comparten la dirección pública y la reputación del correo con otras cuentas.
Una prueba de salida práctica debería reconstruir una carga de trabajo representativa en un proveedor independiente usando una nueva dirección. Debería restaurar datos actuales, rotar credenciales, actualizar DNS, reemplazar listas de permitidos, validar el correo saliente, verificar el monitoreo y medir el tiempo transcurrido. El cliente debe saber qué artefactos se pueden exportar: volcados de base de datos, archivos web, imágenes de disco virtual, configuración de CWP, zonas DNS, registros, certificados y archivos de copia de seguridad.
El registro público no dice si una imagen de VPS de Slnet es exportable, si existen instantáneas o qué tan rápido se puede recuperar un disco completo. Sí dice que el cliente es dueño de las copias de seguridad y la gestión de aplicaciones. Hasta que el pedido diga más, la portabilidad debe ser diseñada por el cliente en lugar de asumida de la palabra cloud.
El alcance australiano es visible; la localidad de la carga de trabajo no lo es
Cada señal de identidad fuerte apunta a Australia. APNIC le da a AS131316 un código de país australiano. PeeringDB dice que su alcance geográfico es Australia. El ABN está activo, la empresa tiene nombres comerciales australianos y las oficinas públicas abarcan Australia Occidental, Victoria, Queensland y Nueva Gales del Sur. El borde de enrutamiento se declara en Melbourne y Perth. El texto actual de migración y hosting de Screwloose discute repetidamente negocios australianos y residencia de datos en Australia.
Eso respalda un alcance operativo australiano. No prueba dónde reside cada carga de trabajo, copia de seguridad, registro o sistema de soporte. Un código de país de registro describe el titular del recurso, no el servidor. Una ciudad de intercambio describe interconexión, no almacenamiento. Una oficina describe presencia comercial, no un rack. Incluso un VPS principal australiano puede tener una copia de seguridad en el extranjero, servicio de monitoreo, retransmisión de correo electrónico o herramienta de soporte.
La distinción importa bajo reglas de privacidad y adquisición. La guía APP 8 de la Oficina del Comisionado de Información Australiano explica que una entidad australiana puede seguir siendo responsable cuando divulga información personal a un destinatario en el extranjero. También distingue la divulgación de algunos usos de contratistas estrechamente controlados y señala los términos del contrato, el acceso, la recuperación, la eliminación y los subcontratistas como hechos relevantes. Simplemente comprar a una empresa australiana no responde a esas preguntas.
La propia comparación de hosting cloud de Screwloose aconseja a los clientes confirmar que las copias de seguridad, registros y herramientas de soporte permanezcan locales, no solo el servidor principal. Esa es exactamente la divulgación que falta en la hoja de VPS dedicado. La página explica la prueba de diligencia correcta pero no publica un cronograma de ubicación para el producto de Slnet.
Un cliente regulado o sensible a la localidad debe preguntar por el país y estado de la instalación principal, la ubicación de la copia secundaria, los países de acceso de soporte, los subprocesadores, las ubicaciones de monitoreo y registro, y qué cambios durante la conmutación por error. También debe preguntar si Melbourne y Perth son ubicaciones de cómputo pedibles o solo ubicaciones de red. Si el servicio conmuta por error a otra plataforma, la ubicación y el controlador contractual pueden cambiar en el momento en que la localidad más importa.
Un proveedor puede vender más allá de Australia sin operar un cloud distribuido globalmente. La evidencia pública respalda una red australiana y un negocio de servicios australiano. No respalda un patrimonio de cómputo multinacional.
La economía recompensa la utilización, mientras que la resiliencia consume capacidad inactiva
A A$15 al mes, el hosting compartido funciona mediante agrupación. Muchos sitios pequeños comparten un servidor, dirección, reputación de correo, pila de software y estructura de soporte. A A$200 y más, el producto VPS compra más aislamiento y una asignación de recursos más grande, pero aún se asienta sobre infraestructura física compartida a menos que el pedido diga lo contrario. Ningún precio puede entenderse sin utilización.
Los proveedores recuperan el costo de servidores, almacenamiento, espacio en rack, energía, tránsito, direcciones, software y mano de obra vendiendo porciones del patrimonio instalado. La capacidad inactiva es cara. Un host de repuesto gana poco hasta que algo falla. Una segunda ciudad requiere equipo, licencias, conectividad y mantenimiento incluso cuando los clientes no la usan activamente. La retención de copias de seguridad consume almacenamiento; las restauraciones de prueba consumen personal y cómputo temporal. La resiliencia genuina tiene por lo tanto un costo que puede no encajar dentro del plan más barato.
El patrimonio de direcciones y la presencia de intercambio de Slnet le dan economías útiles. Puede enrutar sus propios bloques, emparejar localmente en dos mercados y distribuir la ingeniería de red a través del hosting, Internet y otros servicios gestionados. La integración de Host One también puede distribuir el soporte a través de zonas horarias dentro de Australia. Estas son ventajas plausibles basadas en activos visibles.
Las limitaciones son igualmente fundamentadas. El hosting compartido admite efectos de vecino ruidoso. La hoja dedicada deja sus recursos base inconsistentes. El perfil de tráfico en PeeringDB es solo de 100-1000 Mbps y se actualizó por última vez en 2024, muy por debajo de la suma de las velocidades de puerto declaradas; debido a que los niveles de tráfico son bandas autoinformadas y las velocidades de puerto son máximos, ninguna cifra prueba la carga actual. El registro público no da capacidad vendida, reservada o libre.
Para un cliente, la comparación correcta no es simplemente A$15 versus A$200. Es el costo de cumplir un objetivo de disponibilidad. Un pequeño sitio de folleto con copias de seguridad externas y sin dependencia de ingresos puede aceptar racionalmente el hosting compartido. Una aplicación empresarial puede necesitar un sistema operativo gestionado, copia de seguridad independiente, entorno secundario, respuesta fuera de horario y recuperación probada. Esas adiciones pueden exceder el precio base de cómputo, pero compran las capas que convierten un VPS en un plan de continuidad.
El servicio más barato no es necesariamente malo, y el más caro no es automáticamente resiliente. La clave es si el precio incluye los fallos que el cliente no puede absorber.
Lo que los clientes deben pedir a Slnet que demuestre
La primera solicitud debe ser un programa de servicio corregido. Debe resolver la discrepancia de 2 vCPU versus 6 núcleos, indicar la memoria RAM reservada y la capacidad SSD, definir el ancho de banda dedicado, identificar los límites de virtualización y almacenamiento, y listar cada opción de soporte pago necesaria para parches, respuesta a incidentes y restauración.
La segunda debe ser un cronograma de ubicaciones. Debe distinguir oficinas, puntos de red y sitios de cómputo. Para cada ubicación cloud activa, debe nombrar el operador de la instalación, estado o país, si Slnet posee o alquila el hardware, y si hay una segunda ubicación disponible para cargas de trabajo del cliente. Si los nombres de las instalaciones no pueden hacerse públicos, aún pueden divulgarse bajo un acuerdo de cliente.
La tercera debe ser una declaración de dominio de falla. ¿Qué componentes están duplicados? ¿Los hosts están divididos entre racks? ¿La replicación de almacenamiento cruza racks o instalaciones? ¿Las rutas de red salen por operadores separados y entradas de edificio? ¿Se utilizan alimentaciones de energía A y B? ¿Qué fallo desencadena el reinicio automático, y cuál requiere una persona?
La cuarta debe documentar la capacidad operativa. Un comprador no necesita inventario sensible del cliente, pero puede preguntar por la política actual de margen, objetivos de host de repuesto, umbrales de espacio libre de almacenamiento, política de utilización de puertos, stock de reemplazo de hardware y las condiciones bajo las cuales se retrasan los nuevos pedidos. El equipo instalado, el equipo alimentado, el equipo operativo y la capacidad inmediatamente utilizable deben separarse.
La quinta debe ser un resultado de recuperación. Preguntar por la fecha y el alcance de la evacuación de host más reciente, restauración de almacenamiento y ejercicio a nivel de sitio. Solicitar el tiempo de recuperación medido y la pérdida de datos, cualquier paso manual, y si la prueba usó una copia fuera de la cuenta principal y el dominio de falla.
La sexta debe cubrir la red. Preguntar qué upstreams llevan el prefijo del cliente, si Melbourne y Perth son físicamente independientes, cómo se mantienen los controles de origen de ruta y fuga de ruta, si IPv6 nativo está disponible, y cómo cambia una dirección durante la recuperación. Los puertos de intercambio deben tratarse como evidencia de apoyo, no como la respuesta completa.
La séptima debe definir la cobertura humana. ¿Qué número está atendido fuera de horario para una interrupción de hosting? ¿Quién tiene acceso a la instalación? ¿Qué objetivos de reconocimiento y restauración se aplican? ¿Cuándo son las ventanas de mantenimiento, qué aviso se da y qué créditos de servicio se aplican?
La octava debe cubrir la salida. ¿Puede el cliente exportar una imagen completa, base de datos, zona DNS, registros y copias de seguridad? ¿Cuánto tiempo se retienen los datos después de la cancelación o suspensión? ¿Puede continuar la exportación durante una disputa de facturación? ¿Qué direcciones, licencias y configuraciones del panel de control no se pueden mover?
La novena debe resolver la localidad. ¿Dónde se almacenan los datos de producción, las copias de seguridad, los registros y las herramientas de soporte? ¿Quién puede acceder a ellos desde fuera de Australia? ¿Qué subcontratistas están involucrados? ¿La conmutación por error cambia la jurisdicción?
La décima debe ser una prueba realizada por el cliente. Construir una carga de trabajo pequeña, medir rutas y latencia, forzar un reinicio de aplicación, restaurar desde una copia independiente y reconstruir en otro lugar. Una demostración de ventas exitosa muestra que un servicio puede iniciarse. Un ejercicio de recuperación muestra si puede regresar.
Un borde australiano vivo rodea un cloud descrito de manera incompleta
Slnet Hosting no debe ser descartado como un nombre sin sustancia operativa. AS131316 está activo y tiene larga vida. Siete anuncios IPv4 eran casi universalmente visibles en la fecha de publicación. Los siete orígenes verificados eran válidos en RPKI. Los registros de PeeringDB muestran conexiones de intercambio operativas en Melbourne y Perth, y EdgeIX corrobora independientemente la presencia de 1 Gbps en Melbourne. El negocio actual tiene un ABN activo, oficinas nacionales, publicaciones actuales de 2026 y ofertas explícitas de hosting compartido y dedicado.
La incertidumbre comienza donde comienza la resiliencia del cliente. PeeringDB no nombra ninguna instalación para la red. Los documentos de hosting no nombran ningún sitio cloud. La hoja dedicada promete cómputo, almacenamiento y red redundantes pero no proporciona topología ni prueba. Su propio resumen de recursos entra en conflicto con su especificación mínima.
El material público no divulga el recuento de racks, el recuento de hosts, el almacenamiento bruto o utilizable, la energía, la utilización actual, las piezas de repuesto, la capacidad vendida, la retención de copias de seguridad, los resultados de restauración ni una segunda ubicación de cómputo pedible.
Eso produce una evaluación dividida. La operación de red merece una calificación de evidencia Media, acercándose a Fuerte en visibilidad de rutas e identidad, pero limitada por la falta de detalles de instalación y ruta física. La resiliencia de la capacidad alojada merece una calificación Débil porque los hechos decisivos físicos y de recuperación no están disponibles. Ninguna calificación predice una interrupción. Miden lo que un cliente puede verificar antes de una.
La distinción más importante es entre alcance y recuperación. Slnet ha demostrado alcance: sus prefijos son visibles y sus puertos de intercambio abarcan dos áreas metropolitanas australianas. La recuperación requiere un cuerpo diferente de prueba: cómputo de repuesto compatible, copias de almacenamiento independientes, separación de energía y ruta, personas con acceso, un reloj definido y una ruta de salida para el cliente. Hasta que esos detalles se adjunten al VPS de A$200, la promesa alojada sigue dependiendo de una infraestructura que el público solo puede ver en su borde de red.