Résumé

  • Vietnam Physical Server Company Limited a une identité claire en matière de ressources numériques:APNIC RDAP pour AS153404répertorie VNMCVLVNCLOUD-VN, Vietnam Physical Server Company Limited, une adresse à Phu Yen et des contacts maintenus par VNNIC.
  • Le propre ASN de l'entreprise ne constitue pas un réseau opérationnel visible dans les données de routage publiques consultées. L'aperçu AS153404 de RIPEstatindiquait« announced »: falsepour la fenêtre de requête du 12 juillet 2026, et l'état de routage RIPEstataffichait zéro préfixe IPv4, zéro préfixe IPv6 et zéro voisin observé.
  • Le bloc IPv4 attribué est toujours actif d'une autre manière.APNIC RDAP pour 160.191.176.0/23attribue le bloc à Vietnam Physical Server Company Limited, tandis que l'aperçu de préfixe RIPEstatle montrait annoncé par AS150820, LIENVPS TECHNOLOGY COMPANY LIMITED, le 12 juillet 2026.
  • Cette divergence soulève la principale question opérationnelle: la capacité visible par le client peut dépendre moins du propre ASN de l'entreprise que d'un accord d'hébergement, de location ou de routage avec LIENVPS et des réseaux en amont tels que FPT Telecom et Megacore, visibles dans les données de voisinage.
  • Le niveau de preuve publique estFaible. L'entreprise est réelle dans les registres fiscaux et de ressources numériques, et le /23 qui lui est attribué est visible sur Internet, mais les enregistrements ne prouvent pas l'existence d'un catalogue de services actif, d'un nombre de racks, d'un contrat d'installation, d'un stock de serveurs de rechange, d'une procédure d'escalade du support, d'un chemin de restauration des sauvegardes ou d'une capacité de reprise d'activité indépendante multi-site.

Le nom promet des serveurs physiques, mais la cartographie publique commence par les enregistrements

Vietnam Physical Server Company Limited a un nom évocateur. Il invite l'acheteur à imaginer des machines dédiées, des serveurs privés virtuels, un hébergement de type colocation, ou à tout le moins des charges de travail client exécutées sur du matériel situé au Vietnam. Le problème est que les preuves publiques ne commencent pas par une page produit soignée. Elles commencent par des registres, des vues de routage et des extraits d'annuaires d'entreprises.

Cela est important car la capacité hébergée n'est pas un nuage abstrait. Si un client loue un serveur virtuel, un serveur bare-metal, un nœud proxy, un compte de stockage ou un plan d'hébergement géré auprès d'un petit fournisseur d'infrastructure, il dépend en fin de compte d'une chaîne de faits physiques et commerciaux. Il doit y avoir un rack ou une étagère de serveur quelque part. Il doit y avoir de l'alimentation et du refroidissement. Il doit y avoir du transit, une autorisation de routage, une capacité de commutation et un espace d'adressage.

Il doit y avoir un chemin de support lorsqu'un disque, une carte réseau, un hôte, un port, une facture, un ticket d'abus ou une demande de migration échoue. Une entreprise peut détenir directement certaines de ces pièces et d'autres par l'intermédiaire d'un partenaire; le risque de résilience change selon la pièce concernée.

Pour Vietnam Physical Server Company Limited,APNIC RDAP pour AS153404constitue le premier point d'ancrage clair. Le nom de l'AS est VNMCVLVNCLOUD-VN, l'ASN est AS153404, le pays est le Vietnam, l'événement d'enregistrement date du 11 novembre 2024, et la description nomme Vietnam Physical Server Company Limited à Hoa Hoi Village, Xuan Canh Commune, Song Cau Town, province de Phu Yen. La requête web APNIC pour le même objet,AS153404 dans le service de requête APNIC, répète ces informations essentielles et indique VNNIC comme mainteneur du registre national.

Les annuaires d'entreprises correspondent globalement à cette identité.La page fiscale MaSoThue pour le code 4401113590nomme CÔNG TY TNHH MÁY CHỦ VẬT LÝ VIỆT NAM, liste le même code fiscal, indique une adresse d'exploitation à Phu Yen, donne une date d'activité au 18 octobre 2024, nomme TÔ THỊ BÍCH QUYÊN comme représentante, et classe l'activité principale dans le traitement de données, la location et les activités connexes.La page TraTenCongTynomme également l'entreprise, la même représentante, la même date et une adresse à Phu Yen. Les deux pages d'annuaire divergent sur le statut: MaSoThue affichait une mention de suspension temporaire lors de la consultation, tandis que TraTenCongTy indiquait un statut actif. Ce conflit constitue une limite probatoire, pas un verdict en soi.

Le point principal est plus restreint. Il existe suffisamment de preuves issues des registres pour considérer l'entreprise comme un sujet d'infrastructure vietnamien réel. Il n'y a pas assez de preuves de service public pour la considérer comme un fournisseur d'hébergement entièrement cartographié. L'article suit donc l'infrastructure visible: l'ASN, le bloc attribué, l'origine de la route, l'adresse professionnelle, et les informations manquantes qui sépareraient normalement un hébergeur opérationnel d'un détenteur d'adresse dormant ou dépendant d'un partenaire.

