CLOUDNET INTERNET SERVICE PVT LTD est un FAI visible du Tamil Nadu, pas un hébergeur cloud documenté

Résumé

• Le Département des télécommunications de l’Inde a inscrit Cloudnet Internet Service Private Limited comme titulaire d’une autorisation de service Internet de catégorie B pour le Tamil Nadu, en vigueur depuis le 10 avril 2023. Des pages de données d’entreprise relient la même adresse et les mêmes coordonnées à une société de Chennai constituée en 2021. Cela établit une identité réglementée de FAI, et non un portefeuille de produits d’informatique en nuage.
• AS150069 était actif le 10 juillet 2026, en annonçant103.21.6.0/23, les deux routes composantes/24et2001:df1:66c0::/48. L’agrégat IPv4 était visible depuis octobre 2022 et la route IPv6 depuis novembre 2022. L’autorisation de route actuelle était valide selon RPKI, et les enregistrements de registre avaient été maintenus récemment.
• Les collecteurs de routes publics n’ont montré qu’un seul voisin immédiat pour AS150069: l’AS132774 de Niss Internet Services Private Limited. Cela constitue la preuve d’un seul chemin de routage externe visible, et non la preuve que Cloudnet n’a pas d’interconnexion privée ou de circuit de secours. Ce n’est pas non plus une preuve de diversité de routage physique, de basculement automatique ou de capacité excédentaire.
• IPinfo caractérise AS150069 comme un FAI grand public avec un rythme de trafic jour-nuit prononcé et ne signale qu’un seul domaine hébergé dans l’espace d’adressage. Ce sont des signaux utiles, pas des chiffres audités de clients ou de produits. Aucun catalogue de services, emplacement de centre de données, inventaire de baies, offre de machine virtuelle, offre bare-metal, service de stockage, engagement de disponibilité, politique de sauvegarde ou procédure de migration publics de Cloudnet n’a été trouvé.
• La rétrogradation responsable consiste donc à passer d’un présumé opérateur cloud à un petit FAI du Tamil Nadu actuellement routé, dont l’empreinte commerciale et le réseau physique exacts restent non divulgués. Sa résilience dépend de l’infrastructure d’accès locale, des équipements d’agrégation alimentés, du raccordement à Niss, de la connectivité en amont de Niss et de la main-d’œuvre de support. Des preuves de charges de travail hébergées réelles seraient nécessaires avant de discuter de Cloudnet en tant que fournisseur cloud.

L’hypothèse du cloud échoue à la première question produit

Le mot « Cloudnet » peut faire trop de travail si on le laisse faire. Il combine deux éléments de vocabulaire réseau à la mode, et la société contrôle des ressources de numérotation Internet. Ni l’un ni l’autre ne montre qu’un client peut acheter une machine virtuelle, une base de données gérée, un compartiment de stockage, un serveur bare-metal ou même un compte d’hébergement web classique. La distinction est importante car un service cloud a des obligations de défaillance et de récupération qu’un fournisseur d’accès peut n’avoir jamais souscrites.

Le document public le plus solide spécifique à l’entreprise n’est pas un catalogue cloud. Il s’agit de laliste des autorisations de services Internet du Département des télécommunications au 31 janvier 2025. L’entrée identifie Cloudnet Internet Service Private Limited, numéro de licenceDS-11/401/2022-DS-III, catégorie B, zone de service Tamil Nadu, avec une date d’effet au 10 avril 2023. Le contact autorisé, l’adresse du siège social et le numéro de téléphone correspondent aux dossiers de l’entreprise et aux registres Internet.

Lapage des services Internet du Départementexplique ce que signifie la catégorie B. C’est l’autorisation de fournir un service Internet dans une zone de service autorisée, définie comme un cercle télécom ou une zone métropolitaine. Lerecueil des licences unifiéesdécrit l’accès à Internet, l’IPTV et des formes spécifiques de téléphonie sur Internet dans le cadre de l’autorisation. La licence est une preuve matérielle que Cloudnet peut opérer comme FAI dans le Tamil Nadu. Elle ne certifie pas que l’entreprise a construit une couverture à l’échelle de l’État, et elle ne transforme pas une autorisation d’accès en preuve d’hébergement informatique.

Les enregistrements réseau vont dans le même sens.L’aperçu d’IPinfo pour AS150069qualifie le réseau de FAI grand public et trouve un rythme d’activité quotidien prononcé du type associé aux personnes utilisant une connexion pendant les heures de veille. Il signale un domaine hébergé, contre 512 adresses IPv4. Le nombre de domaines hébergés a des limites de mesure: un domaine peut se cacher derrière un réseau de diffusion de contenu, une adresse peut héberger de nombreux noms, un service privé peut ne pas être découvrable, et les clients d’accès peuvent exécuter des serveurs. Même avec ces réserves, un domaine observé n’est pas une preuve affirmative d’un parc d’hébergement.

L’empreinte publique de Cloudnet ne donne aucun prix ni spécification pour le calcul, le stockage, la sauvegarde, la colocation ou l’infrastructure gérée. Aucune adresse de centre de données n’est nommée. Aucun fournisseur de serveur, nombre de baies, conception électrique, certification, zone de disponibilité, portail client, accord de niveau de service, annexe sur le traitement des données, historique des incidents, objectif de restauration ou format d’exportation n’est décrit. Une entreprise peut vendre en privé sans documenter chaque service sur le web ouvert, mais la charge de la preuve ne s’inverse pas. En l’absence d’un produit et d’une surface d’exploitation, l’affirmation « cloud » doit être abandonnée plutôt qu’embellie.

