10VPN Research Network LTD vend une capacité hébergée qui dépend toujours des baies, du transit et des fenêtres de réparation

Résumé

• 10VPN Research Network LTDest une société privée à responsabilité limitée britannique constituée le 19 novembre 2019. Companies House la liste comme active sous le code SIC 63110, « traitement de données, hébergement et activités connexes », mais le même historique de dépôt montre des comptes de société dormante pour 2022, 2023, 2024 et 2025.
• Les preuves réseau en direct sont plus solides que les preuves de service commercial. RIPEstat a montré AS49134 annoncé le 12 juillet 2026 avec quatre préfixes IPv6, aucun IPv4 originait dans cet instantané, 321 des 322 pairs RIS IPv6 échantillonnés voyant l'ensemble de routes, et 29 ASNs voisins observés.
• PeeringDB listait10VPN Research Networkcomme un réseau éducatif/de recherche avec une politique de peering ouverte, une portée mondiale, un trafic dans la bande 100–1000 Mb/s, seize enregistrements de LAN d'échange et trois enregistrements de facilités: Harbour Centre Vancouver, Hurricane Electric Fremont 2 et KoloDC NL1.
• AS209762 n'est pas une deuxième empreinte de production actuelle dans les preuves de routage. RIPEstat l'a marqué comme non annoncé le 12 juillet 2026, et PeeringDB l'a décrit comme un réseau de route-serveur de sauvegarde EVIX qui ne devrait pas originer de préfixes.
• La note de preuve est Moyenne pour l'existence actuelle du réseau et Faible pour la transparence opérationnelle du service hébergé. Le risque pour l'acheteur n'est pas que AS49134 soit invisible; c'est que les sources publiques ne divulguent pas la propriété des baies, les conditions de transit payant, le stock matériel, la couverture du support client, les chemins de restauration, la continuité de facturation ou les limites de portabilité des données.

La question initiale n'est pas de savoir si 10VPN possède un ASN

Le point de départ utile pour10VPN Research Network LTDest l'écart entre son nom, ses dépôts et ses routes. « 10VPN » évoque un service VPN grand public, mais les preuves publiques les plus fiables ne montrent pas un produit de confidentialité de détail, une flotte d'applications mobiles ou une carte de points de terminaison de masse. Elles montrent une société britannique avec une classification industrielle liée à l'hébergement, une piste de contrôle canadienne et un système autonome public qui se comporte comme un petit réseau de recherche et de peering. Cela importe car un client achetant une capacité hébergée auprès d'un petit réseau n'achète pas une abstraction. Le client dépend de baies, d'interconnexions, de chemins amont, de ressources d'adresses, de mains à distance, de contrôle de domaine, de dossiers de facturation et de la volonté d'une petite équipe d'exploitation de maintenir les services récupérables.

L'identité juridique est simple.L'aperçu de Companies House pour 10VPN Research Network LTDliste le numéro de société 12321905, un statut actif, un type de société privée à responsabilité limitée, une constitution le 19 novembre 2019, un siège social au 61 Bridge Street, Kington, Royaume-Uni, et le code SIC 63110 pour le traitement de données, l'hébergement et les activités connexes. Les mêmes pages de Companies House listent le directeur actuel et la personne ayant un contrôle significatif comme Christopher Munz-Michielin, un résident canadien détenant au moins 75 % des parts et des droits de vote. Cela correspond à la description de l'instantané d'un réseau enregistré au Royaume-Uni et opéré depuis le Canada. Cela ne prouve pas, en soi, l'échelle opérationnelle actuelle.

Les comptes constituent la partie prudente.L'historique des dépôts de Companies Housemontre des comptes de société dormante pour les exercices clos le 30 novembre 2022, 30 novembre 2023, 30 novembre 2024 et 30 novembre 2025, après des comptes de micro-entreprise pour 2021. Les comptes dormants ne sont pas une mesure du réseau. Ils ne prouvent pas que chaque routeur est éteint, car les petits réseaux peuvent être gérés via des sociétés affiliées, des arrangements de parrainage, des projets communautaires, une capacité personnelle ou des voies comptables non britanniques. Mais ils affaiblissent toute affirmation selon laquelle la société britannique elle-même démontre publiquement une plateforme de services hébergés génératrice de revenus importante.

Les preuves de routage vont dans l'autre sens.L'aperçu AS de RIPEstat pour AS49134a identifié le détenteur comme « AS_10VPN 10VPN Research Network LTD » et a montré l'ASN comme annoncé dans la fenêtre de requête du 12 juillet 2026.L'enregistrement RDAP RIPE pour AS49134listait l'aut-num comme actif, avec 10VPN Research Network LTD comme un handle d'organisation et Free Range Cloud Ltd. visible dans le contexte du contact abus.La vue du statut de routage de RIPEstata montré quatre préfixes IPv6, dix-huit blocs IPv6 équivalents /48, aucun IPv4 originait dans cet instantané et une forte visibilité IPv6 sur les pairs RIS échantillonnés.

C'est le cœur de l'évaluation. 10VPN n'est pas un nom mort dans le routage public. Ce n'est pas non plus un fournisseur cloud transparent avec des conditions de niveau de service publiées, une architecture régionale, une conception de sauvegarde, des procédures d'exportation client et une couverture de support. Le réseau existe. La promesse de capacité hébergée, si elle est vendue à un client payant, doit toujours être ancrée dans les systèmes physiques et contractuels qui maintiennent les petits réseaux d'interconnexion en vie.

Le statut de la société est actif, mais les comptes déposés créent un déclassement d'échelle

Un enregistrement de société actif donne aux clients une étiquette légale responsable. Il aide à aligner les factures, les conditions de service, les dossiers fiscaux et les avis de litige. Dans le cas de 10VPN,l'aperçu de Companies Housefournit exactement ce genre d'ancre: la société est active, constituée en 2019, et classée dans le traitement de données, l'hébergement et les activités connexes. Cette classification est pertinente pour ce profil d'infrastructure car c'est l'un des rares signaux publics reliant la société juridique à une activité hébergée ou de traitement de données plutôt qu'à un simple laboratoire de recherche ou un réseau de loisir.