L'ASN de l'entreprise est présent mais invisible dans les collecteurs de routes

Le fait de routage le plus important est négatif.L'aperçu AS de RIPEstat pour AS153404identifiait le titulaire comme « VNMCVLVNCLOUD-VN - Vietnam Physical Server Company Limited » mais marquait l'ASN comme non annoncé dans la fenêtre de requête du 12 juillet 2026.L'état de routage RIPEstat pour AS153404n'indiquait aucune route vue pour la première fois ou pour la dernière fois, zéro préfixe IPv4, zéro /48 IPv6, zéro voisin observé et une visibilité de zéro pair collecteur de routes.Les préfixes annoncés RIPEstatont retourné une liste de préfixes vide pour la période du 28 juin au 12 juillet 2026, etl'état BGP RIPEstatn'a retourné aucun état de route.

Cela ne signifie pas que l'entreprise n'a pas d'activité commerciale. Cela signifie que son ASN n'était pas visible comme origine de route Internet dans les données de routage publiques consultées. Un ASN peut être enregistré avant le lancement d'un réseau. Il peut être conservé pour une utilisation future. Il peut être utilisé de manière privée, incohérente, ou via une politique de routage non visible par un ensemble particulier de collecteurs. Il peut aussi rester inactif tandis qu'un fournisseur apparenté originaire l'espace d'adressage. Le lecteur extérieur ne doit pas convertir un ASN enregistré en preuve de capacité active.

L'absence d'unprofil réseau PeeringDB pour AS153404renforce la même prudence. PeeringDB est auto-maintenu, donc l'absence n'est pas un constat d'échec. De nombreux petits réseaux ne publient jamais de profil. Mais PeeringDB serait normalement un endroit public pour voir les installations, les points d'échange, la politique, les contacts NOC, les niveaux de trafic et les préférences d'interconnexion. Sans cela, le dossier public offre moins de moyens de corroborer l'endroit où l'ASN opérerait physiquement.

La question opérationnelle devient: si AS153404 n'est pas annoncé, quel actif public transporte effectivement le trafic associé à Vietnam Physical Server Company Limited? La réponse est le bloc IPv4 attribué à l'entreprise, et ce bloc pointe vers une origine différente.

Le /23 attribué est actif, mais il est originaire de LIENVPS

APNIC RDAP pour 160.191.176.0/23attribue 160.191.176.0 à 160.191.177.255 à VNMCVLVNCLOUD-VN, Vietnam Physical Server Company Limited, à la même adresse Hoa Hoi Village, Xuan Canh Commune, Song Cau Town, Phu Yen. L'événement d'enregistrement est le 5 novembre 2024, quelques jours avant l'enregistrement d'AS153404. Les contacts administratif et technique sont la même paire que celle qui figure sur l'enregistrement AS153404.

Ce bloc n'est pas inactif dans le BGP public. L'aperçu de préfixe RIPEstat pour 160.191.176.0/23a montré le préfixe annoncé le 12 juillet 2026, mais l'ASN d'origine était AS150820, titulaire LIENVPS-VN - LIENVPS TECHNOLOGY COMPANY LIMITED. L'état de routage RIPEstat pour le préfixeindique une première vue le 8 novembre 2024, une dernière vue le 12 juillet 2026, 324 pairs RIS IPv4 sur 325 le voyant, et des objets de route dans APNIC, NTT Communications et RADB. Lesdonnées de looking-glass RIPEstat pour le préfixemontrent la même origine, AS150820, à travers les vues des collecteurs de routes échantillonnés.

RPKI souligne le point.La validation RPKI RIPEstat pour 160.191.176.0/23 avec l'origine AS150820a retourné valide. Le même préfixe vérifié contre l'ASN de l'entreprise,160.191.176.0/23 avec l'origine AS153404, a retourné invalid_asn parce que la ROA validante autorisait AS150820. En clair: le bloc est attribué à Vietnam Physical Server Company Limited, mais l'autorisation de route publique et l'origine observée pointent vers LIENVPS, pas vers le propre AS153404 de l'entreprise.

Ceci ne prouve pas un contrat spécifique entre Vietnam Physical Server Company Limited et LIENVPS. Cela prouve une frontière opérationnelle que les clients doivent comprendre avant de s'appuyer sur l'espace d'adressage. Si un client est servi depuis le bloc 160.191.176.0/23, la joignabilité du trafic dépend du routage d'AS150820, des fournisseurs en amont, du filtrage, de la maintenance des routes et de l'état de la gestion des abus. Si Vietnam Physical Server Company Limited contrôle les serveurs mais que LIENVPS contrôle l'origine de la route, une défaillance de part et d'autre peut affecter les clients.

Si LIENVPS héberge également les serveurs, alors la dépendance physique s'éloigne encore plus de l'entité désignée dans l'annuaire.

Le nom de l'entreprise et le bloc d'adresses attribué pointent donc dans des directions différentes. Le nom suggère une capacité de serveur physique directe. La table de routage suggère un détenteur d'adresse dont le bloc visible circule sur le réseau d'un autre opérateur. Cette distinction devrait être la première question de diligence dans toute vente.

LIENVPS n'est pas qu'un simple fournisseur en amont dans les preuves

