CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED vend une capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de réparation

Résumé

• VNNIC's public internet-resource member list includes Cong ty TNHH Truyen thong va Cong nghe Cloud Data under EDIGI-VN, daté du 22 novembre 2023. APNIC'sRDAP record for AS151872identifies EDIGI-VN in Vietnam, with active status and a 16 November 2023 registration event, while RIPEstat'swhois viewgives the English name CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED and a Ho Chi Minh City address.
• AS151872 is publicly reachable. RIPEstat'sAS overviewshowed the AS announced on 12 July 2026, and therouting-status viewshowed 3 IPv4 prefixes, 4 IPv6 prefixes, 1,024 IPv4 addresses, four IPv6 /48s, visibility to all 325 RIS IPv4 peers and all 322 RIS IPv6 peers, and one observed neighbour.
• The current prefix set is operationally mixed. RIPEstat'sannounced-prefixes viewlisted 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 and 2401:9920::/48. APNIC records attach several of those prefixes to other Vietnamese labels, not directly to EDIGI-VN.
• The company-named IPv4 block is not the current AS151872 proof. APNIC's203.145.46.0/23 RDAP recordnames EDIGI-VN and CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, but RIPEstat'sprefix overviewshowed that block originated by AS150862, MAYTINHVPSTTT-VN - VPSTTT COMPUTER COMPANY LIMITED, and theRPKI check for AS150862was valid.
• The public evidence grade is Medium-Weak. The route origin is alive and measurable, but the public record does not prove owned data-centre space, rack count, spare hardware, multi-site service, transit diversity beyond the visible FPT path, customer migration rights or the support authority that would decide repair windows.

Le fait utile est AS151872, pas une carte cloud de marque

Le dossier public commence par une identité de ressource numérique petite mais concrète. La liste des membres de ressources Internet publiques de VNNIC inclut Cong ty TNHH Truyen thong va Cong nghe Cloud Data sous EDIGI-VN avec une entrée du 22 novembre 2023. L'enregistrement RDAP d'APNIC pourAS151872donne le handle AS151872, le nom EDIGI-VN, le pays VN et le statut actif. Le whois de RIPEstat pourAS151872développe cela en CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED et liste le 338/22 Thoai Ngoc Hau, quartier Phu Thanh, district Tan Phu, Hô-Chi-Minh-Ville, Vietnam.

Cela suffit à identifier l'entreprise derrière un enregistrement de système autonome routé. Cela ne suffit pas à identifier une plateforme cloud. Il n'y a pas de liste d'installations publique dans l'enregistrement AS, pas de nombre de baies, pas de salle de données nommée, pas de région de reprise publiée, pas de calendrier de maintenance et pas d'engagement de niveau de service visible par le client attaché au numéro. Pour un client achetant une capacité hébergée, la différence compte. Un AS enregistré peut décrire qui origines routes.

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

La couche de preuve suivante est le routage actuel. La vue d'ensemble AS de RIPEstat pourAS151872a marqué AS151872 comme annoncé le 12 juillet 2026. Sa vue de statut de routage pourAS151872a montré l'AS visible pour tous les 325 pairs IPv4 RIS et tous les 322 pairs IPv6 RIS à l'heure de requête du 11 juillet 2026 16:00 UTC. Il a également montré un voisin observé. C'est un signal plus fort qu'une liste d'entreprise obsolète. 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 devrait être évaluée comme une dépendance de capacité hébergée plutôt que comme un opérateur de centre de données prouvé. Un acheteur peut surveiller AS151872. Un acheteur peut tester les routes vers ses préfixes. Un acheteur peut demander l'autorisation d'origine de route, l'escalade de support et les conditions d'exportation.

Ce que l'acheteur ne peut pas faire, c'est transformer l'enregistrement AS public en une affirmation que 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é de rechange dans un second site.

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