Mais un code SIC d'hébergement est une étiquette large. Il peut couvrir le traitement de données, l'hébergement, les activités connexes et des modèles de service qui diffèrent radicalement en termes de risque physique. Un seul serveur privé virtuel revendu depuis un autre fournisseur, une armoire dans un centre de données neutre, une expérience de route-serveur, un service de transit payant, un tunnel IPv6, et un laboratoire BGP géré peuvent tous se situer près de la catégorie d'hébergement sans donner au client les mêmes garanties de récupération. La catégorie ouvre la question; elle n'y répond pas.

Le même registre public montre aussi pourquoi l'échelle devrait être déclassée.La page d'historique des dépôtsliste des comptes de société dormante arrêtés au 30 novembre 2025, déposés le 18 décembre 2025. Elle liste également des comptes dormants pour 2024, 2023 et 2022. Les comptes dormants indiquent normalement au lecteur que la société n'a déclaré aucune transaction comptable significative au cours de la période concernée. Ce ne sont pas une sonde réseau, et ils ne remplacent pas les données de route. Mais pour un client envisageant des services hébergés, ils sont un indice sérieux que les déclarations publiques de l'entreprise ne montrent pas la masse opérationnelle que l'on attendrait d'un grand fournisseur commercial.

Les pages des personnes ajoutent un autre élément de contexte.La page des dirigeantsmontre le directeur actuel comme Christopher Munz-Michielin, canadien, nommé le 2 juin 2024.La page des personnes ayant un contrôle significatifliste la même personne comme détenant 75 % ou plus des parts et des droits de vote. La piste de contact RDAP RIPE pointe également vers le Canada, avec un contact administratif et technique en Colombie-Britannique. Rien de tout cela n'est négatif. Cela réduit simplement l'image opérationnelle: un véhicule légal britannique, un centre de contrôle canadien, et une empreinte réseau qui est mondiale en termes de routage mais petite en termes de divulgation publique des activités commerciales.

Pour un acheteur, cette combinaison change la conversation d'approvisionnement. La question n'est pas « la société est-elle réelle? » Elle l'est. La meilleure question est « quelle partie légale signe le contrat de service, quelle installation physique héberge la charge de travail, quel amont ou parrain porte la route, et quelle personne ou canal de support peut restaurer le service lorsque la panne survient en dehors des heures de bureau normales? » Un grand acheteur cloud pourrait poser ces questions via un portail d'approvisionnement. Un client d'un petit réseau doit les poser directement et obtenir des réponses par écrit.

Les preuves du statut de la société méritent donc une lecture divisée. Un statut actif et un code SIC lié à l'hébergement soutiennent l'existence d'une enveloppe de service légale. Les comptes dormants et le matériel de service public clairsemé vont à l'encontre de toute affirmation de capacité commerciale profonde. La conclusion la plus sûre est que 10VPN devrait être évalué comme un réseau à empreinte mince avec une certaine pertinence de service hébergé, et non comme un opérateur cloud multi-région divulgué.

AS49134 est actif, mais l'image de routage public actuelle est IPv6-first

La preuve opérationnelle la plus solide autour de 10VPN est AS49134.Le point de terminaison d'aperçu AS de RIPEstata montré AS49134 annoncé le 12 juillet 2026.Son point de terminaison de statut de routagea montré un schéma très spécifique: zéro préfixe IPv4 originait dans l'instantané, quatre préfixes IPv6, dix-huit blocs IPv6 équivalents /48, 321 des 322 pairs RIS IPv6 échantillonnés voyant l'ensemble de routes, et zéro pair IPv4 échantillonné voyant de l'espace IPv4 originait.Le point de terminaison des préfixes annoncéslistait les préfixes IPv6 actuels comme 2602:fed2:fd0::/44, 2602:fed2:fd0::/46, 2602:fed2:31::/48 et 2602:fd60:11::/48.

Cela fait d'AS49134 une surface de routage réelle et vivante. Cela indique également à un client de service hébergé de ne pas supposer un service inclusif IPv4 à partir des seules preuves d'origine.La page BGP Toolkit de Hurricane Electric pour AS49134montrait la même forme de base: quatre préfixes originaits, zéro préfixe IPv4 originait, quatre préfixes IPv6 originaits, RPKI valide pour l'ensemble IPv6 originait et 29 pairs BGP observés. BGP.tools listait de même10VPN Research Network LTD sur AS49134avec zéro IPv4 et quatre préfixes IPv6 originaits, et étiquetait le réseau comme IPv6-only dans sa vue résumée.

Le schéma IPv6-first n'est pas un défaut en soi. Pour un réseau de recherche, une posture fortement IPv6 peut être intentionnelle et techniquement cohérente. Elle peut supporter des tunnels, des expériences de peering, des travaux de route-serveur, du trafic de recherche et des points de terminaison de service modernes. Elle peut même réduire la pression de rareté par rapport à IPv4. Mais de nombreux clients hébergés ont encore besoin d'IPv4.

Les passerelles de paiement, les VPN d'entreprise, les systèmes de surveillance plus anciens, les relais de messagerie, les listes blanches, les API héritées et les appareils clients restent souvent dépendants d'IPv4. Si 10VPN vend ou supporte un service hébergé, le client devrait demander si l'accessibilité IPv4 est native, fournie par l'amont, tunnelée, traduite, empruntée à un parrain, ou extérieure au service.

L'image de sécurité de routage est meilleure que l'image d'échelle. Les points de terminaison de validation RPKI de RIPEstat ont retourné un statut valide pour les préfixes IPv6 originaits testés:2602:fed2:fd0::/44,2602:fed2:fd0::/46,2602:fed2:31::/48et2602:fd60:11::/48. Un RPKI valide ne rend pas un petit réseau résilient, mais il montre que les données d'origine IPv6 actuelles ne sont pas simplement une fuite de route informelle.

