Le propre AS de VPS PA Company Limited s'est tu alors que son `/23` est resté actif via EZTech

Résumé

• APNIC a enregistré AS151918, nomméVPSPA-VN, au nom de VPS PA Company Limited au Vietnam le 31 mars 2024. APNIC a également enregistré le bloc IPv4 portable157.66.48.0/23sous la même société à la même date, donnant à VPS PA une empreinte claire de ressource numérique publique.
• L'enregistrement de routage n'est plus direct. La vue de RIPEstat du 12 juillet 2026 concernant AS151918 n'a signalé aucun préfixe actuel, aucun espace IPv4 ou IPv6 annoncé, zéro voisin observé et zéro visibilité RIS; CAIDA a également marqué AS151918 comme non vu.
• Le bloc157.66.48.0/23de la société est toujours visible, mais RIPEstat identifie AS150895,EZTECH-VN, comme l'origine actuelle. La route était visible pour l'ensemble des 325 pairs IPv4 RIS dans la réponse de statut de routage citée et disposait d'une autorisation d'origine RPKI valide pour AS150895.
• Cette séparation est importante sur le plan opérationnel. VPS PA dispose d'espace d'adressage et de preuves historiques que son propre AS a déjà été l'origine du bloc, mais le chemin de livraison public actuel dépend d'une origine externe, du transit, de l'emplacement des installations, du stock matériel, de l'alimentation et des arrangements de support que les sources publiques ne divulguent pas.
• La note pratique est Faible plutôt que Négative: le/23joignable prouve une route publique active pour un espace d'adressage étiqueté au nom de la société, mais les preuves publiques ne prouvent pas une capacité commandable, un contrôle sur les baies, une reprise multi-site, une portabilité de l'origine de la route, un équipement de rechange, une escalade du support ou des conditions d'exportation des données clients.

Le fait utile est la séparation, pas l'étiquette

L'indice public le plus fort concernant VPS PA Company Limited n'est pas un slogan ou une page de vente. C'est la séparation entre les ressources enregistrées pour la société et le réseau qui transporte actuellement l'une de ces ressources. L'enregistrement RDAP d'APNIC pour AS151918identifieVPSPA-VN, donne le Vietnam comme pays et liste VPS PA Company Limited dans les remarques. Un enregistrement parallèle d'APNICRDAP pour157.66.48.0/23attribue 512 adresses IPv4 sous le même nomVPSPA-VNet la même description de société. Les deux enregistrements datent du 31 mars 2024.

Il s'agit d'une empreinte d'infrastructure réelle. Un numéro de système autonome peut prendre en charge un routage BGP indépendant, et une allocation IPv4 portable peut être utilisée pour des serveurs clients, des points de terminaison de plan de contrôle, des panneaux d'hébergement, des concentrateurs VPN, des infrastructures DNS, des relais de messagerie ou des interconnexions privées. Dans un marché où de nombreuses offres d'hébergement de petite taille ne sont que des instances revendues sur un cloud plus grand, un ASN plus un espace d'adressage portable est matériellement plus spécifique qu'une revendication générique de « cloud ».

Il donne aux clients un identifiant public à surveiller.

Le problème est que l'identifiant et la route actuelle ne correspondent plus. Lavue d'ensemble AS de RIPEstat pour AS151918marque le titulaire commeVPSPA-VN - VPS PA Company Limitedmais indique que l'AS n'était pas annoncé au moment de la requête du 12 juillet 2026. Laréponse des préfixes annoncés de RIPEstata renvoyé une liste vide de préfixes pour la période actuelle. Saréponse de statut de routagea signalé zéro préfixe IPv4, zéro adresse IPv4, zéro préfixe IPv6, zéro équivalent/48IPv6, zéro voisin observé et zéro pair RIS voyant l'AS.

Ce n'est pas une distinction mineure. Si VPS PA était actuellement l'origine de son propre bloc, les clients pourraient demander si cet AS a plus d'un fournisseur en amont, si les routes sont filtrées, si RPKI est valide et si un changement de fournisseur pourrait se faire sans renumérotation. Lorsque l'AS de la société est silencieux et que le bloc est originaire d'un autre AS, la première question change.

Le client doit demander qui contrôle les routeurs de production, qui peut modifier l'objet de route ou l'autorisation d'origine de route, qui peut escalader une panne de transporteur et qui est contractuellement responsable si le chemin visible se brise.

L'empreinte du registre est réelle mais étroite

Les vues whois dérivées du registre d'APNIC et de RIPEstat donnent à VPS PA un profil administratif concret. Laréponse whois de RIPEstat pour AS151918listeVPSPA-VN, VPS PA Company Limited et une adresse à Binh Dinh au04 Tran Huy Lieu, Thi Nai Ward, Quy Nhon City. Laréponse whois de RIPEstat pour157.66.48.0/23répète la description de la société, l'adresse, le pays et le statutALLOCATED PORTABLEpour le bloc d'adresses. Ce sont des faits d'identité solides.

