CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED vend de la capacité hébergée qui dépend encore des baies, du transit et des fenêtres de maintenance

Résumé

• La liste publique des membres disposant de ressources internet du VNNIC inclut Cong ty TNHH Truyen thong va Cong nghe Cloud Data sous le label EDIGI-VN, datée du 22 novembre 2023. L'enregistrementRDAP pour AS151872de l'APNIC identifie EDIGI-VN au Viêt Nam, avec un statut actif et un événement d'enregistrement au 16 novembre 2023, tandis que lavue whois de RIPEstatdonne le nom anglais CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED et une adresse à Hô Chi Minh-Ville.
• AS151872 est joignable publiquement. Lavue d'ensemble de l'ASde RIPEstat a montré l'AS annoncé le 12 juillet 2026, et lavue de l'état du routagea montré 3 préfixes IPv4, 4 préfixes IPv6, 1 024 adresses IPv4, quatre /48 IPv6, une visibilité sur les 325 pairs RIS IPv4 et les 322 pairs RIS IPv6, et un voisin observé.
• L'ensemble de préfixes actuel est opérationnellement mixte. Lavue des préfixes annoncésde RIPEstat a listé 157.66.198.0/23, 160.30.10.0/24, 160.30.11.0/24, 2001:df3:e4c0::/48, 2001:df3:e8c0::/48, 2401:9760::/48 et 2401:9920::/48. Les enregistrements APNIC attachent plusieurs de ces préfixes à d'autres labels vietnamiens, pas directement à EDIGI-VN.
• Le bloc IPv4 au nom de l'entreprise n'est pas la preuve actuelle de l'AS151872. L'enregistrementRDAP pour 203.145.46.0/23de l'APNIC nomme EDIGI-VN et CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, mais lavue d'ensemble du préfixede RIPEstat a montré que ce bloc était originaire de AS150862, MAYTINHVPSTTT-VN - VPSTTT COMPUTER COMPANY LIMITED, et lavérification RPKI pour AS150862était valide.
• Le niveau de preuve public est Moyen-Faible. L'origine de la route est active et mesurable, mais le dossier public ne prouve pas la possession d'un espace de centre de données, le nombre de baies, le matériel de rechange, le service multi-site, la diversité de transit au-delà du chemin FPT visible, les droits de migration des clients ou l'autorité de support qui déciderait des fenêtres de maintenance.

L'information utile est l'AS151872, pas une vitrine cloud de marque

Le dossier public commence par une identité de ressource numérique petite mais concrète. Laliste des membres disposant de ressources internetdu VNNIC inclut Cong ty TNHH Truyen thong va Cong nghe Cloud Data sous le label EDIGI-VN avec une entrée du 22 novembre 2023. L'enregistrementRDAP pour AS151872de l'APNIC donne le handle AS151872, le nom EDIGI-VN, le pays VN et un statut actif. L'enregistrementwhois de RIPEstat pour AS151872développe cela en CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED et liste le No. 338/22 Thoai Ngoc Hau, quartier Phu Thanh, district de Tan Phu, Hô Chi Minh-Ville, Viêt Nam.

Cela suffit pour identifier l'entreprise derrière un enregistrement de système autonome routé. Cela ne suffit pas pour identifier une plateforme cloud. Il n'y a pas de liste d'installations publiques dans l'enregistrement AS, pas de nombre d'armoires, pas de nom de salle de données, pas de région de récupération publiée, pas de calendrier de maintenance et pas de promesse de niveau de service client attachée au numéro. Pour un client qui achète de la capacité hébergée, la différence est importante. Un AS enregistré peut décrire qui origine les routes.

Il ne dit pas où se trouvent les serveurs, quelles unités de distribution d'alimentation les alimentent, qui a un accès en mains distantes, combien de disques de rechange sont sur site, ou si un client peut déplacer ses données sous pression.

La couche suivante de preuves est le routage actuel. Lavue d'ensemble de l'ASde RIPEstat a marqué AS151872 comme annoncé le 12 juillet 2026. Savue de l'état du routagea montré l'AS visible par tous les 325 pairs RIS IPv4 et tous les 322 pairs RIS IPv6 au moment de la requête du 11 juillet 2026 à 16h00 UTC. Elle a également montré un voisin observé. C'est un signal plus fort qu'une liste d'entreprise périmée. Cela dit que le réseau est présent dans la table de routage globale. Mais cela ne dit toujours pas quel produit se cache derrière la route.

C'est pourquoi l'entreprise doit être évaluée comme une dépendance de capacité hébergée plutôt que comme un opérateur de centre de données avéré. Un acheteur peut surveiller AS151872. Un acheteur peut tester les routes vers ses préfixes. Un acheteur peut demander une autorisation d'origine de route, une escalade de support et des conditions d'exportation.

Ce que l'acheteur ne peut pas faire, c'est transformer l'enregistrement AS public en une affirmation selon laquelle CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED possède un bâtiment particulier, contrôle une salle de données spécifique ou dispose d'une capacité excédentaire dans un second site.

L'ensemble de préfixes actif est réel, mais ce n'est pas une preuve de propriété simple

