Slnet Hosting annonce des ports 10G à Melbourne et Perth, mais sa fiche VPS à 200 $ ne nomme pas le site de reprise

Résumé

• AS131316 présentait sept annonces IPv4 visibles couvrant 2 048 adresses le 15 juillet 2026. PeeringDB listait des connexions d'échange opérationnelles de 10 Gbps à Melbourne et Perth et une connexion EdgeIX de 1 Gbps à Melbourne, tandis que RIPE RIS voyait le réseau via 325 de ses 326 pairs IPv4.
• La fiche actuelle de cloud dédié commence à 200 AUD plus GST et promet un VPS basé sur CWP avec une redondance du calcul, du stockage et du réseau. Elle n'identifie pas l'infrastructure cloud, un deuxième site de calcul, le nombre de racks, la disposition du stockage, la conception de l'alimentation, le pool d'hôtes de secours, l'objectif de reprise ni le résultat testé de basculement.
• Le même document produit de quatre pages donne deux descriptions de ressources différentes: au moins 2 vCPU, 8 Go de RAM et 50 Go de SSD au début, puis un VPS 6 cœurs, 16 Go de RAM et 150 Go de SSD dans son résumé final. Un client a besoin du devis et du calendrier de service pour déterminer ce qui est réellement réservé.
• L'opération réseau actuelle est bien soutenue, mais la résilience de la capacité hébergée ne l'est pas. L'évaluation équitable est Moyen pour le réseau visible et Faible pour les preuves publiques de redondance physique du cloud, de capacité de réserve utilisable et de restauration client.

Le chiffre le plus clair se trouve en bordure de réseau, pas à l'intérieur du cloud

Slnet Hosting possède une empreinte réseau publique plus substantielle que son nom compact ne le suggère. À 08h00 UTC le 15 juillet 2026, lavue de l'état de routage pour AS131316de RIPEstat comptait sept préfixes IPv4, 2 048 adresses annoncées, cinq voisins observés et une visibilité de 325 des 326 pairs RIS IPv4. La première route observée datait de juillet 2011. Il ne s'agit pas d'un enregistrement dormant conservé sur une étagère. C'est un système autonome de longue date dont les routes étaient presque universellement visibles par les collecteurs dans cet instantané.

L'enregistrement d'interconnexion est également spécifique. Leprofil PeeringDBmaintenu par l'opérateur liste un port 10 Gbps à IX Australia Melbourne, un second port 10 Gbps à IX Australia Perth et un port 1 Gbps à EdgeIX Melbourne. Les trois entrées sont marquées opérationnelles et incluent toutes des adresses d'échange IPv4 et IPv6. Laliste des entitésd'EdgeIX montre indépendamment Screw Loose Software, AS131316, sur une connexion 1 Gbps. Ces enregistrements établissent un bord de réseau australien est-ouest crédible.

Ils n'établissent pas la capacité du cloud vendu à un client. Un port d'échange est un endroit où un réseau peut échanger du trafic. Ce n'est pas un compte des hyperviseurs, une garantie de réplication de stockage, une réservation d'alimentation ou une preuve que la charge de travail d'un client peut redémarrer dans l'autre ville. Additionner 10, 10 et 1 pour obtenir un titre de 21 Gbps serait arithmétiquement facile et opérationnellement trompeur.

Les ports se trouvent dans différents échanges, peuvent servir un trafic différent et peuvent être contraints par le transit, la politique de routage, les liens internes, les ports serveur ou la charge de travail elle-même.

Le numéro d'hébergement orienté client provient d'un document différent. Lafiche de service d'hébergement cloud dédiéde Screwloose IT de décembre 2025 annonce un conteneur VPS à partir de 200 AUD plus GST par mois. Elle indique que la plateforme inclut une redondance sous-jacente entre le calcul, le stockage et le réseau. Pourtant, elle ne nomme pas le centre de données, le nombre de salles ou racks indépendants, l'emplacement de la copie de sauvegarde, le temps de récupération, le point de récupération, ni le test de basculement le plus récent.

Cet écart définit l'histoire. Slnet peut prouver une bordure routée en direct. Il peut prouver qu'un produit d'hébergement actuel existe. Le dossier public ne relie pas ces deux couches en une conception de reprise vérifiable.

Slnet est le nom du réseau au sein d'une entreprise australienne de services plus large

Les noms autour d'AS131316 doivent être démêlés avant de juger de la propriété. Leenregistrement de système autonomed'APNIC appelle le réseauSLNET-AU, le décrit comme Slnet Hosting et identifie le déclarant comme Screw Loose Software. L'enregistrement est actif depuis le 7 juin 2011 et a été modifié pour la dernière fois en septembre 2024. PeeringDB utilise Screw Loose Software comme nom d'organisation et ScrewlooseIT comme nom alternatif.

Le site web commercial actuel utilise Screwloose IT. Ses documents clients affichent ABN 59 160 395 479. Leregistre ABNdu gouvernement australien identifie ce numéro comme Australian Client Services Pty. Ltd., une société privée active, et liste Screwloose IT et Hostone parmi ses noms commerciaux enregistrés. En d'autres termes, Slnet Hosting est mieux compris comme l'identité publique de routage et d'hébergement associée à une entreprise australienne plus large de services IT gérés, de télécommunications et de cloud. Il ne doit pas être traité comme une société juridique séparément vérifiée simplement parce que l'ASN a un label distinct.

L'historique de première partie donne un contexte utile. Lapage entreprisede Screwloose IT indique qu'elle a investi dans une présence en centre de données en 2009 et a commencé à offrir l'hébergement Exchange, l'hébergement de sites web et d'applications web, des serveurs cloud et des bureaux cloud. Elle indique que l'entreprise est entrée dans les télécommunications en 2013 et a ensuite acquis une empreinte en Australie occidentale via Host One. Uneannonce distincte de Host Oneindique que l'acquisition a pris effet le 1er janvier 2022 et a ajouté une équipe à Perth et trois heures de support supplémentaires chaque jour grâce à la coopération entre Perth et Melbourne.