Ce ne sont pas des faits d'installation. Une adresse de registre peut être un siège social, un lieu de contact, une adresse résidentielle ou commerciale, ou un endroit où la paperasse est conservée. Elle ne prouve pas que des serveurs y sont installés, qu'une salle de données existe à Quy Nhon, qu'une alimentation électrique dispose d'une génératrice de secours, ou que les machines virtuelles des clients sont physiquement dans la province de Binh Dinh. L'analyse des infrastructures publiques doit maintenir l'enregistrement dans son rôle: la société détient des ressources, mais l'enregistrement ne dit pas où son calcul s'exécute.

Les dates sont encore informatives. Le bloc IPv4 a été enregistré à 18:21 UTC le 31 mars 2024; l'AS a été enregistré quelques minutes plus tard à 18:24 UTC. Cette séquence ressemble à une préparation coordonnée pour le routage plutôt qu'à une entrée isolée et obsolète. Lesconseils généraux d'APNIC sur la gestion des numéros ASexpliquent pourquoi les réseaux demandent des numéros de système autonome lorsqu'ils ont besoin d'une politique de routage indépendante, et lesconseils sur les ressources IPv4 d'APNICfournissent le contexte de gestion des ressources pour l'espace d'adressage alloué. Ces documents généraux ne prouvent pas le modèle économique de VPS PA, mais ils expliquent pourquoi les deux enregistrements comptent ensemble.

L'allocation fixe également une limite supérieure stricte à l'inventaire IPv4 visible publiquement. Un/23contient 512 adresses avant que les réservations, la conception réseau, les interfaces routeurs, les pare-feu, les nœuds de surveillance et la segmentation client ne réduisent le nombre disponible pour un usage commercial. Cela suffit pour une petite empreinte d'hébergement, un ensemble de pools NAT, une plateforme de serveurs privés virtuels, un service proxy ou VPN, ou un environnement mixte client/interne. Ce n'est pas en soi une preuve d'un grand cloud public. La capacité de calcul installée dépend des serveurs, disques, RAM, densité d'hyperviseurs, refroidissement, alimentation et personnel opérationnel, dont aucun n'est divulgué dans l'enregistrement APNIC.

AS151918 une fois routé, puis a disparu de la table actuelle

AS151918 n'est pas un numéro qui n'est jamais apparu. Laréponse de l'historique de routage de RIPEstat pour157.66.48.0/23montre AS151918 comme l'origine du bloc VPS PA sur une série d'intervalles d'avril 2024 à mars 2025. La même réponse montre la route plus tard portée par AS150895 de mars 2025 à l'instantané du 12 juillet 2026. Cet historique est utile car il exclut une lecture simpliste selon laquelle AS151918 n'était qu'un objet de registre dormant. Il était visible pendant une période, puis le chemin de livraison actuel a changé.

L'état actuel est celui qui compte pour les clients qui placent des charges de travail en juillet 2026. Laréponse des voisins ASN de RIPEstat pour AS151918a renvoyé zéro voisin gauche, droit, unique et incertain. Saréponse de cohérence de routage ASn'a renvoyé aucun préfixe, import ou export. Laréponse du classement AS de CAIDA pour AS151918a marqué l'ASN commeseen=false, avec zéro préfixe, zéro adresse et zéro degré total. BGP.tools présente égalementAS151918comme un réseau inactif avec zéro préfixe IPv4 et IPv6 originaire.

Ces sources mesurent des choses différentes, mais elles pointent dans la même direction. RIPEstat est une interface de collecteur de routes et de données de registre; CAIDA est un ensemble de données de recherche qui déduit les relations AS à partir du routage observé; BGP.tools est une surface de consultation publique indépendante. Aucune ne peut voir un réseau de gestion privé ou un serveur qui utilise les adresses d'un autre fournisseur. Toutes sont assez solides pour dire qu'AS151918 ne doit pas être traité comme une bordure Internet publique actuelle.

Cela a de l'importance pour les revendications de résilience. Un fournisseur d'hébergement peut détenir un ASN tout en s'appuyant sur la bordure amont de quelqu'un d'autre. Un fournisseur peut également suspendre temporairement le routage indépendant lors d'une migration, d'une consolidation ou d'une externalisation du transit. Le dossier public n'identifie pas laquelle de ces explications s'applique à VPS PA. Ce qu'il montre, c'est que les clients ne doivent pas traiter AS151918 comme un chemin de repli actif sans preuve récente.

Un AS silencieux n'annonce pas les routes des clients lors d'une panne simplement parce qu'il existe dans un registre.

Le/23est vivant, mais via AS150895