Le lien avec LIENVPS est plus fort qu'une simple ligne de chemin.APNIC RDAP pour AS150820identifie AS150820 comme LIENVPS-VN, LIENVPS TECHNOLOGY COMPANY LIMITED. Il liste la même adresse Hoa Hoi Village, Xuan Canh Commune, Song Cau Town, province de Phu Yen qui apparaît dans les enregistrements de ressources numériques de Vietnam Physical Server Company Limited. Il nomme également Phan Thi Lien comme contact administratif et technique pour LIENVPS, tandis que l'enregistrement AS153404 de Vietnam Physical Server Company Limited nomme Phan Thi Lien comme contact technique et To Thi Bich Quyen comme contact administratif.

Ces recoupements sont importants mais ne doivent pas être exagérés. Une géographie partagée et des noms de contact partagés peuvent refléter des entreprises liées, des consultants partagés, des accords de services de registre, ou un groupe d'entreprises utilisant une adresse locale commune. Ils ne prouvent pas, sans contrat ou document d'entreprise, une propriété commune, un contrôle commun, une revente de service, ou une responsabilité de support client. L'article traite LIENVPS comme une dépendance opérationnelle visible dans les preuves de routage, et non comme une relation d'entreprise confirmée.

La surface de route d'AS150820 est matériellement plus grande que celle d'AS153404. L'aperçu AS de RIPEstat pour AS150820a montré LIENVPS annoncé le 12 juillet 2026. L'état de routage RIPEstat pour AS150820a montré 13 préfixes IPv4, 6 656 adresses IPv4, zéro préfixe IPv6 et deux voisins observés.Les préfixes annoncés RIPEstat pour AS150820incluaient 160.191.176.0/23 ainsi que d'autres blocs /23 tels que 157.15.38.0/23, 160.22.174.0/23, 160.250.46.0/23, 160.22.172.0/23, 36.50.174.0/23, 160.191.240.0/23, 160.187.120.0/23, 203.175.96.0/23, 161.248.208.0/23, 160.30.190.0/23, 165.99.14.0/23 et 157.66.252.0/23.

Les données de voisinage indiquent la forme probable des connexions en amont.Les voisins d'ASN RIPEstat pour AS150820ont montré deux voisins du côté gauche le 12 juillet 2026: AS140810 et AS18403.L'aperçu AS140810 de RIPEstatidentifie AS140810 comme MEGACORE-AS-VN - Megacore Technology Company Limited.L'aperçu AS18403 de RIPEstatidentifie AS18403 comme FPT-VN - FPT Telecom Company. Ceci est un contexte utile pour le transit et la joignabilité domestique, mais cela reste une observation de routage plutôt qu'un SLA client.

Les preuves de réseau public pour Vietnam Physical Server Company Limited sont donc asymétriques. Son propre ASN est présent mais invisible. Son bloc attribué est actif, originaire de manière valide par LIENVPS, et globalement visible. Cela suffit à rendre l'entreprise pertinente pour l'économie de l'hébergement et le risque de localisation. Cela ne suffit pas à prouver que Vietnam Physical Server Company Limited exploite elle-même des racks, des commutateurs ou des équipes de support.

La dépendance physique pourrait se situer derrière l'origine de route de quelqu'un d'autre

La dépendance physique centrale de l'attribution n'est pas théorique. Un produit serveur vendu sous un petit nom d'hébergement vietnamien devrait se trouver dans l'un de plusieurs arrangements. L'entreprise pourrait posséder des serveurs dans un rack loué. Elle pourrait louer des serveurs physiques auprès d'un autre hébergeur local. Elle pourrait revendre de la capacité VPS. Elle pourrait détenir l'espace d'adressage et demander à LIENVPS de l'originer. Elle pourrait préparer un service qui n'est pas encore commercialement visible.

Elle pourrait aussi être une coquille corporative dont la présence publique Internet est le bloc d'adresses plutôt qu'une marque grand public.

Chaque arrangement échoue différemment. Si Vietnam Physical Server Company Limited possède les serveurs mais que LIENVPS origine la route, un changement de politique de routage, une défaillance de session en amont, un changement de ROA, une facture de service de route impayée, une suspension pour abus, ou une erreur de filtre de route chez AS150820 peut déconnecter les clients même si les serveurs physiques sont en bonne santé. Si LIENVPS fournit également les racks ou les hôtes virtuels, alors l'alimentation, le stock de disques, la santé de l'hyperviseur et l'escalade du support peuvent appartenir principalement à LIENVPS.

Si une troisième installation se trouve sous les deux entreprises, le point unique réel peut être un bail de centre de données, une alimentation électrique, une interconnexion, une file d'attente de maintenance ou une fenêtre de maintenance qu'aucun enregistrement de registre public ne nomme.

Les données de routage ne donnent qu'une petite partie de la carte des dépendances. Elles nous disent que 160.191.176.0/23 était visible via AS150820 et vu par la plupart des pairs IPv4 RIPE RIS le 12 juillet 2026. Elles nous disent que la route était valide RPKI pour AS150820. Elles nous disent qu'AS150820 avait deux voisins observés dans RIPEstat. Elles ne nous disent pas si le trafic entre dans une installation à Hanoï, Hô Chi Minh-Ville, Da Nang, Phu Yen, ou internationale. Elles ne nous disent pas si les charges de travail des clients se trouvent au Vietnam ou si seule l'identité du détenteur d'adresse est vietnamienne.