Cela laisse une histoire différente et plus fondée. Cloudnet a un système autonome actif, une autorisation de FAI du Tamil Nadu, une petite allocation IPv4, une allocation IPv6 et une dépendance amont visible. Ce sont les os d’un réseau d’accès. L’infrastructure physique qui les sous-tend est largement inconnue, ce qui rend la résilience plus difficile à évaluer mais ne rend pas le réseau imaginaire.

Une société de Chennai et une autorisation du Tamil Nadu

Des agrégateurs d’entreprises identifient Cloudnet Internet Service Private Limited par le numéro d’identification d’entrepriseU64120TN2021PTC142654.La page de l’entreprise sur Toflerdate sa constitution au 8 avril 2021, indique un capital social autorisé de 1 million de roupies et un capital libéré de 100 000 roupies, et nomme Logasundari et Gopikrishnan comme administrateurs.L’enregistrement de ZaubaCorpfournit le même CIN, l’enregistrement à Chennai et l’adresse de Kottivakkam, bien que certains champs de date dans ses résumés soient incohérents et ne doivent pas être traités comme un substitut d’un dépôt actuel.

L’adresse est particulièrement utile pour la résolution d’identité. La liste des licences place la société au troisième étage de la parcelle 11/236A, Vivekanandar Third Street, Kottivakkam, Chennai.L’enregistrement APNIC de AS150069utilise le nom légal abrégé, CLOUDNET INTERNET SERVICE PVT LTD, et son rôle administratif répète la même adresse et le même numéro de téléphone. L’enregistrement de l’allocation IPv4etcelui de l’allocation IPv6portent le même nom de réseau,CNISPL, et la même chaîne de contacts. Il ne s’agit pas simplement d’entreprises similaires partageant un nom générique; les enregistrements convergent vers une seule entreprise.

Cette convergence exclut également plusieurs homonymes. Un autre Cloudnet Broadband Services Private Limited apparaît dans des documents de licence plus anciens de l’Haryana, et Cloudnet Communications Private Limited apparaît dans des tableaux d’abonnés. D’autres entreprises ailleurs utilisent Cloud Net ou Cloudnet comme nom commercial. Ils ne doivent pas être utilisés pour combler les lacunes du catalogue de services, du nombre de clients ou de l’historique de cette société. L’ancrage d’identité ici est la licence du Tamil Nadu, le CIN, l’adresse de Kottivakkam et AS150069.

La liste DoT de 2025 est une preuve d’une autorisation à cette date de rapport. Ce n’est pas un certificat d’exploitation quotidien pour juillet 2026. En revanche, les routes actives et les objets de registre Internet récemment maintenus fournissent des preuves techniques beaucoup plus fraîches. L’entreprise ne doit donc pas être décrite comme simplement enregistrée ou historiquement licenciée. Son système autonome portait une annonce visible mondialement au moment de l’observation.

L’adresse ne répond toujours pas à la question de savoir où se trouve l’équipement réseau. Un siège social peut être un bureau administratif, un point de présence, les deux, ou ni l’un ni l’autre. L’enregistrement IPv4 inclut les coordonnées13.427804, 80.14154212, mais la géolocalisation de registre est une métadonnée fournie par l’opérateur, pas une enquête sur une salle de routeurs. IPinfo place plusieurs adresses ou routeurs observés dans et autour de Chennai et Nagari, tandis que ses sondes récentes ont atteint des adresses répondant depuis des points de vue de la région de Chennai. Une telle géolocalisation est probabiliste. Elle ne peut pas identifier un terminal de ligne optique, prouver la propriété d’un trajet de fibre ou établir qu’un client est desservi à une rue particulière.

L’énoncé géographique défendable est par conséquent étroit. Cloudnet est autorisé pour la zone de service du Tamil Nadu, enregistré à Chennai et exploite un espace d’adressage que des mesures indépendantes associent à l’Inde et à la région de Chennai. Les preuves publiques ne cartographient pas son empreinte commerciale à l’intérieur du Tamil Nadu, ne montrent pas qu’il dessert tout Chennai, ni ne divulguent un point de présence au-delà de l’adresse enregistrée.

AS150069 fournit des preuves d’exploitation actuelles

Un système autonome est une unité de politique de routage, pas une entreprise complète. Pourtant, AS150069 est la preuve la plus claire que Cloudnet exploite quelque chose actuellement.L’aperçu AS de RIPEstata signalé l’ASN comme annoncé le 10 juillet 2026. Saréponse de préfixes annoncésa listé l’agrégat IPv4103.21.6.0/23, les deux routes plus spécifiques103.21.6.0/24et103.21.7.0/24, et le préfixe IPv62001:df1:66c0::/48.

L’agrégat IPv4 contient 512 adresses.L’état de routage actuela montré AS150069 comme la seule origine visible pour le/23, vu par 326 des 327 pairs IPv4 déclarants. Il a également montré les deux/24sous l’agrégat. Des réponses d’état distinctes pour103.21.6.0/24et103.21.7.0/24ont enregistré la même origine et la même visibilité. Ce n’était pas une trace visible par un seul observateur.

La chronologie est substantielle.L’historique de routage pour le/23commence l’annonce de l’agrégat de Cloudnet en octobre 2022 et la poursuit jusqu’à la date de recherche. Les deux/24sont apparus pour la première fois en décembre 2022. Leur visibilité a fortement chuté pendant une période commençant en mars 2025 tandis que le/23couvrant restait largement visible, puis est revenue à une large visibilité en mai 2026. C’est un changement de granularité de route et de propagation, pas une preuve que le service client s’est arrêté. Le trafic adressé aux deux blocs pouvait encore suivre l’agrégat couvrant lorsqu’une route plus spécifique n’était pas visible.

