Résumé
- Lien Cloud est une entreprise vietnamienne de traitement de données et d'hébergement, juridiquement identifiable, avec un ASN actif enregistré auprès d'APNIC, AS151883, et le bloc IPv4 nommé 36.50.134.0/23. Les observations publiques de routage montrent néanmoins qu'aucun préfixe n'est émis par AS151883; le /23 est accessible mondialement via AS150862, VPSTTT COMPUTER COMPANY LIMITED.
- Cet arrangement peut soutenir une activité réelle de VPS ou d'hébergement, mais il place un contrôle significatif en dehors du périmètre visible de l'entreprise cliente. Les éléments disponibles n'établissent pas qui possède les serveurs, quel centre de données les héberge, si l'alimentation et le transit sont diversifiés, ou si Lien Cloud peut déplacer les adresses des clients en cas de défaillance de l'amont ou du contrat.
- Les acheteurs devraient considérer l'enregistrement local d'adresses, un benchmark de machine virtuelle et une autorisation de route valide comme des preuves d'une empreinte d'hébergement fonctionnelle, et non comme des preuves d'une résilience multi-sites. La récupération dépend de sauvegardes détenues par le client, de configurations portables, de restaurations testées et d'une voie de sortie claire qui ne repose pas sur le même compte, rack ou fournisseur.
- Le niveau de preuve estFaible. Des signaux opérationnels existent, mais les divulgations vérifiables de manière indépendante sur les installations, la capacité, le support, la propriété et la récupération restent trop minces pour étayer des affirmations plus solides de disponibilité ou de localité.
Deux identités réseau, un écart important
Lien Cloud présente un puzzle d'infrastructure inhabituellement compact. L'entreprise existe dans les registres publics des entreprises et des ressources Internet vietnamiennes. Un enregistrement d'entreprise vietnamien donne le code fiscal 4401108463, une date de création le 13 novembre 2023, Phan Thi Lien comme représentant légal, et le traitement de données et l'hébergement comme activité principale enregistrée.La liste des membres de ressources d'adresses de VNNICenregistre Công ty TNHH Công nghệ Lien Cloud comme LIENCLOUD-VN, rejoignant le 21 décembre 2023.L'enregistrement d'APNIC pour AS151883nomme LIENCLOUD-VN, marque la ressource active et la date au 15 décembre 2023. Ce sont des faits d'identité solides.
Ils ne sont pas les mêmes que les faits opérationnels. L'observation de routage la plus claire actuelle est que le propre système autonome de Lien Cloud n'annonce pas de préfixe IPv4 ou IPv6.La vue des préfixes annoncés de RIPEstat pour AS151883a renvoyé un ensemble vide le 12 juillet 2026, tandis quebgp.toolsdécrivait également l'ASN comme alloué mais absent de la table de routage globale. L'entréeAS Rank de CAIDAne montrait aucun fournisseur, pair, client ou préfixe visible. Trois systèmes d'observation différents pointent donc vers la même conclusion étroite: l'ASN enregistré n'expose actuellement pas de réseau routé qui lui soit propre.
Le bloc d'adresses de l'entreprise raconte une histoire différente.L'enregistrement d'APNIC pour 36.50.134.0/23attribue la plage de 36.50.134.0 à 36.50.135.255 à LIENCLOUD-VN et la marque active. Cela donne au bloc 512 adresses IPv4 au total, bien que les conventions de réseau et de diffusion, les réservations d'infrastructure, les affectations clients et les contrôles d'abus signifient que le nombre vendable est inférieur.L'aperçu du préfixe de RIPEstatindique que le /23 est annoncé mondialement, mais l'origine est AS150862, nommé MAYTINHVPSTTT-VN et enregistré auprès de VPSTTT COMPUTER COMPANY LIMITED. Sonrésultat de validation RPKIest valide, avec une autorisation d'origine de route permettant à AS150862 d'annoncer exactement le /23.
Cette distinction importe plus que la soupe d'acronymes. L'enregistrement d'adresse répond, au moins administrativement, à qui appartient la ressource nommée 36.50.134.0/23. La route répond quel réseau indique actuellement au reste d'Internet comment l'atteindre. Ces rôles peuvent légitimement différer. Un petit hébergeur peut demander à un opérateur plus grand d'annoncer ses adresses, de transporter le trafic et de placer l'équipement dans une installation établie. Un tel arrangement peut être efficace et techniquement compétent.
Il peut aussi concentrer la survie du petit hébergeur sur un contrat et un ensemble de systèmes que les clients ne peuvent pas voir.
La structure observée ne prouve pas que VPSTTT possède Lien Cloud, que Lien Cloud est un revendeur, ou que l'une des deux sociétés exploite le rack physique. Elle prouve seulement la relation de routage actuelle autour du préfixe: AS150862 est l'origine visible.La vue de bgp.tools pour AS150862liste deux amonts, AS18403 FPT Telecom et AS140810 Megacore Technology, et identifie 36.50.134.0/23 parmi les préfixes qu'il annonce. C'est une preuve utile de diversité amont au niveau AS150862. Cela ne démontre pas deux entrées dans un bâtiment, deux routeurs desservant le rack de Lien Cloud, deux chemins d'alimentation indépendants, ou un droit contractuel pour Lien Cloud de basculer entre les fournisseurs.
Le résultat est une surface opérationnelle divisée. Lien Cloud est l'identité publique attachée à l'espace d'adressage et probablement la contrepartie commerciale pour au moins certaines charges de travail hébergées. AS150862 est l'opérateur de routage visible. Un opérateur d'installation non divulgué peut contrôler la salle, l'accès au rack, les alimentations et les mains à distance. Le matériel peut être possédé par Lien Cloud, loué à un fournisseur de serveurs, loué à AS150862, ou fourni par une autre partie.
Tant que ces limites ne sont pas documentées, un acheteur ne peut pas dire quelle partie peut réparer un disque défaillant, approuver un changement de route, rétablir l'alimentation d'une armoire ou libérer une image de serveur après un litige.
Ce que le registre public soutient concernant le service
La description de service la plus sûre commence par les faits et s'arrête avant que le marketing ne comble les lacunes. L'activité principale enregistrée de Lien Cloud est le traitement de données, la location et les activités connexes, selonle registre d'entreprise vietnamien reproduit par Infocom. Son /23 nommé est routé et a montré une activité visible de l'extérieur. Unpost de benchmark LowEndTalk indépendantd'octobre 2025 montrait une machine virtuelle KVM Debian 12 avec un processeur AMD EPYC 7H12, 1,9 Gio de mémoire, 24,5 Gio de disque, connectivité IPv4, pas d'IPv6 dans le test, AS150862 comme réseau et LIEN CLOUD TECHNOLOGY COMPANY LIMITED comme étiquette d'hôte. L'auteur a indiqué que le VPS avait été obtenu auprès de h2cloud.vn via Telegram.
Ce benchmark est un signal de marché, pas un registre d'actifs audité. Il suggère qu'au moins une machine virtuelle associée par géolocalisation ou données de registre à l'espace d'adresses de Lien Cloud était vivante et utilisable fin 2025. Il ne peut établir qui a vendu le service, qui possédait le nœud, où se trouvait physiquement la machine, si son stockage était répliqué, ou si la performance testée persistait après la courte exécution. Les scripts de benchmark fournis par les utilisateurs rapportent ce qu'un système d'exploitation invité et des bases de données externes peuvent observer; ils n'ouvrent pas la porte du rack.
Le signal devient plus intéressant, mais pas concluant, à côté ducatalogue public Vietnam KVM d'H2Cloud. Cette page annonce des processeurs AMD EPYC 7H12 ou Intel Xeon Gold 6133, virtualisation KVM, stockage NVMe et un port 10 Gbps. La famille de CPU et le style de service ressemblent au benchmark. Pourtant, le catalogue ne nomme pas Lien Cloud, et ses offres affichées montraient zéro unité disponible lors de la vérification. Lesconditions de service distinctes d'H2Cloudplacent la responsabilité de sauvegarde pour les VPS cloud et les serveurs sur l'utilisateur. Rien de tout cela n'établit une relation d'entreprise ou technique durable entre H2Cloud et Lien Cloud. Cela montre comment un VPS vietnamien à bas coût peut être vendu en périphérie de détail tandis que les rôles d'adresse, de route, de serveur et d'installation sous-jacents restent répartis entre plusieurs noms.
La présence d'un invité KVM ne doit pas non plus être gonflée en preuve d'un cloud au sens technique plus fort.La définition du cloud computing par le NISTinclut le libre-service à la demande, l'accès réseau large, la mise en commun des ressources, l'élasticité rapide et le service mesuré. Une machine virtuelle sur du matériel partagé ne satisfait qu'une partie de ce tableau. Les preuves publiques ne montrent pas si Lien Cloud offre un provisionnement automatisé, un pool de ressources sur plusieurs hôtes, une migration en direct, une utilisation mesurée, une interface applicative, des contrôles d'isolation des locataires ou une mise à l'échelle rapide. « Cloud » dans un nom commercial ou une étiquette de produit ne remplace pas ces capacités.
Ce qui peut être dit est plus étroit: Lien Cloud a l'activité légale, les ressources d'adresses et un signe crédible de tierce partie de calcul hébergé associé à son nom. Ce qui ne peut pas encore être dit est qu'il possède une plateforme cloud, exploite un centre de données, gère plusieurs sites, fournit un objectif de niveau de service particulier ou maintient suffisamment de capacité de rechange pour récupérer un nœud défaillant sans interruption prolongée. Cette différence entre capacité installée et capacité utilisable façonne chaque scénario de panne.
Le service physique commence là où les preuves publiques se taisent
Un VPS semble immatériel pour son utilisateur. C'est un compte, une adresse IP, un mot de passe et une image disque. Le service lui-même est obstinément physique. Les cœurs CPU sont des tranches de temps sur un ou plusieurs processeurs. La mémoire est insérée dans des emplacements de serveur. Le disque NVMe annoncé est un périphérique dans un châssis ou une allocation d'une baie de stockage. Les paquets sortent par des cartes d'interface réseau, des commutateurs de tête de rack, des routeurs de périphérie et de la fibre.
Chaque composant consomme de l'énergie conditionnée et produit de la chaleur que l'équipement de refroidissement doit évacuer.
Pour Lien Cloud, la première question non résolue est l'emplacement. Les registres d'APNIC donnent une adresse administrative au hameau de Hoa Hoi, commune de Xuan Canh, dans l'ancienne zone de la ville de Song Cau, à Phu Yen. Une adresse d'entreprise n'est pas une coordonnée de centre de données. Le test LowEndTalk étiquetait l'invité comme étant à Hô Chi Minh-Ville, mais la géolocalisation IP décrit souvent une inscription commerciale, un emplacement réseau inféré ou un point d'échange voisin plutôt que le rack. D'autres services de signalement d'adresses ont étiqueté des IP individuelles dans le même /23 comme à Hanoï.
Ces étiquettes de ville contradictoires sont un avertissement, pas un moyen de trianguler un bâtiment.
Aucune page d'installation publique examinée pour cet article ne nommait Lien Cloud comme propriétaire, locataire ou exploitant. Aucune divulgation visible n'identifiait de campus de centre de données, nombre de racks, densité de puissance, conception de refroidissement, système de suppression d'incendie, régime d'accès physique ou fournisseur de mains à distance. Aucune certification n'a pu être liée à l'équipement déployé de l'entreprise. Cela signifie que l'emplacement de l'actif physique doit rester non vérifié.
Un acheteur ayant besoin que les données restent au Vietnam dispose de quelques preuves: l'allocation est vietnamienne, le réseau d'origine est vietnamien et le VPS observé était étiqueté Vietnam. Mais un code de pays IP n'est pas un registre de garde, et une route vietnamienne ne prouve pas où se trouve chaque réplique, instantané ou copie de sauvegarde.
La qualité des installations ne peut pas non plus être empruntée à la marque d'un amont. La connexion d'AS150862 à FPT Telecom ne signifie pas que Lien Cloud se trouve dans un centre de données FPT, encore moins que son rack exact hérite d'une certification particulière. Même lorsqu'un hébergeur nomme un site certifié, le périmètre de certification importe.L'explication du système Tier par l'Uptime Institutedistingue la capacité de base des composants redondants, de la maintenabilité concurrente et de la tolérance aux pannes. Un site Tier III peut retirer chaque composant de capacité et voie de distribution pour maintenance planifiée sans interrompre les opérations, mais il reste exposé à certaines pannes d'équipement et erreurs d'opérateur. Le propre serveur à cordon unique ou commutateur de tête de rack du locataire peut toujours créer une panne plus étroite à l'intérieur d'un bâtiment capable.
C'est pourquoi une divulgation utile identifierait non seulement la marque de l'installation mais le chemin de l'entrée électrique à la machine virtuelle. Les serveurs sont-ils à double cordon vers les alimentations A et B? Les deux alimentations sont-elles actives et testées? Chaque hôte a-t-il deux interfaces réseau connectées à des commutateurs différents? Les contrôleurs de stockage sont-ils redondants? Une maintenance planifiée d'un commutateur, onduleur ou refroidissement peut-elle se produire sans arrêter le nœud? Qui reçoit l'avis d'installation, et à quelle vitesse est-il relayé aux clients?
Aucune de ces réponses n'est publique pour Lien Cloud.
L'histoire récente du Vietnam montre pourquoi les questions sont pratiques. Après le typhon Yagi en 2024, le ministère de l'Information et des Communications a signalé6 285 stations de base mobiles affectées par des coupures de courant, ainsi que des fibres interprovinciales et intraprovinciales coupées. Des milliers de stations sont revenues grâce à des générateurs, mais la restauration complète dépendait encore du réseau électrique et de l'accès aux zones inondées. Un rack de centre de données est généralement plus protégé qu'une station de base de terrain, mais la même chaîne de dépendance demeure: alimentation du réseau, carburant du générateur, refroidissement, chemins de fibre et personnel disponible. Une affirmation de résilience doit survivre à un événement régional, pas seulement à une machine virtuelle défaillante.
La capacité installée n'est pas la capacité récupérable
Les catalogues d'hébergement transforment la capacité en chiffres nets: cœurs, Go de RAM, Go de stockage NVMe et vitesse de port. Ces chiffres décrivent une commande, pas les ressources de rechange disponibles en cas de panne. Si un hôte physique exécute vingt VPS clients à utilisation ordinaire, ses pairs survivants ont besoin de suffisamment de mémoire, de marge CPU et de performance de stockage pour absorber ces invités après sa défaillance. Un fournisseur peut vendre chaque cœur nominal sur un nœud et fournir des performances acceptables la plupart des jours.
Le test est de savoir s'il a réservé de la capacité lorsqu'un nœud, un périphérique de stockage ou un domaine d'alimentation disparaît.
Le registre public n'offre aucun nombre de nœuds pour Lien Cloud, aucune utilisation d'hôte, aucun ratio de surréservation, aucun inventaire de serveurs de rechange. Le /23 fournit une limite supérieure sur les points de terminaison IPv4 directement adressés, pas une limite inférieure sur les machines. Un seul serveur physique peut héberger de nombreuses adresses; un client peut en détenir plusieurs; la traduction d'adresses réseau peut prendre en charge de nombreux invités derrière moins d'adresses publiques; des adresses inutilisées peuvent rester inactives.
L'allocation de 512 adresses ne dit donc rien de fiable sur la capacité CPU, mémoire ou stockage.
Le benchmark indépendant fournit un indice de capacité installée: un invité a vu un processeur EPYC 7H12 et KVM. Il ne révèle pas si un deuxième nœud compatible existait. La migration en direct nécessite plus que des étiquettes de CPU correspondantes. La source et la destination ont besoin de paramètres de virtualisation compatibles, de connectivité réseau, de mémoire suffisante, et soit de stockage partagé soit d'un mécanisme pour transférer les disques. Si le seul nœud avec les bons indicateurs CPU est plein, une fonction de migration peut exister dans le logiciel mais rester inutilisable en urgence.
Le stockage crée une ambiguïté similaire. « NVMe » décrit une interface et une classe de périphérique, pas une architecture de durabilité. Un disque NVMe local peut être très rapide et rester un domaine de défaillance unique. La mise en miroir peut survivre à la perte d'un disque mais pas nécessairement à une corruption du contrôleur, une suppression accidentelle ou un incendie de rack. Le stockage distribué ne peut tolérer une perte de nœud que si les répliques occupent des nœuds et domaines de défaillance véritablement indépendants, le quorum reste disponible et la capacité réseau est suffisante pour reconstruire.
Les preuves publiques ne montrent pas quel modèle, le cas échéant, Lien Cloud utilise.
Le stock de matériel importe car le temps de réparation commence après le diagnostic. Les serveurs d'entreprise ne sont pas magiquement restaurés par l'étiquette sur le CPU. Une carte mère défaillante peut nécessiter un remplacement compatible, un micrologiciel à jour et des mains au rack. Un périphérique NVMe mort doit être identifié, remplacé et reconstruit. Si le fournisseur ne détient pas de pièce de rechange à froid, il attend un fournisseur ou déplace les charges de travail ailleurs. S'il loue le matériel, il ouvre un ticket auprès du propriétaire. Chaque couche ajoute une file d'attente et un transfert.
La divulgation de capacité la plus révélatrice pour un petit hébergeur serait donc modeste et testable: nombre de nœuds de production; nombre et emplacement des domaines de défaillance; marge minimale RAM et stockage de rechange; si les disques sont locaux ou répliqués; temps de reconstruction d'hôte prévu; emplacement des pièces de rechange; et date du dernier exercice de perte de nœud. Aucune divulgation de ce type n'a été trouvée. En son absence, les clients devraient supposer qu'un incident matériel peut durer plus longtemps que le temps de redémarrage affiché dans un panneau de contrôle.
La diversité de transit existe en amont, mais le contrôle est ce qui compte
La route pour 36.50.134.0/23 est valide et visible. C'est une constatation positive. Les annonces d'origine de route invalides peuvent être filtrées par les réseaux effectuant une validation d'origine RPKI; le bloc de Lien Cloud, tel qu'émis par AS150862, n'a pas ce défaut dans l'observation vérifiée. Le bloc est également apparu de manière cohérente dans l'ensemble annoncé d'AS150862. Lapage du projet Spoofer de CAIDA pour AS150862montre le segment de test 36.50.134.x/24 bloquant les sources usurpées privées et routables dans un test de juin 2026. Cette seule mesure ne certifie pas chaque interface, mais c'est un signal opérationnel favorable.
Les deux amonts listés d'AS150862 sont également meilleurs qu'un seul fournisseur visible. FPT Telecom et Megacore peuvent offrir des routes alternatives au niveau du système autonome. La topologie laisse néanmoins quatre questions sans réponse. Premièrement, les deux sessions amont sont-elles actives pour 36.50.134.0/23, ou l'une est-elle un chemin nominal ou de secours? Deuxièmement, leurs fibres entrent-elles dans l'installation concernée par des conduits physiquement séparés? Troisièmement, le rack de Lien Cloud se connecte-t-il de manière redondante à la périphérie d'AS150862?
Quatrièmement, Lien Cloud a-t-il l'autorité et l'accès pour demander des changements de route pendant un incident?
L'autorisation valide accorde à AS150862 les droits d'origine pour le /23. Elle ne donne pas à Lien Cloud une indépendance instantanée vis-à-vis d'AS150862. Déplacer le préfixe vers AS151883 ou un autre fournisseur nécessiterait une autorisation de route nouvelle ou modifiée, une politique de routage, une acceptation amont, des sessions configurées et une coordination opérationnelle. Les filtres de préfixe et la sécurité de routage sont délibérément conservateurs.Le RFC 7454 sur les opérations et la sécurité BGPrecommande des contrôles sur les préfixes acceptés et annoncés, des limites de préfixe maximum, des chemins AS et des sessions de routage. Un amont réputé ne devrait pas accepter une origine inconnue simplement parce que quelqu'un le demande pendant une panne.
L'AS151883 dormant pourrait être un futur outil d'indépendance, mais seulement si Lien Cloud dispose de routeurs, d'accords de transit, d'objets de politique, d'autorisations de route, de surveillance et de personnel prêts à l'utiliser. L'enregistrement seul n'est pas une veille chaude. L'absence de préfixes, de fournisseurs et de pairs visibles suggère que l'ASN doit être traité comme un potentiel administratif plutôt qu'une capacité de récupération.
Les preuves qui changeraient cette vue incluent une annonce dual-stack en direct, des amonts documentés, une politique de routage publiée, des canaux de contact actuels et une diversité de route observée dans le temps.
L'absence d'IPv6 est une autre contrainte. Ni le benchmark Lien Cloud ni les vues de routage public pour AS151883 ne montrent de service IPv6. Le profil public d'AS150862 ne montrait pas non plus d'IPv6 émis dans le résumé bgp.tools vérifié. Les clients dont les services nécessitent de l'IPv6 natif semblent donc dépendre d'un autre tunnel, d'une couche de traduction ou d'un fournisseur, à moins que Lien Cloud ne puisse documenter une capacité non visible publiquement. Un service IPv4-only n'est pas en soi une panne, mais il réduit les choix de migration et fait des adresses IPv4 rares une partie du problème de sortie.
La portée internationale ajoute une dépendance nationale. Le ministère vietnamien a signalé en 2024 que le pays disposait de cinq systèmes de câbles sous-marins internationaux avec 34 Tbps de capacité disponible plus deux routes terrestres vers Hong Kong et Singapour totalisant 5 Tbps, tout en fixant un plan pourau moins dix nouvelles routes sous-marines d'ici 2030. Le plan d'expansion existe parce que la concentration des routes et des câbles affecte les performances. Un hébergeur peut rester joignable à l'intérieur du Vietnam tandis que les clients à l'étranger subissent congestion ou perte après une panne de câble international. Lien Cloud ne publie aucune politique d'ingénierie du trafic ni engagement de capacité internationale, donc les performances outre-mer ne doivent pas être déduites d'une étiquette de port virtuel 10 Gbps.
Six façons dont un petit service d'hébergement peut échouer
Panne de rack ou d'installation.Un déclencheur de disjoncteur, un problème de refroidissement, une alarme incendie, une erreur de maintenance ou un commutateur de tête de rack défaillant peut supprimer chaque VM dans une armoire. Si tout l'équipement Lien Cloud se trouve dans cette armoire, un bâtiment de haute qualité ne crée pas de diversité de service. La récupération nécessite un autre domaine de défaillance alimenté et connecté avec des copies actuelles des données clients. Le registre public n'en établit pas.
Panne amont ou de route.AS150862 pourrait perdre une session, filtrer le préfixe, subir une panne de routeur ou entrer dans un litige commercial. Ses deux amonts visibles réduisent certains risques réseau, mais seulement si les deux transportent le préfixe et que le chemin des serveurs de Lien Cloud vers les deux périphéries est redondant. Parce qu'AS151883 n'est pas visiblement actif, les clients ne devraient pas supposer que Lien Cloud peut immédiatement annoncer les adresses ailleurs. Un changement de route peut également prendre du temps à se propager et peut être rejeté si l'autorisation ou les filtres sont obsolètes.
Panne matérielle et de stock.Un crash d'hyperviseur peut redémarrer rapidement les invités si un stockage partagé et une capacité de calcul de rechange existent. Une panne de carte mère, de fond de panier ou de stockage local peut prendre beaucoup plus de temps. Les petits fournisseurs tirent souvent leur avantage de prix en utilisant un ensemble limité de serveurs. C'est commercialement rationnel jusqu'à ce que la récupération nécessite une pièce de rechange qui n'a jamais été achetée. La seule famille de CPU observée dans le benchmark ne peut pas répondre à la question du stock.
Panne de support.Les incidents d'hébergement traversent les frontières organisationnelles. Le client signale une VM morte à Lien Cloud; Lien Cloud peut contacter un propriétaire de matériel, un opérateur réseau ou une installation; les mains à distance peuvent avoir besoin d'approbation et d'une instruction précise. Une affirmation de contact 24h/24 n'a de sens que si quelqu'un peut agir, pas seulement accuser réception. Aucune matrice d'escalade publique, déclaration d'heures de personnel, objectif de réponse ou historique d'incident n'a été trouvé pour Lien Cloud. L'enregistrement APNIC fournit un contact technique individuel et une voie d'abus via VNNIC, mais les données de contact du registre ne sont pas un service d'assistance client.
Panne de facturation ou de contrôle de compte.Un serveur fonctionnel peut devenir inaccessible après une suspension automatisée, une discordance de paiement, un renouvellement expiré ou un compromis du panneau de contrôle. Ce mode de panne est facile à négliger car le rack et la route restent sains. Les clients ont besoin de clarté sur les délais de grâce, les voies d'appel, la révision manuelle, la propriété du domaine et de la console, et si les sauvegardes restent récupérables après suspension. Aucune condition publique spécifique à l'entreprise n'a été trouvée pour répondre à ces questions. Un prix mensuel bas peut coexister avec un coût commercial élevé si un événement de facturation bloque le seul compte administratif.
Panne de migration ou de contrat fournisseur.L'incident le plus difficile n'est pas un composant cassé mais la disparition du pont commercial reliant le client à l'infrastructure. Si Lien Cloud perd l'accès à un nœud ou le droit d'utiliser un bloc d'adresses, peut-il exporter des images disque, conserver les adresses IP ou déplacer les charges de travail vers une autre installation? La portabilité IP est particulièrement contrainte. Un enregistrement semblant indépendant du fournisseur ne garantit pas qu'un client final puisse conserver une adresse assignée, et l'arrangement d'origine actuel dépend toujours d'AS150862. La migration basée sur DNS est généralement plus portable que les listes blanches basées sur IP, mais seulement lorsque le client contrôle le DNS et dispose d'une destination testée.
Ces pannes peuvent cascader. Une panne d'installation crée un afflux de support. Le personnel se concentre sur la restauration des nœuds tandis que l'automatisation de facturation continue de suspendre les comptes en retard. Un serveur de remplacement arrive mais manque de stockage local suffisant. Une route est annoncée depuis un nouvel emplacement mais rejetée parce que l'autorisation nomme toujours l'ancienne origine. Les sauvegardes client existent mais partagent le même compte fournisseur. La résilience est la capacité de briser cette chaîne à plusieurs endroits, pas la présence d'une seule icône de sauvegarde.
Les fenêtres de maintenance font partie du produit
Chaque service hébergé nécessite éventuellement un travail planifié: mises à jour de micrologiciel, remplacement de disque, maintenance de commutateur, tests de générateur, travaux sur batteries et mises à niveau logicielles. Un fournisseur transparent transforme ces opérations en fenêtres de maintenance bornées. Il identifie les composants affectés, donne un préavis, explique si un redémarrage est attendu, confirme l'achèvement et publie des informations de suivi lorsque le résultat diffère du plan.
Pour Lien Cloud, aucune page de statut public ou archive de maintenance n'a été trouvée. Cette absence ne prouve pas de mauvaises opérations; les très petits fournisseurs peuvent communiquer directement via des tickets ou des groupes de messagerie. Cela signifie que les clients potentiels ne peuvent pas inspecter la fréquence des pannes, la qualité des avis de maintenance ou la performance de restauration avant l'achat. Un message privé peut être rapide, mais il est difficile à auditer et peut être indisponible lorsque le titulaire du compte ou l'opérateur de support est hors ligne.
La fenêtre de maintenance du bâtiment et celle de l'hôte sont également différentes. Une installation peut annoncer des travaux sur onduleur à son locataire. Le locataire doit décider si son équipement est à double alimentation, s'il faut migrer les invités, et si le travail menace un commutateur ou un nœud de stockage unique. Si Lien Cloud loue la capacité via un autre opérateur, l'avis peut passer par plusieurs parties avant d'atteindre l'utilisateur. Le temps perdu dans cette chaîne réduit la possibilité d'effectuer une sauvegarde fraîche ou de drainer un service gracieusement.
Un acheteur sérieux devrait demander des preuves d'un événement de maintenance terminé, avec les détails sensibles supprimés: heure de l'avis initial, périmètre, début et fin réels, impact client et action corrective. Il devrait également demander en quoi la maintenance d'urgence diffère, qui a le pouvoir de l'approuver, et si les clients peuvent reporter un redémarrage. Ces réponses révèlent le modèle opérationnel plus fiablement qu'un pourcentage de disponibilité sans méthode de mesure.
La récupération appartient en partie au client
Aucun fournisseur ne peut éliminer le rôle du client dans la récupération, surtout là où les propres preuves du fournisseur sont minces. La première protection est une copie indépendante des données. « Indépendant » signifie que la suppression, la suspension, le vol d'identifiants ou la perte physique chez l'hôte principal ne peuvent pas supprimer la sauvegarde. Un second volume attaché à la même VM n'est pas indépendant. Un instantané stocké sous le même compte de panneau de contrôle peut protéger contre une mauvaise mise à jour logicielle mais échouer en cas de compromission du compte ou de litige avec le fournisseur.
Les conseils de CISA contre les ransomwaresrecommandent des sauvegardes hors ligne et chiffrées, des tests réguliers de disponibilité et d'intégrité, des images dorées pour reconstruire les systèmes, et la considération d'un second cloud afin qu'un seul compte fournisseur ne compromette pas toutes les copies. Le principe s'applique au-delà des ransomwares. Une sauvegarde testée est aussi la réponse à une baie défaillante, une suppression accidentelle, un compte suspendu ou un hôte qui ne peut pas trouver de matériel de remplacement.
La deuxième protection est une définition de service portable. Les clients devraient conserver les notes d'installation du système d'exploitation, les versions de paquets, les règles de pare-feu, les comptes utilisateurs, les certificats, les secrets d'application, les tâches planifiées et les versions de dépendances en dehors de la VM hébergée. La configuration de l'infrastructure devrait être versionnée lorsque c'est pratique. L'objectif est de reconstruire sur un serveur propre sans dépendre de l'accès à l'invité défaillant.Les conseils de continuité du NISTcadrent la récupération autour d'équipements, d'emplacements, de stockage et de télécommunications de remplacement. Même une entreprise à un seul serveur peut appliquer cette logique à une échelle modeste.
La troisième protection est le contrôle des noms et des identifiants. Le DNS devrait résider dans un compte contrôlé par le client, protégé par une authentification multifacteur et des codes de récupération stockés séparément. L'enregistrement de domaine ne devrait pas dépendre uniquement de l'hébergeur. Les certificats devraient être renouvelables sur une machine de remplacement. L'accès administratif devrait utiliser plus d'une personne autorisée lorsque l'entreprise le permet. Les coordonnées doivent survivre à la perte d'un serveur de messagerie hébergé sur la même VM.
La quatrième est un exercice de restauration réel. Exportez une sauvegarde, provisionnez une petite VM ailleurs, restaurez l'application, modifiez un nom DNS temporaire et vérifiez les données, les connexions, les tâches planifiées et les courriels sortants. Enregistrez le temps. Ce test révèle si le format de sauvegarde est utilisable en dehors de l'hôte d'origine et si les hypothèses de licence, d'architecture ou de panneau de contrôle créent un verrouillage. Il fournit également un objectif de temps de récupération réaliste plutôt qu'une estimation optimiste.
Les clients qui dépendent de listes blanches IP ont une tâche plus difficile. Passer à un autre fournisseur change normalement l'adresse de service. Ils devraient maintenir une procédure de mise à jour avec les partenaires, utiliser des noms DNS lorsque c'est accepté, éviter d'incorporer une IP dans le logiciel, et pré-autoriser une plage de secours pour les intégrations critiques. Le /23 de Lien Cloud peut être portable au niveau de l'opérateur sous les bons accords, mais un client VPS individuel ne devrait pas s'attendre à avoir le droit d'emporter une adresse à moins que le contrat ne le précise explicitement.
La localité est une question juridique et opérationnelle
Le Vietnam traite désormais les services de centre de données et de cloud comme des services de télécommunications.La loi sur les télécommunications n° 24/2023/QH15définit les deux catégories, exige que les fournisseurs enregistrent ou notifient leur fourniture, se conforment aux règles de sécurité cyberinformationnelle, de cybersécurité et de données personnelles, déclarent la qualité de service, et déclarent la conformité d'un centre de données commercial avec les normes pertinentes avant sa mise en service. Les dispositions relatives au cloud et aux centres de données ont pris effet le 1er janvier 2025.Le décret 163/2024/ND-CPajoute des détails sur la conservation des informations utilisateur et l'enregistrement des services, et exige que les données des agences d'État utilisant ces services soient stockées au Vietnam.
Le cadre juridique rend l'emplacement et l'identité de l'opérateur plus conséquents, mais il ne permet pas à un client de déduire la conformité d'un enregistrement IP. Un acheteur devrait demander quelle entité juridique signe le contrat de service, quelle entité est le fournisseur de services cloud ou de centre de données à des fins réglementaires, où les données de production et les sauvegardes sont stockées, et quels sous-traitants peuvent y accéder. La réponse pourrait nommer Lien Cloud pour le contrat client et d'autres parties pour la colocation, le transit ou les mains à distance.
Ce n'est pas intrinsèquement indésirable; cela doit simplement être divulgué.
Les données personnelles ajoutent une autre couche. Laloi sur la protection des données personnelles n° 91/2025/QH15du Vietnam s'applique aux organisations vietnamiennes et aux parties étrangères impliquées dans le traitement de données personnelles couvertes. Le registre officiel du gouvernement confirme que la loia pris effet le 1er janvier 2026. Les clients restent responsables de comprendre s'ils sont responsables du traitement, sous-traitants ou une autre partie réglementée; une « IP Vietnam » ne règle pas cette analyse.
La souveraineté des données n'est donc pas simplement de conserver un disque principal à l'intérieur des frontières nationales. Elle inclut les instantanés, les sauvegardes hors site, les journaux de surveillance, l'accès au support, les vidages de mémoire et tout service outre-mer pouvant récupérer le contenu client. Une preuve solide de localité nommerait chaque pays de stockage, l'entité juridique contrôlant chaque copie, les périodes de conservation, les arrangements de chiffrement et les procédures de suppression. Aucune divulgation de Lien Cloud examinée ici ne fournit cette carte.
L'hébergement local peut encore offrir des avantages réels: latence nationale plus faible, paiement en monnaie locale, support en vietnamien et un cadre juridique national plus clair. La stratégie d'infrastructure nationale du Vietnam vise davantage de centres de données, de câbles internationaux et de redondance mutuelle. Leplan d'infrastructure numériquedu ministère appelle explicitement à des centres de données interconnectés et à une capacité de sauvegarde mutuelle. Ces ambitions nationales ne sont cependant pas la preuve qu'un /23 ou un nœud VPS particulier les a réalisées.
Qui est affecté lorsque le service échoue
Les clients probables de la capacité VPS vietnamienne à bas coût incluent des développeurs individuels, de petites agences, des communautés de jeux, des utilisateurs d'automatisation, des exploitants de sites web et de petites entreprises. Leur échelle technique peut être modeste, mais le mécanisme d'impact est familier. Une boutique en ligne perd des commandes. Un serveur de jeu perd l'état et la confiance de la communauté. Une agence manque une échéance client. Une application interne bloque le personnel. Un serveur de messagerie perd sa réputation de livraison après un changement d'adresse.
Un service de surveillance échoue précisément quand un autre système en a besoin.
La partie affectée n'est pas toujours le titulaire du compte. Une agence peut placer des dizaines de sites clients sur une seule VM. Un revendeur peut diviser un serveur en comptes plus petits. Un seul nœud physique peut donc concentrer de nombreuses entreprises qui ne savent pas qu'elles partagent un domaine de défaillance. L'absence de décomptes publics de nœuds et de locataires rend cette concentration impossible à quantifier pour Lien Cloud.
La gestion des abus peut également créer des effets collatéraux. Des services de réputation publics ont enregistré des signalements contre des adresses individuelles dans le /23, mais ces signalements sont des allégations non vérifiées concernant le trafic, peuvent contenir des faux positifs et ne doivent pas être lus comme des conclusions contre l'entreprise ou chaque locataire. Ils importent opérationnellement car une plage partagée peut accumuler un historique de listes noires. Un locataire abusif peut affecter la livraison de courrier ou l'accès externe pour les voisins.
Les preuves qui régleraient la préoccupation incluent une politique d'utilisation acceptable publiée, un contact d'abus réactif, un traitement limité dans le temps, une validation de source sortante et des procédures pour remplacer ou réhabiliter une adresse sans effacer la responsabilité.
Le résultat anti-usurpation de CAIDA est encourageant au niveau du réseau d'origine, tandis que l'autorisation de route valide réduit une classe de risque de routage. Aucun des deux ne traite de l'abus applicatif, des invités compromis ou de la réputation de courrier. L'hygiène réseau est en couches: autorisation de route, filtrage source, contrôles des locataires, correction, réponse aux incidents et communication client couvrent chacune une défaillance différente.
Quelles preuves justifieraient un verdict plus fort
Lien Cloud pourrait passer d'un niveau de preuve faible à moyen sans publier de secrets commerciaux. Une divulgation concise de l'infrastructure pourrait nommer la ville et l'exploitant de l'installation, indiquer si l'équipement est possédé ou loué, donner le nombre de racks ou de sites indépendants, identifier les responsabilités d'origine et de transit, confirmer le statut IPv6, décrire la réplication de stockage et spécifier qui effectue les mains à distance. Elle pourrait publier un historique de statut de service, les limites de sauvegarde, les heures de support, les objectifs d'escalade et les formats d'exportation.
Les adresses de routeur sensibles, les numéros de rack et les noms de clients n'ont pas besoin d'apparaître.
Les preuves de route pourraient s'améliorer grâce à une utilisation active d'AS151883 avec des fournisseurs documentés, ou à une explication claire qu'AS150862 est l'origine gérée prévue. Cette dernière peut être la conception sensée pour un petit opérateur. L'indépendance n'est pas automatiquement supérieure à un service géré compétent. Les faits importants sont de savoir si l'accord a de la redondance, si Lien Cloud peut joindre un opérateur autorisé pendant un incident, et ce qu'il advient du /23 et du trafic client si l'accord prend fin.
Les preuves d'installation devraient distinguer les capacités d'un site de la topologie déployée de Lien Cloud. Nommer un bâtiment certifié Tier n'est utile que si la certification est à jour et si la conception du locataire préserve les chemins d'alimentation et de réseau pertinents vers chaque hôte. Les preuves de capacité devraient séparer le matériel total installé de la capacité de rechange prête au basculement. Les preuves de récupération devraient rapporter le résultat d'un exercice de perte de nœud ou de restauration, y compris le temps de récupération et la perte de données, plutôt qu'une promesse générique.
Les clients peuvent demander ces éléments avant de déplacer un service critique. Ils devraient également lire le contrat réel pour les crédits de service, les exclusions, la responsabilité de sauvegarde, la restitution des données, la suspension, la résiliation et la responsabilité. Une page de prix décrit ce qui est facile à acheter; le contrat décrit ce qui se passe lorsque la partie facile prend fin.
Verdict: une empreinte réelle avec une résilience non prouvée
Lien Cloud n'est pas un nom vide. L'entreprise a une identité légale correspondante, une adhésion reconnue à VNNIC, un ASN actif, un /23 assigné, un arrangement d'origine de route valide via AS150862 et au moins un signe externe crédible d'un invité KVM fonctionnel associé à son étiquette d'hôte. Ces points soutiennent la conclusion qu'il y a eu une activité hébergée authentique autour de l'entreprise et de ses ressources d'adresses.
Les mêmes preuves fixent un plafond ferme. AS151883 n'est pas visiblement routé. Le bloc nommé dépend de l'ASN d'une autre société. L'installation physique n'est pas divulguée. La propriété des serveurs, racks et stockage est inconnue. La capacité multi-sites, la diversité des chemins d'alimentation, l'utilisation du transit au rack, le matériel de rechange, l'escalade de support, la conception de sauvegarde et les droits de migration ne sont pas vérifiés publiquement. La différence entre un VPS fonctionnel aujourd'hui et un service récupérable demain reste sans réponse.
Pour les charges de travail expérimentales, les sites web sauvegardés indépendamment et les services pouvant tolérer un changement d'IP, le modèle peut être tout à fait utilisable si le prix et la latence locale sont attractifs. Pour les données personnelles réglementées, les systèmes critiques pour les revenus, les listes blanches strictes ou les charges de travail avec des objectifs de récupération courts, les preuves manquantes sont matérielles.
La position rationnelle n'est pas de supposer la panne, mais de valoriser la dépendance: garder une seconde copie ailleurs, posséder le DNS et le domaine, tester une restauration, comprendre le contrat et exiger une réponse documentée avant de traiter une machine virtuelle comme une infrastructure résiliente.
L'actif le plus révélateur de Lien Cloud n'est donc pas le bloc de 512 adresses en lui-même. C'est la limite autour de ce bloc: enregistré sous un nom, routé par un autre réseau, hébergé quelque part non identifié publiquement, et offert à des utilisateurs qui peuvent ne voir qu'un panneau de contrôle. La fiabilité dépend de la qualité de l'ingénierie et de la gouvernance de ces jointures cachées. Jusqu'à ce que l'entreprise montre ces preuves, son empreinte opérationnelle devrait être considérée comme réelle, mais sa capacité de redondance et de récupération comme non prouvée.