Le fait le plus vivant du dossier est la route vers157.66.48.0/23. Laréponse d'informations réseau de RIPEstatidentifie AS150895 comme l'origine actuelle du préfixe. Saréponse de statut de routage pour le préfixesignale une première visibilité pour le bloc le 13 avril 2024 sous une origine précoce différente, une dernière visibilité le 12 juillet 2026 sous AS150895 et une visibilité chez 325 des 325 pairs IPv4 RIS dans la réponse citée. Lavue d'ensemble du préfixe de RIPEstatidentifie également AS150895 comme l'origine actuelle côté titulaire dans la vue BGP.

Lapage de préfixe de BGP.tools pour157.66.48.0/23indique indépendamment que le préfixe est originaire d'AS150895 et nomme l'AS comme EZ Technology Company Limited. La vue de registre faisant autorité pour AS150895 provient de l'enregistrement RDAP d'APNIC pour AS150895, qui nommeEZTECH-VN, le Vietnam et une date d'enregistrement en 2023. Lavue d'ensemble AS de RIPEstat pour AS150895liste le titulaire commeEZTECH-VN - EZ TECHNOLOGY COMPANY LIMITEDet marque l'AS comme annoncé.

AS150895 n'est pas un stub à un préfixe dans l'observation actuelle. Laréponse des préfixes annoncés de RIPEstat pour AS150895a renvoyé 43 préfixes pour la période du 28 juin au 12 juillet 2026. Saréponse de statut de routage pour AS150895a signalé 41 préfixes IPv4, 15 872 adresses IPv4, deux préfixes IPv6, deux équivalents/48IPv6 et sept voisins observés au moment de la requête du 12 juillet. Laréponse des voisins ASN pour AS150895listait deux voisins côté gauche et cinq côté droit. Laréponse du classement AS de CAIDA pour AS150895l'a marqué commeseen=trueet a attribué un cône et un degré non nuls.

Ces mesures font d'AS150895 une origine de route crédible pour le bloc. Elles n'en font pas un opérateur d'installation divulgué, une société mère, un fournisseur de VPS PA, ou un garant des charges de travail des clients de VPS PA. L'origine en BGP signifie que l'ASN a annoncé la joignabilité du préfixe à l'Internet public. Elle ne révèle pas si AS150895 possède les serveurs, loue les baies, fournit le transit, gère les routeurs de bordure, agit en vertu d'un accord avec VPS PA, ou transporte simplement l'espace d'adressage dans le cadre d'un service plus large. L'article peut identifier la frontière; il ne peut pas remplir le contrat.

La validation d'origine protège une affirmation et en affaiblit une autre

La sécurité de l'origine de la route ajoute une autre ligne nette. Laréponse de validation RPKI de RIPEstat pour AS150895 et157.66.48.0/23a renvoyévalid, avec une autorisation d'origine de route couvrant le préfixe et autorisant AS150895. Laréponse de validation RPKI de RIPEstat pour AS151918 et le même préfixea renvoyéinvalid_asncar l'autorisation de validation nommait AS150895, pas l'AS propre de VPS PA.

C'est une bonne nouvelle pour la route qui existe aujourd'hui et une contrainte sur toute histoire simple de basculement. Une autorisation d'origine valide aide d'autres réseaux à rejeter certaines origines accidentelles ou malveillantes. Ce n'est pas une sécurité de chemin complète, mais cela améliore la confiance dans l'origine actuelle. Le même enregistrement signifie également qu'AS151918 ne pourrait pas simplement réapparaître comme origine du bloc sous l'autorisation actuelle sans être invalide pour les validateurs qui appliquent la validation d'origine.

Une récupération ou une migration vers AS151918 nécessiterait des changements coordonnés de la politique de routage et de l'autorisation d'origine de route, plus la propagation et l'acceptation par les fournisseurs en amont.

Le contexte des normes est clair.RFC 4271décrit l'échange de joignabilité et de chemins AS dans BGP.RFC 6811définit la validation d'origine de préfixe BGP en utilisant RPKI.RFC 7454couvre les pratiques opérationnelles pour sécuriser BGP, y compris le filtrage et le contrôle de route. Ce ne sont pas des audits spécifiques à une entreprise. Ce sont les raisons pour lesquelles un acheteur doit traiter « nous avons un ASN » et « nous pouvons déplacer le préfixe lors d'une panne de transporteur » comme des affirmations différentes.

Pour VPS PA, la preuve de sécurité rétrécit la surface de contrôle probable. Le bloc ne flotte pas dans une route non autorisée; il est valablement originaire d'AS150895. Si le service de production dépend de cette route, le chemin vivant a un avantage de sécurité de route. Mais l'AS propre de la société n'est actuellement pas le chemin autorisé pour ce bloc. Toute affirmation selon laquelle VPS PA a un contrôle de route indépendant doit donc expliquer la relation entre l'AS silencieux, l'autorisation AS150895 et les procédures opérationnelles pour changer d'origine lors d'un défaut.

Une route fonctionnelle n'est pas la même chose qu'une capacité hébergée