Elles ne nous disent pas si le matériel est possédé, loué, ou virtualisé sur un cluster partagé.

Pour un client, la distinction est pratique. Une charge de travail peut être « locale au Vietnam » dans la conversation commerciale parce que l'entreprise est vietnamienne ou parce que l'espace d'adressage est enregistré au Vietnam. Ce n'est pas la même chose que de savoir où se trouvent réellement la machine, la sauvegarde, le panneau de gestion, le bureau de facturation et le technicien d'urgence. La souveraineté des données et la localisation concernent l'ensemble du chemin d'exploitation, pas seulement le code pays ISO dans un registre.

Les questions ouvertes sont concrètes. Quelle installation héberge les serveurs? Quelle entité juridique signe le contrat? Quel ASN originaire le préfixe du client? Qui contrôle la ROA? Quels fournisseurs en amont transportent le trafic normal? Quelle équipe réseau gère les incidents de routage? Quel personnel peut remplacer un disque ou un serveur défaillant? Où les sauvegardes sont-elles stockées? Que se passe-t-il si LIENVPS change de politique de routage ou cesse d'originer le bloc? Le dossier public soulève ces questions mais n'y répond pas.

La zone de service est le Vietnam, mais la localisation ne peut être déduite d'une adresse postale

L'attribution de l'annuaire donne la région comme VN, et les enregistrements publics soutiennent une lecture centrée sur le Vietnam. Les enregistrements APNIC de l'ASN et du bloc d'adresses listent le pays VN. Les pages MaSoThue et TraTenCongTy listent des adresses vietnamiennes et un code fiscal vietnamien. LIENVPS et les voisins en amont visibles via RIPEstat sont des sujets de réseau vietnamiens ou des réseaux orientés vers le Vietnam. Un client cherchant une capacité hébergée au Vietnam traiterait naturellement cela comme une piste de marché local.

Mais la localisation n'est pas un simple indicateur. Une entreprise peut être enregistrée au Vietnam tandis que l'équipement se trouve dans une autre province, dans la cage d'un autre opérateur, ou dans un autre pays. Un bloc IPv4 vietnamien peut être routé via un ASN vietnamien tandis que certains services sont hébergés ailleurs. Un serveur peut se trouver au Vietnam tandis que les sauvegardes, les outils de support, les systèmes d'identité, les enregistrements de facturation ou la surveillance sont traités en dehors du pays. Les preuves publiques pour Vietnam Physical Server Company Limited ne tranchent aucune de ces couches.

Le nom de l'entreprise « Physical Server » augmente le besoin de preuves. Un client de serveur physique n'achète pas simplement une région logique. L'acheteur peut s'attendre à un contrôle sur la localisation du matériel, l'accès d'audit, les engagements de maintenance à distance, le traitement de la destruction des disques, le chemin d'interconnexion et le remplacement en cas de panne.

Si ces engagements sont importants, l'acheteur devrait demander une installation nommée, une déclaration de propriété du rack ou du serveur, un bon de commande qui identifie l'entité opératrice, et un calendrier de placement des données pour les données primaires, les sauvegardes et les journaux.

La question de la souveraineté des données est particulièrement aiguë parce que l'origine de route la plus visible est LIENVPS. Si le bloc attribué est utilisé pour les services clients, le client a besoin de savoir si Vietnam Physical Server Company Limited est l'opérateur de service, le détenteur d'adresse, le nom commercial, ou une partie dépendante de LIENVPS. La réponse affecte la responsabilité contractuelle. Si la route est retirée, s'agit-il d'un incident Vietnam Physical Server Company Limited ou d'un incident AS150820? Si la gestion des abus bloque une adresse, qui communique avec le client?

Si un audit gouvernemental ou d'entreprise demande où les données se trouvaient pendant une période, quel opérateur peut répondre?

Rien de tout cela ne signifie que les clients devraient éviter automatiquement l'entreprise. Cela signifie que les clients ne devraient pas assimiler une adresse vietnamienne, un code fiscal vietnamien et un enregistrement de ressource vietnamien à une garantie de localisation complète. La revendication utile que les preuves publiques peuvent soutenir est plus modeste: l'entité possède des ressources numériques vietnamiennes et un bloc IPv4 attribué vietnamien qui était routé via un opérateur vietnamien à la date vérifiée.

Les preuves du statut de l'entreprise sont mitigées et devraient réduire la confiance

Les preuves des annuaires d'entreprises sont utiles ici car une entreprise sans site de service visible a besoin d'un certain contexte corporatif public. Elles sont également imparfaites. La page MaSoThue pour le code fiscal affichait un statut de suspension temporaire lors de la consultation, tandis que TraTenCongTy affichait un statut actif. Les deux pages s'accordent sur le nom de l'entreprise, le représentant, l'adresse et la date d'activité. Cette combinaison devrait réduire la confiance mais pas effacer l'entité de la carte de l'infrastructure.