Lesdonnées des préfixes annoncésde RIPEstat ont listé sept ressources actuelles pour AS151872 dans la fenêtre de fin juin au 12 juillet 2026: 157.66.198.0/23, 160.30.10.0/24, 160.30.11.0/24, 2001:df3:e4c0::/48, 2001:df3:e8c0::/48, 2401:9760::/48 et 2401:9920::/48. La pageAS151872 de BGP.Toolsaffichait la même silhouette de haut niveau: trois préfixes IPv4, quatre préfixes IPv6, un amont et un pair visibles pour ce service. La pageAS151872 d'IPIP.NETmontrait de manière similaire trois préfixes IPv4, quatre préfixes IPv6 et 1 024 adresses IPv4.

Les labels attachés aux préfixes actifs rendent l'histoire opérationnelle plus compliquée. L'enregistrementRDAP pour 157.66.198.0/23de l'APNIC identifie DAZITT-VN et DAZI MARCOM CO., LTD, pas EDIGI-VN. L'enregistrementRDAP pour 160.30.10.0/23identifie IPXO-VN et IPXO Technology Company Limited.2001:df3:e4c0::/48identifie GENLOGIN-VN,2001:df3:e8c0::/48identifie CLEMAX-VN,2401:9760::/48identifie THCLOUD-VN, et2401:9920::/48renvoie à nouveau DAZITT-VN.

Ces labels ne prouvent pas un arrangement de revente, une relation client ou une relation d'installation. Ils montrent seulement que l'ensemble de routes actif d'AS151872 inclut des préfixes dont les noms de registre publics appartiennent à plusieurs labels de ressources vietnamiens.

Sur les marchés du cloud et de l'hébergement, ce schéma peut apparaître lorsqu'un fournisseur origine des ressources déléguées, lorsque des clients ou des affiliés utilisent la plateforme de routage d'un fournisseur, lorsque des détenteurs d'adresses utilisent du BGP hébergé, ou lorsque l'administration des ressources numériques et l'exploitation du service sont assurées par des mains différentes. Le routage public ne peut pas déterminer quelle explication s'applique ici.

L'implication pour l'approvisionnement est claire: ne considérez pas le nombre d'adresses routées comme une capacité de serveurs possédée. Les 1 024 adresses IPv4 et les quatre /48 IPv6 indiquent une surface réseau adressable, pas une profondeur de calcul, de stockage ou de support utilisable. Un acheteur devrait demander quels préfixes seraient attribués à son service, quel nom apparaît dans les enregistrements de route et de registre, qui peut autoriser les changements de route, et si le client peut conserver, renuméroter ou remplacer ces adresses pendant la migration.

Le bloc au nom d'EDIGI est la plus grande prudence

La raison la plus forte de ralentir est 203.145.46.0/23. L'enregistrementRDAP pour 203.145.46.0/23de l'APNIC nomme EDIGI-VN, décrit CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, et donne la même adresse d'Hô Chi Minh-Ville que celle utilisée dans l'enregistrement whois d'AS151872. Une lecture rapide appellerait cela le bloc IPv4 principal de l'entreprise. La table de routage actuelle dit quelque chose de plus étroit.

Lavue d'ensemble du préfixe 203.145.46.0/23de RIPEstat a montré le bloc annoncé par AS150862, pas par AS151872. Lavue d'ensemble d'AS150862identifie cette origine comme MAYTINHVPSTTT-VN - VPSTTT COMPUTER COMPANY LIMITED. La vue RPKI soutient également l'origine actuelle:203.145.46.0/23 avec AS150862a retourné valide, tandis quele même préfixe avec AS151872a retourné invalid_asn.

Cela ne signifie pas que le bloc au nom d'EDIGI est mal utilisé, abandonné ou indisponible. Cela signifie que l'origine de route publique actuelle n'est pas l'AS de l'entreprise que le reste de l'article teste. Le bloc peut être desservi par un autre opérateur vietnamien, déplacé pour des raisons opérationnelles, utilisé dans le cadre d'un arrangement client, ou ne plus être pertinent pour le produit hébergé d'un acheteur. Les preuves publiques ne peuvent pas en décider.

Elles peuvent seulement avertir l'acheteur de ne pas supposer qu'un label de registre EDIGI et un chemin de service AS151872 sont la même chose.

Pour la planification de la continuité, cette distinction est cruciale. Si un client reçoit des adresses de 203.145.46.0/23, le chemin d'incident peut ne pas être le même que le chemin pour 157.66.198.0/23 ou 160.30.10.0/24 sous AS151872. Si le client surveille uniquement AS151872, il peut manquer le bloc labellisé EDIGI. S'il surveille uniquement le bloc labellisé EDIGI, il peut manquer le service actif AS151872. Un examen sérieux du service doit cartographier le pool d'adresses, l'AS d'origine, l'autorisation de route, le propriétaire du support et les conditions de migration pour chaque préfixe orienté client.

Un seul voisin visible transforme le transit en un test, pas un slogan

Les preuves publiques de voisinage pointent vers FPT. Lavue des voisins ASNde RIPEstat a montré un voisin observé pour AS151872, AS18403. Lavue d'ensemble d'AS18403identifie AS18403 comme FPT-VN - FPT Telecom Company, et l'enregistrementwhois d'AS18403donne FPT Telecom Company au Viêt Nam. BGP.Tools affiche également AS18403 comme l'amont et le pair visibles pour AS151872.