Ces deux pages ne présentent pas une chronologie parfaitement alignée: un historique date l'expansion en Australie occidentale de 2018, tandis que l'annonce de l'acquisition donne 2022. La divergence n'efface pas le réseau visible ni l'ABN actuel. Cela signifie que la date exacte et la structure juridique de l'intégration de Host One devraient provenir des documents et contrats d'entreprise, et non d'une chronologie marketing.

Lapage de contactliste désormais des bureaux à Osborne Park, Mulgrave, Milton et Bondi. Ce sont des signaux précieux de support et de zone de service. Ce ne sont pas des adresses de centres de données. Un bureau peut héberger des ingénieurs et du personnel de comptabilité tandis que les serveurs clients se trouvent dans une installation tierce ailleurs. Aucun des bureaux listés ne doit être considéré comme un site cloud sans une déclaration d'installation séparée.

Cette limite de propriété compte lors d'une panne. Australian Client Services peut contrôler la relation client, la configuration de la plateforme, ses propres serveurs, la politique de routage d'AS131316 et l'escalade. Un opérateur de colocation contrôle l'accès au bâtiment, la distribution d'énergie et les mains à distance. Les opérateurs de transit et d'échange contrôlent d'autres parties du chemin. Le client contrôle la conception de l'application, les copies indépendantes et la capacité de déménager. Le nom sur la facture ne peut supprimer ces autres dépendances.

Deux produits d'hébergement exposent deux modèles de capacité très différents

La documentation produit actuelle décrit à la fois l'hébergement partagé et un conteneur cloud dédié. Lafiche de service d'hébergement de site webtarifie l'hébergement web partagé à 15 AUD plus GST par mois. Elle fournit un compte CWP, une adresse publique partagée et une pile Apache ou Nginx, PHP et MariaDB ou MySQL courante. Le CPU, la mémoire et les entrées-sorties disque sont partagés entre les clients. Le document prévient expressément que l'utilisation intensive d'un client peut affecter les autres, que certains paramètres ne peuvent pas être modifiés au niveau du compte et que la réputation email est partagée.

C'est un arrangement d'hébergement mutualisé simple. Le fournisseur maintient la disponibilité du serveur partagé, les services communs, la sécurité de base et la santé du serveur. Le client ou le développeur maintient le site, le code, les plugins, les thèmes, l'utilisation de la base de données et les comptes administratifs. Les correctifs OS, les réparations CWP, les travaux de performance, la suppression de logiciels malveillants, la réparation du site et la plupart des restaurations sont en dehors du plan à 15 AUD. La migration et la restauration sans défaut serveur peuvent être achetées comme services professionnels.

Le produit dédié déplace la limite mais ne l'élimine pas. La fiche d'hébergement cloud dédié décrit un conteneur VPS avec une adresse statique dédiée, une allocation de bande passante dédiée et une isolation au niveau root. Il promet au moins 2 vCPU, 8 Go de RAM et 50 Go de stockage SSD, dimensionnés via un devis formel. Il liste également un pare-feu d'application web, des règles ModSecurity, des protections FirewallD ou CSF, la détection d'attaques, la journalisation, la surveillance et les redémarrages automatiques de service si nécessaire.

Le fournisseur accepte la responsabilité de maintenir le VPS disponible, de faire fonctionner le CPU, la RAM et le stockage alloués, de maintenir son infrastructure cloud et de maintenir actifs les contrôles de sécurité de base. Mais les frais n'incluent pas les correctifs du système d'exploitation, les mises à jour CWP, les mises à niveau de la pile serveur, le réglage des performances, le durcissement plus fort, le dépannage du site ou la réponse aux incidents pour une violation au niveau serveur.

La restauration d'un site compromis est hors de portée, et la restauration à partir d'une sauvegarde est incluse uniquement lorsque le besoin découle d'une panne serveur.

Ce n'est pas une critique d'un contrat inhabituel. L'hébergement est souvent divisé en couches d'installation, de plateforme, de système et d'application. Le point important est que la page de vente actuelle appelle l'offre de Screwloose un service cloud professionnel et indique que des spécialistes locaux fournissent un support continu, tandis que les fiches d'inclusions formelles tracent une ligne plus étroite autour des frais d'hébergement de base. Un acheteur doit décider s'il veut un conteneur isolé, un système d'exploitation géré, une application gérée, ou les trois.

La facture peut ressembler à un service cloud unique tandis que la reprise traverse plusieurs responsabilités tarifées séparément.

Les descriptions 2 cœurs et 6 cœurs ne peuvent pas toutes deux définir un même minimum standard

La fiche dédiée contient un problème de spécification concret. La section 2 indique que chaque environnement dédié inclura au moins 2 cœurs vCPU, 8 Go de RAM et 50 Go de stockage SSD. La section 6, sur la dernière page, résume le plan comme un VPS dédié 6 cœurs, 16 Go de RAM et 150 Go de SSD. Le document n'explique pas si la configuration plus grande est un exemple, un plan révisé, un résidu spécifique au client ou le produit standard réel.

C'est important car la comptabilité des capacités commence avec l'unité vendue. Si le conteneur de base réserve deux cœurs virtuels et 8 Go, sa densité hôte et son économie de prix diffèrent d'un service à six cœurs et 16 Go. Un disque de 50 Go crée un fardeau de sauvegarde, d'instantané et de migration différent de 150 Go. La phrase "à partir de" laisse déjà de la place aux devis; le résumé contradictoire rend le devis essentiel plutôt que supplémentaire.

Un client ne devrait pas résoudre la divergence en sa faveur. Il devrait demander un calendrier de service signé qui indique si le CPU est partagé, plafonné, burstable ou épinglé; si "cœur" signifie vCPU ou cœur physique; si la mémoire est réservée; si le stockage est local ou distribué; si 50 Go ou 150 Go sont inclus; et si l'adresse statique provient d'AS131316. Il devrait également demander ce que signifie "allocation de bande passante dédiée" en mégabits par seconde, s'il s'agit d'une vitesse de port ou d'un débit garanti, et quels contrôles de congestion ou d'utilisation équitable s'appliquent.

La divergence limite également toute estimation de la capacité installée. Les données de routage public fournissent 2 048 adresses, mais une adresse n'égale pas un VPS et de nombreuses adresses peuvent desservir des routeurs, des hôtes partagés, des réseaux clients ou des attributions dormantes. Les fiches produit fournissent des ressources par compte, mais pas de nombre d'hôtes. PeeringDB fournit des vitesses de port, mais pas de capacité de fabric côté serveur.