Il y a plusieurs raisons à la prudence. Premièrement, les annuaires d'entreprises non officiels peuvent se mettre à jour à des vitesses différentes. Deuxièmement, la géographie administrative vietnamienne a changé dans certains enregistrements publics, ce qui peut créer des variantes d'adresse qui semblent contradictoires sans changer l'emplacement sous-jacent. Troisièmement, le statut fiscal et le statut réseau ne bougent pas toujours ensemble.

Une entreprise peut conserver des ressources numériques pendant que le statut d'entreprise change; un bloc routé peut rester actif via un autre opérateur même si le détenteur d'adresse nommé ne vend pas activement de service; et un service peut être actif tandis qu'une page d'annuaire est en retard.

Pour les lecteurs, la leçon pratique n'est pas de choisir une page d'annuaire et d'ignorer l'autre. La leçon pratique est d'exiger une preuve opérationnelle fraîche. Avant qu'un client place des charges de travail de production, l'entreprise devrait être en mesure de montrer une partie contractante actuelle, une entité de facturation, un canal de support, des conditions de service, une carte réseau pour le produit acheté et la preuve que la capacité annoncée est effectivement disponible. Si le statut actuel de l'entreprise n'est pas clair, l'acheteur ne devrait pas se fier à une entrée d'annuaire fiscal comme garantie.

Les contacts APNIC ajoutent un autre indice sans trancher la question. AS153404 utilise [email protected] et [email protected] dans les vCards des contacts administratif et technique. Des vérifications DNS locales n'ont trouvé aucun enregistrement A ou AAAA pour mcvlvn.shop, tandis que les enregistrements MX pointaient vers Zoho mail et les NS vers des serveurs de noms hébergés par Namecheap. Cela signifie que le domaine peut supporter le contact par courriel même s'il n'exposait pas de site web public au nom d'hôte vérifié. Un domaine de contact sans site web n'est pas inhabituel.

Dans ce cas, cela s'ajoute au schéma: il existe une empreinte de registre joignable, mais pas de surface de service client visible.

L'empreinte publique limitée est donc un risque opérationnel matériel. Lorsqu'un fournisseur a des pages produit claires, un client peut tester les revendications concernant les plans VPS, les serveurs dédiés, les sauvegardes, la migration et la disponibilité. Ici, le dossier public offre peu de langage produit direct. L'acheteur doit obtenir ces détails en privé et les tester avant de s'appuyer sur la capacité.

Les chemins de défaillance commencent par l'origine de la route et continuent jusqu'au rack

Le principal chemin de défaillance est une défaillance de l'origine de la route ou du contrat du fournisseur, suivie des défaillances ordinaires de rack et de support. Le risque lié à l'origine de la route est visible parce que le bloc attribué est observé via AS150820 plutôt qu'AS153404. Si AS150820 retire 160.191.176.0/23, configure mal une route, perd une session en amont, change les filtres de route, rend un objet IRR incohérent, ou change l'état de la ROA, les clients utilisant ce bloc peuvent perdre la joignabilité.

Le client peut ne pas savoir s'il doit appeler Vietnam Physical Server Company Limited, LIENVPS, ou un opérateur d'installation à moins que cette responsabilité ne soit explicitement définie.

L'état RPKI est un détail utile. Le préfixe est valide pour AS150820. C'est bien pour la route qui existe réellement. Mais le même préfixe est invalide pour AS153404, ce qui signifie que Vietnam Physical Server Company Limited ne pourrait pas simplement originaire le /23 depuis son propre ASN sans modifier l'autorisation de route. Si un plan de migration suppose « nous pouvons déplacer le préfixe vers notre ASN pendant un incident », ce plan doit inclure les changements de ROA, l'acceptation en amont, les mises à jour d'objets de route, le temps de propagation et les effets sur les DNS ou le contrôle d'accès des clients.

Ce n'est pas un interrupteur que l'on peut actionner en toute sécurité sans préparation.

Le chemin en amont importe également. Les voisins d'AS150820 dans RIPEstat pointent vers FPT Telecom et Megacore. Un client devrait demander s'il s'agit de fournisseurs de transit, de pairs, de voisins visibles du côté gauche des collecteurs de routes, ou d'une partie d'un arrangement plus large. Il devrait demander si le trafic du client a plus d'un chemin fonctionnel sous charge et si les deux chemins survivent à une panne d'installation. La visibilité BGP publique peut montrer qu'une route existe; elle ne peut pas prouver une redondance utilisable à l'intérieur du fournisseur.

Derrière le routage se trouve le rack. Si Vietnam Physical Server Company Limited vend ou supporte une capacité de serveur physique, un client est exposé aux pannes de disque, de carte mère, d'alimentation, de ventilateur, de carte réseau, de port de commutation et d'alimentation électrique. Si le service est VPS, un client est exposé à la défaillance de l'hôte, à la contention de stockage, au surdimensionnement, à la maintenance de l'hyperviseur, à la qualité des snapshots et aux retards de migration à froid.

Si le service est une capacité de proxy ou de location d'adresse, un client est exposé aux rapports d'abus, à la réputation du sous-réseau, au retrait de route et à la réattribution d'adresse. Le dossier public n'identifie pas lequel de ces types de service est effectivement en vente, donc le client doit cartographier le produit exact.