C'est un fait opérationnel utile, mais il ne faut pas l'étirer. Un collecteur de routes public peut montrer un voisin visible. Il ne peut pas montrer chaque interconnexion privée, service de sauvegarde, contrat commercial ou politique de routage. AS151872 peut avoir des arrangements internes qui ne sont pas exposés dans cette vue. Il peut aussi avoir une bordure publique très mince. L'hypothèse pratique de l'acheteur n'est ni « il n'y a pas de redondance » ni « FPT rend tout résilient ».

L'hypothèse pratique est « le chemin de route publique visible commence par FPT, donc le fournisseur devrait expliquer ce qui se passe lorsque ce chemin est dégradé ou retiré ».

Lesdonnées du looking-glass pour 157.66.198.0/23ont montré des chemins de collecteurs publics se terminant par AS151872, généralement via AS18403 après des amonts tels que Telstra, PCCW, Lumen ou d'autres transporteurs mondiaux dans les chemins observés. Cela est une accessibilité mondiale normale. Ce n'est pas une preuve qu'AS151872 achète directement auprès de chaque transporteur distant. La question orientée client reste locale: quel chemin transporte les paquets hors de l'installation, quel équipement le termine, et qui le répare?

Pour un service hébergé, la diversité de transit n'est significative que si elle est séparée aux bonnes couches. Deux noms d'amont n'aident pas s'ils entrent dans la même baie par le même routeur, dépendent de la même alimentation électrique, partagent la même salle de rencontre du bâtiment, ou nécessitent la même file d'attente de support pour changer la politique de routage. Inversement, un seul amont public peut être acceptable pour une charge de travail à risque plus faible si le service est explicitement tarifé et documenté comme étant à attachement unique et si le client a un chemin de sortie.

Le risque n'est pas la singularité en elle-même. Le risque est qu'un client croie avoir acheté de la diversité alors que les preuves publiques ne montrent qu'un seul voisin visible.

RPKI est partagé entre valide et inconnu

La validation de l'origine de route ajoute une autre couche de preuves mitigées. Les vérifications RPKI de RIPEstat ont retourné valide pour160.30.10.0/24 avec AS151872, valide pour160.30.11.0/24 avec AS151872, valide pour2001:df3:e4c0::/48, valide pour2001:df3:e8c0::/48, et valide pour2401:9760::/48. Elle a retourné inconnu pour157.66.198.0/23et inconnu pour2401:9920::/48.

Inconnu n'est pas invalide. Cela signifie que la vue de validation publique n'a pas trouvé d'autorisation d'origine de route positive couvrant cette origine et ce préfixe au moment de la vérification. Pour de nombreux petits réseaux, ce statut est encore courant. Pour un client achetant une capacité hébergée critique, cela reste une question significative. Si les amonts ou les pairs appliquent un filtrage strict des routes, le statut inconnu peut changer le comportement en cas de défaillance. En cas de fuite ou de détournement de route, les origines autorisées rendent le filtrage et le diagnostic plus faciles.

Les normes pertinentes ne certifient pas cette entreprise. Elles expliquent ce qu'il faut demander.RFC 6811définit la validation d'origine de préfixe BGP.RFC 7454décrit les pratiques opérationnelles pour le filtrage BGP et la sécurité du routage.MANRSencadre les normes de filtrage des routes, d'anti-usurpation et de coordination. Lapage de certification des ressourcesde l'APNIC explique RPKI dans la région APNIC.

Le client devrait demander une déclaration d'authentification des routes par préfixe. Quels préfixes orientés client ont des ROA valides? Lesquels sont intentionnellement laissés inconnus? Qui peut créer ou modifier l'autorisation? À quelle vitesse le fournisseur peut-il réparer un état d'origine de route invalide? Un petit fournisseur d'hébergement peut être fiable si ces réponses sont claires. Un fournisseur avec des routes actives et une autorisation peu claire peut laisser les clients exposés lors des changements de politique en amont.

Une adresse à Hô Chi Minh n'est pas un emplacement de baie

L'adresse de l'entreprise apparaît de manière cohérente dans les documents publics. Le whois de RIPEstat liste No. 338/22 Thoai Ngoc Hau, quartier Phu Thanh, district de Tan Phu, Hô Chi Minh-Ville, Viêt Nam pour AS151872. L'enregistrement203.145.46.0/23au nom d'EDIGI dans l'APNIC donne la même adresse. Lemiroir du code fiscalde MaSoThue liste également le nom de l'entreprise vietnamienne, le code fiscal 0318010419, le nom anglais et l'adresse de Thoai Ngoc Hau, tout en signalant un statut négatif pour l'adresse enregistrée. Parce que cette page est un miroir d'informations commerciales plutôt qu'un registre de réseau officiel, son champ de statut doit être traité comme un signal à vérifier, pas comme un jugement opérationnel complet.

Même sans le signal de statut négatif, l'adresse ne doit pas être lue comme une carte de centre de données. Un bureau enregistré, un contact administratif, une adresse fiscale, un contact de route ou une adresse commerciale peut être distinct des baies qui hébergent les charges de travail des clients. Un petit fournisseur de cloud ou d'hébergement peut colocaliser son équipement dans une installation tierce, louer des nœuds bare-metal auprès d'un autre fournisseur, originer des préfixes de clients ou de partenaires, ou gérer des serveurs à distance. Aucun de ces arrangements n'est automatiquement mauvais.