Les données de préfixes annoncés de RIPEstat pourAS151872listaient 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 page BGP.Tools pourAS151872affichait la même forme générale: trois préfixes IPv4, quatre préfixes IPv6, un amont et un pair visibles pour ce service. La page IPIP.NET pourAS151872montrait également trois préfixes IPv4, quatre préfixes IPv6 et 1 024 adresses IPv4.

Les étiquettes attachées aux préfixes actifs rendent l'histoire opérationnelle plus compliquée. L'enregistrement RDAP d'APNIC pour157.66.198.0/23identifie DAZITT-VN et DAZI MARCOM CO., LTD, pas EDIGI-VN. L'enregistrement RDAP d'APNIC pour160.30.10.0/23identifie IPXO-VN et IPXO Technology Company Limited. APNIC pour2001:df3:e4c0::/48identifie GENLOGIN-VN,2001:df3:e8c0::/48identifie CLEMAX-VN,2401:9760::/48identifie THCLOUD-VN, et2401:9920::/48renvoie à nouveau DAZITT-VN.

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

Dans les marchés du cloud et de l'hébergement, ce modèle 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 un BGP hébergé, ou lorsque l'administration des ressources numériques et l'exploitation du service sont séparées. Le routage public ne peut pas décider quelle explication s'applique ici.

L'implication pour les achats est simple: ne traitez pas le nombre d'adresses routées comme une capacité de serveur possédée. Les 1 024 adresses IPv4 et quatre /48 IPv6 indiquent une surface réseau adressable, pas une capacité de calcul, de stockage ou de profondeur 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 nommé EDIGI est la plus grande mise en garde

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

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

Cela ne signifie pas que le bloc nommé 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 servi par un autre opérateur vietnamien, déplacé pour des raisons opérationnelles, utilisé sous un arrangement client, ou plus pertinent pour le produit hébergé d'un acheteur. Les preuves publiques ne peuvent pas décider cela. 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 pour 157.66.198.0/23 ou 160.30.10.0/24 sous AS151872. Si le client surveille seulement AS151872, il peut manquer le bloc labellisé EDIGI. S'il surveille seulement le bloc labellisé EDIGI, il peut manquer le service AS151872 actif. 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 client.

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

La preuve de voisin public pointe vers FPT. La vue des voisins ASN de RIPEstat pourAS151872a montré un voisin observé pour AS151872, AS18403. La vue d'ensemble AS de RIPEstat pourAS18403identifie AS18403 comme FPT-VN - FPT Telecom Company, et l'enregistrement whois pourAS18403donne FPT Telecom Company au Vietnam. BGP.Tools affiche également AS18403 comme l'amont et le pair visible pour AS151872.

C'est un fait opérationnel utile, mais il ne doit pas être étiré. 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 route. AS151872 peut avoir des arrangements internes qui ne sont pas exposés dans cette vue. Il peut également avoir une bordure publique très fine. 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 public visible commence par FPT, donc le fournisseur doit expliquer ce qui se passe lorsque ce chemin est dégradé ou retiré."

Les données de looking-glass pour157.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. C'est une atteignabilité mondiale normale. Ce n'est pas une preuve qu'AS151872 achète directement à chaque transporteur distant. La question 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'a de sens que si elle est séparée aux bonnes couches. Deux noms d'amonts n'aident pas s'ils entrent dans la même baie par le même routeur, dépendent de la même alimentation, partagent la même salle de rencontre de bâtiment, ou nécessitent la même file d'attente de support pour changer la politique de route. 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 mono-hébergé et si le client a une voie de sortie. Le risque n'est pas la singularité en soi.

Le risque est qu'un client croie avoir acheté la diversité alors que les preuves publiques ne montrent qu'un seul voisin visible.

RPKI est partagé entre valide et inconnu

La validation d'origine de route ajoute une autre couche de preuve mixte. 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. Il 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 vérifié. Pour de nombreux petits réseaux, ce statut est encore courant. Pour un client achetant une capacité hébergée critique, c'est encore une question significative. Si les amonts ou les pairs appliquent un filtrage de route strict, un statut inconnu peut changer le comportement de défaillance. Si une fuite de route ou un détournement se produit, les origines autorisées facilitent le filtrage et le diagnostic.