La route157.66.48.0/23prouve que les paquets peuvent trouver le bloc d'adresses depuis l'Internet public. Elle ne prouve pas combien d'instances client existent, si les adresses sont attribuées à des serveurs virtuels, si les machines sont en métal nu, s'il y a un backend de stockage, si des données sont sauvegardées, ou si un client peut exporter une image disque. C'est le problème central de dépendance physique pour les petites sociétés d'hébergement et de VPS: le routage public est visible, tandis que les couches de baie, d'alimentation et de réparation ne le sont généralement pas.

Une revendication crédible de capacité hébergée divulguerait ou permettrait au client de vérifier au moins certains des éléments suivants: site ou ville du centre de données, contrôle de la baie ou de l'armoire, conception de l'alimentation, responsabilité de l'onduleur et du générateur, redondance du refroidissement, contrats amont, propriété des commutateurs et routeurs, politique de serveur de rechange, stock de disques de remplacement, emplacement de sauvegarde, escalade du support, continuité de facturation et assistance à la migration. Les enregistrements APNIC de VPS PA ne répondent pas à ces questions. Le nomvpspa.vnne fournit pas non plus de surface de service de première partie actuelle: laréponse de chaîne DNS de RIPEstat pourvpspa.vna renvoyé des serveurs de noms faisant autorité.vnmais aucun nœud de transfert pour le domaine dans la requête citée.

L'absence de vitrine publique doit être lue avec précaution. Elle ne prouve pas que VPS PA n'a pas de clients. Une capacité d'hébergement peut être vendue via des canaux de messagerie, des ventes partenaires, des contrats privés ou des arrangements de marque blanche. Cela signifie qu'un acheteur ne peut pas se fier à un catalogue de services public, une page de statut, une politique de support, un SLA, une politique d'utilisation acceptable ou un guide de migration pour comprendre la frontière opérationnelle.

En termes d'approvisionnement, la société est visible comme titulaire de ressources et origine de route historique, pas comme une plateforme cloud publique entièrement documentée.

Ladéfinition de l'informatique en nuage du NISTest utile ici car elle sépare les caractéristiques de service telles que la mise en commun des ressources, l'élasticité rapide et le service mesuré de la simple possession de serveurs ou d'adresses IP. Le dossier public de VPS PA soutient la possibilité de services hébergés, mais il ne démontre pas ces caractéristiques de cloud. Leguide de planification d'urgence du NISTexplique également pourquoi les responsabilités de sauvegarde, de test et de récupération comptent. Une route peut rester active tandis que les données client sont irrécupérables; un serveur peut rester sous tension tandis que le routage amont échoue; une sauvegarde peut exister tandis que le temps de restauration est commercialement inutilisable.

Le chemin de défaillance probable commence à la frontière entre le titulaire d'adresse et l'origine

Si les clients ou les systèmes partenaires utilisent des adresses dans157.66.48.0/23, le chemin de défaillance le plus visible n'est pas AS151918. C'est le chemin de livraison actuel originaire d'AS150895. Une erreur de politique de routage, une erreur d'objet de route, une inadéquation RPKI, une panne amont, une facture fournisseur impayée, un arrêt de port, un événement DDoS, une saturation de capacité ou une maintenance du routeur de bordure dans ce chemin pourrait supprimer la joignabilité du bloc. Parce qu'AS151918 est silencieux et invalide pour le bloc sous l'autorisation actuelle, restaurer le service via l'AS propre de VPS PA ne serait pas un changement instantané à moins que les changements de routage et d'autorisation requis ne soient déjà préparés et testés.

Ce n'est pas une accusation contre l'une ou l'autre société. C'est ainsi que fonctionne la dépendance BGP. Laréponse de cohérence de routage de préfixe de RIPEstatmontre la route actuelle dans BGP et dans whois avec l'origine AS150895 et APNIC comme source IRR. Larequête API de PeeringDB pour ASN 151918n'a renvoyé aucun enregistrement d'entité dans la réponse examinée, ce qui signifie qu'il n'y a pas de profil PeeringDB public maintenu par l'opérateur pour l'AS de VPS PA pour divulguer des points d'échange, des installations ou une politique de peering. Cette absence n'est pas une preuve d'absence de transit privé, mais elle supprime un canal normal pour vérifier l'interconnexion.

Le prochain chemin de défaillance est physique. Une plateforme VPS a besoin de baies, d'alimentation, de refroidissement, d'inventaire de serveurs et de maintenance de stockage. Si VPS PA possède ses propres serveurs mais loue des baies, les fenêtres de maintenance de l'opérateur du centre de données, le temps de réponse à distance et la conception de l'alimentation comptent. Si VPS PA revend plutôt la capacité d'un fournisseur, le remplacement du matériel et la situation du compte du fournisseur comptent encore plus.

Si AS150895 ou un autre fournisseur sous-jacent exploite les routeurs et peut-être l'emplacement physique, les clients doivent savoir quelle file de tickets de problème résout réellement un défaut.