La déclaration de capacité défendable est donc étroite. Slnet dispose d'un parc d'adresses routées réel et d'une connectivité d'échange déclarée. Screwloose vend au moins un niveau d'hébergement partagé et un niveau VPS sur devis. Le nombre total de serveurs, de cœurs virtuels, de téraoctets, de racks et de commandes disponibles reste non divulgué.

Sept routes IPv4 valides montrent une opération actuelle, pas une capacité de calcul de réserve

Le parc de routes est inhabituellement ordonné. Laréponse des préfixes annoncésde RIPEstat a montré ces sept routes continuellement visibles sur la fenêtre observée du 1er au 15 juillet: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/24et103.172.76.0/23. Ensemble, elles contiennent 2 048 adresses IPv4.

Les enregistrements d'APNIC révèlent l'historique derrière l'ensemble. Les enregistrements103.4.122.0/24et103.4.123.0/24portent le nom SLNET.103.50.13.0/24est enregistré auprès de Hostone Pty Ltd.103.114.34.0/24nomme Screw Loose Software. L'allocation103.172.76.0/23nomme Australian Client Services Pty Ltd. Un autre /24 visible est tiré d'un bloc enregistré auprès de Bottle Communications. Ces étiquettes sont cohérentes avec un réseau assemblé à travers des noms d'exploitation et des titres de propriété d'adresses acquis ou liés, mais elles ne prouvent pas par elles-mêmes le contrat actuel régissant chaque bloc.

Les sept vérifications d'origine sont revenues valides dans RIPEstat lorsqu'elles ont été testées contre AS131316. Par exemple, lavalidation 103.172.76.0/23a trouvé une autorisation d'origine de route correspondante avec une longueur maximale de /23. Un RPKI valide est précieux: il permet aux réseaux entités de rejeter une origine non autorisée pour la route couverte. Il ne maintient pas le routeur autorisé sous tension, n'empêche pas une mauvaise politique, n'ajoute pas de bande passante et ne restaure pas un serveur défaillant.

Le bord public n'avait également pas d'espace IPv6 originaire dans l'instantané RIPE. C'est notable car chaque entrée d'échange PeeringDB inclut une interface IPv6. Une adresse IPv6 sur un LAN d'échange montre que le routeur peut y participer; ce n'est pas la même chose qu'originer des préfixes IPv6 clients. Un acheteur qui a besoin d'IPv6 natif devrait demander une allocation spécifique au service et la tester, plutôt que d'inférer la disponibilité à partir des lignes d'échange.

Les sept routes sont une preuve solide que l'opérateur reste actif. Elles ne peuvent pas dire à un acheteur combien d'adresses sont libres, combien d'inventaire serveur est disponible derrière elles, si les pools d'adresses de Perth et Melbourne correspondent à un calcul séparé, ou si l'adresse d'un client peut se déplacer lors d'une panne de site.

Trois lignes d'échange ne sont pas une carte routière physique

PeeringDB étiquette les connexions d'échange 10 Gbps de Melbourne et Perth comme opérationnelles, et l'entrée plus récente d'EdgeIX Melbourne a été mise à jour en mars 2026. Lavue des entités WA-IXde Packet Clearing House liste également AS131316 à27.106.192.207, fournissant une corroboration indépendante de l'identité d'échange de Perth. Le réseau est clairement représenté dans les deux villes.

Ce qui est absent est tout aussi important. L'API PeeringDB ne renvoie aucun enregistrement d'installation pour AS131316. Cela ne prouve pas que le réseau ne possède pas de racks ou ne loue pas de colocation. PeeringDB est auto-maintenu et incomplet. Cela signifie seulement que le profil public n'identifie pas les bâtiments dans lesquels se trouvent les routeurs ou les systèmes d'hébergement de Slnet. Les noms d'échange identifient les tissus métropolitains, pas les suites exactes, les alimentations électriques ou les chemins de câbles.

Une connexion d'échange peut être livrée de plusieurs façons. Un routeur peut se trouver dans l'une des installations listées de l'échange. Un opérateur peut étendre le LAN d'échange via le transport vers un autre bâtiment. Un revendeur peut fournir une connexion virtuelle. Un seul port physique peut transporter plusieurs services logiques. Sans enregistrement d'installation ou déclaration d'opérateur, une ligne d'échange doit être traitée comme une présence métropolitaine logique avec une vitesse de port déclarée, pas une route tracée à travers un bâtiment nommé.

La même prudence s'applique à la géolocalisation des adresses. IPinfo place les adresses AS131316 réactives à Melbourne et Perth et a observé un chemin court récent vers103.172.76.1depuis une sonde de Perth. C'est un signal de marché utile. Les bases de données de géolocalisation peuvent être basées sur le registre, la latence, le routage et les soumissions d'opérateur, et peuvent être erronées au niveau du bâtiment ou même de la ville. Un résultat de sonde montre un point d'extrémité réseau répondant avec une faible latence depuis un emplacement; il ne montre pas le rack qui contient les disques clients.

Les bureaux de Screwloose ne peuvent pas combler le vide. Un bureau de support à Osborne Park n'est pas automatiquement le site du routeur WA-IX. Un bureau à Mulgrave n'est pas automatiquement le cloud de Melbourne. La déclaration de 2009 concernant une présence en centre de données établit que l'entreprise est entrée dans l'infrastructure hébergée, mais elle ne nomme pas d'installation actuelle. L'acquisition de Host One soutient une empreinte commerciale et réseau en Australie occidentale, mais elle ne précise pas que les conteneurs VPS se répliquent entre Perth et Melbourne.

La carte qui peut être dessinée de manière responsable comporte deux nœuds réseau au niveau de la ville, Melbourne et Perth, plus quatre bureaux commerciaux. Elle ne peut pas inclure une installation cloud exacte, une route de données client ou une ligne de basculement interurbain. Ceux-ci restent des questions d'approvisionnement.

La redondance doit être attachée à un domaine de défaillance