Les normes pertinentes ne certifient pas cette entreprise. Elles expliquent quoi 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 de route, d'anti-usurpation et de coordination. La page de certification des ressources d'APNICresource-certification pageexplique RPKI dans la région APNIC.

Le client devrait demander une déclaration d'authentification de route par préfixe. Quels préfixes face 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 encore être fiable si ces réponses sont claires. Un fournisseur avec des routes vivantes et une autorisation peu claire peut laisser les clients exposés lors de changements de politique en amont.

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

L'adresse de l'entreprise apparaît systématiquement dans les registres publics. Le whois RIPEstat liste le 338/22 Thoai Ngoc Hau, quartier Phu Thanh, district Tan Phu, Hô-Chi-Minh-Ville, Vietnam pour AS151872. L'enregistrement APNIC nommé EDIGI pour203.145.46.0/23donne la même adresse. Le miroir de code fiscal MaSoThuetax-code mirrorliste également le nom vietnamien de l'entreprise, le code fiscal 0318010419, le nom anglais et l'adresse 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 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, une adresse commerciale peuvent être séparés des baies qui hébergent les charges de travail des clients. Un petit fournisseur de cloud ou d'hébergement peut colocaliser des équipements dans une installation tierce, louer des nœuds nus d'un autre fournisseur, originer des préfixes clients ou partenaires, ou gérer des serveurs à distance. Aucun de ces arrangements n'est automatiquement mauvais. Chacun change le chemin de réparation.

Si un client achète un service local au Vietnam, il doit demander où se trouve chaque couche: production, stockage, sauvegarde, surveillance, enregistrements de support, enregistrements de facturation, accès de gestion et 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é chez un autre fournisseur, ou un mélange.

Le but n'est pas de demander 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 d'alimentation est planifié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 elle ne devrait pas être sollicitée pour faire plus qu'elle ne peut.

La capacité hébergée est une chaîne de pièces empruntées et exploitées

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 pièces il possède, lesquelles il loue, lesquelles sont contrôlées par le client et lesquelles dépendent des fournisseurs amonts. Il devient fragile lorsque ces limites sont cachées.

Les preuves d'espace d'adressage montrent déjà plusieurs étiquettes. 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 de domaine de l'entreprise ajoute également de l'incertitude: les contacts AS utilisent des adresses email edigi.vn, mais une requête directe vershttps://edigi.vna retourné une réponse Cloudflare 521 lors de cette revue, ce qui indique généralement que Cloudflare n'a pas pu atteindre le serveur d'origine. Cette observation ne prouve pas que les services clients sont en panne, mais elle affaiblit la confiance dans la documentation publique destinée aux clients.

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 des VPS ou un inventaire de serveurs nus d'un autre fournisseur? Origine-t-elle des préfixes clients pour des systèmes tiers? Fournit-elle des services réseau à d'autres labels de logiciels ou 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, atteignabilité amont, baies ou contrats. La capacité utilisable est ce qui peut réellement supporter les charges de travail des clients après avoir considéré l'alimentation, le refroidissement, le filtrage de route, le matériel défaillant, la réponse du support et les contraintes de stock de rechange. La capacité récupérable est ce qui peut être restauré dans les délais du client. L'AS public nous dit que la première couche existe. Il ne nous dit pas la deuxième ou la troisième.

Le travail de support est une dépendance physique

Dans un petit environnement d'hébergement, le travail 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 des sauvegardes ou coordonner avec l'amont, le service peut échouer même si la route reste visible. La visibilité de route actuelle d'AS151872 n'est donc que le début de la question de support.

Les registres publics donnent des contacts administratifs et techniques via APNIC et RIPEstat, mais ils ne publient pas de carte d'escalade client. Ils ne disent pas si le support après heures 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 AS151872 actifs et le bloc 203.145.46.0/23 nommé EDIGI maintenant routé par AS150862. Ils ne montrent pas si le statut de facturation peut suspendre un serveur avant que le client exporte ses données.