L’IPv6 n’est pas seulement une réservation de registre.L’état de routage pour2001:df1:66c0::/48a montré AS150069 annonçant le préfixe à tous les 321 pairs IPv6 déclarants le 10 juillet. La route a été vue pour la première fois en novembre 2022. L’objet de route APNIC a été modifié le 8 juillet 2026, deux jours avant l’observation, et l’enregistrement de contact associé avait également été mis à jour en juin. Ces dates montrent une administration continue des ressources. Elles ne nous disent pas combien de trafic client utilise IPv6 ni combien d’utilisateurs le reçoivent.

La distinction entre capacité installée et utilisable est essentielle. Un/23est un pool d’adresses, pas un achat de bande passante. Cinq cent douze adresses IPv4 ne signifient pas 512 clients, serveurs, ports ou mégabits. Un fournisseur peut utiliser des adresses pour des interfaces de routeur, des pools NAT de niveau opérateur, des circuits d’affaires, de l’infrastructure ou un inventaire de réserve. Un foyer peut utiliser plusieurs adresses publiques; de nombreux foyers peuvent partager une adresse. Le nombre presque incompréhensiblement plus grand d’adresses numériques à l’intérieur d’un/48IPv6 est encore moins utile comme mesure de capacité.

Trois annonces IPv4 simultanées ne triplent pas non plus le réseau. Le/23et ses deux/24composants couvrent le même espace d’adressage. Des annonces plus spécifiques peuvent soutenir une politique de routage, de l’ingénierie de trafic ou une transition opérationnelle, mais les données de routage visibles ne révèlent pas quel but s’applique. Compter l’agrégat et les composants comme 1 024 adresses IPv4 uniques reviendrait à compter deux fois les mêmes 512 adresses.

Les routes actuelles soutiennent un réseau réel et actif. Elles ne montrent pas la technologie d’accès des abonnés, le nombre de ports, le transit agrégé, l’utilisation de pointe, la contention, le backhaul, la capacité de cache ou la vitesse du service. Ces quantités déterminent si une connexion vendue est utilisable au pic du soir. Aucune ne peut être calculée à partir de l’ASN.

Un voisin immédiat est la frontière externe visible

Lavue des voisins d’AS de RIPEstata trouvé un seul voisin immédiat le 10 juillet 2026: AS132774. APNIC identifie cet ASN commeNiss Internet Services Private Limited, un réseau du Tamil Nadu enregistré à Tirunelveli. Lavue AS150069 du rapport CIDRmontre indépendamment la même adjacence et aucun ASN en aval.

Les collecteurs de routes voient la topologie, pas les contrats. Un AS directement précédant Cloudnet dans les chemins observés est compatible avec le fait que Niss fournisse du transit, du routage géré ou une autre forme de portée amont. Cela ne révèle pas le prix, la bande passante engagée, les conditions de burst, le raccordement physique, le fournisseur de fibre, le préavis, l’obligation de restauration ou si Cloudnet achète le service directement. Le label commercial « amont » est une inférence raisonnable ici, mais le résultat public est strictement un seul voisin BGP externe visible.

La distinction devient importante lorsqu’on parle de redondance. Un seul voisin visible est une preuve contre l’affirmation d’une diversité amont démontrée publiquement. Ce n’est pas une preuve que Cloudnet n’a qu’un seul câble. Cloudnet pourrait avoir deux circuits physiquement séparés dans différents routeurs Niss tout en présentant le même chemin ASN. Il pourrait avoir une session de sauvegarde qui était inactive au moment de l’observation. Il pourrait recevoir une route par défaut sur une connexion non visible par les collecteurs. Inversement, plusieurs sessions BGP vers un seul fournisseur pourraient converger sur un seul conduit, bâtiment, routeur ou domaine d’alimentation. Le nombre de sessions et la diversité physique sont des choses différentes.

Niss elle-même a une topologie plus large. Sonentrée PeeringDBliste le peering NIXI Chennai et des installations à Chennai et Tirunelveli, tandis quebgp.toolsliste plusieurs amonts pour AS132774. Ce sont des faits autodéclarés et observés à propos de Niss, pas des propriétés héritées de Cloudnet. Un paquet de Cloudnet peut bénéficier des options de Niss après avoir atteint AS132774, mais le fait que Niss ait plusieurs amonts ne prouve pas que Cloudnet a deux moyens indépendants d’atteindre Niss.

Lavue en temps réel de RIPEstat pour le/23a placé à plusieurs reprises AS132774 immédiatement avant AS150069 dans les chemins collectés. De nombreux chemins passaient ensuite par AS9498 de Bharti Airtel au-delà de Niss. Cela indique la chaîne visible à ce moment-là: Cloudnet, Niss, puis des réseaux de transit plus grands. Cela ne signifie pas que Cloudnet a un contrat direct avec Airtel, et cela n’établit pas où le raccordement physique a lieu.

Cette frontière crée un mécanisme de défaillance clair. Si le seul raccordement actif de Cloudnet vers Niss échoue, ou si une session de routage est retirée sans alternative de travail, toutes les adresses Cloudnet routées mondialement peuvent devenir inaccessibles même si la fibre client et les commutateurs locaux restent alimentés. Si la connexion Niss reste active mais que sa capacité engagée est épuisée, les utilisateurs peuvent voir de la congestion plutôt qu’une panne franche. Si un filtre de route ou une autorisation est incorrect, une famille d’adresses ou une longueur de préfixe peut échouer tandis que d’autres continuent.