L'image des voisins montre à la fois la portée et la dépendance.Le point de terminaison asn-neighbours de RIPEstata montré 29 voisins uniques observés le 12 juillet 2026, avec des voisins de gauche incluant AS53356 et AS6939. BGP.tools et Hurricane Electric identifient ces noms comme Free Range Cloud Hosting Inc. et Hurricane Electric LLC. Ce sont des noms d'amont ou de pairs significatifs pour un petit réseau. Pourtant, l'adjacence BGP observée n'est pas la même chose que la redondance physique. Elle ne prouve pas des salles de réunion séparées, des entrées fibre diverses, un stock de routeurs de rechange, des conditions de niveau de service payant, ou suffisamment de capacité inutilisée pour absorber une panne.

La lecture pratique est étroite et utile: AS49134 était visible et bien propagé pour IPv6 dans les preuves du 12 juillet. C'est plus fort que ce que des déclarations d'entreprise dormantes laisseraient supposer seules. Les mêmes preuves avertissent également les clients que le réseau public est spécialisé, petit et dépendant d'un ensemble limité de conditions amont et de facilités.

PeeringDB montre une portée mondiale, mais pas une capacité à l'échelle du cloud

PeeringDB donne le profil opérationnel auto-décrit le plus clair pour AS49134.L'API réseau PeeringDB pour ASN 49134listait « 10VPN Research Network » avec « 10VPN RESEARCH NETWORK LTD » comme nom alternatif, site webhttps://10vpn.net, politique de peering général ouverte, une URL de politique àhttps://10vpn.net/peering.php, un trafic dans la bande 100-1000 Mb/s, un ratio équilibré, une portée mondiale, IPv6 activé, unicast activé, trois facilités et seize enregistrements d'échange. Il listait également le type de réseau comme Éducatif/Recherche et donnait l'ensemble IRR comme RIPE::AS-10VPN-RESEARCH.

Ce profil est inhabituellement utile car il réduit la probabilité de mauvaise classification. Le réseau ne se présente pas dans PeeringDB comme un cloud hyperscale, un géant de la diffusion de contenu ou un transporteur avec des térabits de trafic public. Il se présente comme un réseau de recherche avec peering ouvert. Le peering ouvert est précieux pour l'accessibilité et l'expérimentation. Il peut aussi être fragile sur le plan opérationnel si les clients confondent la présence sur un exchange avec un transit payant garanti ou un support d'hébergement géré.

La liste des échanges est géographiquement large.L'API netixlan de PeeringDBlistait des enregistrements LAN d'échange pour KleyReX, LOCIX Netherlands, Gig IX Ashburn, EVIX, 4b42 Switzerland, ARIX, BFD-IX, IXP NL DRO, IXP FI HEL, IXP US FRE, IXP UK LON, IXP LI VAD, FCIX, SBIX Zurich, TOHU IX et FogIXP. Les vitesses dans cette liste allaient de 100 Mb/s à 10 Gb/s, avec plusieurs enregistrements à 100 Mb/s, plusieurs à 1 Gb/s et un enregistrement à 10 Gb/s à TOHU IX.La page AS49134 de Hurricane Electriclistait dix-sept exchanges Internet, tandis que l'API PeeringDB actuelle retournait seize enregistrements LAN d'échange. La différence n'est pas surprenante entre les vues publiques et les cycles de mise à jour. Le point le plus important est que l'empreinte est distribuée, mais les tailles de port et le type de réseau n'indiquent pas un grand cloud commercial.

La présence sur un exchange est souvent mal interprétée. Une ligne dans PeeringDB peut représenter un port physique, un port d'échange virtuel, une session de route-serveur, un produit de peering à distance ou une petite présence maintenue pour des raisons d'accessibilité et de communauté. Cela ne signifie pas automatiquement que le réseau possède des baies dans chaque ville impliquée par les noms d'échange. Cela ne prouve pas un inventaire matériel local, un support local ou un placement de charge de travail sur chaque marché.

Pour un client, un chemin d'échange virtuel de 100 Mb/s peut être utile pour le trafic de laboratoire, mais il peut ne pas être le bon chemin de récupération pour un hébergement de production.

La politique de peering nécessite également une lecture attentive. PeeringDB montrait que les contrats ne sont pas requis, le ratio non requis et les emplacements préférés. Cela correspond à un réseau de recherche ouvert. Cela ne donne pas au client des droits de récupération exécutoires. Si le trafic se déplace lors d'une panne, un pair ouvert peut ne pas transporter le chemin souhaité par le client, peut limiter le débit, peut router différemment par famille d'adresses, ou peut disparaître pendant la maintenance sans recours pour le client.

Le peering améliore la portée, mais ce sont les conditions de transit et de support qui déterminent la récupérabilité.

L'empreinte de peering ouvert soutient donc l'hypothèse centrale de la mission: il y a une activité réseau réelle ici, et la géographie est plus large qu'un serveur de loisir dans une seule pièce. Mais la même empreinte doit être traduite en questions opérationnelles plutôt qu'en confort marketing. Quels ports sont physiques et lesquels sont virtuels? Quels chemins d'échange transportent le trafic client? Quels ports ont une capacité de réserve? Quelles routes sont utilisées uniquement pour la recherche ou les sessions de laboratoire?

Quel amont est responsable lorsque la charge de travail d'un client ne peut être atteinte depuis un réseau commercial grand public? PeeringDB indique aux clients par où commencer à demander; il ne répond pas à lui seul à la question de l'horloge de réparation.

Les installations listées rendent la dépendance physique visible

Les preuves de facilité de PeeringDB sont petites mais concrètes.L'API netfac pour net_id 21500listait trois enregistrements de facilité pour 10VPN: Harbour Centre Vancouver au Canada, Hurricane Electric Fremont 2 aux États-Unis et KoloDC NL1 à Dronten, Pays-Bas. Les pages de facilité spécifiques à PeeringDB ajoutent du contexte:Harbour Centre Vancouverest à Vancouver,Hurricane Electric Fremont 2est à Fremont, etKoloDC NL1est à Dronten.