Les défaillances de support et de facturation ne sont pas des risques plus faibles. Une petite entreprise de capacité hébergée peut perdre la confiance des clients lorsque les factures, le traitement des abus, les e-mails de contact de domaine ou les portails de paiement échouent, même si les routeurs restent stables. Inversement, un réseau peut être injoignable tandis que l'automatisation de la facturation continue. Sans page de statut publique, archive d'incidents, calendrier de maintenance ou politique de support, les clients doivent vérifier l'escalade par contrat plutôt que par observation.

La capacité installée et la capacité utilisable sont des nombres différents

Le bloc VPS PA est suffisamment grand pour être significatif sur le plan opérationnel et suffisamment petit pour que la discipline de capacité compte. Un/23donne 512 adresses IPv4, mais la capacité utilisable dépend de l'architecture. Certaines adresses peuvent être acheminées vers des équilibreurs de charge, des hyperviseurs, des passerelles, des pools NAT, des systèmes de surveillance ou des points de terminaison de service réservés. Si les plans VPS individuels nécessitent des adresses IPv4 publiques, le bloc d'adresses peut devenir le goulot d'étranglement avant le CPU ou la mémoire. Si les clients partagent des adresses derrière NAT, le bloc d'adresses peut prendre en charge plus de comptes mais créer différentes contraintes d'abus, de journalisation et de redirection de port.

La route publique ne révèle pas combien de serveurs physiques se trouvent derrière les adresses. Dix machines denses pourraient héberger de nombreuses petites instances; quelques nœuds en métal nu pourraient consommer rapidement la capacité commerciale; un service proxy ou relais pourrait utiliser le bloc sans plateforme VPS à usage général du tout. Le nom de la société inclut « VPS », mais les preuves publiques examinées ici ne montrent pas de grille tarifaire en direct, d'inventaire d'hyperviseur, de niveau de stockage, de promesse de conservation des sauvegardes ou de portail client.

L'inférence correcte est donc limitée: le bloc peut prendre en charge des services hébergés, et le routage historique via AS151918 suggère que VPS PA avait autrefois une bordure publique plus directe, mais les sources publiques n'établissent pas la capacité de calcul actuelle installée.

L'empreinte de routage plus large d'AS150895 fournit un contexte différent. Une origine de route avec 43 préfixes actuels, une visibilité IPv4 et IPv6 et sept voisins observés est plus substantielle qu'une coquille à un seul préfixe. Si le bloc de VPS PA est transporté dans l'environnement d'exploitation de ce réseau, la route peut bénéficier des arrangements amont d'AS150895. Mais ce n'est toujours pas une déclaration de capacité de VPS PA. Un fournisseur solide peut transporter une allocation client faiblement documentée. Un préfixe bien routé peut pointer vers un service minuscule.

Une grande origine de route peut également centraliser le risque si chaque bloc client dépend de la même politique amont ou de la même concentration d'installation.

C'est pourquoi les acheteurs de capacité hébergée devraient demander des détails installé vs disponible. Combien de nœuds desservent le bloc? Les clients sont-ils épinglés à une seule baie, un seul site ou un seul tableau de stockage? Le fournisseur dispose-t-il de disques de rechange, de serveurs de remplacement et d'un accès à distance à toute heure? Les sauvegardes sont-elles dans la même installation ou sous un autre compte fournisseur? Combien de temps faudrait-il pour exporter une image disque complète du client si la relation avec le fournisseur changeait?

Le dossier public ne répond pas à ces questions; il explique seulement pourquoi ce sont les bonnes questions.

Le changement d'origine de mars 2025 est l'indice opérationnel

L'horodatage le plus important dans l'enregistrement de routage n'est pas la date d'enregistrement. C'est la transition autour de mars 2025, lorsque le bloc VPS PA est passé de l'origine visible de la société à AS150895 dans l'historique de RIPEstat. Un changement d'origine de route peut être courant: une société peut acheter du transit auprès d'un nouveau fournisseur amont, consolider les annonces, passer à un réseau géré, utiliser la bordure d'un fournisseur tout en conservant la garde des adresses, ou nettoyer le routage après une période d'auto-exploitation.

Il peut également marquer du stress: perte d'une session amont, incapacité à maintenir l'équipement de bordure, changement de contrat de fournisseur, ou choix opérationnel de confier la frontière publique à une autre organisation.

Les données publiques ne disent pas laquelle de ces explications est vraie. Elles disent que les clients ne doivent pas ignorer le changement. Si un bloc d'adresses utilisé pour les charges de travail client change d'origine, la frontière opérationnelle change avec lui. Le service d'assistance qui peut réparer une machine virtuelle n'est pas nécessairement l'équipe qui peut restaurer l'annonce BGP. La personne qui peut remplacer un disque n'est pas nécessairement celle qui peut modifier un ROA. Le titulaire du compte qui paie pour l'espace en baie n'est pas nécessairement le titulaire des ressources nommé dans APNIC.