La récupération dépend de faits qui ne sont pas publics: si Cloudnet a un second circuit; s’il se termine sur un équipement de périphérie différent; si ce circuit suit un chemin séparé; si le basculement est automatique; si la sauvegarde a assez de capacité pour le pic normal; si IPv4 et IPv6 sont tous deux transportés; et quelle entreprise détient la première réponse. Un diagramme avec deux lignes ne prouverait rien de tout cela à moins d’identifier les points communs physiques et contractuels.

Le réseau physique commence là où BGP cesse d’expliquer

BGP peut montrer qu’AS150069 rend un bloc d’adresses accessible. Il ne peut pas montrer le câble des locaux du client au premier équipement actif. Entre ces points peuvent se trouver un terminal de réseau optique, une fibre de dérivation, un coupleur, une fibre de distribution aérienne ou souterraine, un terminal de ligne optique, une agrégation Ethernet, un backhaul loué, des panneaux de brassage, des alimentations électriques et du refroidissement. Les preuves publiques n’identifient pas lesquels de ces éléments Cloudnet utilise ou possède.

L’autorité de catégorie B de l’entreprise permet le service dans la zone de service autorisée du Tamil Nadu; elle ne certifie pas une conception d’accès particulière. Cloudnet pourrait exploiter de la fibre jusqu’au domicile, de l’Ethernet d’affaires, des liaisons sans fil, un service par l’intermédiaire de câblo-opérateurs locaux ou un mélange. Aucune carte de couverture, feuille de plan, spécification de réseau optique, enregistrement de tour ou partenariat de câble local public n’a été trouvé. La présence de deux adresses IP répondantes dansle scan récent d’IPinfomontre que des points d’extrémité ont répondu aux mesures, pas comment le dernier kilomètre a été construit.

Cette frontière de propriété inconnue change qui répare une panne. Un câble de dérivation client coupé peut être sous la responsabilité de Cloudnet ou d’un opérateur local. Une défaillance de fibre d’alimentation peut nécessiter une équipe de poteaux, un entrepreneur civil ou le propriétaire de la fibre louée. Une défaillance d’agrégation peut nécessiter des optiques de remplacement, un commutateur, une carte OLT ou une alimentation. Une défaillance de backhaul peut dépendre d’un autre opérateur. Le client voit un service indisponible, tandis que la réparation traverse plusieurs organisations.

L’alimentation crée sa propre chaîne. L’équipement client a besoin d’électricité. Les armoires de rue, les sites sans fil, les terminaux de ligne optique, les commutateurs d’agrégation et les routeurs de périphérie ont besoin d’électricité. Le fait qu’un siège social ait de l’électricité ne dit rien sur un nœud de distribution distant. Un onduleur peut combler une courte interruption mais a une autonomie finie et des batteries qui vieillissent. Un générateur n’aide que s’il est installé, alimenté, entretenu et connecté au site affecté. Aucune déclaration publique de Cloudnet ne donne l’autonomie de secours, la couverture de générateur, la maintenance des batteries, les doubles alimentations ou l’architecture électrique du site.

L’inventaire matériel est important pour un petit réseau car la pièce défaillante peut être bon marché mais spécifique sur le plan opérationnel. Un module optique de rechange peut restaurer une liaison rapidement s’il est compatible et disponible. Une carte de ligne, une alimentation ou un châssis d’accès défaillant peut prendre plus de temps s’il doit être commandé. Les sauvegardes de configuration doivent être à jour et utilisables sur l’équipement de remplacement. Le dossier public ne contient aucune donnée sur le temps moyen de réparation, la politique de stock, la liste de fournisseurs ou la fenêtre de maintenance.

La main-d’œuvre de support fait donc partie de la capacité. Un réseau peut avoir de la bande passante inutilisée et rester indisponible parce qu’aucun technicien ne peut atteindre une coupure, aucun ingénieur ne peut changer une route ou aucun contact autorisé ne peut escalader avec un amont. Les enregistrements de registre et de licence de Cloudnet publient une seule chaîne de contact administratif, mais ces enregistrements ne décrivent pas un centre d’opérations réseau doté en personnel, une couverture de terrain 24 heures sur 24, un système de tickets ou un roulement d’escalade. Il serait erroné de transformer un numéro de contact en une promesse de niveau de service.

La question de l’emplacement physique doit rester ouverte. Kottivakkam est un emplacement de siège social enregistré. Les coordonnées de registre suggèrent un autre point dans le nord du Tamil Nadu, et des mesures tierces associent des adresses à Chennai, Nagari et d’autres étiquettes du Tamil Nadu. Les bases de données de géolocalisation IP peuvent refléter l’enregistrement de l’adresse, des emplacements d’utilisateurs inférés ou un biais de mesure. Rien ne prouve que Cloudnet a une baie dans un centre de données nommé ou possède de l’équipement sur un site particulier.

La facturation, le support et les contrats peuvent interrompre un réseau intact

Toute défaillance de service ne commence pas par un câble coupé. Un fournisseur d’accès doit identifier les clients, autoriser les sessions, émettre des factures, accepter les paiements, appliquer les changements de forfait et distinguer un compte en souffrance d’une panne réseau. Selon la conception, l’authentification peut reposer sur une base de données d’abonnés, un serveur RADIUS, une passerelle de réseau haut débit, un système de gestion de réseau optique ou la plateforme d’un revendeur. Le dossier public ne divulgue pas lesquels de ces éléments Cloudnet utilise. Il établit que l’administration client est une couche d’exploitation distincte de BGP.