Ce sont des emplacements significatifs. Vancouver correspond à la piste de contrôle canadienne et au contexte Free Range Cloud. Fremont correspond au rôle de Hurricane Electric dans l'image de routage public. Dronten correspond aux étiquettes de préfixe IPv6 des Pays-Bas visibles dans BGP.tools et Hurricane Electric. Ensemble, ils suggèrent un petit réseau multi-sites assemblé à travers des facilités neutres, des ports d'échange et des arrangements amont.

Mais un enregistrement de facilité n'est pas un titre de propriété, un nombre de baies ou une garantie que les charges de travail des clients se trouvent dans cette salle. Un petit réseau peut avoir une armoire, une baie fractionnée, une interconnexion, un accès mains à distance, un routeur dans la cage d'un autre fournisseur, un port parrainé, un chemin d'échange virtuel, ou une relation de service qui produit une inscription dans PeeringDB. Chaque arrangement change le comportement en cas de panne.

Un routeur sous le contrôle direct de 10VPN peut être redémarré, remplacé ou reconfiguré différemment d'une interconnexion virtuelle contrôlée par un autre fournisseur. Une présence parrainée peut disparaître si le contrat du parrain change. Une baie fractionnée peut dépendre de la file d'attente de mains à distance de la facilité pour même un travail matériel simple.

Le cadre de trois villes soulève également des questions de localisation des données. La société est enregistrée au Royaume-Uni, contrôlée depuis le Canada, et visiblement connectée via le Canada, les États-Unis et les Pays-Bas. C'est normal pour l'infrastructure Internet. Ce n'est pas non plus trivial pour les clients ayant des exigences de localisation des données, de journalisation, de traitement des abus ou juridictionnelles.

Une charge de travail hébergée décrite comme « chez 10VPN » pourrait physiquement se trouver dans une facilité canadienne, américaine, néerlandaise, sur le réseau d'un parrain, ou sur la plateforme d'un autre fournisseur. Les registres publics ne divulguent pas lequel s'applique à un service client particulier.

Si la capacité hébergée n'est qu'un serveur privé virtuel, un point de terminaison de tunnel, un réflecteur de route, un serveur de route, une session de transit ou un serveur de laboratoire, la réponse sur la localisation des données peut être simple. Si elle stocke des données client, authentifie des utilisateurs, journalise le trafic, héberge la messagerie, sauvegarde des fichiers ou transporte des systèmes métier, la réponse doit être écrite dans les conditions de service.

Un client devrait demander quel pays stocke les données principales, quel pays stocke les sauvegardes, quelle équipe de support peut accéder au système, quels journaux sont conservés, et comment les données sont restituées en cas d'annulation.

Les mêmes preuves de facilité façonnent également la fenêtre de réparation. Vancouver, Fremont et Dronten ne sont pas interchangeables du point de vue du client. Un défaut matériel à Fremont peut être facile pour les mains à distance de Hurricane Electric mais loin de la direction canadienne. Un problème de chemin à Dronten peut reposer sur les procédures de la facilité européenne. Une panne à Vancouver peut affecter les hypothèses de plan de contrôle ou de support différemment d'une panne de peering aux Pays-Bas.

Une présence multi-sites peut améliorer la résilience si les charges de travail sont répliquées et les routes conçues pour le basculement. Elle peut aussi compliquer la réparation si chaque site dépend d'une facilité, d'un amont et d'un processus de mains à distance différents.

La liste visible des facilités donne donc à 10VPN une histoire d'infrastructure plus solide qu'un nom purement virtuel. Elle crée également un test client clair: quel site, baie, cage de fournisseur et chemin amont exacts servent le service acheté, et que se passe-t-il lorsque ce site est hors service pendant des heures?

AS209762 ne devrait pas être compté comme capacité client actuelle

L'instantané de la mission nommait à la fois AS49134 et AS209762 sous RIPE, il est donc important de les séparer. AS49134 est actuel dans les preuves de routage public. AS209762 n'est pas actuel de la même manière.L'aperçu AS de RIPEstat pour AS209762a identifié le détenteur comme « EVIX-Route-Server 10VPN Research Network LTD » mais a montré l'ASN comme non annoncé dans la fenêtre de requête du 12 juillet 2026.Le point de terminaison de statut de routage pour AS209762n'a montré aucun espace IPv4 ou IPv6 annoncé actuel, aucun pair le voyant, aucun voisin observé et un préfixe vu pour la dernière fois en septembre 2019.

PeeringDB ajoute l'indice explicatif.Une requête PeeringDB pour ASN 209762retourne « EVIX Route Servers », type Route Server, avec des notes le décrivant comme un serveur de route de sauvegarde pour EVIX situé à Dronten, Pays-Bas, et indiquant qu'il ne devrait pas originer de préfixes. Ce langage est important. Cela signifie qu'AS209762 n'est pas la preuve d'une deuxième plateforme d'hébergement commercial actuelle, ni la preuve d'une autre région orientée client, ni la preuve d'une diversité de route sur laquelle un acheteur peut compter aujourd'hui.

Les serveurs de route et les réflecteurs de route peuvent être une infrastructure cruciale, mais ils jouent un rôle différent de celui d'une plateforme hébergée. Un serveur de route aide les entités à échanger des routes dans un contexte d'Internet exchange sans maintenir de sessions bilatérales avec chaque pair. Un réflecteur de route distribue des informations de route à l'intérieur d'un réseau ou d'un contexte de service. Aucun des deux rôles ne prouve le stockage, le calcul, la sauvegarde, le support client ou la portabilité des données.

En fait, la note de PeeringDB indiquant qu'AS209762 ne devrait pas originer de préfixes est un avertissement contre le traitement de celui-ci comme une origine de production.