La facturation et le support sont également des dépendances d'infrastructure. Un serveur peut être en bonne santé et routé pendant qu'un compte est suspendu, qu'un ticket de support stagne, qu'un litige de facturation bloque la migration, ou qu'un ticket d'abus coupe l'accès au bloc d'adresses. Les petits fournisseurs dépendent souvent d'un petit nombre de personnes qui comprennent l'environnement de routage et de rack réel. Si ces personnes sont indisponibles pendant un congé, une inondation, un incident électrique ou une panne en amont, le temps de réparation peut s'allonger même lorsque la panne est techniquement simple.

La capacité installée et la capacité utilisable ne sont pas la même chose

Le /23 attribué contient 512 adresses IPv4. Cela ne signifie pas 512 serveurs utiles, 512 nœuds clients, 512 IP propres, ou 512 unités de capacité de réserve. Le nombre d'adresses n'est pas le nombre de serveurs. Un fournisseur d'hébergement peut allouer de nombreuses adresses à quelques hôtes à haute densité, des pools de proxy, des services de test, des interfaces de gestion, ou des schémas NAT clients. Il peut également conserver la majeure partie d'un bloc inutilisée. Les données de routage publiques ne peuvent pas distinguer la capacité installée de la capacité utilisable.

La capacité installée est ce qui peut être vu ou inféré: l'enregistrement de l'ASN, l'attribution du /23, la route active via AS150820, l'autorisation RPKI et la classification de la ligne d'activité. La capacité utilisable est ce qui reste après une panne réelle. Si un hôte meurt, combien de machines de rechange sont prêtes? Si un chemin de transit se congestionne, combien de capacité propre en amont reste-t-il? Si un bloc d'adresses est signalé par un tiers, le fournisseur peut-il déplacer les clients vers un espace propre?

Si une personne de support est indisponible, qui d'autre peut changer le BGP, remplacer un disque ou débloquer le panneau de contrôle d'un client?

Les preuves publiques ne soutiennent que le côté installé. Elles montrent une petite ressource d'adresse et une route active. Elles ne montrent pas l'inventaire des racks, la densité des hôtes virtuels, la capacité CPU, la réplication de stockage, les pièces de rechange, la rétention des sauvegardes, le nombre de clients, ou un engagement de niveau de service publié. Un acheteur ne devrait pas traiter le /23 visible comme la preuve que le fournisseur peut absorber une panne de rack, une augmentation de client, un incident en amont ou un événement d'abus.

Cette distinction est centrale pour l'économie de l'hébergement. Les petits fournisseurs rivalisent souvent sur le prix, la disponibilité locale, le support personnalisé rapide ou des chemins d'achat plus faciles. Ces forces peuvent être réelles. Elles sont également liées au risque de concentration. Si la même personne gère les ventes, les changements de route et le support d'urgence, la réponse peut être excellente un jour normal et fragile lors de défaillances simultanées. Si la même installation détient les copies de production et de sauvegarde, la sauvegarde existe mais la récupération ne survit pas à une panne d'installation.

Si le même fournisseur en amont transporte tout le trafic, la route est valide mais pas diversifiée.

Pour Vietnam Physical Server Company Limited, la carte publique ne prouve aucun de ces risques de concentration, mais elle ne les réfute pas non plus. La posture correcte est de traiter chaque revendication de redondance comme non vérifiée jusqu'à ce qu'elle soit liée à des installations, des routes, des tests de récupération et des conditions de service nommés.

Ce que les clients devraient demander avant de compter sur cette capacité

La première question est de savoir si Vietnam Physical Server Company Limited vend actuellement des services et sous quel statut juridique. L'acheteur devrait demander l'entité contractante actuelle, les détails fiscaux, les conditions de service et les contacts de support. Il devrait réconcilier la différence de statut entre MaSoThue et TraTenCongTy plutôt que de supposer que la réponse la plus pratique est correcte.

La deuxième question est de savoir où la charge de travail sera exécutée. La réponse devrait identifier le pays, la ville, le type d'installation et la frontière de l'opérateur. « Vietnam » est trop large. « Adresse à Phu Yen » n'est pas suffisant. « 160.191.176.0/23 » n'est pas non plus suffisant, car un bloc d'adresses ne prouve pas l'emplacement du matériel. L'acheteur devrait demander qui possède ou loue le rack, qui contrôle l'accès physique, qui remplace les composants défaillants et quelles heures de support s'appliquent aux pannes matérielles.

La troisième question est de savoir comment fonctionne la route. Si le service utilise 160.191.176.0/23, l'acheteur devrait demander pourquoi l'origine de la route est AS150820, si LIENVPS est l'opérateur réseau, et si Vietnam Physical Server Company Limited peut fonctionner indépendamment si AS150820 change de politique. L'acheteur devrait demander qui contrôle la ROA, les objets IRR, les tickets en amont et les filtres de route. Il devrait demander si AS153404 est destiné à un usage futur et ce qui serait nécessaire pour y déplacer une route client.