Cette distinction est facile à voir de l’extérieur. AS150069 peut rester visible mondialement tandis qu’un compte est incapable de se connecter. Un paiement affecté au mauvais grand livre, un justificatif expiré, un serveur d’authentification défaillant ou un drapeau de suspension incorrect peuvent se présenter comme une panne au niveau du routeur du client. Le personnel de terrain peut trouver des niveaux optiques sains et un chemin amont intact, pourtant le service reste indisponible jusqu’à ce que le contrôle du compte soit corrigé. Un collecteur de routes n’enregistrera rien de tout cela.

La continuité de la facturation est également importante lors d’un incident plus large. Les clients ont besoin d’un canal accessible pour signaler les pannes et déterminer si un paiement, un appareil ou une panne de zone est responsable. Le personnel a besoin de dossiers de compte et de réseau à jour. Si la même panne de courant, de serveur ou de connectivité met hors service à la fois le service d’accès et ses systèmes de support, le diagnostic ralentit. Les contacts réglementaires et de registre publiés par Cloudnet ne révèlent pas s’il a une plateforme de service client distincte, des enregistrements hors site, un routage téléphonique d’urgence ou un processus manuel testé.

Le contrat de gros avec le voisin visible est un autre point de contrôle possible. Une fibre et un routeur peuvent être techniquement sains tandis qu’un litige avec le fournisseur, une commande expirée, une facture impayée, un plafond de capacité ou une autorisation de route périmée interrompt le service. Il n’y a aucune preuve qu’un tel litige soit survenu entre Cloudnet et Niss. Le point est structurel: là où la portée dépend d’un autre opérateur, la continuité commerciale appartient à l’évaluation de la résilience au même titre que les optiques et l’alimentation.

La défaillance du contrat fournisseur devient plus conséquente lorsqu’il n’y a pas d’alternative prouvée. Changer d’amont nécessite plus que commander une ligne. Le nouveau fournisseur doit atteindre un raccordement, accepter les routes de Cloudnet, appliquer des filtres, transporter IPv4 et IPv6, prendre en charge les autorisations de route valides et fournir une capacité suffisante. Le trafic client peut avoir besoin de nouvelles routes par défaut, de chemins DNS ou de politique d’adresse. Si la migration est précipitée après la fin d’un service existant, le réseau peut être hors ligne même si Cloudnet contrôle toujours son ASN et ses préfixes.

Déplacer des clients d’accès individuels soulève un problème de migration différent. Si Cloudnet cessait de desservir une zone ou remettait des abonnés à un autre opérateur, la continuité dépendrait de la propriété de la fibre de dérivation et de l’équipement client, de la portabilité des dossiers de compte, des préavis, des remboursements et de la capacité du fournisseur de remplacement à fournir le service. Le BGP public peut ne montrer aucun changement si les adresses et l’origine restent les mêmes, ou un grand changement si les clients sont renumérotés. Aucun de ces résultats n’explique à lui seul qui a assumé l’obligation de détail.

Pour un véritable service hébergé, la migration serait encore plus difficile: les clients auraient besoin d’exportation de données, d’images de machine, de contrôle DNS et de temps pour reconstruire. C’est l’une des raisons pour lesquelles l’hypothèse non étayée du cloud ne peut être traitée à la légère. Elle implique des obligations de garde et de sortie de données qui sont absentes des preuves. Pour le réseau d’accès qui est effectivement visible, les questions immédiates sont plus simples mais toujours sans réponse: qui possède la relation abonné, qui peut restaurer l’authentification, qui escalade avec Niss, et comment un client est déplacé si cette relation prend fin.

La capacité installée n’est pas la capacité commerciale

Il n’y a pas de liste de prix ou de tableau de vitesses public de Cloudnet à comparer au réseau. Même s’il y en avait une, la vitesse d’accès annoncée ne serait encore que le bord extérieur de la question de capacité. Un forfait d’abonné à 100 Mbps ne réserve pas 100 Mbps à travers chaque commutateur d’agrégation, backhaul et liaison de transit à toute heure. Les fournisseurs mutualisent la capacité en supposant que les clients ne demanderont pas tous leur débit maximal simultanément.

Les quantités opérationnelles pertinentes sont absentes. Cloudnet ne publie pas le nombre d’abonnements actifs, le mélange de vitesses, le transit engagé, la capacité de peering, la conception du backhaul, l’utilisation des ports, le débit en heure de pointe, le taux de sursouscription ou le dossier de congestion. Le pool IPv4 de 512 adresses ne comble pas ces lacunes. Le NAT de niveau opérateur peut permettre à bien plus de 512 dispositifs clients de partager le pool; les services professionnels statiques peuvent consommer plusieurs adresses par compte; et l’IPv6 modifie le calcul d’adressage sans ajouter un seul bit de capacité de transit par lui-même.

Cloudflare Radar a affiché unepopulation estimée pour AS150069de l’ordre de quelques centaines, l’estimation affichée variant selon les instantanés et les sous-pages. Ces estimations utilisent des signaux de trafic et de mesure plutôt que le système de facturation du fournisseur. Elles indiquent une petite population d’utilisateurs observable et renforcent l’interprétation de FAI grand public, mais elles ne doivent pas être citées comme un registre d’abonnés. Un abonnement peut desservir un foyer ou une entreprise avec de nombreuses personnes, tandis que certains utilisateurs peuvent ne pas apparaître dans les mesures sous-jacentes.