Cela importe car les petites entreprises d'infrastructure accumulent souvent des identifiants publics au fil du temps. D'anciens ASN, d'anciennes listes de facilités, des arrangements de parrainage et des noms de serveur de route hérités peuvent rester visibles longtemps après que leur signification commerciale a changé. Un acheteur qui voit deux ASNs peut supposer une redondance.

La meilleure lecture est plus étroite: AS49134 est l'origine actuelle avec une visibilité IPv6; AS209762 est historique ou associé à un serveur de route dans les vues de routage public et ne devrait pas être compté comme une capacité client actuelle sans preuve récente du fournisseur.

La même prudence s'applique aux nombres d'échanges et aux nombres de préfixes. Les vues publiques peuvent différer. Hurricane Electric listait huit préfixes annoncés au total, dont quatre IPv4 et quatre IPv6, tandis que sa vue originait montrait zéro IPv4 et quatre IPv6. La vue des préfixes annoncés originaits de RIPEstat montrait quatre préfixes IPv6 actuels et aucun IPv4 originait par AS49134. Un client ne devrait pas transformer ces différences en un jeu de reproches. Les collecteurs de routes publiques voient différentes positions de chemin et utilisent différentes définitions.

La conclusion opérationnelle est simple: demander les préfixes exacts, la famille d'adresses, l'ASN d'origine et le chemin amont attribués au service acheté, puis les tester depuis des réseaux externes.

AS209762 abaisse donc, plutôt qu'augmente, la note de résilience. Il montre un historique technique et une implication de serveur de route, mais il ne prouve pas le basculement client. La meilleure preuve actuelle reste AS49134, le profil AS49134 de PeeringDB et les enregistrements visibles de facilité et d'échange attachés à ce réseau.

L'affirmation de service hébergé est plausible mais publique sous-documentée

Le dossier de service hébergé pour 10VPN repose sur trois types de preuves. Premièrement, Companies House classe la société sous le code SIC 63110, traitement de données, hébergement et activités connexes. Deuxièmement, PeeringDB présente AS49134 comme un réseau réel avec des facilités et une présence d'échange plutôt qu'un simple nom de domaine. Troisièmement, BGP.tools et Hurricane Electric montrent une propagation de route en direct, des amonts et des préfixes IPv6 originaits. Ensemble, ces faits justifient d'examiner 10VPN comme une dépendance de capacité hébergée. Ils ne justifient pas de la décrire comme une plateforme cloud mature.

Ce qui manque est tout aussi important que ce qui est présent. Les sources publiques ne montrent pas de pages produit pour des niveaux de calcul nommés, des classes de stockage, des services de sauvegarde, des tableaux de bord clients, des conditions de niveau de service, des heures de support, un historique d'état, des divulgations de région de centre de données, des nombres de baies physiques, des politiques de remplacement matériel ou des procédures d'exportation de données. Le champ site web dans PeeringDB pointe vers10vpn.net, et les pages de routage public lient un looking glass àhttps://lg.10vpn.net, mais les requêtes HTTP et HTTPS directes vers le domaine principal ont expiré depuis cet environnement lors de la recherche pour cet article. Cela ne doit pas être traité comme une affirmation de panne universelle, car un point d'observation peut être bloqué ou mal routé. Cela renforce cependant la règle selon laquelle la surface web publique n'est pas assez solide pour porter une affirmation de service de haute confiance.

Les comptes dormants font le même point sous un autre angle. Une société peut détenir un ASN, participer au peering et se classer dans l'hébergement tout en ayant peu de revenus clients dans la société britannique. Elle peut exploiter un réseau de recherche pour l'apprentissage, la communauté, le parrainage, les expériences de peering ou de petits services hébergés. Elle peut également supporter des clients via une autre société ou un arrangement informel. Ces possibilités ne présentent pas le même risque pour un acheteur. Une entreprise qui n'a besoin que d'un tunnel IPv6 pour le travail en laboratoire peut tolérer l'ambiguïté.

Une entreprise qui a besoin de systèmes de production hébergés, de service de messagerie, d'accès aux paiements, d'accès à distance ou de stockage de données clients ne le peut pas.

Le mot « hébergé » doit donc être traduit en actifs concrets. Si le service est un VPS, quel hôte physique et quel pool de stockage l'exécutent? Si le service est du transit, quel amont transporte le trafic par défaut et que se passe-t-il lorsqu'un chemin tombe? Si le service est de la colocation, quelle baie, circuit d'alimentation et processus de mains à distance s'appliquent? Si le service est un tunnel, quel point de terminaison, serveur de route et processus d'abus s'appliquent? Si le service est un DNS géré, un courrier ou un hébergement d'application, comment les sauvegardes sont-elles effectuées et comment un client peut-il partir?

C'est là que les petits réseaux peuvent être à la fois utiles et risqués. Un petit réseau technique peut répondre plus rapidement, peer plus ouvertement et expliquer les détails de routage plus honnêtement qu'un grand fournisseur. Il peut supporter IPv6 d'une manière que les grands hôtes de détail négligent encore. Il peut également manquer de couverture de support formelle, d'inventaire de rechange, de continuité de facturation et d'automatisation de remplacement. Le registre public autour de 10VPN montre le côté technique plus clairement que le côté gestion de service.

La note opérationnelle doit donc être divisée. Pour « existe-t-il un réseau public actuel sous AS49134? » la réponse est oui. Pour « le registre public prouve-t-il une plateforme de service hébergé résiliente? » la réponse est non. Pour « un client techniquement sophistiqué pourrait-il utiliser 10VPN pour la recherche, le peering, le tunnel ou de petits besoins hébergés après une diligence raisonnable? » les preuves publiques rendent cela plausible, mais le client doit confirmer la limite de service avant de le traiter comme une infrastructure de production.

La capacité installée et la capacité utilisable sont différentes ici