Pour les acheteurs, la bonne preuve est pratique. Ouvrez un ticket de support qui demande 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 d'installation. Demandez le temps maximum pour remplacer un matériel commun, restaurer une machine virtuelle et exporter une sauvegarde complète pendant un é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 bon marché n'a pas besoin de prétendre être un cloud d'entreprise multi-région. Le danger est une dépendance mal assortie. Si l'application du client, le service de revendeur ou le service de charge de travail publique dépend d'une réparation rapide, le client a besoin d'escalade écrite et de 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 composant par composant

L'affectation VN dans les registres APNIC et VNNIC soutient une identité de ressource numérique vietnamienne. Elle ne prouve pas où les données du client sont stockées. Pour la souveraineté des données et la localité, le client a besoin d'une réponse par composant. La production peut être à un endroit, le stockage à un autre, la sauvegarde à un autre, l'accès de support à un autre et les enregistrements de facturation à un autre. Une route qui a son origine au Vietnam ne décide pas à elle seule l'un de ces emplacements.

Le contexte juridique et réglementaire du Vietnam rend la distinction importante. Les clients traitant des informations personnelles, des données réglementées, des charges de travail du secteur public, des données de paiement ou des dossiers commerciaux sensibles doivent savoir quelles données peuvent circuler, 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 disponibilité du site web de l'entreprise ne répond à rien de tout cela.

Le décalage du bloc 203.145.46.0/23 labellisé EDIGI rend la question plus urgente car il 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 doit indiquer où se trouvent les disques de production, où se trouvent les sauvegardes, où se trouvent les données de journalisation et 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 doit également indiquer si ces emplacements sont des garanties contractuelles, une pratique opérationnelle normale ou à la discrétion du fournisseur. Un client qui a besoin d'un traitement des données uniquement au Vietnam ne devrait pas se fier à un code de pays dans un enregistrement AS.

La localité affecte également la récupération. Un fournisseur peut conserver des sauvegardes dans un autre site pour la résilience, mais le client doit savoir si ces sauvegardes sont utilisables lors d'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 une étiquette. 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 sans urgence. C'est particulièrement vrai lorsque les preuves publiques montrent des étiquettes de préfixes mixtes et une origine actuelle séparée pour le bloc nommé d'après 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 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é sous EDIGI-VN mais originaire d'AS150862, qui approuve les changements? Si le client utilise l'espace IPv6 /48 sous AS151872, les enregistrements d'origine de route, les règles de pare-feu et les listes d'autorisation partenaires sont-ils documentés?

L'exportation de données devrait être tout aussi concrète. Le client peut-il exporter des images de 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 l'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 des IP attribuées par le fournisseur, des sauvegardes non documentées et d'un support lent. Un petit fournisseur peut encore être un bon choix si le client peut partir proprement. La portabilité n'est pas un manque de loyauté. C'est la preuve de reprise après sinistre du client.

Qui ressent la panne

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 un 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 courriels renvoyés, des appels API bloqués, des sauvegardes échouées ou des listes d'autorisation d'adresses défaillantes.

Les chemins de défaillance sont superposés. Un problème de route publique peut retirer l'atteignabilité de tous les préfixes AS151872 actuels. Une panne de fibre locale ou d'amont peut dégrader l'atteignabilité via AS18403. Un problème d'alimentation de baie peut laisser BGP visible pendant que les serveurs sont hors ligne. Une panne de disque ou de pool de stockage peut rendre 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. Un décalage entre le nom du registre, l'origine de la route et le contrat client peut ralentir la première heure de diagnostic.

Le bloc 203.145.46.0/23 nommé EDIGI ajoute un risque en aval spécifique. Si des clients ou partenaires ont enregistré ce bloc comme "EDIGI" à cause des données APNIC, mais que l'origine de route actuelle est AS150862, les listes de surveillance et de contact 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 complètement le fournisseur. Elles sont une raison de cartographier le service avant de dépendre de lui. 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, ce qui arrive au bloc nommé EDIGI, et comment un client sort.