La même prudence s’applique aux performances mesurées.La page de qualité Internet de Cloudflare pour AS150069agrège les tests de vitesse disponibles et les observations de réseau. Une mesure prise depuis une adresse répondante peut montrer qu’un chemin a fonctionné à un moment et un endroit donnés. Elle ne peut pas certifier une vitesse de forfait pour chaque abonné, quantifier la fréquence des pannes sur l’empreinte d’accès ou révéler si la ligne testée est représentative. Les petits échantillons sont particulièrement vulnérables aux changements de composition.

Lesréglementations de qualité 2024 de la TRAIétablissent des références et des obligations de déclaration pour les fournisseurs d’accès et de haut débit, y compris la fourniture de service, la performance du réseau, la réparation des pannes et le traitement des plaintes. Lerapport de performance trimestriel de décembre 2024explique que son résumé de performance haut débit publié couvrait les fournisseurs de plus de 10 000 abonnés. Cloudnet n’est pas identifié dans le résumé public comme l’un de ces grands fournisseurs. Cette omission n’établit pas sa taille ni ne l’exempte des obligations applicables; elle signifie que le résumé national ne peut pas être utilisé comme preuve de performance spécifique à Cloudnet.

La capacité utilisable est ce qui reste après contention, défaillance et politique. Si un chemin de secours ne transporte qu’une fraction du trafic normal, la redondance nominale peut encore produire une congestion sévère. Si les spécifiques IPv4 sont retirés mais que l’agrégat demeure, la portée peut continuer avec une ingénierie de trafic modifiée. Si l’IPv6 échoue alors que l’IPv4 reste actif, les utilisateurs peuvent subir des délais et des pannes spécifiques aux applications plutôt qu’une déconnexion totale. Une déclaration de capacité crédible nécessiterait des mesures en heure de pointe pour les deux familles d’adresses, pas la taille des préfixes alloués.

Un service cloud nécessiterait un ensemble de preuves différent

Un fournisseur d’accès et un fournisseur cloud peuvent partager des routeurs, des adresses et du personnel, mais ils vendent des promesses différentes. Le service d’accès transporte le trafic d’un client vers d’autres systèmes. L’hébergement informatique maintient l’application, les données ou le serveur d’un client en fonctionnement sur l’infrastructure propre ou louée du fournisseur. La seconde promesse introduit des questions que le dossier d’AS150069 ne peut pas répondre.

La première est l’actif. Une offre crédible de serveur virtuel devrait identifier une plateforme de calcul ou au moins divulguer les caractéristiques du CPU, de la mémoire, du stockage, du réseau et de la location. Le bare-metal devrait identifier les classes de serveurs et les conditions de provisionnement. La colocation devrait identifier l’installation, la puissance de la baie et les arrangements de mains à distance. L’hébergement géré devrait définir quelles tâches d’exploitation le fournisseur effectue. Aucun matériel spécifique à l’entreprise trouvé ici ne décrit aucun de ces produits.

La deuxième est l’emplacement. « Hébergé en Inde » ou « hébergé à Chennai » nécessiterait une preuve de l’installation où résident les données et le calcul. Un ASN enregistré en Inde ne localise pas un serveur. Le trafic peut être acheminé via un réseau indien vers de l’équipement dans une autre installation ou juridiction; inversement, Cloudnet pourrait utiliser une infrastructure indienne tierce qui n’apparaît pas dans son propre espace d’adressage. Le pays de registre et la résidence des données sont des affirmations distinctes.

La troisième est le contrôle. Si Cloudnet revendait les machines virtuelles d’un autre fournisseur, Cloudnet pourrait contrôler la facturation et le support tandis que le fournisseur sous-jacent contrôlait les baies, les hyperviseurs, l’alimentation et les pièces. Si Cloudnet louait de la colocation, il pourrait posséder des serveurs mais pas les systèmes du bâtiment. S’il exploitait sa propre salle, il pourrait encore dépendre des propriétaires et des opérateurs. Les clients doivent savoir qui peut restaurer l’alimentation, remplacer un disque, récupérer une sauvegarde et approuver l’accès d’urgence. Aucun document public ne trace cette frontière.

La quatrième est la redondance. Un service cloud peut répliquer des données à travers des disques, des hôtes, des baies, des salles, des bâtiments ou des régions, chacun protégeant contre une défaillance différente. Deux copies sur un seul hôte ne survivent pas à la défaillance de l’hôte. Deux hôtes dans une baie peuvent partager une unité de distribution d’alimentation. Deux baies dans un bâtiment peuvent partager l’alimentation électrique, le refroidissement et la fibre amont. Deux bâtiments peuvent encore dépendre d’un seul conduit métropolitain ou plan de contrôle. Sans une architecture divulguée et un chemin de restauration testé, le mot « cloud » ne dit rien sur le domaine de défaillance.

La cinquième est la sortie. Un client se remettant d’une défaillance du fournisseur a besoin d’une image exportable, d’un vidage de base de données, d’une copie d’objet, d’un contrôle DNS et de suffisamment de temps et de bande passante pour déménager. La résiliation du contrat, un litige de facturation ou une défaillance d’entreprise peut être aussi perturbateur qu’une panne matérielle si les justificatifs ou les données sont verrouillés sur un seul compte. Aucune condition de Cloudnet n’a été trouvée décrivant la restitution des données, la suppression, l’aide à la migration, la rétention des sauvegardes ou la suspension de compte.