La capacité installée est ce à quoi un réseau peut pointer: ASNs, préfixes, ports d'échange, facilités, amonts, sécurité de routage et enregistrements de peering public. La capacité utilisable est ce qui reste lorsqu'une baie perd de l'alimentation, qu'un chemin d'échange virtuel est retiré, qu'un contrat de parrain change, qu'un amont se congestionne, qu'un routeur meurt, qu'une facture échoue, qu'un domaine ne répond pas, ou que la seule personne qui connaît la configuration est indisponible.

Le registre public de 10VPN est un cas d'étude utile car la capacité installée est visible tandis que la capacité utilisable est en grande partie non divulguée.

Le côté installé est réel. PeeringDB liste seize enregistrements de LAN d'échange et trois enregistrements de facilité. RIPEstat montre une accessibilité IPv6 en direct. La validation RPKI est valide pour les origines IPv6 testées. Hurricane Electric voit 29 pairs BGP et un RPKI IPv6 originait valide. BGP.tools liste les amonts et les pairs, et sa vue de route nomme Hurricane Electric et Free Range Cloud dans des positions de chemin importantes. Ce ne sont pas des affirmations marketing vides.

Le côté utilisable est incertain. La bande de trafic 100-1000 Mb/s de PeeringDB est large. Elle pourrait décrire un réseau de recherche modeste mais utile, pas un domaine d'hébergement client. Les vitesses de port d'échange incluent de nombreuses entrées à 100 Mb/s. Un port à 100 Mb/s peut être parfaitement adéquat pour un laboratoire ou une présence de serveur de route mais peut devenir un goulot d'étranglement pour les charges de travail client après un reroutage. Un port à 1 Gb/s peut absorber le trafic normal mais peut ne pas transporter tout le trafic si un deuxième site tombe en panne.

Une entrée d'échange à 10 Gb/s peut sembler impressionnante mais peut encore être virtuelle, distante ou limitée par la politique amont.

L'image d'origine actuelle IPv6-only importe également. Un client peut voir l'accessibilité de route d'AS49134 et supposer un service double pile. Les preuves publiques ne soutiennent pas cette hypothèse sans confirmation du fournisseur. Si la charge de travail du client a besoin d'IPv4, le service réel peut dépendre d'un autre ASN, d'un parrain, d'un NAT, d'un tunnel, d'un préfixe emprunté, d'un amont virtuel ou d'un bloc d'adresses attribué par le fournisseur non originait par AS49134. Chaque option change le contrôle de routage et le risque de portabilité des données.

La liste des facilités nécessite également une traduction. Trois facilités listées ne prouvent pas trois régions d'hébergement synchronisées. Une architecture multi-sites n'améliore la récupération que si les services sont répliqués, les routes conçues pour le basculement, les données client cohérentes et le support capable de déplacer rapidement les charges de travail. Si chaque site est un petit point d'interconnexion spécialisé, une panne peut être survivable pour des expériences de route mais pas pour une application client.

Si le service client se trouve dans un seul des trois sites, les deux autres ne raccourcissent pas la fenêtre de réparation à moins qu'ils n'aient la capacité, les images, les sauvegardes et les droits d'accès prêts.

Le client devrait donc demander une déclaration de capacité spécifique à la panne, et non un résumé réseau général. « Pouvez-vous survivre à une panne d'un seul amont? » est mieux que « Avez-vous des pairs? » « Pouvez-vous déplacer mon service de Dronten à Fremont sans changer les données ou l'adressage IP? » est mieux que « Avez-vous des facilités? » « Quelle capacité de port et de transit engagée reste-t-il après la panne du plus grand lien? » est mieux que « Avez-vous une entrée d'échange 10G? » La capacité installée ne devient utile que lorsqu'elle est cartographiée sur le chemin de panne du client.

Les chemins de panne les plus probables sont ordinaires, pas exotiques

Les plus grands risques pour un petit réseau hébergé sont rarement dramatiques. Ce sont des dépendances ordinaires qui n'ont pas été documentées. Dans le cas de 10VPN, les preuves publiques pointent vers sept chemins de panne pratiques: interruption de baie ou de facilité, perte d'amont, congestion de port d'échange, pénurie de stock matériel, retard de support, friction de facturation ou de continuité d'entreprise, et difficulté de migration.

Le chemin de baie et de facilité est le plus simple. Un routeur, serveur, commutateur, alimentation ou interconnexion à Vancouver, Fremont ou Dronten tombe en panne. Si le service y est directement hébergé, le client perd l'accessibilité ou les performances. Si la facilité ne fournit que le peering, l'effet peut être plus étroit. L'inconnue clé est le contrôle. 10VPN possède-t-il le matériel? Est-il dans une baie d'un parrain? La facilité fournit-elle des mains à distance? Y a-t-il un routeur de rechange sur site? Les configurations sont-elles sauvegardées ailleurs que sur le site en panne?

Les registres publics ne répondent pas à ces questions.

Le chemin amont est visible mais pas résolu. RIPEstat et BGP.tools montrent AS53356 et AS6939 dans des rôles de chemin importants. Cela suggère que Free Range Cloud et Hurricane Electric sont centraux pour l'accessibilité. Si un amont retire des routes, le réseau peut continuer à fonctionner sur l'autre. Si un chemin transporte une famille d'adresses ou un site particulier, le basculement peut être partiel. Si le client dépend d'IPv4 via un parrain, les preuves d'origine IPv6 actuelles d'AS49134 peuvent ne pas décrire du tout le chemin client.

La congestion de port d'échange est le troisième chemin. Le peering ouvert peut améliorer la diversité des routes, mais les petites tailles de port peuvent créer des détours fragiles. Une route qui fonctionne en trafic normal peut devenir mauvaise après une panne si le trafic se déplace sur un port à 100 Mb/s. Les serveurs de route d'échange peuvent également changer de comportement pendant la maintenance ou le filtrage. Un client qui paie pour un service hébergé devrait savoir quels chemins sont du peering au mieux et quels chemins sont du transit payant.