La quatrième question est de savoir ce que signifie réellement la récupération. Si un serveur tombe en panne, la solution est-elle une machine de rechange, un remplacement de disque, une restauration d'image, une reconstruction manuelle, un crédit SLA, ou un ticket au mieux? Si la route est retirée, y a-t-il une origine de secours? Si le portail de facturation ou de support du fournisseur est indisponible, le client peut-il toujours obtenir un accès console ou des sauvegardes? Si le client souhaite partir, peut-il exporter une image disque, une base de données, un fichier de zone et des journaux sans attendre un support manuel?

La cinquième question est le placement des données. Le client devrait identifier où les données primaires, les snapshots, les sauvegardes, la surveillance, les enregistrements de support et de facturation sont stockés. Si la charge de travail est réglementée, le client devrait demander si les données quittent le Vietnam et si le fournisseur peut documenter cette réponse. Si le fournisseur utilise LIENVPS ou un autre opérateur sous le capot, l'acheteur devrait savoir si cet opérateur peut accéder aux données du client ou seulement acheminer des paquets.

La dernière question est la surveillance. Un client devrait surveiller les IP achetées, l'ASN d'origine, l'état RPKI et la joignabilité de l'application depuis l'extérieur du fournisseur. Il peut consulter l'aperçu de préfixe RIPEstat, l'état de routage RIPEstat, lavalidation RPKI RIPEstat, l'état AS150820 de RIPEstatet lesrecherches PeeringDBcomme vérifications externes. Ces vérifications ne remplacent pas un contrat, mais elles réduisent les surprises.

Les signaux non officiels doivent être traités comme des signaux, pas des preuves

La piste de recherche publique comprend des listes d'annuaires d'entreprises, des extraits de recherche, des vérifications DNS et des agrégateurs BGP. Ces signaux aident à formuler des questions, mais ils ne peuvent pas prouver la qualité du service client. Une page d'annuaire fiscal peut être périmée. Un résultat de recherche peut être partiel. Un domaine DNS peut supporter le courrier électronique sans héberger de site web. Un agrégateur BGP peut avoir du retard ou résumer l'état de la route différemment d'un autre collecteur. Une route peut être globalement visible alors que l'application du client est en panne.

Le signal non officiel le plus pertinent est le conflit des annuaires d'entreprises. MaSoThue indiquant une suspension temporaire et TraTenCongTy montrant un statut actif suggèrent que le dossier d'entreprise nécessite une confirmation directe. Le signal ne peut pas prouver si l'entreprise sert des clients le 12 juillet 2026. Les preuves qui trancheraient la question comprendraient un extrait de registre officiel actuel, un bon de commande de service signé, des conditions de service client actuelles, un portail de service joignable, et une confirmation de l'entreprise ou de son opérateur en amont.

Le signal DNS est similaire. Les contacts APNIC utilisent mcvlvn.shop. Des vérifications DNS locales ont trouvé des enregistrements de courrier et de serveurs de noms mais pas d'enregistrement A ou AAAA de site web. Cela suggère que le domaine est suffisamment configuré pour le contact par courriel mais pas comme une vitrine publique. Cela ne prouve pas que l'entreprise manque de clients; certains fournisseurs d'infrastructure vendent par des canaux directs, des applications de messagerie ou des réseaux de partenaires.

Cela élève cependant la charge de la preuve pour tout acheteur qui s'attend à une plateforme d'hébergement normale avec des plans publics, une documentation et des pages de statut.

Le signal de routage est plus fort car il provient de données BGP et RPKI publiques. Pourtant, il prouve la joignabilité pour le préfixe, pas la fiabilité du service. La route ne dit pas ce qu'il y a à l'intérieur du bloc. Elle n'identifie pas les serveurs des clients. Elle ne montre pas si les adresses sont utilisées pour l'hébergement web, VPS, VPN, proxy, test, espace de stationnement, ou une autre activité. Elle ne prouve pas non plus qui touche le matériel lorsqu'une panne se produit.

La bonne posture analytique est donc modeste. Vietnam Physical Server Company Limited a une empreinte d'infrastructure publique, mais la majeure partie de la surface opérationnelle est cachée. L'entreprise devrait être traitée comme un sujet de capacité hébergée à preuve faible jusqu'à ce qu'une preuve actuelle de service, d'installation et de support apparaisse.

La surveillance devrait suivre la dépendance, pas seulement le nom de l'entreprise

Si un client utilise déjà un service lié à Vietnam Physical Server Company Limited, la surveillance doit suivre la partie du système qui est réellement visible. Surveiller uniquement AS153404 manquerait la condition de route publique actuelle, car AS153404 n'était pas l'origine visible dans les données vérifiées. La liste de surveillance externe la plus utile commence par 160.191.176.0/23, AS150820, la ROA qui autorise AS150820, et les points de terminaison d'application que le client exploite réellement.

Une surveillance de base de la route doit répondre à quatre questions. 160.191.176.0/23 est-il toujours annoncé? AS150820 est-il toujours l'origine? L'état RPKI a-t-il changé de valide? Les voisins visibles d'AS150820 ont-ils changé d'une manière qui suggère un incident en amont ou de politique de routage? RIPEstat peut répondre à une grande partie de cela à partir de collecteurs publics via l'aperçu de préfixe, l'état de routage du préfixe, lavalidation RPKIet lavue des voisins AS150820. Un client ne devrait pas traiter un seul indicateur vert comme preuve que le service est sain, mais un changement soudain dans l'un de ces champs est une raison de contacter le fournisseur.