Ce ne sont pas des allégations selon lesquelles Cloudnet n’a pas les capacités. Ce sont les questions minimales auxquelles les preuves publiques devraient répondre avant d’attribuer ces capacités. Une offre privée, un contrat ou un cahier des charges technique pourrait changer la conclusion pour un client particulier. Jusqu’à ce que de telles preuves apparaissent, AS150069 doit être lu comme une preuve d’exploitation réseau, pas un produit cloud.

RPKI est une hygiène de routage utile, pas une résilience en soi

Cloudnet a pris une mesure concrète de sécurité de routage. Lavalidation RIPEstat pour l’agrégat IPv4a trouvé une autorisation d’origine de route valide couvrant AS150069 et permettant des annonces jusqu’à/24. Les routes composantes sont donc valides sous la même autorisation. Lavalidation pour le/48IPv6était également valide.

RPKI aide les autres réseaux à rejeter une annonce d’origine qui entre en conflit avec l’autorisation signée. Il réduit une classe d’erreur ou de détournement de routage. Il ne vérifie pas chaque AS dans le chemin, ne chiffre pas le trafic, n’empêche pas une coupure de fibre, ne fournit pas un second amont, n’empêche pas la congestion et ne maintient pas un routeur alimenté. Une route valide peut mener à un service indisponible si le réseau d’origine n’a pas de chemin fonctionnel vers le client.

La combinaison actuelle est néanmoins significative: des ressources enregistrées, des origines IPv4 et IPv6 actives, des objets de route et des autorisations d’origine valides. Elle montre plus de maturité opérationnelle qu’un nom d’entreprise dormant. Elle aiguise également la question de la résilience car la topologie visible reste étroite. Une portée correctement autorisée à travers un seul voisin observé reste un seul voisin observé.

Les annonces IPv4 plus spécifiques ajoutent une autre complication opérationnelle. Pendant la période où les/24avaient une faible visibilité, l’agrégat/23est resté largement visible. Annoncer à la fois l’agrégat et les spécifiques peut préserver une route de couverture si un spécifique disparaît. Cela peut également être utilisé pour la politique ou l’atténuation. Les collecteurs publics ne peuvent pas révéler la conception prévue, et l’agrégat ne crée pas un second chemin physique. La redondance de routage et la redondance de circuit ne doivent pas être confondues.

L’IPv6 mérite également une conclusion limitée. Le/48a été annoncé mondialement pendant des années et son objet de route a été mis à jour récemment. Cela soutient un routage IPv6 actif à la périphérie du réseau. Cela ne prouve pas que chaque client de détail reçoit un préfixe IPv6, que l’équipement client le prend en charge, ou que le personnel de support dépanne les deux protocoles de manière égale. Une divulgation spécifique au fournisseur ou une mesure côté client serait nécessaire pour établir la profondeur du déploiement.

Les personnes touchées sont probablement des clients d’accès, pas des charges de travail hébergées

Le rythme quotidien d’IPinfo, la licence de FAI et l’absence de catalogue d’hébergement pointent vers un réseau d’accès. Les estimations d’utilisateurs observés de Cloudflare et les adresses répondantes de la région de Chennai soutiennent cette direction. Elles ne révèlent pas les noms, les emplacements exacts ou les types de clients. La population probablement touchée est donc conditionnelle: des foyers, des petites entreprises ou des utilisateurs institutionnels qui reçoivent une connectivité via AS150069 ou via le service d’accès de Cloudnet.

Pour un foyer, une panne interrompt la messagerie, le streaming, le travail à distance, l’éducation, les paiements et les appareils connectés. Pour une petite entreprise, la même défaillance peut arrêter les applications cloud, l’autorisation de carte, le contact avec les fournisseurs et les communications clients. Une entreprise utilisant une adresse statique de Cloudnet peut également perdre la portée entrante vers une caméra, un point de terminaison VPN ou un service auto-hébergé. Ce sont des mécanismes, pas des affirmations selon lesquelles une organisation nommée achète le service de Cloudnet.

La dépendance s’étend au-delà du titulaire du compte. Un opérateur local ou un revendeur peut placer des clients derrière l’espace routé de Cloudnet. Aucun ASN en aval n’était visible, mais les arrangements de détail en aval ne nécessitent pas un ASN séparé. Si Cloudnet fournit de la capacité à une autre entreprise d’accès, une panne à la frontière Cloudnet-Niss pourrait affecter des utilisateurs qui ne reconnaissent ni l’un ni l’autre nom d’entreprise. Le routage public ne peut pas compter ces arrangements.

Différentes pannes produisent des symptômes différents. Une dérivation coupée affecte un seul local. Une panne de coupleur ou de port d’accès affecte un groupe. Une panne d’agrégation ou de backhaul affecte une zone plus large. La perte du raccordement Niss peut affecter l’ensemble de l’empreinte routée. Une panne DNS ou d’authentification peut laisser les liaisons actives tandis que les sessions échouent. Les erreurs de facturation ou de système de compte peuvent déconnecter un individu sans aucune panne réseau. Le dossier public n’identifie pas quels systèmes Cloudnet exploite lui-même.

La récupération doit être mesurée à partir de la périphérie client. Restaurer une annonce BGP ne suffit pas si la fibre d’alimentation reste coupée. Réparer la fibre ne suffit pas si l’authentification est en panne. Alimenter un commutateur ne suffit pas si la session amont est toujours indisponible. Un compte rendu d’incident solide identifierait la couche défaillante, l’opérateur responsable, les heures de début et de restauration, la zone affectée, la solution de contournement et si la capacité a été entièrement restaurée.