Chacun modifie le chemin de réparation.

Si un client achète un service local au Viêt Nam, il devrait demander où se trouve chaque couche: calcul de production, stockage, sauvegarde, surveillance, enregistrements de support, enregistrements de facturation, accès de gestion et staging d'exportation. « Hô Chi Minh-Ville » comme adresse ne suffit pas. Le client a besoin de savoir si la production est à Hô Chi Minh-Ville, dans une autre ville vietnamienne, dans une baie louée dans une installation de transporteur, dans un environnement virtualisé sur un autre fournisseur, ou un mélange.

Le but n'est pas d'exiger des plans d'étage sensibles. Le but est de localiser la responsabilité. Si un serveur tombe en panne, qui peut entrer dans la baie? Si un commutateur tombe en panne, qui possède la pièce de rechange? Si une maintenance électrique est programmée, qui reçoit l'avis? Si une route doit être déplacée, qui peut changer BGP? L'adresse publique de l'entreprise ne répond pas à ces questions, et il ne faut pas lui demander plus qu'elle ne peut.

La capacité hébergée est une chaîne d'éléments empruntés et opérés

Les preuves actuelles d'AS151872 ressemblent à une petite chaîne de capacité hébergée, pas à un cloud hyperscale autonome. Cette distinction compte pour les attentes. Un petit réseau peut fournir un bon service lorsqu'il sait exactement quelles parties il possède, quelles parties il loue, quelles parties sont contrôlées par le client et quelles parties sont chez les fournisseurs en amont. Il devient fragile lorsque ces frontières sont cachées.

Les preuves de l'espace d'adressage montrent déjà plusieurs labels. DAZITT-VN, IPXO-VN, GENLOGIN-VN, CLEMAX-VN et THCLOUD-VN apparaissent sur les préfixes actuellement originaires d'AS151872. EDIGI-VN apparaît sur 203.145.46.0/23, mais ce bloc est actuellement originaire d'AS150862. Les preuves de routage montrent AS18403/FPT comme le voisin public d'AS151872. L'indice du domaine de l'entreprise ajoute également de l'incertitude: les contacts AS utilisent des adresses e-mail edigi.vn, mais une requête directe àhttps://edigi.vna retourné une réponse Cloudflare 521 au cours de cette revue, ce qui indique généralement que Cloudflare n'a pas pu joindre le serveur d'origine. Cette observation ne prouve pas que les services clients sont hors ligne, mais elle diminue la confiance dans la documentation publique orientée client.

Pour l'économie de l'hébergement, la question est de savoir comment l'entreprise transforme ces dépendances en capacité utilisable. Possède-t-elle ses propres serveurs dans des baies louées? Revend-elle l'inventaire VPS ou bare-metal d'un autre fournisseur? Origine-t-elle des préfixes clients pour des systèmes tiers? Fournit-elle des services de réseau à d'autres labels de logiciels ou de cloud vietnamiens? Les données publiques ne peuvent pas trancher ces questions. Elles montrent que tout client devrait éviter le mot « cloud » comme raccourci.

La capacité installée est ce qui existe sur le papier: adresses, numéro AS, accessibilité en amont, baies ou contrats. La capacité utilisable est ce qui peut réellement supporter les charges de travail des clients après prise en compte des contraintes d'alimentation, de refroidissement, de filtrage des routes, de pannes matérielles, de réponse du support et de stock de pièces de rechange. La capacité récupérable est ce qui peut être restauré dans le délai du client. L'AS public nous dit que la première couche existe. Il ne nous dit pas pour la deuxième ou la troisième.

La main-d'œuvre de support est une dépendance physique

Dans un petit environnement d'hébergement, la main-d'œuvre de support fait partie de l'infrastructure. Si un client ne peut pas joindre la personne ou l'équipe qui peut changer une route, remplacer un disque, redémarrer une console, débloquer la facturation, récupérer les sauvegardes ou se coordonner avec l'amont, le service peut échouer même si la route reste visible. La visibilité actuelle de la route d'AS151872 n'est donc que le début de la question du support.

Les documents publics donnent des contacts administratifs et techniques via l'APNIC et RIPEstat, mais ils ne publient pas de carte d'escalade client. Ils ne disent pas si le support en dehors des heures ouvrées est interne, externalisé, géré par une installation, géré par l'amont ou géré par un autre opérateur d'hébergement. Ils ne montrent pas si le même chemin de support couvre les préfixes actifs d'AS151872 et le bloc 203.145.46.0/23 au nom d'EDIGI maintenant routé par AS150862. Ils ne montrent pas si le statut de facturation peut suspendre un serveur avant que le client n'exporte ses données.

Pour les acheteurs, la bonne preuve est pratique. Ouvrez un ticket de support demandant une déclaration d'origine de route par préfixe. Demandez comment joindre le support d'urgence si le portail client est indisponible. Demandez qui est autorisé à contacter FPT ou un autre amont au nom du client. Demandez si le client peut recevoir des avis de maintenance de l'installation. Demandez le temps maximum pour remplacer le matériel courant, restaurer une machine virtuelle et exporter une sauvegarde complète en état dégradé.