Comment vérifier avant de compter sur le 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 des adresses privées ou par un mélange. Comparez la réponse avec les enregistrements APNIC pourAS151872et203.145.46.0/23, le statut de routage RIPEstat pourAS151872, et la vue d'ensemble du préfixe RIPEstat pour203.145.46.0/23.

La deuxième étape de vérification est la topologie. Demandez le type d'installation de production, le type d'installation de reprise, le chemin de transit public, le chemin de connectivité privée s'il y en a, le chemin d'escalade amont et le processus d'avis de maintenance. Le fournisseur n'a pas besoin de divulguer des coordonnées de baie sensibles pour répondre à cela. Il peut indiquer si le client est mono-site, multi-site, mono-amont, double-amont, sauvegardé dans un autre emplacement ou dépendant d'un fournisseur de colocation tiers.

La troisième étape est la sécurité du routage. Demandez une déclaration ROA préfixe 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 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 d'une sauvegarde, déplacez-la vers un autre environnement, mettez à jour le DNS ou les listes d'autorisation partenaires, confirmez les journaux, vérifiez l'intégrité des données et enregistrez le temps écoulé. Incluez l'escalade de 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 proprement un grand déplacement d'urgence.

La limite 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. Elle n'a pas besoin de révéler des diagrammes internes sensibles. Elle devrait simplement connecter chaque bloc réseau face client à son étiquette de registre, son origine de route, son état d'autorisation de route, son chemin amont, son propriétaire de support et son impact 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 nommé EDIGI qui est actuellement en dehors de l'ensemble d'origine d'AS151872.

La matrice devrait répondre à une question de base 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. Ce peut être un client qui a fourni son propre espace d'adressage. Ce peut être un amont ou un autre opérateur vietnamien. Ce 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 permission 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 mondiale mais transporter 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. Si un client achète une 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 l'étiquette de registre, l'origine de route ou l'état RPKI change pendant le contrat.

Les preuves mixtes 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 nommé EDIGI a une autre origine actuelle. Ce n'est pas automatiquement un signe d'avertissement; cela peut être une délégation opérationnelle normale. Mais une délégation normale a encore 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 face client sont protégées par des filtres anti-abus du fournisseur, du géorepérage, 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 complètement accessible depuis les collecteurs de routes alors qu'une seule baie, commutateur, nœud de stockage ou circuit d'alimentation est le point réel de défaillance client. La table de routage n'expose pas si les serveurs sont dans des salles possédées, des armoires louées, de la colocation tierce, un inventaire de serveurs nus loués ou le parc virtualisé d'un autre fournisseur. Elle n'expose pas non plus si des pièces de rechange courantes sont conservées sur place.

Cela compte car les pannes d'hébergement commencent souvent par des contraintes physiques ordinaires. Un serveur peut perdre un disque. Un commutateur de tête de baie peut tomber en panne. Une unité de distribution d'alimentation peut se déclencher. Une fenêtre de maintenance UPS peut supprimer la redondance. Une installation peut nécessiter une planification de main à distance. Une pièce de remplacement peut être retardée. L'AS public peut rester annoncé pendant tout 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 registre public ne donne aucun nombre de baies, nom de salle de données, conception d'alimentation ou preuve de stock de matériel. La conclusion correcte 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 mono-baie ou multi-baie, 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 clients en même temps.