Le dossier public de VPS PA laisse chacun de ces rôles non divulgué.

La transition affecte également l'interprétation des incidents. Si le/23devient injoignable, un client pourrait d'abord vérifier AS151918 parce que la société possède cet AS. En juillet 2026, ce serait la mauvaise première bordure. Le client aurait besoin de surveiller l'annonce d'AS150895, les chemins amont d'AS150895 et l'autorisation d'origine de route pour le préfixe. Si AS151918 réapparaît soudainement, ce serait un événement significatif uniquement si la nouvelle route est acceptée, visible et valide sous RPKI. Si AS150895 continue d'annoncer tandis que les services échouent, le problème peut se situer derrière la route: défaillance d'hyperviseur, perte de stockage, commutation interne, politique de pare-feu, alimentation, refroidissement, suspension pour abus ou facturation.

Cette distinction est particulièrement importante pour un petit fournisseur car les contrats clients regroupent souvent des systèmes séparés sous une seule marque. Un acheteur peut penser « VPS PA est en panne » alors que trois couches différentes sont impliquées: la ressource d'adresse, l'AS d'origine et la plateforme de calcul. Le BGP public ne peut confirmer que les deux premières. Il peut montrer si la route vers le bloc existe et qui l'annonce. Il ne peut pas montrer si un serveur client particulier est sous tension, si un instantané est intact, si un ticket de support est lu, ou si un fournisseur a suspendu un compte de service.

La question de la récupération est donc procédurale. Si AS150895 a une fenêtre de maintenance, quel préavis VPS PA reçoit-il et transmet-il aux clients? Si AS150895 change de fournisseurs amont, VPS PA teste-t-il la joignabilité depuis les réseaux haut débit vietnamiens et les emplacements internationaux? Si AS150895 retire le bloc, VPS PA peut-il l'annoncer via AS151918 avec un ROA valide, ou doit-il attendre une réparation du côté du fournisseur? Si le bloc est abusé par un client et filtré en amont, les clients propres peuvent-ils être déplacés vers d'autres adresses?

Le dossier public actuel ne montre pas ces réponses, donc le changement d'origine reste un marqueur de risque plutôt qu'une architecture résolue.

Ce que les clients doivent vérifier avant de placer des charges de travail de production

Le premier élément de vérification est la responsabilité de la route. Les clients doivent demander si AS150895 est l'origine de production prévue pour157.66.48.0/23, si VPS PA contrôle le ROA, si AS151918 est une solution de secours, et si un basculement testé existe. La réponse doit être opérationnelle, pas seulement administrative. « Nous possédons le bloc » n'est pas la même chose que « nous pouvons restaurer la route ». « Nous avons un ASN » n'est pas la même chose que « nos sessions amont sont configurées, surveillées et validées ».

Le deuxième élément est la responsabilité du site et de l'alimentation. Si VPS PA exploite des serveurs physiques, les clients doivent connaître la ville de l'installation, si les baies sont dédiées ou partagées, qui fournit l'alimentation, quelle redondance est contractée et à quoi ressemblent les avis de maintenance. Si la société utilise un autre fournisseur d'hébergement ou de réseau pour l'équipement réel, les clients doivent savoir quel contrôle reste avec VPS PA lors d'une panne. Un revendeur peut fournir un service utile, mais seulement si le revendeur est honnête sur l'étendue de son autorité.

L'adresse APNIC publique à Binh Dinh ne doit pas être traitée comme un emplacement de centre de données sans preuve d'installation distincte.

Le troisième élément est la réparation matérielle. La capacité hébergée tombe en panne de manière banale: les SSD s'usent, les modules mémoire font des erreurs, les contrôleurs RAID paniquent, les alimentations meurent, les cartes réseau perdent leurs liaisons et les cartes de gestion à distance cessent de répondre. Un petit fournisseur avec quelques pièces de rechange peut récupérer beaucoup plus rapidement qu'un autre qui attend que le fournisseur expédie des remplacements ou planifie une intervention à distance.

Aucune des sources de routage publiques ne révèle l'inventaire de rechange, la couverture de garantie ou la fenêtre de réparation de VPS PA. Pour les charges de travail de production, cette absence compte autant que la diversité amont.

Le quatrième élément est l'isolation des sauvegardes. Un instantané de serveur virtuel dans le même tableau de stockage, la même baie, le même compte ou la même plateforme fournisseur est pratique, mais il peut ne pas survivre à l'incident qui supprime l'instance principale. Un récit de sauvegarde utile devrait dire où les copies sont stockées, à quelle fréquence les restaurations sont testées, comment les clients peuvent récupérer les données, ce qui se passe lorsqu'un litige de facturation ou une suspension pour abus affecte le compte, et si le chemin de sauvegarde dépend du même préfixe.

Le dossier public ne contient aucune déclaration de sauvegarde, donc tout client comptant sur la plateforme devrait conserver une copie indépendante sous ses propres identifiants.