La réponse peut être modeste, et c'est bien si le prix et la charge de travail correspondent. Un service VPS à bas coût n'a pas besoin de prétendre être un cloud d'entreprise multi-régions. Le danger est une dépendance mal assortie. Si l'application du client, le service de revente ou la charge de travail de service public dépend d'une réparation rapide, le client a besoin d'une escalade écrite et d'une récupération testée, pas seulement d'une facture et d'une adresse IP.

La localité des données doit être spécifiée un composant à la fois

L'attribution de VN dans les enregistrements APNIC et VNNIC soutient une identité de ressource numérique vietnamienne. Elle ne prouve pas où les données des clients sont stockées. Pour la souveraineté et la localité des données, le client a besoin d'une réponse au niveau des composants. Le calcul de production peut être à un endroit, le stockage à un autre, la sauvegarde à un autre, l'accès au support depuis un autre et les enregistrements de facturation dans un autre. Une route qui prend son origine au Viêt Nam ne détermine pas par elle-même l'un de ces emplacements.

Le contexte juridique et réglementaire du Viêt Nam rend cette distinction importante. Les clients manipulant des informations personnelles, des données réglementées, des charges de travail du secteur public, des données de paiement ou des enregistrements commerciaux sensibles doivent savoir quelles données peuvent être déplacées, qui peut y accéder et ce qui se passe lors de la résiliation. L'enregistrement public AS151872 ne répond à rien de tout cela. La vérification de la disponibilité du site web de l'entreprise ne répond à rien de tout cela.

La discordance du bloc 203.145.46.0/23 au nom d'EDIGI rend la question plus urgente car elle montre que les noms de registre et les origines de route peuvent être séparés.

La bonne demande est un calendrier de localité. Il devrait indiquer où se trouvent les disques de production, où se trouvent les sauvegardes, où se trouvent les journaux et les données de surveillance, où se trouvent les tickets de support, où se trouvent les enregistrements de compte et de facturation, et d'où les administrateurs peuvent se connecter. Il devrait également indiquer si ces emplacements sont des garanties contractuelles, une pratique opérationnelle normale ou discrétionnaires pour le fournisseur.

Un client qui a besoin d'un traitement des données exclusivement au Viêt Nam ne devrait pas se fier à un code pays dans un enregistrement AS.

La localité affecte également la récupération. Un fournisseur peut conserver les sauvegardes dans un autre site pour la résilience, mais le client doit savoir si ces sauvegardes sont utilisables pendant une panne locale et si leur restauration change la juridiction, les adresses IP, la latence ou les preuves de conformité. Un fournisseur peut utiliser un autre AS ou une autre installation vietnamienne pour soutenir le basculement, mais le client doit savoir qui contrôle ce basculement. La localité n'est pas un label. C'est un ensemble de faits opérationnels.

La migration est le test honnête de la dépendance

La façon la plus claire de tester un service hébergé est de le quitter une fois, délibérément et en l'absence d'urgence. Cela est particulièrement vrai lorsque les preuves publiques montrent des labels de préfixes mixtes et une origine actuelle distincte pour le bloc au nom de l'entreprise. Un client qui ne peut pas exporter, reconstruire et renuméroter une petite charge de travail dans des conditions calmes devrait supposer qu'une migration en situation de crise sera lente.

Pour CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, le test de migration devrait inclure les adresses, pas seulement les données. Si la charge de travail utilise l'espace 157.66.198.0/23, 160.30.10.0/24 ou 160.30.11.0/24 originaire d'AS151872, le client peut-il déplacer ces adresses? Si la charge de travail utilise l'espace 203.145.46.0/23 enregistré à EDIGI-VN mais originaire d'AS150862, qui approuve les modifications? Si le client utilise un espace IPv6 /48 sous AS151872, les enregistrements d'origine de route, les règles de pare-feu et les listes d'autorisation des partenaires sont-ils documentés?

L'exportation des données devrait être tout aussi concrète. Le client peut-il exporter des images disque, des données d'objet, des bases de données, des instantanés, des paramètres DNS, des règles de pare-feu, des journaux d'accès et des enregistrements de facturation sans intervention manuelle? Les exportations peuvent-elles être exécutées si le panneau de contrôle est dégradé? Les exportations sont-elles limitées? Combien de temps les sauvegardes sont-elles conservées après l'annulation? Qui peut autoriser une exportation d'urgence si le titulaire du compte habituel est indisponible?

La réponse détermine le risque économique de la relation d'hébergement. Une capacité hébergée bon marché peut devenir coûteuse si elle crée des dépendances captives autour d'adresses IP attribuées par le fournisseur, de sauvegardes non documentées et d'un support lent. Un petit fournisseur peut quand même être un bon choix si le client peut le quitter proprement. La portabilité n'est pas un manque de loyauté. C'est la preuve de reprise après sinistre du client.

Qui ressent la défaillance

Le client visible d'AS151872 peut être un opérateur d'application vietnamien, un revendeur, une petite entreprise, un service logiciel, une agence, un intégrateur de systèmes ou un autre réseau utilisant le routage hébergé. L'utilisateur final peut ne jamais voir le nom CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED. Il remarquera des applications plus lentes, des pages de connexion inaccessibles, des e-mails rejetés, des appels API bloqués, des sauvegardes échouées ou des listes d'autorisation d'adresses en échec.