La frontière du support intersecte la frontière physique. Si l'entreprise loue de l'espace dans une autre installation, l'installation peut contrôler l'accès et la main à distance. Si elle loue des serveurs chez un autre fournisseur, cet autre fournisseur peut contrôler le remplacement matériel. Si elle utilise un amont pour BGP et une autre partie pour la colocation, une panne de route et une panne d'alimentation peuvent nécessiter des chemins d'escalade complètement 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 forme pratique: des exemples d'avis de maintenance, une description de l'alimentation redondante par niveau de service client, des 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 exigences grandioses d'entreprise. Ce sont les faits minimaux 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 réparation, mais l'état du compte appartient à la même liste. Un service hébergé peut être techniquement sain et toujours indisponible pour le client parce qu'une facture est contestée, qu'un administrateur a quitté l'entreprise, qu'un chemin de réinitialisation de mot de passe échoue, qu'un ticket d'abus verrouille le compte, ou qu'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 divulguent pas comment CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED gère la suspension, la récupération de compte, la suppression, la revue d'abus ou l'exportation d'urgence. Cette absence ne devrait pas être comblée par des hypothèses. 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 de phishing est déposée contre un serveur compromis, ou si le propriétaire du compte nommé 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 nommé EDIGI ajoute une autre question administrative. Si 203.145.46.0/23 apparaît dans la documentation client à cause de l'enregistrement APNIC, mais que l'origine de route actuelle est AS150862, le client a besoin de savoir quelle entité contrôle le statut commercial des adresses sur 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 d'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 périodes de grâce de facturation, l'escalade d'abus, les contacts d'urgence, le transfert de propriétaire de compte et les droits d'exportation de données donne aux clients un moyen de se remettre des fautes administratives. Un fournisseur qui traite ces détails comme des trivia de back-office 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 en parallèle du 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 soit important.

Ce qui améliorerait les preuves

Les preuves deviendraient matériellement plus solides si l'entreprise ou une page produit client connectait les faits de routage publics au service vendu. La mise à niveau la plus précieuse serait une carte de service simple: rôle d'AS151872, rôle de 203.145.46.0/23, préfixes clients actifs, amonts, type d'emplacement de production, type d'emplacement de reprise, propriétaire du support, emplacement de sauvegarde et méthode d'exportation. Elle n'aurait pas besoin de publier des numéros d'armoire ou des détails de sécurité sensibles. Elle aurait besoin de supprimer l'ambiguïté sur les registres publics qui comptent encore pour les clients.

Une deuxième mise à niveau serait une preuve de contrôle de route actuelle. 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 nommé EDIGI. L'objectif n'est pas une hygiène de routage cosmétique. L'objectif est de rendre les changements de route diagnostiquables lors d'un incident.

Une troisième mise à niveau serait un profil d'interconnexion ou d'installation. La requête API PeeringDB pourAS151872n'a retourné aucun profil réseau public lors 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 face 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 prétendre que des sauvegardes existent, mais la preuve la plus forte est un rapport de restauration qui indique ce qui a été restauré, où il 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 étiquettes 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 de listes d'autorisation.

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

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 endroit facile pour lire les conditions de service actuelles, le statut, les canaux de support ou les limites du produit. Une page de support et de statut publique stable ne prouverait pas la résilience en elle-même. Elle rendrait la dépendance plus facile à opérer.

Note de preuve

La note de preuve est Moyenne-Faible. Elle est plus forte qu'un simple enregistrement coquille car AS151872 est actuellement visible, a trois préfixes IPv4, quatre préfixes IPv6 et une atteignabilité mondiale mesurable. Il a également plusieurs enregistrements d'origine de route valides. VNNIC et APNIC identifient le label de ressource EDIGI-VN et l'entreprise, et les collecteurs de routes publics montrent systématiquement 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 d'alimentation, le matériel de rechange, la couverture de support, les contrats clients, les pages produit, les objectifs de récupération ou les conditions d'exportation de données. La requête API PeeringDB pourAS151872n'a retourné aucun profil réseau public, donc elle ne fournit pas d'installations, de points d'échange ou de politique de peering. L'ensemble de routes actif inclut des préfixes avec d'autres étiquettes de registre. Le bloc 203.145.46.0/23 nommé EDIGI est actuellement originaire d'AS150862, pas d'AS151872. Le domaine web public lié à l'email de contact ne servait pas de 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 de support, emplacement de sauvegarde et chemin de sortie avant d'y placer des charges de travail importantes.