L’absence d’une page d’incident public ou d’un historique d’état de service empêche un jugement de performance. Le silence ne prouve pas une fiabilité parfaite, et des rapports d’utilisateurs dispersés n’établiraient pas un taux à l’échelle du réseau sans vérification. Les preuves actuelles soutiennent la cartographie de la chaîne de défaillance, pas l’évaluation de la disponibilité historique de Cloudnet.

Ce qui établirait une image d’exploitation plus solide

Le premier élément manquant est une description de service actuelle orientée client. Pour le service d’accès, elle devrait nommer la couverture, la technologie d’accès, les vitesses des forfaits, la contention ou les règles d’utilisation équitable, les conditions d’installation, le contact de panne et les objectifs de service. Pour tout service hébergé, elle devrait spécifier les caractéristiques de calcul, de stockage, de réseau, de sauvegarde et de migration. Un logo et une promesse générique de service rapide ne suffiraient pas.

Le deuxième est une carte réseau physique et contractuelle à un niveau d’abstraction approprié. Cloudnet n’a pas besoin de publier des itinéraires sensibles au niveau de la rue. Il pourrait divulguer le nombre de points de présence actifs, les villes ou zones de service qu’ils couvrent, si le backhaul est possédé ou loué, et si les circuits amont se terminent sur des sites séparés et suivent des chemins divers. La clé est d’identifier les domaines de défaillance communs sans exposer de secrets opérationnels.

Le troisième est la preuve de capacité. Les mesures utiles incluent le trafic total et en heure de pointe, l’utilisation des ports, le transit engagé et en burst, la capacité de basculement, la saturation des nœuds d’accès et l’adoption des clients IPv4/IPv6. Un instantané doit porter une date. La capacité de conception, les interfaces installées, la capacité allumée et le débit disponible pour le client doivent être rapportés séparément.

Le quatrième est la preuve de récupération. Cloudnet pourrait indiquer l’autonomie de l’alimentation de secours par classe de site, la politique de matériel de rechange, la propriété de l’escalade, les fenêtres de maintenance et les performances de restauration récentes. Une affirmation de résilience devient crédible lorsqu’une défaillance a été testée: retrait de route, perte d’amont, interruption de courant, remplacement de matériel et restauration de configuration. Le résultat devrait montrer si le service a effectivement basculé et combien de capacité est restée.

Le cinquième est une corroboration topologique indépendante. Un deuxième voisin visible renforcerait le cas de diversité de routage mais nécessiterait encore une preuve de chemin physique. Un circuit de secours vers le même AS peut être précieux s’il entre dans une installation différente et évite les conduits communs. Inversement, deux noms de fournisseur peuvent partager le même opérateur de dernier kilomètre. Les contrats, les emplacements de raccordement et les enquêtes de route règlent ce que BGP seul ne peut pas.

Le sixième est la preuve de toute affirmation cloud. Un nom d’installation ou un site vérifiable indépendamment, des conditions client, des spécifications d’infrastructure, une déclaration de localisation des données, une architecture de sauvegarde, une matrice de responsabilité de sécurité et une procédure de sortie feraient passer la discussion de l’inférence à l’analyse de produit. Un seul domaine hébergé ou un serveur répondant depuis le/23ne prouverait pas une plateforme cloud commerciale.

Jusqu’à ce que ces éléments existent, la preuve la plus solide de Cloudnet reste son identité réglementée de FAI et son routage actif. Les inconnues ne sont pas des lacunes décoratives. Ce sont les endroits exacts où le service peut échouer: ligne d’accès, alimentation d’agrégation, backhaul, raccordement Niss, transit en aval, escalade de support et restauration client.

Un petit réseau actif, avec une histoire plus étroite que son nom

CLOUDNET INTERNET SERVICE PVT LTD n’est pas une coquille corporative vide. Elle a une autorisation de service Internet de catégorie B du Tamil Nadu, une identité cohérente à Chennai dans les registres publics, un système autonome actif, une allocation IPv4 de 512 adresses, un/48IPv6 annoncé et des autorisations d’origine de route valides. Ses routes sont visibles depuis 2022, et ses données de registre ont été maintenues peu de temps avant la date d’observation.

Les mêmes preuves fixent une frontière ferme. Un seul voisin de routage immédiat était visible. Aucun matériel public n’a établi de diversité amont ou physique, une empreinte d’accès cartographiée, une bande passante installée, une autonomie d’alimentation de secours, une performance de réparation sur le terrain ou une opération de support dotée en personnel. Plus important encore, rien n’a localisé établi un service commercial de cloud, VPS, bare-metal, colocation, stockage ou hébergement géré.

Ce n’est pas un résultat décevant. C’est un résultat plus utile. Le nom n’obscurcit plus la surface d’exploitation qui peut effectivement être observée. Cloudnet semble transporter du trafic d’accès dans le Tamil Nadu via AS150069 et Niss Internet Services. Sa résilience sera déterminée par une infrastructure ordinaire: câbles, électronique alimentée, backhaul, configuration de route, pièces de rechange et personnes capables de les restaurer.

Le grade de preuve réseau est Faible pour une évaluation complète de l’infrastructure, malgré des preuves solides que l’ASN est actif. Le routage est visible; le système physique et commercial derrière ne l’est pas. Un grade plus fort nécessite la preuve de l’endroit où les clients se connectent, comment le trafic sort, ce qui bascule, comment la capacité se comporte sous contrainte et qui répare chaque couche. Toute future affirmation de service cloud doit commencer une étape plus tôt, en prouvant qu’il y a un service hébergé à évaluer.