"Redondance de l'infrastructure sous-jacente" semble complet car il nomme le calcul, le stockage et le réseau. Pour rendre la phrase opérationnelle, chaque couche a besoin d'un composant indépendant et d'une défaillance définie qu'elle est censée survivre.

La redondance de calcul peut signifier un hôte physique de secours, un cluster qui peut redémarrer un conteneur, une migration en direct, ou simplement plusieurs alimentations dans un seul châssis. Ces conceptions ont des résultats différents. Un hôte de secours peut absorber une panne uniquement s'il a assez de CPU, mémoire, accès au stockage et configuration réseau compatibles. La migration en direct aide lors de la maintenance planifiée mais peut ne pas aider après une panne soudaine d'hôte ou de stockage. Deux hôtes dans le même rack partagent toujours l'alimentation et la commutation du rack.

La redondance de stockage peut signifier des disques en miroir, RAID, des volumes répliqués, des instantanés ou des sauvegardes. La mise en miroir peut survivre à une panne de disque mais reproduit immédiatement la corruption. Un instantané peut protéger contre un changement erroné tout en restant sur le même tableau. La réplication peut améliorer la disponibilité tout en conservant la même dépendance vis-à-vis de l'opérateur et du compte. Une sauvegarde devient utile seulement lorsqu'elle peut être restaurée avec les applications, les paramètres, les identifiants et la configuration réseau nécessaires à la reprise du service.

La redondance réseau peut signifier des liens doubles, deux commutateurs, deux routeurs, des fournisseurs d'accès séparés ou des entrées de bâtiment physiquement diverses. Les trois ports d'échange de PeeringDB créent des options utiles, et lavue des voisinsde RIPEstat a observé Kinetix Networks, Simtronic, Hurricane Electric et deux voisins de moindre confiance. Mais l'adjacence BGP observée ne révèle pas les contrats, la part de trafic, les chemins de fibre ou si le basculement a été testé. Deux fournisseurs d'accès logiques peuvent partager une queue de transporteur ou un domaine d'alimentation.

La redondance d'alimentation n'est pas décrite du tout dans la fiche d'hébergement. Le matériel public ne précise pas le nombre d'alimentations secteur, la topologie UPS, l'autonomie du générateur, la densité de puissance des racks ou si l'équipement de Slnet utilise des alimentations A et B. Ce sont normalement des faits au niveau de l'installation et peuvent être disponibles sous confidentialité, mais ils ne peuvent pas être déduits d'une connexion d'échange.

La question client pertinente n'est pas "Est-ce redondant?" Mais "Quelles pannes uniques ce service peut-il survivre sans action du client, et que se passe-t-il après deux pannes liées?" Une réponse utile nomme les hôtes primaire et secondaire, la copie de stockage, le rack et l'installation, le déclencheur du redémarrage, l'intervalle de perte de données attendu, le temps de restauration prévu et le dernier exercice réussi. Aucun document public de Slnet ne fournit cette chaîne.

Le premier chemin de panne commence à l'intérieur du VPS

Une application hébergée par Slnet peut échouer alors qu'AS131316 reste parfaitement visible. Le système d'exploitation invité peut planter. Un système de fichiers plein peut arrêter une base de données. Un composant CWP non corrigé peut être compromis. Un plugin de site peut épuiser la mémoire. Un certificat peut expirer. Dans ces cas, les routeurs, l'alimentation de l'installation et l'hôte physique peuvent tous être sains.

La fiche de service dédié trace cette limite nettement. Le fournisseur surveille la joignabilité de base et maintient les outils de pare-feu de base actifs, mais les correctifs du système d'exploitation, les mises à jour CWP, les mises à niveau de la pile web, le réglage proactif et un durcissement plus fort ne sont pas inclus. La récupération après compromission au niveau du site est également en dehors des frais de base. Un client qui pensait que l'"hébergement cloud professionnel" incluait l'administration système gérée pourrait découvrir la différence lors de l'incident.

Le deuxième chemin de panne est l'hôte. Un processeur, module mémoire, carte mère, carte réseau, disque, contrôleur ou alimentation peut tomber en panne. Le dossier public ne divulgue pas combien d'hôtes existent, si les disques clients sont locaux, si un cluster peut redémarrer un conteneur ailleurs, combien de mémoire réservée est gardée libre, ou si des pièces de rechange sont sur site. Le redémarrage automatique de service est utile pour un processus planté; ce n'est pas une preuve qu'un châssis défaillant peut être remplacé dans un délai.

Le troisième chemin est le stockage partagé ou le pool de serveurs. Un VPS dédié peut avoir des ressources invité réservées tout en partageant les tableaux de stockage, les commutateurs et les systèmes de contrôle avec d'autres conteneurs. Un compte d'hébergement partagé va plus loin: la fiche produit indique explicitement que les clients partagent le CPU, la mémoire et les entrées-sorties disque, et un utilisateur lourd peut affecter les autres. La pression sur la capacité peut donc apparaître comme des pages lentes, des requêtes de base de données retardées ou des échecs de courrier avant d'apparaître comme une panne complète.

Le quatrième chemin est le rack et l'installation. Un disjoncteur, une unité de distribution d'alimentation, un événement de refroidissement, une restriction d'accès ou une erreur de maintenance peut affecter plusieurs hôtes à la fois. La redondance à l'intérieur d'un châssis ne sert à rien si les deux alimentations utilisent la même source. Un hôte de secours dans le même rack peut être indisponible lors d'une panne de rack. Sans un second domaine de défaillance nommé, la revendication publique de redondance doit être traitée comme locale à une architecture non divulguée.

Aucun de ces risques ne prouve une mauvaise opération. Ils définissent les preuves dont un acheteur sérieux a besoin. Les documents actuels de Slnet établissent les responsabilités et les caractéristiques du produit. Ils ne publient pas l'historique des pannes, les métriques de statut ou les résultats de restauration chronométrés qui montreraient comment les couches se comportent sous stress.

Les sauvegardes sont promises dans le marketing et assignées au client dans les conditions

Lapage des services cloudde Screwloose indique que le cloud est toujours sauvegardé et place la redondance au cœur de la solution. Le matériel de migration plus large recommande des copies immuables, des objectifs de temps de récupération et de point de récupération convenus, des restaurations de test de routine et des plans de restauration. Ce sont des pratiques sensées.