Les chemins de défaillance sont superposés. Un problème de route publique peut supprimer l'accessibilité de tous les préfixes actuels d'AS151872. Une panne de fibre locale ou en amont peut dégrader l'accessibilité via AS18403. Un problème d'alimentation de baie peut laisser BGP visible alors que les serveurs sont hors ligne. Une panne de disque ou de pool de stockage peut faire paraître la route saine alors que les données sont indisponibles. Un goulot d'étranglement du support peut prolonger un incident après que la cause technique est connue.

Un problème de facturation ou de statut de compte peut bloquer la récupération même lorsque l'infrastructure est réparable. Une discordance entre le nom de registre, l'origine de route et le contrat client peut ralentir la première heure de diagnostic.

Le bloc 203.145.46.0/23 au nom d'EDIGI ajoute un risque spécifique en aval. Si des clients ou des partenaires ont enregistré ce bloc comme « EDIGI » en raison des données de l'APNIC, mais que l'origine de route actuelle est AS150862, la surveillance et les listes de contacts d'incident peuvent pointer dans des directions différentes. Le client ne devrait pas attendre une panne pour décider quel contact possède quel préfixe.

Les preuves publiques ne sont pas une raison de rejeter carrément le fournisseur. C'est une raison de cartographier le service avant d'en dépendre. Le réseau existe. Il est actuellement visible. Plusieurs préfixes ont une autorisation d'origine de route valide. Les questions non résolues sont physiques et contractuelles: où se trouve la charge de travail, qui la répare, combien de chemins existent, qu'arrive-t-il au bloc au nom d'EDIGI, et comment un client sort.

Comment vérifier avant de dépendre du service

La première étape de vérification est l'identité. Demandez au fournisseur de confirmer si le service client est fourni par AS151872, par 203.145.46.0/23 sous AS150862, par un autre bloc routé, par un adressage privé ou par un mélange. Comparez la réponse avec les enregistrementsAS151872et203.145.46.0/23de l'APNIC, lestatut de routage AS151872de RIPEstat, et lavue d'ensemble du préfixe 203.145.46.0/23de RIPEstat.

La deuxième étape de vérification est la topologie. Demandez le type d'installation de production, le type d'installation de récupération, le chemin de transit public, le chemin de connectivité privée le cas échéant, le chemin d'escalade en amont et le processus d'avis de maintenance. Le fournisseur n'a pas besoin de divulguer les coordonnées sensibles des baies pour répondre. Il peut indiquer si le client est en site unique, multi-site, mono-amont, bi-amont, sauvegardé à un autre emplacement ou dépendant d'un fournisseur de colocalisation tiers.

La troisième étape est la sécurité du routage. Demandez une déclaration ROA par préfixe et comparez-la avec les vues RPKI de RIPEstat. Les entrées valides pour 160.30.10.0/24, 160.30.11.0/24 et plusieurs /48 IPv6 sont positives. Les entrées inconnues pour 157.66.198.0/23 et 2401:9920::/48 devraient être expliquées. Le statut valide de AS150862 pour 203.145.46.0/23 devrait également être expliqué si le client s'attend à un service de marque EDIGI.

La quatrième étape est un exercice de récupération. Restaurez une charge de travail représentative à partir de la sauvegarde, déplacez-la dans un autre environnement, mettez à jour le DNS ou les listes d'autorisation des partenaires, confirmez les journaux, vérifiez l'intégrité des données et enregistrez le temps écoulé. Incluez l'escalade du support dans le test. Si le chemin de support ne peut pas exécuter un petit déplacement planifié, il est peu probable qu'il exécute un grand déplacement d'urgence proprement.

La frontière du fournisseur a besoin d'une matrice de préfixes

Le document le plus utile qu'un client pourrait demander est une matrice de préfixes. Il n'a pas besoin de révéler des diagrammes internes sensibles. Il devrait simplement relier chaque bloc réseau orienté client à son label de registre, son origine de route, son état d'autorisation de route, son chemin en amont, son propriétaire de support et son impact sur le client. Pour AS151872, cette matrice commencerait par 157.66.198.0/23, 160.30.10.0/24, 160.30.11.0/24, les quatre /48 IPv6 visibles, et le bloc 203.145.46.0/23 au nom d'EDIGI qui est actuellement en dehors de l'ensemble d'origines d'AS151872.

La matrice devrait répondre à une question fondamentale pour chaque préfixe: si cette route change, qui peut la réparer? La réponse peut être CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED. Cela peut être un client qui a fourni son propre espace d'adressage. Cela peut être un amont ou un autre opérateur vietnamien. Cela peut être une combinaison. Le routage public voit le résultat, pas la chaîne d'autorité. Les clients ont besoin de la chaîne d'autorité car la réparation de route est souvent un problème de permissions avant d'être un problème technique.

La même matrice devrait séparer l'utilisation en production de l'utilisation réservée ou administrative. Un préfixe peut apparaître dans la table de routage globale mais porter des interfaces de gestion, des hôtes de test, du NAT client, du courrier, du DNS, des points de terminaison de sauvegarde, des sondes de surveillance ou aucune charge de travail client payante du tout. Si on vend à un client de la capacité sur un bloc d'adresses public, il devrait demander si ce bloc est dédié, partagé, filtré, portable ou remplaçable.

Il devrait également demander ce qui se passe si le label de registre, l'origine de route ou l'état RPKI change pendant le contrat.