Le cinquième élément est l'escalade du support. La route actuelle pointe vers une frontière fournisseur-origine. Lors d'une panne, les clients ont besoin d'un chemin d'escalade nommé: le contact support de VPS PA, l'escalade vers l'opérateur d'origine de la route, la fenêtre de réponse attendue et la personne qui peut approuver un travail de route ou d'installation d'urgence. Si le chemin de support n'est qu'un pseudo de chat ou une boîte aux lettres générique, les clients devraient traiter le service comme au mieux sans garantie, sauf si les termes du contrat disent le contraire.

Un préfixe joignable est utile, mais la restauration est un processus humain et contractuel.

Le sixième élément est la sortie. Un client devrait savoir s'il peut exporter des images disque, des instantanés, des bases de données, des clés, des journaux et des données DNS sans attendre une approbation manuelle. Il devrait également savoir si les adresses IP publiques sont portables vers le client, liées à l'allocation de VPS PA, ou remplaçables uniquement par une renumérotation. Parce que157.66.48.0/23est une allocation étiquetée VPS PA, les adresses peuvent être précieuses pour le modèle opérationnel de VPS PA, pas portables vers des clients individuels. Si un client doit déménager, le véritable chemin de récupération peut être l'exportation de données et le changement DNS, pas la préservation de la même adresse IP.

Les revendications de redondance nécessitent des preuves à trois couches distinctes

La redondance dans ce cas doit être évaluée au niveau de la route, de l'installation et du service. La redondance de route signifierait plus qu'AS150895 étant visible à travers de nombreux collecteurs publics. Cela signifierait une diversité amont contrôlée, une réponse connue aux fuites ou retraits de routes, une autorisation d'origine valide pour l'origine prévue et une procédure testée pour le basculement. Les preuves publiques actuelles montrent une route largement visible via AS150895, mais elles ne montrent pas AS151918 comme un chemin alternatif fonctionnel.

La redondance des installations signifierait plus qu'une adresse de société et un préfixe vivant. Cela nécessiterait des preuves que l'équipement client ou les machines virtuelles peuvent survivre à un événement électrique, un problème de refroidissement, une fenêtre de maintenance de baie ou un problème d'accès au centre de données. Une seule baie avec deux liaisons montantes peut sembler résiliente dans BGP jusqu'à ce que les deux liaisons partagent le même bâtiment, le même contrat de fournisseur ou la même dépendance électrique. Aucune source examinée ne nomme une installation de VPS PA, donc cette couche reste non vérifiée.

La redondance de service signifierait que les charges de travail client peuvent continuer ou être restaurées lorsqu'un hyperviseur, un nœud de stockage, un compte de facturation ou une file d'attente de support échoue. C'est la couche que de nombreux petits clients VPS expérimentent le plus directement. Si un nœud hôte échoue, la route BGP peut rester parfaitement saine tandis que chaque machine virtuelle sur ce nœud est injoignable. Si le stockage échoue, une route peut rester active tandis que les données sont perdues.

Si le personnel de support est réduit, une récupération techniquement possible peut encore prendre plus de temps que le seuil de tolérance de l'entreprise du client.

La conclusion prudente n'est pas que VPS PA manque de redondance. La conclusion prudente est que les preuves publiques ne la démontrent pas. Le/23vivant prouve la joignabilité pour un bloc étiqueté au nom de la société. Cela ne prouve pas le basculement de route, le basculement de site, la réplication de stockage, la restauration de sauvegarde, la couverture de support ou la continuité de facturation. Pour un client, ces preuves manquantes devraient modifier le placement des charges de travail: les services expérimentaux, les systèmes de préparation et les points de terminaison non critiques ont un profil de risque différent des systèmes de paiement, des bases de données réglementées, des API de production ou de la messagerie client.

Les questions de localisation des données ne peuvent pas être résolues par BGP seul

Les enregistrements de VPS PA sont vietnamiens et le répertoire de service est le Vietnam, donc la localisation compte. La publication officielle vietnamienne dudécret 53/2022/ND-CPet la version de la base de données juridique officielle dudécret 53font partie du contexte politique pour les questions de stockage de données et de cybersécurité. Cet article ne porte pas de conclusion juridique sur le fait qu'un client ou une charge de travail particulier soit couvert. Il explique pourquoi un acheteur réglementé ne devrait pas traiter une adresse de registre vietnamienne comme une preuve que les données, les sauvegardes, les journaux et l'accès au support restent au Vietnam.

La géographie BGP est particulièrement glissante. Un préfixe enregistré au Vietnam peut être annoncé depuis un AS vietnamien et toujours traverser un transit international avant d'atteindre un utilisateur. Un serveur peut se trouver au Vietnam tandis que le support à distance, les sauvegardes, la facturation et la surveillance dépendent de comptes ailleurs. Une route peut être visible globalement depuis Londres, Singapour, Hong Kong, Los Angeles ou d'autres points d'observation parce qu'Internet mesure des chemins, pas nécessairement la salle de serveurs physique. Ladocumentation du service d'information de routage de RIPEet ladocumentation de l'API de données RIPEstatsont des rappels utiles que les observations publiques BGP sont des vues de mesure, pas des reçus d'entrepôt.