Les documents juridiques et produits sont plus conditionnels. LesConditions généralesstipulent que le client est seul responsable de la sauvegarde et de la sécurisation des données connectées ou fournies avec le service. La fiche dédiée exclut la restauration d'un site web à partir de la sauvegarde sauf si le besoin découle d'une panne serveur. La fiche partagée limite également les restaurations incluses et rend les autres restaurations facturables.

Ces déclarations peuvent coexister si le service maintient des copies d'infrastructure tandis que le client reste responsable de la reprise d'activité. Mais les documents publics ne définissent pas la distinction. Ils ne précisent pas la fréquence de sauvegarde, la rétention, le chiffrement, l'immuabilité, l'emplacement, le support, la séparation des comptes, la bande passante de restauration ou le calendrier de suppression. Ils ne disent pas si "toujours sauvegardé" s'applique à chaque VPS, seulement aux engagements gérés, ou seulement à certaines classes de données.

Leguide d'évaluation Essential Eightdu Centre australien de cybersécurité distingue le fait d'avoir des copies de la preuve de restauration. Il demande si les données, applications et paramètres peuvent être restaurés à un point commun dans le temps et si la récupération complète ou partielle a été exercée. Cette distinction est directement pertinente ici. Une copie disque sans la configuration CWP correcte, l'état de la base de données, le DNS, les clés et les règles de pare-feu peut ne pas recréer un service fonctionnel.

Un client de Slnet devrait demander deux réponses. Premièrement, quelle copie le fournisseur maintient-il pour se remettre de sa propre panne d'hôte ou de stockage? Deuxièmement, quelle copie le client peut-il récupérer indépendamment si le fournisseur, le compte ou l'installation est indisponible? La deuxième copie devrait inclure les données et suffisamment de configuration pour reconstruire sur une autre plateforme. Elle devrait être testée en dehors du compte d'hébergement principal.

Sans ces réponses, l'interprétation la plus sûre est conservatrice: la redondance du fournisseur peut améliorer la disponibilité normale, mais le client reste propriétaire de la continuité. C'est également la position la plus cohérente avec les conditions générales publiées.

La diversité de routage n'aide que lorsque le serveur est joignable depuis le bord

Les relations réseau observées d'AS131316 réduisent la probabilité qu'une seule adjacence logique soit l'ensemble du bord public. RIPEstat a vu deux voisins de gauche de haute puissance, AS134143 et AS55707, plus Hurricane Electric et deux relations incertaines. PeeringDB montre la participation au serveur de routage sur les trois échanges. Les autorisations d'origine de route publiques couvrent les sept préfixes visibles. C'est une posture de routage plus forte qu'un petit hôte avec un bloc d'adresses attribué par un fournisseur et pas d'AS indépendant.

Pourtant, chaque contrôle réseau répond à une question limitée. RPKI aide les autres réseaux à distinguer une origine autorisée. Il n'empêche pas Slnet de retirer une route ou d'annoncer un mauvais chemin. Un serveur de routage d'échange aide à établir de nombreux peerings efficacement, mais ce n'est pas un substitut au transit payé vers l'ensemble d'Internet. Un port 10 Gbps peut transporter le trafic d'échange local pendant que le trafic client vers une autre destination utilise un chemin de transit plus petit ou congestionné.

Un bord Perth et un bord Melbourne peuvent encore dépendre d'un seul plan de contrôle interne ou d'un seul contrat fournisseur.

LesConditions généralesreconnaissent directement la limite du fournisseur. Elles permettent à Screwloose d'utiliser et de faire varier un mélange de sa propre infrastructure et de celle de tiers, disent que le service peut dépendre de l'équipement et des arrangements tiers, et permettent la résiliation si un tiers cesse de fournir un service nécessaire. Elles déclinent également toute responsabilité, dans la mesure permise par la loi, pour les défaillances de l'infrastructure réseau tierce.

Pour un client hébergé, la résilience de routage doit être testée de la charge de travail vers l'extérieur. Le VPS est-il doublement connecté à des routeurs de bord séparés? Ces routeurs sont-ils dans le même bâtiment? Le préfixe client apparaît-il à travers les deux relations de transit? Une route peut-elle se déplacer entre les villes sans déplacer le serveur? La mitigation DDoS introduit-elle une autre dépendance? Existe-t-il une console hors bande lorsque la route publique échoue?

IPv6 mérite son propre test. Les interfaces d'échange de PeeringDB sont double pile, mais RIPEstat n'a vu aucun préfixe IPv6 originaire le 15 juillet. Un client ne devrait pas supposer que son VPS a un IPv6 routé globalement simplement parce que le routeur de bord a une adresse d'échange. La commande devrait indiquer le préfixe assigné, l'origine et la limite de support.

Le dossier réseau public de Slnet est assez bon pour poser des questions précises. Il n'est pas assez détaillé pour y répondre au nom de l'opérateur.

La réparation dépend des personnes, du périmètre et de l'horloge

Screwloose présente le support local comme un différenciateur. La page cloud indique que des spécialistes gèrent la migration et le support continu et que les heures du helpdesk sont du lundi au vendredi, de 9h à 17h. L'annonce de l'acquisition de Host One indique que les équipes de Perth et Melbourne étendent la couverture de support quotidienne de trois heures. La page de contact actuelle liste la même fenêtre de bureau en semaine dans quatre villes.

LeSLA des services IT géréspublié ajoute des détails pour les clients qui achètent ce service. Le support régulier à distance et par email fonctionne de 9h à 17h heure de l'Australie occidentale. Les appels après heures sont transférés vers un mobile si possible et traités au mieux, avec un service de réponse externe comme backup. Les incidents urgents ont un objectif de réponse de zéro à quatre heures ouvrables, tandis que les priorités moyennes et basses peuvent prendre plus de temps. Le premier dimanche de chaque mois est réservé à la maintenance du système avec préavis si une panne est attendue.

Ce SLA n'est pas automatiquement le SLA d'hébergement. Il régit un accord de services IT gérés nommé et peut être remplacé par un calendrier spécifique au client. La fiche VPS dédiée offre une surveillance de base mais ne publie aucune priorité d'incident, temps d'accusé de réception, objectif de restauration, crédit de service ou engagement d'ingénieur 24 heures pour le produit d'hébergement lui-même.