Les preuves mitigées d'AS151872 rendent cela particulièrement important. L'AS actif contient des ressources dont les noms de registre public appartiennent à plusieurs labels vietnamiens, tandis que le bloc IPv4 au nom d'EDIGI a une autre origine actuelle. Ce n'est pas automatiquement un signe d'alerte; cela peut être une délégation opérationnelle normale. Mais une délégation normale a tout de même besoin de documentation.

Sans elle, un client peut perdre des heures pendant une panne à décider s'il doit appeler le contact du compte d'hébergement, le contact de route AS151872, l'opérateur AS150862, le détenteur d'adresse ou l'amont.

L'acheteur devrait également demander si des adresses orientées client sont protégées par des filtres anti-abus du fournisseur, du géoblocage, une atténuation DDoS, des limites de courrier sortant ou une politique de route spéciale. Ces contrôles peuvent être précieux, mais ils peuvent aussi compliquer la migration et la réponse aux incidents. Une matrice de préfixes transforme ces contraintes cachées en faits opérationnels que le client peut tester.

L'alimentation, les pièces de rechange et la maintenance sont invisibles depuis BGP

BGP rend les routes visibles; il ne rend pas le service physique visible. AS151872 peut être entièrement joignable depuis les collecteurs de routes alors qu'une seule baie, un commutateur, un nœud de stockage ou un circuit d'alimentation est le point réel de défaillance du client. La table de routage n'expose pas si les serveurs sont dans des salles propres, des armoires louées, une colocalisation tierce, un inventaire bare-metal loué ou l'environnement virtualisé d'un autre fournisseur. Elle n'expose pas non plus si les pièces de rechange courantes sont conservées sur site.

Cela importe parce que les pannes d'hébergement commencent souvent par des contraintes physiques ordinaires. Un serveur peut perdre un disque. Un commutateur en haut de baie peut tomber en panne. Une unité de distribution d'alimentation peut disjoncter. Une fenêtre de maintenance d'UPS peut supprimer la redondance. Une installation peut nécessiter une planification des interventions manuelles à distance. Une pièce de rechange peut être retardée. L'AS public peut rester annoncé tout au long de cela. De l'extérieur, la route semble saine alors que l'application du client est indisponible.

Pour CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, le dossier public ne donne aucun nombre de baies, nom de salle de données, conception de l'alimentation ou preuve de stock de matériel. La bonne conclusion n'est pas que ces éléments sont absents. C'est que les clients doivent les demander directement. Au minimum, un client de production devrait savoir si sa charge de travail est en baie unique ou multi-baies, si le stockage est local ou répliqué, si la sauvegarde est hors baie et hors site, et si la maintenance peut affecter tous les services orientés client en même temps.

La frontière du support recoupe la frontière physique. Si l'entreprise loue de l'espace dans une autre installation, l'installation peut contrôler l'accès et les interventions à distance. Si elle loue des serveurs auprès d'un autre fournisseur, l'autre fournisseur peut contrôler le remplacement du matériel. Si elle utilise un amont pour BGP et un autre pour la colocalisation, une panne de route et une panne d'alimentation peuvent nécessiter des chemins d'escalade entièrement différents. Un bon fournisseur peut gérer ces dépendances, mais le client ne devrait pas les découvrir seulement après une panne.

Les clients devraient demander des preuves sous une forme pratique: exemples d'avis de maintenance, description de l'alimentation redondante par niveau de service client, objectifs de remplacement pour le matériel courant, l'emplacement de rétention des sauvegardes et un exercice de restauration récent. Ce ne sont pas des demandes grandioses d'entreprise. Ce sont les faits minimums nécessaires pour décider si le service est approprié pour une charge de travail qui ne peut pas tolérer une longue fenêtre de réparation.

La facturation et l'état du compte peuvent devenir une panne d'infrastructure

Le titre de l'article mentionne les baies, le transit et les fenêtres de maintenance, mais le statut du compte appartient à la même liste. Un service hébergé peut être techniquement sain et pourtant indisponible pour le client parce qu'une facture est contestée, un administrateur a quitté l'entreprise, un chemin de réinitialisation de mot de passe échoue, un ticket d'abus verrouille le compte, ou une suspension de service bloque l'accès aux sauvegardes. Les petits fournisseurs d'hébergement peuvent être particulièrement exposés si l'autorité commerciale et technique est concentrée dans la même petite équipe.

Les preuves publiques ne révèlent pas comment CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED gère la suspension, la récupération de compte, la suppression, l'examen des abus ou l'exportation d'urgence. Cette absence ne doit pas être comblée par des suppositions. Un acheteur devrait demander ce qui se passe si le client manque un paiement par accident, si un examen de fraude est déclenché, si une plainte pour hameçonnage est déposée contre un serveur compromis, ou si le titulaire du compte désigné est indisponible pendant un incident.

La réponse devrait indiquer si le client peut toujours récupérer les sauvegardes et si la suspension affecte le DNS, les annonces de route, l'accès à la console et le support.

Le bloc au nom d'EDIGI ajoute une autre question administrative. Si 203.145.46.0/23 apparaît dans la documentation du client en raison de l'enregistrement APNIC, mais que l'origine de route actuelle est AS150862, le client doit savoir quelle entité contrôle le statut commercial pour les adresses de ce bloc. Si un service est suspendu, qui a le pouvoir de restaurer la visibilité de la route? Si le client part, qui coordonne la renumérotation ou le nettoyage? S'il y a une plainte pour abus, qui la reçoit et qui peut la clore?