Pour un client vietnamien utilisant un espace d'adressage associé à VPS PA, les questions de localisation sont pratiques. Où sont stockées les données principales? Où sont stockées les sauvegardes? Qui peut accéder à l'hyperviseur? Un fournisseur extérieur au contrat du client détient-il un accès administrateur? Le client peut-il exporter des données sans attendre qu'une route d'origine du fournisseur soit réparée? Les enregistrements d'abus, les journaux et les tickets de support sont-ils conservés d'une manière qui correspond aux obligations du client? Aucune de ces questions ne peut être résolue par AS151918, AS150895 ou157.66.48.0/23seuls.

Ce qui améliorerait la note de preuve

La note de preuve actuelle est Faible car le réseau public est à moitié visible. Le bloc d'adresses est réel, routé, valablement autorisé et largement vu. L'AS propre de la société est réel et historiquement actif. Pourtant, la bordure publique actuelle n'est pas AS151918, le domaine de première partie apparent ne résout pas une surface de service, et aucun matériel public examiné ici ne montre d'installations, de serveurs, de profondeur de support, de test de restauration, d'historique de statut ou de conditions de portabilité des données client.

Un dossier plus solide nécessiterait des preuves récentes, publiques et de préférence de première partie. Une page de service VPS PA actuelle liée à157.66.48.0/23, une page de statut, une politique de support, une page réseau nommant les installations et les fournisseurs amont, un profil PeeringDB pour AS151918, une nouvelle route via AS151918 avec RPKI valide, ou un guide de migration orienté client amélioreraient tous l'évaluation. De même, des preuves indépendantes de présence dans un centre de données, une pratique de sauvegarde auditée, des fenêtres de maintenance publiées ou une déclaration claire qu'AS150895 est le transporteur de production prévu pour le bloc.

Le changement technique le plus précieux serait la preuve de portabilité de route. Si AS151918 est destiné à être une bordure de secours ou future indépendante, la société devrait pouvoir montrer un plan de route autorisé, une diversité amont, un basculement testé et une autorisation d'origine valide pour l'origine souhaitée. Si AS150895 est l'origine de route permanente, les clients ont besoin d'une explication au niveau du contrat de la frontière du fournisseur. Dans les deux cas, le dossier public devrait distinguer un AS enregistré, un préfixe vivant, un service routé et une plateforme hébergée récupérable.

Cette distinction devrait également façonner la surveillance. Un client qui décide d'utiliser des adresses associées à VPS PA devrait surveiller le préfixe, pas seulement le nom de la société. Les signaux utiles incluent la visibilité continue de157.66.48.0/23, tout changement d'origine loin d'AS150895, toute réapparition d'AS151918, tout changement de statut RPKI de valide à invalide ou inconnu, et toute disparition prolongée des collecteurs de routes. Ces signaux réseau devraient être associés à des preuves non BGP: si le support répond pendant une fenêtre de maintenance, si les factures et l'accès au compte restent disponibles, si les sauvegardes peuvent être restaurées vers un autre fournisseur, et si les points de terminaison DNS ou d'application peuvent être déplacés sans attendre le retour de la route d'origine.

La même approche s'applique aux changements positifs. Si AS151918 redevient visible, cela ne devrait pas automatiquement faire passer la société à une preuve solide. La question améliorée serait de savoir si la route est stable, valide, suffisamment visible, soutenue par plus d'un fournisseur amont crédible et connectée à la plateforme client réelle. Si un site VPS public apparaît, la question améliorée serait de savoir si le site divulgue l'emplacement, les conditions de service, les chemins de support et les droits d'exportation de données.

Les signaux publics doivent être accumulés, pas traités comme un simple interrupteur d'incertain à prouvé.

Jusqu'à ce que ces preuves apparaissent, VPS PA Company Limited devrait être interprétée comme un petit titulaire de ressources vietnamien avec un bloc IPv4 étiqueté au nom de la société et vivant, transporté via un autre réseau. C'est un signal significatif, pas une assurance cloud complète. Les clients les plus affectés par une panne seraient ceux dont les charges de travail, enregistrements DNS, API, VPN, systèmes de messagerie ou consoles de gestion dépendent d'adresses dans157.66.48.0/23, plus les clients en aval des revendeurs qui peuvent ne pas savoir que l'origine de route visible n'est pas l'AS propre de VPS PA. Leur risque concerne moins l'existence du nom que la question de savoir si la route, les baies, l'alimentation, le matériel et les personnes derrière le service peuvent survivre à la prochaine fenêtre de maintenance.