Laprocédure de traitement des plaintesfournit une escalade pour les défauts, le service, les accords et la facturation. Elle promet un accusé de réception immédiat lorsqu'un représentant répond par téléphone et un accusé de réception dans les deux jours ouvrables pour les emails ou messages enregistrés, suivi d'une escalade au responsable si nécessaire. C'est un chemin utile de droits des clients. Ce n'est pas un canal de réparation d'urgence et ne doit pas être confondu avec un tel canal.

Lorsqu'un hôte tombe en panne à 2h du matin un samedi, les faits décisifs sont pratiques: la surveillance alerte-t-elle un ingénieur; cet ingénieur peut-il accéder à l'hyperviseur et au stockage; des mains à distance sont-elles disponibles dans l'installation; du matériel compatible est-il sur site; qui peut autoriser un basculement; et comment le client est-il informé? Un helpdesk du lundi au vendredi peut coexister avec une récupération automatisée et une ingénierie d'astreinte, mais les documents d'hébergement publics ne définissent pas cet arrangement.

La main-d'œuvre de support est une capacité. Un ingénieur peut gérer un redémarrage de routine. Un événement d'installation ou de routage peut produire de nombreux appels simultanés, nécessiter une escalade fournisseur et consommer les mêmes personnes qui communiquent avec les clients. La surface de bureau national de Slnet est un signal positif. La taille de l'équipe, la profondeur d'astreinte et les procédures d'urgence restent non divulguées.

La facturation et les contrats fournisseurs peuvent arrêter un serveur sain

Ce n'est pas chaque panne qui commence par du matériel cassé. Les Conditions générales de Screwloose lui permettent de restreindre, suspendre ou résilier le service lorsque de l'argent est dû. Elles permettent également la résiliation si un tiers requis cesse de fournir le service. Ces clauses créent deux chemins de panne non techniques: le compte client et la chaîne d'approvisionnement du fournisseur.

Une suspension de facturation peut rendre un VPS sain inaccessible. Une facture contestée, une carte expirée ou une erreur administrative peuvent arriver au même symptôme visible par le client qu'une panne de routeur. Les conditions prévoient une voie de contestation de facturation et exigent que les montants non contestés soient payés. Elles ne précisent pas si l'exportation d'urgence des données reste disponible pendant un litige ou une suspension.

Le chemin fournisseur est tout aussi important. Slnet peut posséder des routeurs et des serveurs tout en louant de l'espace rack, de l'alimentation, de la fibre, du transit ou des mains à distance. Un contrat d'installation, une facture de transporteur ou un retrait commercial peuvent forcer une migration sans qu'aucun équipement ne tombe en panne. L'utilisation par Screwloose de l'infrastructure tierce est explicite dans ses conditions.

Les matériels publics ne nomment pas l'installation cloud ou les fournisseurs, donc les clients ne peuvent pas évaluer la concentration, la durée du contrat ou les options de remplacement à partir du site web seul.

L'historique de Host One montre pourquoi la continuité commerciale est importante. Les opérations et l'espace d'adressage de l'Australie occidentale apparaissent dans l'empreinte actuelle d'AS131316, mais les pages publiques offrent des dates différentes pour l'intégration. Cela ne signale pas un problème présent. Cela illustre comment les combinaisons d'entreprises peuvent déplacer des personnes, des adresses et des services clients à travers les frontières organisationnelles tandis que le nom du réseau reste stable.

La protection pertinente est un contrat qui sépare l'accès aux données d'un litige de compte, définit un préavis avant un retrait planifié, indique combien de temps les données sont conservées après la résiliation et exige une assistance raisonnable pour la migration. Un client devrait également conserver les coordonnées actuelles, les méthodes de paiement et les contacts d'escalade en dehors de l'environnement hébergé. Si le seul coffre de mots de passe, système de messagerie ou portail de support est hébergé sur le service affecté, la récupération administrative devient plus difficile.

L'économie du cloud rend souvent ces dépendances invisibles pendant le fonctionnement normal. Le client paie un montant mensuel unique, tandis que le fournisseur paie plusieurs fournisseurs et alloue un personnel limité. La continuité dépend de chaque lien restant disponible ou remplaçable dans la tolérance du client.

La portabilité s'arrête à l'adresse sauf si le contrat dit le contraire

Leplaybook de migration cloud2026 de Screwloose recommande l'inventaire, le profilage des performances, les objectifs de reprise, les copies immuables, les groupes pilotes, les bascules progressives, la synchronisation delta et un chemin de retour testé. Il indique également que les charges de travail et les sauvegardes devraient rester dans les régions australiennes lorsque la localité est importante. C'est un conseil de migration judicieux.

Les fiches d'inclusions d'hébergement font de la migration une activité payante ou séparément cadrée. La migration d'hébergement partagé peut attirer des frais de services professionnels. La fiche dédiée indique que la gestion de l'application appartient au client ou au développeur. Cela signifie qu'un passage de Slnet à un autre fournisseur peut nécessiter à la fois la coopération de l'infrastructure et le travail de l'application.

Les adresses IP sont particulièrement claires. La clause 12 des Conditions générales indique qu'une adresse n'est délivrée que pour la durée du service, le droit du client de l'utiliser prend fin à la résiliation, et Screwloose contrôle le routage associé et la délégation DNS. Un client normal ne peut donc pas supposer qu'une adresse statique AS131316 suivra son VPS ailleurs.

Les conséquences s'étendent au-delà du DNS. Les partenaires peuvent mettre sur liste blanche l'ancienne adresse. La réputation email peut s'y attacher. Les journaux de sécurité, les certificats, les règles de pare-feu, les systèmes de paiement et les API distantes peuvent en dépendre. Les clients d'hébergement partagé font face à une limite de réputation supplémentaire car la fiche de service indique qu'ils partagent l'adresse publique et la réputation email avec d'autres comptes.