La surveillance applicative nécessite une couche séparée. Un préfixe peut être visible tandis qu'un hôte VPS est surchargé, qu'une baie de stockage est dégradée, qu'un pare-feu bloque le trafic client, ou qu'une action de facturation limite le service. Le client doit surveiller le comportement HTTP, SSH, VPN, courrier, base de données et DNS depuis plusieurs réseaux, y compris au moins un emplacement au Vietnam et un à l'extérieur du Vietnam si la joignabilité transfrontalière est importante.

Les tests externes doivent être possédés par le client ou par un moniteur indépendant, pas seulement par le tableau de bord du fournisseur d'hébergement.

La surveillance de la récupération est la pièce la plus souvent omise. Le client doit périodiquement restaurer une sauvegarde vers un hôte séparé, exporter la configuration DNS et du compte, tester l'accès console, et vérifier que les contacts d'urgence fonctionnent en dehors du compte hébergé. Si le serveur principal, la boîte de réception des tickets et les avis de facturation se trouvent tous dans le même environnement de fournisseur, un simple verrouillage de compte peut devenir une panne technique.

Cela est particulièrement pertinent pour un fournisseur à faible empreinte car le dossier public ne montre pas de portails redondants, de pages de statut publiées ou de chemins d'escalade formels.

Le plan de surveillance doit également préserver les preuves pour d'éventuels litiges futurs. Conservez les horodatages des changements de route, les captures d'écran ou les journaux des échecs de vérification d'application, les factures, les tickets de support et les réponses du fournisseur. Si un incident d'origine de route se produit, le client devra distinguer trois possibilités: la route a disparu globalement, la route est restée visible mais l'application a échoué, ou la route est restée valide mais les performances se sont dégradées via un fournisseur en amont. Ce sont des incidents différents avec des remèdes différents.

Le test final est la portabilité. Un client doit être capable de déplacer le service sans attendre une explication parfaite de l'incident. Cela signifie conserver les exportations de données, les images, les secrets, l'accès au domaine et la documentation en dehors du fournisseur. Cela signifie également éviter les dépendances strictes au bloc 160.191.176.0/23 à moins que le client n'ait un plan de portabilité écrit. L'espace d'adressage est collant: les pare-feu, les listes d'autorisation, la réputation de courrier, les bases de données de géolocalisation et le DNS du client rendent un bloc routé difficile à changer rapidement.

Dans un environnement à preuve faible, la portabilité n'est pas du pessimisme. C'est le seul moyen de rendre une petite dépendance de capacité hébergée surviable.

Niveau de preuve: Faible

Vietnam Physical Server Company Limited obtient un niveau de preuve de réseau public Faible. Les preuves positives sont réelles: les enregistrements APNIC/VNNIC identifient AS153404 et 160.191.176.0/23 avec le nom de l'entreprise; les pages d'annuaires d'entreprises vietnamiennes identifient l'entreprise, le code fiscal, le représentant, l'adresse et la ligne d'activité de traitement de données; le /23 attribué est globalement visible; et la route est valide RPKI lorsqu'elle est originaire d'AS150820.

Les preuves limitantes sont décisives. L'AS153404 lui-même n'était pas annoncé dans les données RIPEstat vérifiées. Il n'avait aucun préfixe visible, aucun voisin visible et aucun état BGP visible. Le /23 attribué n'est pas originaire de l'ASN de l'entreprise; il est originaire de LIENVPS. PeeringDB n'a retourné aucun profil réseau pour AS153404 ou AS150820.

Les enregistrements publics ne montrent pas de catalogue de services client, de conditions actuelles, de centre de données nommé, de nombre de racks, d'inventaire de serveurs, de conception de sauvegarde, de rotation de support, de processus DDoS ou d'abus, de procédure de migration, ou de plan de reprise d'activité multi-site. Le statut des annuaires d'entreprises est également contradictoire entre une ligne de suspension temporaire et une ligne de statut actif.

Ce niveau n'est pas une affirmation que l'entreprise est inactive ou dangereuse. C'est une limite sur ce qu'un lecteur peut savoir à partir des preuves publiques. Un acheteur peut voir que Vietnam Physical Server Company Limited a une empreinte de ressources numériques Internet attribuée et que son /23 était routé via LIENVPS le 12 juillet 2026. Un acheteur ne peut pas voir assez pour faire confiance aux revendications de résilience sans vérification directe.

La conclusion la plus spécifique est le point du titre. Vietnam Physical Server Company Limited peut vendre ou supporter une capacité hébergée, mais cette capacité dépend toujours de racks physiques, de transit, d'autorisation de route, de contrats en amont, d'alimentation, d'inventaire matériel, de main-d'œuvre de support, de continuité de facturation et d'options de migration. La route visible n'est pas l'ASN de l'entreprise; le dossier commercial visible est mince; et le chemin de récupération reste principalement privé.

Tout client de production devrait traiter le service comme un candidat à la diligence, et non comme une plateforme redondante prouvée, jusqu'à ce que l'entreprise puisse montrer où se trouvent les serveurs, qui achemine les adresses, qui répare les pannes et comment les clients peuvent partir proprement lorsqu'ils en ont besoin.