Le stock matériel est le quatrième chemin. Les sources publiques ne révèlent pas si 10VPN conserve des routeurs de rechange, des optiques, des SSD, des alimentations ou des serveurs de remplacement dans une installation. Pour un petit réseau, c'est souvent la différence entre un travail de mains à distance d'une heure et une panne de plusieurs jours. Même si les sauvegardes de configuration existent, un routeur en panne ne peut pas transmettre de paquets tant qu'un remplacement n'est pas installé et accepté par la facilité et les amonts.

Le support est le cinquième chemin. Les pages publiques n'ont pas exposé une surface de support mature lors de cette recherche. Cela ne signifie pas qu'aucun support n'existe; de nombreux petits fournisseurs gèrent le support via un contact direct, des tickets ou des canaux affiliés. Mais le client ne devrait pas supposer une réponse 24/7, un support téléphonique, des mises à jour de statut ou une escalade formelle à moins qu'un contrat ne le stipule. Plus le réseau est petit, plus il est important de savoir qui peut agir lors d'un problème d'alimentation le dimanche ou d'une fuite de route à minuit.

La facturation et la continuité sont le sixième chemin. Les comptes britanniques dormants, les rôles de parrain et le contrôle transfrontalier ne prouvent pas l'instabilité. Ils rendent cependant important de savoir quelle société facture le service, quelle partie possède les données client, quelle partie contrôle le domaine, et ce qui se passe si la société britannique reste active mais qu'un autre arrangement opérationnel change. Les pannes d'hébergement sont parfois administratives avant d'être techniques.

La migration est le septième chemin. Si un client doit partir, peut-il exporter les données, conserver les adresses IP, déplacer le DNS, préserver la messagerie, déplacer les tunnels, récupérer les sauvegardes et fermer les comptes sans perdre de service? Les registres publics ne décrivent pas ces chemins. Un petit réseau peut être très flexible s'il a un opérateur coopératif. Il peut aussi être difficile à quitter si les adresses, les routes et le stockage sont tous informels.

Qui est affecté dépend de la limite de service

Les personnes affectées par une panne de 10VPN varient considérablement selon ce que 10VPN fournit réellement. C'est pourquoi ce profil évite de traiter l'entreprise comme un cloud générique. Un entité à un serveur de route, un utilisateur de tunnel, un client VPS, un client de colocation, un client de transit et un pair de recherche vivent tous une panne différemment.

Pour un utilisateur de peering ou de recherche, le principal préjudice peut être la perte de visibilité de route, de disponibilité de tunnel, de connectivité de laboratoire ou de participation au serveur de route. Cela peut interrompre les expériences et la surveillance, mais peut ne pas affecter les clients publics. Pour un petit utilisateur d'hébergement, le préjudice est plus direct: une application s'arrête, la messagerie fait la queue, les modifications DNS échouent, les journaux sont perdus, ou un panneau d'administration distant devient inaccessible.

Pour un client de transit, le préjudice est l'isolation réseau ou une accessibilité dégradée. Pour un client de colocation, le préjudice est l'accès physique et la continuité d'alimentation. Pour une entreprise dépendant d'un service IPv4 couche autour d'AS49134, le préjudice peut être plus complexe car les preuves d'origine publique sont les plus solides pour IPv6.

L'empreinte transfrontalière modifie l'impact sur l'utilisateur. Un opérateur canadien contrôlant une société britannique avec une présence au Canada, aux États-Unis et aux Pays-Bas peut servir des utilisateurs mondiaux, mais cela crée également des questions sur la loi, le traitement des données et l'accès d'urgence. Si les données sont stockées à Dronten et que le support est en Colombie-Britannique, la réparation peut traverser les fuseaux horaires. Si un utilisateur est en Europe mais que le point de contrôle est au Canada, les attentes en matière de confidentialité et de support doivent être explicites.

Si un utilisateur est en Amérique du Nord mais qu'une route critique dépend d'un échange européen, la latence et les fenêtres de maintenance peuvent le surprendre.

Le DNS public et le comportement web ajoutent une préoccupation plus étroite. Le domaine principal 10vpn.net résolvait des adresses A et AAAA publiques lors des vérifications locales, mais les requêtes HTTP et HTTPS vers le site racine ont expiré depuis cet environnement. Un seul point d'observation ne peut pas prouver une panne de service générale, surtout pour un réseau qui peut filtrer le trafic ou router différemment selon l'emplacement. Néanmoins, la leçon pour le client est juste: ne pas compter sur le site web du fournisseur ou le lien looking glass comme seul canal d'urgence.

Conserver les coordonnées hors bande, les dossiers de contrat, les identifiants DNS, les exportations de sauvegarde et les détails de route dans un endroit qui reste accessible lorsque le chemin du fournisseur est en panne.

C'est particulièrement important pour les petits réseaux car les canaux de support et de contrôle peuvent partager la même infrastructure. Si le site web, la messagerie, le ticketing et le service hébergé dépendent tous de la même baie ou du même amont, une panne peut supprimer à la fois le service et la route pour demander de l'aide. Une configuration résiliente sépare la communication client du réseau affecté. Les sources publiques ne montrent pas si 10VPN dispose de cette séparation.

Pour les clients, la population affectée devrait être définie avant l'achat. Le service est-il destiné à l'expérimentation, aux projets personnels, aux outils internes, aux sites web publics, aux données clients, à la voix, aux paiements, à la surveillance ou aux charges de travail réglementées? Le profil réseau public de 10VPN peut être acceptable pour certains de ces usages et inapproprié pour d'autres. La différence n'est pas la réputation de la marque; c'est la distance entre la tolérance du client pour les temps d'arrêt et le système de récupération documenté du fournisseur.

Ce qui améliorerait la note de preuve

La note de preuve de 10VPN pourrait s'améliorer rapidement avec une quantité modeste de clarté publique. Le réseau n'a pas besoin de ressembler à un fournisseur hyperscale pour être crédible. Il doit montrer ce qu'il vend réellement, où il fonctionne, et comment les clients récupèrent. Le registre de routage public donne déjà une base. Les pièces manquantes sont la limite de service et les preuves de réparation.