Ces questions ne sont pas des signes de méfiance. Elles font partie de la résilience. Un fournisseur qui peut expliquer les délais de grâce pour la facturation, l'escalade des abus, les contacts d'urgence, le transfert de propriétaire de compte et les droits d'exportation des données donne aux clients un moyen de se remettre des défaillances administratives. Un fournisseur qui traite ces détails comme des trivia d'arrière-boutique laisse les clients exposés à des pannes qui n'apparaissent jamais dans un collecteur de routes.

La posture la plus sûre pour le client est de documenter un chemin commercial d'urgence parallèlement au chemin technique. Le chemin technique dit qui peut restaurer les paquets, les serveurs et les sauvegardes. Le chemin commercial dit qui peut empêcher un problème administratif de bloquer la restauration. Les deux devraient être connus avant que le service ne devienne important.

Ce qui améliorerait les preuves

Les preuves deviendraient matériellement plus solides si l'entreprise ou une page produit orientée client reliait les faits de routage publics au service vendu. La mise à niveau la plus précieuse serait une carte de service simple: rôle de l'AS151872, rôle de 203.145.46.0/23, préfixes clients actifs, amonts, type d'emplacement de production, type d'emplacement de récupération, propriétaire du support, emplacement de sauvegarde et méthode d'exportation. Il ne serait pas nécessaire de publier les numéros d'armoires ou des détails de sécurité sensibles.

Il faudrait supprimer l'ambiguïté sur les enregistrements publics qui importent encore pour les clients.

Une deuxième mise à niveau serait des preuves de contrôle de route actuelles. Cela pourrait inclure un plan ROA publié ou fourni au client pour chaque préfixe actif, une explication pour le statut RPKI inconnu sur 157.66.198.0/23 et 2401:9920::/48, et une explication pour l'origine valide AS150862 sur le bloc 203.145.46.0/23 au nom d'EDIGI. Le but n'est pas une hygiène de routage cosmétique. Le but est de rendre les changements de route diagnostiquables pendant un incident.

Une troisième mise à niveau serait un profil d'interconnexion ou d'installation. Larequête API PeeringDB pour AS151872n'a retourné aucun profil de réseau public au cours de cette revue. L'absence de PeeringDB n'est pas un verdict négatif; de nombreux petits fournisseurs et réseaux clients n'ont pas de profil public. Mais un profil ou un document équivalent orienté client pourrait indiquer les points d'échange, les installations, la politique de trafic et les contacts de support. Cela aiderait les clients à distinguer le transit public de la résilience privée ou au niveau de l'installation.

Une quatrième mise à niveau serait une preuve de récupération. Un fournisseur peut affirmer que les sauvegardes existent, mais la preuve la plus solide est un rapport de restauration qui indique ce qui a été restauré, où cela a été restauré, combien de temps cela a pris, quelles dépendances ont échoué et ce que le client a dû faire. Pour un service hébergé avec des labels de préfixes mixtes, ce rapport devrait inclure les changements d'adresse, les mises à jour DNS, les changements de pare-feu et les mises à jour des listes d'autorisation.

Le client a besoin de savoir si la récupération est seulement une opération de serveur ou une opération complète de réseau et de données.

Enfin, l'empreinte web publique pourrait être plus claire. Le domaine edigi.vn étant indisponible via une réponse Cloudflare 521 au moment de la vérification n'est qu'un signal transitoire, mais il laisse les clients sans un endroit facile pour lire les conditions de service actuelles, le statut, les canaux de support ou les limites des produits. Une page de support et de statut publique stable ne prouverait pas la résilience par elle-même. Cela rendrait la dépendance plus facile à exploiter.

Niveau de preuve

Le niveau de preuve est Moyen-Faible. Il est plus fort qu'un simple enregistrement coquille vide car AS151872 est actuellement visible, a trois préfixes IPv4, quatre préfixes IPv6 et une accessibilité mondiale mesurable. Il a également plusieurs enregistrements d'origine de route valides. Le VNNIC et l'APNIC identifient le label de ressource EDIGI-VN et l'entreprise, et les collecteurs de routes publics montrent constamment AS151872 comme actif.

Le côté faible est tout aussi important. Les preuves publiques n'identifient pas les installations possédées, les baies louées, le nombre de baies, la conception de l'alimentation, le matériel de rechange, la couverture du support, les contrats clients, les pages produits, les objectifs de récupération ou les conditions d'exportation des données. Larequête API de PeeringDB pour AS151872n'a retourné aucun profil de réseau public, donc elle ne fournit pas d'installations, de points d'échange ou de politique de peering. L'ensemble de routes actif comprend des préfixes avec d'autres labels de registre. Le bloc 203.145.46.0/23 au nom d'EDIGI est actuellement originaire d'AS150862, pas d'AS151872. Le domaine web public lié à l'e-mail de contact ne servait pas un site public normal au moment de la vérification.

La conclusion est étroite: CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED a une empreinte de routage vietnamienne mesurable, mais la recherche publique ne prouve pas une plateforme cloud autonome. Un client devrait traiter le service comme une dépendance à vérifier par préfixe, baie, route, propriétaire du support, emplacement de sauvegarde et chemin de sortie avant d'y placer des charges de travail importantes.