Un test de sortie pratique devrait reconstruire une charge de travail représentative sur un fournisseur indépendant en utilisant une nouvelle adresse. Il devrait restaurer les données actuelles, faire pivoter les identifiants, mettre à jour le DNS, remplacer les listes blanches, valider le courrier sortant, vérifier la surveillance et mesurer le temps écoulé. Le client devrait savoir quels artefacts peuvent être exportés: dumps de base de données, fichiers web, images de disque virtuel, configuration CWP, zones DNS, journaux, certificats et archives de sauvegarde.

Le dossier public ne dit pas si une image VPS Slnet est exportable, si des instantanés existent, ou à quelle vitesse un disque complet peut être récupéré. Il dit que le client possède les sauvegardes et la gestion de l'application. Jusqu'à ce que la commande en dise plus, la portabilité devrait être conçue par le client plutôt que supposée à partir du mot cloud.

Le périmètre australien est visible; la localité de la charge de travail ne l'est pas

Chaque signal d'identité fort pointe vers l'Australie. APNIC attribue à AS131316 un code pays australien. PeeringDB indique que son périmètre géographique est l'Australie. L'ABN est actif, l'entreprise a des noms commerciaux australiens et les bureaux publics couvrent l'Australie occidentale, Victoria, Queensland et Nouvelle-Galles du Sud. La bordure de routage est déclarée à Melbourne et Perth. Le matériel de migration et d'hébergement actuel de Screwloose discute à plusieurs reprises des entreprises australiennes et de la résidence des données australiennes.

Cela soutient un périmètre d'exploitation australien. Cela ne prouve pas où réside chaque charge de travail, sauvegarde, journal ou système de support. Un code pays de registre décrit le détenteur de la ressource, pas le serveur. Une ville d'échange décrit l'interconnexion, pas le stockage. Un bureau décrit la présence commerciale, pas un rack. Même un VPS primaire australien peut avoir une sauvegarde à l'étranger, un service de surveillance, un relais email ou un outil de support.

La distinction compte selon les règles de confidentialité et d'approvisionnement. Leguide APP 8du Bureau du Commissaire à l'information australien explique qu'une entité australienne peut rester responsable lorsqu'elle divulgue des informations personnelles à un destinataire outre-mer. Il distingue également la divulgation de certaines utilisations étroitement contrôlées par des entrepreneurs et pointe vers les termes du contrat, l'accès, la récupération, la suppression et les sous-traitants comme faits pertinents. Simplement acheter auprès d'une entreprise australienne ne répond pas à ces questions.

La proprecomparaison d'hébergement cloudde Screwloose conseille aux clients de confirmer que les sauvegardes, les journaux et les outils de support restent locaux, pas seulement le serveur principal. C'est exactement la divulgation qui manque dans la fiche VPS dédiée. La page explique le bon test de diligence mais ne publie pas de calendrier de localisation pour le produit de Slnet.

Un client réglementé ou sensible à la localité devrait demander le pays et l'état de l'installation primaire, l'emplacement de la copie secondaire, les pays d'accès au support, les sous-traitants, les emplacements de surveillance et de journalisation, et ce qui change lors du basculement. Il devrait également demander si Melbourne et Perth sont tous deux des emplacements de calcul commandables ou seulement des emplacements réseau. Si le service bascule vers une autre plateforme, l'emplacement et le contrôleur contractuel peuvent changer au moment où la localité compte le plus.

Un fournisseur peut vendre au-delà de l'Australie sans exploiter un cloud distribué globalement. Les preuves publiques soutiennent un réseau australien et une entreprise de services australienne. Elles ne soutiennent pas un parc de calcul multi-pays.

L'économie récompense l'utilisation, tandis que la résilience consomme de la capacité inutilisée

À 15 AUD par mois, l'hébergement partagé fonctionne par mutualisation. De nombreux petits sites partagent un serveur, une adresse, une réputation email, une pile logicielle et une structure de support. À 200 AUD et plus, le produit VPS achète plus d'isolation et une allocation de ressources plus grande, mais il reste sur une infrastructure physique partagée sauf indication contraire de la commande. Aucun prix ne peut être compris sans utilisation.

Les fournisseurs récupèrent le coût des serveurs, du stockage, de l'espace rack, de l'alimentation, du transit, des adresses, des logiciels et de la main-d'œuvre en vendant des tranches du parc installé. La capacité inutilisée est coûteuse. Un hôte de secours rapporte peu jusqu'à ce que quelque chose tombe en panne. Une deuxième ville nécessite de l'équipement, des licences, de la connectivité et de la maintenance même lorsque les clients ne l'utilisent pas activement. La rétention des sauvegardes consomme du stockage; les restaurations de test consomment du personnel et du calcul temporaire.

Une résilience authentique a donc un coût qui peut ne pas tenir dans le plan le moins cher.

Le parc d'adresses et la présence d'échange de Slnet lui donnent des économies utiles. Il peut router ses propres blocs, faire du peering localement sur deux marchés et répartir l'ingénierie réseau entre l'hébergement, Internet et d'autres services gérés. L'intégration de Host One peut également répartir le support sur les fuseaux horaires en Australie. Ce sont des avantages plausibles ancrés dans des actifs visibles.

Les contraintes sont tout aussi ancrées. L'hébergement partagé admet des effets de voisin bruyant. La fiche dédiée laisse ses ressources de base incohérentes. Le profil de trafic dans PeeringDB n'est que de 100-1000 Mbps et a été mis à jour pour la dernière fois en 2024, bien en dessous de la somme des vitesses de port déclarées; parce que les niveaux de trafic sont des bandes auto-déclarées et les vitesses de port sont des maxima, aucun chiffre ne prouve la charge actuelle. Le dossier public ne donne aucune capacité vendue, réservée ou libre.

Pour un client, la bonne comparaison n'est pas simplement 15 AUD contre 200 AUD. C'est le coût pour atteindre un objectif de disponibilité. Un petit site vitrine avec sauvegardes externes et sans dépendance de revenus peut rationnellement accepter l'hébergement partagé. Une application métier peut nécessiter un OS géré, une sauvegarde indépendante, un environnement secondaire, une réponse après heures et une reprise testée. Ces ajouts peuvent dépasser le prix de base du calcul, mais ils achètent les couches qui transforment un VPS en plan de continuité.