La première amélioration serait une page de services actuelle qui distingue le peering de recherche, les tunnels, le transit, la colocation, le VPS, le bare metal, les services gérés et toute autre offre hébergée. Chaque service devrait nommer la famille d'adresses, le site, la dépendance amont, la partie facturante, le canal de support et le chemin d'annulation. Une page courte et actuelle serait plus précieuse qu'un langage marketing large.

La deuxième amélioration serait une note sur les facilités et l'architecture. Elle n'aurait pas besoin de révéler des diagrammes sensibles. Elle pourrait dire quelles installations listées sont physiques, lesquelles sont virtuelles ou distantes, lesquelles hébergent des charges de travail clients, lesquelles fournissent uniquement de l'interconnexion, et lesquelles ont une capacité de réserve. Pour un petit réseau, l'honnêteté importe plus que l'échelle. Un client peut planifier autour d'une seule baie si la baie est divulguée. Il ne peut pas planifier autour d'une présence globale vague.

La troisième amélioration serait une note de récupération. Comment les configurations des routeurs sont-elles sauvegardées? Y a-t-il des dispositifs de rechange à Vancouver, Fremont ou Dronten? Quel est le processus de mains à distance? Quels amonts sont du transit payant et lesquels sont des pairs au mieux? Y a-t-il une page de statut en dehors du réseau 10VPN? Comment les données client sont-elles exportées? Quel contact reste utilisable lors d'une panne de routage?

La quatrième amélioration serait une clarté financière et juridique. La société britannique est active, mais les comptes dormants jusqu'en 2025 laissent ouverte la question de savoir où se produisent les transactions opérationnelles. Si les clients sont facturés par 10VPN Research Network LTD, cela devrait être reflété dans les conditions. S'ils sont facturés par une autre société ou un arrangement informel, cela devrait être explicite. L'enveloppe de service légale fait partie de la résilience de l'infrastructure car elle décide qui peut rembourser, migrer, libérer des données ou résoudre des litiges.

La cinquième amélioration serait une divulgation fraîche des routes et des ports. PeeringDB listait déjà des mises à jour récentes en juillet 2026. Une page de statut ou de réseau qui confirme l'ensemble de préfixes AS49134 prévu, la posture IPv4, la posture IPv6, les ports d'échange et les amonts réduirait l'ambiguïté. Si IPv4 est intentionnellement absent de l'espace originait, dites-le. Si le service IPv4 est disponible via un autre chemin, expliquez la limite.

Jusqu'à ce que ces améliorations apparaissent, la note de preuve reste divisée. AS49134 est réel et actif. Le RPKI est valide pour les origines IPv6 testées. PeeringDB montre une présence d'échange et de facilité significative. Companies House confirme une société britannique active. Ce sont de bons faits. Le déclassement provient des dépôts dormants, d'une surface de service public mince, de preuves de service IPv4 non résolues, d'informations de support public limitées et d'aucune conception de récupération divulguée.

La conclusion pratique est un oui étroit, pas un oui large

10VPN Research Network LTD doit être traité comme un vrai petit réseau, pas comme une étiquette VPN générique et pas comme une plateforme cloud entièrement documentée. L'affirmation du titre est intentionnellement spécifique: si 10VPN vend une capacité hébergée, cette capacité dépend toujours de baies, de transit et de fenêtres de réparation. Les preuves publiques nous permettent d'identifier certaines de ces dépendances. Elles ne nous permettent pas de les marquer comme entièrement contrôlées, redondantes ou prêtes pour la production client.

Les faits positifs les plus forts sont concrets. Companies House liste une société active constituée en 2019 avec un code SIC lié à l'hébergement. RIPEstat montre AS49134 annoncé et visible pour IPv6 le 12 juillet 2026. PeeringDB liste un réseau éducatif/recherche mondial avec peering ouvert, trois facilités et seize enregistrements de LAN d'échange. Hurricane Electric et BGP.tools corroborent quatre préfixes IPv6 originaits, aucun IPv4 originait dans leurs vues résumées, des amonts et pairs observés, et un RPKI valide pour l'espace IPv6 originait.

AS209762 est expliqué comme lié à un serveur de route plutôt que comme une capacité client actuelle.

Les faits prudents les plus forts sont également concrets. La société britannique a déposé des comptes dormants jusqu'en 2025. Le profil réseau public est éducatif/recherche et à faible trafic selon la bande PeeringDB. Les enregistrements de facilité ne divulguent pas la propriété des baies ou le placement des charges de travail clients. Les enregistrements d'échange ne prouvent pas une capacité de réserve. Le service IPv4 n'est pas prouvé par l'ensemble d'origine d'AS49134. Les conditions de support public, de sauvegarde, de migration et de niveau de service n'étaient pas évidentes à partir des sources examinées ici.

Pour un client, la décision devrait dépendre du cas d'utilisation. 10VPN peut être un choix raisonnable pour le routage de recherche, les expériences IPv6, la pratique de peering, les petits services techniques ou une relation spécialisée avec quelqu'un qui comprend les compromis opérationnels. Il n'est pas publiquement prouvé comme fournisseur pour des données réglementées, des systèmes hébergés critiques pour l'entreprise ou des charges de travail nécessitant un support 24/7 formel et une récupération cross-site documentée.

Le test de l'acheteur est donc simple et exigeant. Demandez à 10VPN de mapper le service acheté à un site physique, un ASN d'origine, une famille d'adresses, un plan amont, un plan de sauvegarde, un plan de support, une partie facturante et un chemin de sortie. Si la réponse est claire, le modèle de petit réseau peut être jugé sur ses mérites. Si la réponse est vague, les preuves publiques doivent être lues comme un avertissement: la route peut être visible, mais une capacité hébergée récupérable n'a pas été prouvée.