Le service le moins cher n'est pas nécessairement mauvais, et le plus cher n'est pas automatiquement résilient. La clé est de savoir si le prix inclut les pannes que le client ne peut pas absorber.

Ce que les clients devraient demander à Slnet de démontrer

La première demande devrait être un calendrier de service corrigé. Il devrait régler le désaccord entre 2 vCPU et 6 cœurs, indiquer la mémoire réservée et la capacité SSD, définir la bande passante dédiée, identifier les limites de virtualisation et de stockage, et lister chaque option de support payant nécessaire pour les correctifs, la réponse aux incidents et la restauration.

La deuxième devrait être un calendrier de localisation. Il devrait distinguer les bureaux, les points réseau et les sites de calcul. Pour chaque emplacement cloud actif, il devrait nommer l'opérateur d'installation, l'état ou le pays, si Slnet possède ou loue le matériel, et si un deuxième emplacement est disponible pour les charges de travail des clients. Si les noms d'installation ne peuvent pas être rendus publics, ils peuvent toujours être divulgués dans le cadre d'un contrat client.

La troisième devrait être une déclaration de domaine de défaillance. Quels composants sont dupliqués? Les hôtes sont-ils répartis sur des racks? La réplication de stockage traverse-t-elle les racks ou les installations? Les chemins réseau sortent-ils par des transporteurs et des entrées de bâtiment séparés? Des alimentations A et B sont-elles utilisées? Quelle panne déclenche un redémarrage automatique, et laquelle nécessite une personne?

La quatrième devrait documenter la capacité opérationnelle. Un acheteur n'a pas besoin d'inventaire sensible au client, mais il peut demander la politique de marge actuelle, les objectifs d'hôtes de secours, les seuils d'espace libre de stockage, la politique d'utilisation des ports, le stock de remplacement matériel et les conditions dans lesquelles les nouvelles commandes sont retardées. L'équipement installé, l'équipement sous tension, l'équipement opérationnel et la capacité immédiatement utilisable devraient être séparés.

La cinquième devrait être un résultat de récupération. Demandez la date et le périmètre de la plus récente évacuation d'hôte, restauration de stockage et exercice au niveau du site. Demandez le temps de récupération mesuré et la perte de données, les étapes manuelles éventuelles, et si le test a utilisé une copie en dehors du compte primaire et du domaine de défaillance.

La sixième devrait couvrir le réseau. Demandez quel fournisseur amont transporte le préfixe client, si Melbourne et Perth sont physiquement indépendants, comment les contrôles d'origine de route et de fuite de route sont maintenus, si l'IPv6 natif est disponible, et comment une adresse change lors de la récupération. Les ports d'échange doivent être traités comme des preuves à l'appui, pas la réponse complète.

La septième devrait définir la couverture humaine. Quel numéro est doté en personnel après les heures pour une panne d'hébergement? Qui a accès à l'installation? Quels objectifs d'accusé de réception et de restauration s'appliquent? Quand sont les fenêtres de maintenance, quel préavis est donné, et quels crédits de service s'appliquent?

La huitième devrait couvrir la sortie. Le client peut-il exporter une image complète, une base de données, une zone DNS, des journaux et des sauvegardes? Combien de temps les données sont-elles conservées après annulation ou suspension? L'exportation peut-elle continuer pendant un litige de facturation? Quelles adresses, licences et paramètres du panneau de contrôle ne peuvent pas être déplacés?

La neuvième devrait régler la localité. Où sont stockées les données de production, les sauvegardes, les journaux et les outils de support? Qui peut y accéder depuis l'extérieur de l'Australie? Quels sous-traitants sont impliqués? Le basculement change-t-il la juridiction?

La dixième devrait être un test effectué par le client. Construisez une petite charge de travail, mesurez les routes et la latence, forcez un redémarrage d'application, restaurez à partir d'une copie indépendante et reconstruisez ailleurs. Une démonstration commerciale réussie montre qu'un service peut démarrer. Un exercice de reprise montre s'il peut revenir.

Un bord australien actif entoure un cloud incomplètement décrit

Slnet Hosting ne doit pas être écarté comme un nom sans substance opérationnelle. AS131316 est actif et de longue durée. Sept annonces IPv4 étaient presque universellement visibles à la date de publication. Les sept origines vérifiées étaient valides RPKI. Les enregistrements de peering montrent des connexions d'échange opérationnelles à Melbourne et Perth, et EdgeIX corrobore indépendamment la présence 1 Gbps à Melbourne. L'entreprise actuelle a un ABN actif, des bureaux nationaux, des publications actuelles de 2026 et des offres d'hébergement explicites partagées et dédiées.

L'incertitude commence là où commence la résilience client. PeeringDB ne nomme aucune installation pour le réseau. Les documents d'hébergement ne nomment aucun site cloud. La fiche dédiée promet un calcul, un stockage et un réseau redondants mais ne donne ni topologie ni test. Son propre résumé de ressources entre en conflit avec sa spécification minimale.

Le matériel public ne divulgue pas le nombre de racks, le nombre d'hôtes, le stockage brut ou utilisable, l'alimentation, l'utilisation actuelle, les pièces de rechange, la capacité vendue, la rétention des sauvegardes, les résultats de restauration ou un deuxième emplacement de calcul commandable.

Cela produit une évaluation partagée. L'opération réseau mérite une note Moyenne sur les preuves, s'approchant de Forte en visibilité de route et identité mais freinée par le manque de détail sur l'installation et le chemin physique. La résilience de la capacité hébergée mérite une note Faible car les faits physiques et de reprise décisifs ne sont pas disponibles. Aucune note ne prédit une panne. Elles mesurent ce qu'un client peut vérifier avant une panne.

La distinction la plus importante est entre la portée et la reprise. Slnet a démontré la portée: ses préfixes sont visibles et ses ports d'échange couvrent deux métropoles australiennes. La reprise nécessite un ensemble différent de preuves: calcul de réserve compatible, copies de stockage indépendantes, séparation de l'alimentation et du routage, personnes ayant accès, une horloge définie et un chemin de sortie client. Jusqu'à ce que ces détails soient attachés au VPS à 200 AUD, la promesse hébergée reste dépendante d'une infrastructure que le public ne peut voir qu'à son bord réseau.