Geeky Cloud vend une capacité hébergée qui dépend encore des racks, du transit et des fenêtres de réparation

Résumé

• Geeky Cloud est visible publiquement comme un fournisseur basé au Bangladesh avec une empreinte de service à Khulna. Sonsite web publiccommercialise l'internet résidentiel, l'internet professionnel, l'internet dédié, la vidéosurveillance (CCTV), la configuration réseau et la sécurité réseau, liste des bureaux à Nirala, Gollamari et Bagmara à Khulna, et se décrit comme un FAI agréé par la BTRC.
• Les preuves réseau les plus solides sont réelles mais limitées.APNIC RDAP pour AS148974et lavue whois APNICidentifient GEEKY-AS-AP comme Geeky Cloud au Bangladesh, tandis que lesdonnées des préfixes annoncés par RIPEstatmontrent 103.175.17.0/24 et 2001:df7:e680::/48 comme les ressources annoncées visibles pendant la fenêtre d'observation.
• L'hygiène de routage est meilleure que le discours public sur la résilience. Lavalidation RPKI RIPEstat pour 103.175.17.0/24et lavalidation RPKI RIPEstat pour 2001:df7:e680::/48marquent toutes deux l'origine actuelle comme valide, tandis que lesdonnées d'état de routage RIPEstat pour AS148974rapportent un préfixe IPv4, un /48 IPv6 et un voisin observé.
• Le risque pratique est la concentration des dépendances. Geeky Cloud peut vraisemblablement servir des clients d'accès local et de petits cas d'usage hébergés ou liés aux médias, mais les documents publics ne prouvent pas l'existence de sites de centres de données nommés, de racks propres, de stock de serveurs de rechange, de basculement multi-opérateur, d'historique public des incidents, de sauvegardes clients portables ou d'un chemin documenté pour quitter le fournisseur si l'upstream, l'installation d'accès, le contact de facturation ou la file d'attente de réparation tombe en panne.

Pourquoi Geeky Cloud nécessite une lecture prudente

Le nom Geeky Cloud invite à une lecture orientée services cloud, mais les preuves publiques exigent une approche plus prudente. Une entreprise peut utiliser le langage du cloud alors que son activité visible est de l'accès local, de la connectivité gérée, de la diffusion de médias ou un mélange de petits services hébergés derrière une marque de FAI de quartier. Dans ce cas, les documents publics pointent d'abord vers l'accès Internet à Khulna. Le propresite du Bangladeshde Geeky Cloud est rédigé principalement pour des clients locaux: il vend de l'internet résidentiel, de l'internet professionnel et de l'internet dédié, indique les débits des forfaits résidentiels, vante la vitesse BDIX et CDN, énumère les canaux de contact pour le support et le paiement des factures, et situe l'entreprise à Khulna plutôt que sur un marché de centres de données nommé.

Cela ne rend pas l'entreprise étrangère à la capacité hébergée. Les FAI locaux offrent souvent plus que du haut débit résidentiel. Ils peuvent héberger des sites web clients, exécuter des services de cache et de médias, fournir des réseaux de bureau, installer des équipements clients, vendre des liaisons gérées, prendre en charge le backhaul de vidéosurveillance, maintenir des armoires locales ou acheminer le trafic professionnel via leur propre système autonome. Pour une petite entreprise à Khulna, la différence pratique entre « fournisseur d'accès Internet » et « dépendance au cloud » peut être mince.

Si le fournisseur d'accès héberge également un serveur multimédia, entretient l'espace d'adressage, exécute le DNS des clients ou transporte la seule liaison de bureau à haut débit abordable, le service numérique du client reste lié aux racks, à l'alimentation, au transit upstream et au personnel de réparation.

La bonne question n'est donc pas de savoir si Geeky Cloud doit être comparé à une plateforme cloud hyperscale. Il ne le doit pas. La question est de savoir si un acheteur peut comprendre les couches physiques et contractuelles derrière la capacité que Geeky Cloud vend. La réponse publique est partielle. Les enregistrements APNIC montrent que Geeky Cloud possède son propre numéro AS et des ressources d'adressage portables. RIPEstat montre que ces ressources sont visibles dans le routage mondial. Le site web de l'entreprise présente une surface de vente et de support active.

Mais ces mêmes documents ne montrent pas de noms d'installations publiques, de propriété des racks, d'upstreams redondants au-delà du seul voisin observé, de page d'état, d'objectifs de réparation, de garanties d'exportation client ou de limites de capacité transparentes.

Cette dichotomie est la conclusion centrale de l'article. Geeky Cloud n'est pas une coquille vide. Il dispose d'un site de service visible, de pages de contact joignables et d'une identité de routage active. Il n'est pas non plus documenté publiquement comme un opérateur de calcul hébergé profond. L'entreprise doit être traitée comme un véritable réseau local avec un ensemble de routes publiques restreint et une fine couche d'assurance autour des revendications de capacité hébergée. C'est une catégorie utile mais dégradée: suffisamment crédible pour enquêter, trop peu étayée pour s'y fier sans chemins de secours.

Le site public pointe vers l'accès à Khulna, pas vers une console cloud générique

La proposition client visible commence pargeekycloud.com.bd. Le site présente Geeky Cloud comme un fournisseur d'accès Internet dans la ville de Khulna, avec des forfaits pour les foyers et les bureaux, des canaux de support, des contacts de paiement et un formulaire de contact. Ses sections de service couvrent l'internet résidentiel, l'internet professionnel, l'internet dédié, la vidéosurveillance, la configuration réseau et la sécurité réseau. Les fiches de forfait indiquent des vitesses allant jusqu'à 40, 50, 70 et 100 Mbps, des prix en taka bangladais, un langage de réseau en fibre optique, des revendications de vitesse BDIX et CDN, de l'IPv6 à la demande et un support dédié rapide. C'est le langage d'un fournisseur d'accès local et de réseau géré.

La page d'accueil fournit également plusieurs indices opérationnels. Premièrement, elle insiste sur le paiement des factures et l'utilisation responsable des connexions, ce qui est typique des FAI résidentiels. Deuxièmement, elle met en avant le streaming 4K, les jeux, Facebook, la vitesse BDIX et CDN, autant d'éléments qui importent à un client d'accès domestique ou de petit bureau. Troisièmement, elle répertorie une ligne d'assistance, un centre d'appels et un numéro de support, les détails de paiement marchand Bkash-Nagad et le contact WhatsApp.

Quatrièmement, elle indique les emplacements des bureaux: un siège social au House 10, Road 4, 2nd Cross Road, quartier résidentiel de Nirala, Khulna 9100, ainsi que des agences à Gollamari et Bagmara. Ces détails sont utiles car ils ancrent le service dans une géographie de réparation locale.

Le site contient effectivement une entrée « serveur multimédia », et lapage du serveur multimédiarenvoie une page active. Cela importe pour la diffusion de contenu local et l'expérience client, en particulier au Bangladesh où le trafic lié à BDIX et les performances du cache local peuvent façonner la qualité perçue. Mais un lien vers un serveur multimédia n'équivaut pas à un catalogue public de produits cloud. Le site public n'affiche pas de plans VPS, d'inventaire de serveurs bare metal, de zones de centres de données nommées, d'instantanés de stockage, de contrôles de réseau virtuel, de documentation API, de familles d'instances, de conditions d'exportation de sauvegarde ou d'un panneau cloud en libre-service. Il vend d'abord de la connectivité.

La surface de contact est également active. Lapage de contactrenvoie un formulaire client et un contexte de support. En revanche, plusieurs suppositions d'URL courantes telles que les pages de paiement, à propos et forfaits ont renvoyé des réponses 404 lors de cette analyse, même si le contenu des forfaits est visible sur la page d'accueil. Ce n'est pas un défaut majeur en soi. Les sites de petits FAI gardent souvent l'essentiel du contenu sur une seule page. Mais cela montre pourquoi les acheteurs doivent éviter de considérer les étiquettes de menu comme preuve d'un parc de services mature. La page qui compte est celle qui existe réellement et explique le service.

Le domainegeekycloud.netajoute une autre couche. Il redirige vers geekycloud.com.bd et est servi par Cloudflare, tandis que la page finale.com.bd répond directement depuis un serveur web Apache sur une adresse distincte en dehors du préfixe 103.175.17.0/24 visible de Geeky Cloud. Le chemin du site web n'est donc pas le même que le chemin du réseau d'accès client. Un visiteur peut atteindre un site public par un chemin tandis que l'accès Internet d'un abonné, une session de serveur multimédia ou l'espace d'adressage routé dépend d'un chemin différent. Cette distinction est importante pour l'analyse des pannes.

La lecture la plus simple est que la façade publique de Geeky Cloud est celle d'un FAI et d'une marque de connectivité gérée desservant les clients de Khulna. Une capacité hébergée peut exister autour des médias, des services locaux, des équipements réseau clients ou de la connectivité professionnelle, mais les pages publiques ne permettent pas de la vérifier en tant que plateforme cloud étendue. L'article traite donc le terme « cloud » comme une revendication à examiner à travers les preuves de routage et de dépendance, et non comme une garantie de résilience de type cloud.

Le registre donne à Geeky Cloud une véritable identité réseau

La preuve matérielle la plus solide se trouve dans l'APNIC. L'enregistrement RDAP APNIC pour AS148974identifie le titulaire comme Geeky Cloud et situe l'AS au Bangladesh. Larequête whois APNIC pour AS148974donne l'aut-num comme AS148974, le nom de l'AS comme GEEKY-AS-AP, la description comme Geeky Cloud, le pays comme BD, l'organisation comme ORG-GC26-AP, et le mainteneur comme MAINT-GEEKY-BD. Elle répertorie également le contact abuse lié à la boîte aux lettres ipabu de Geeky Cloud et montre l'aut-num modifié pour la dernière fois en 2022.

Le dossier d'organisation est tout aussi concret. La sortie APNIC sous la même requête AS identifie ORG-GC26-AP comme Geeky Cloud, donne le type d'organisation comme LIR, indique le pays BD et fournit une adresse à Khulna. Unerequête de mainteneur APNIC pour MAINT-GEEKY-BDdistincte associe le mainteneur à Geeky Cloud au Bangladesh et renvoie à la même famille de contacts administratifs. L'enregistrement RDAP IPv4 APNICet larequête whois IPv4 APNICidentifient 103.175.17.0/24 comme GEEKY-BD, décrit comme Geeky Cloud, pays BD, statut alloué portable. L'enregistrement RDAP IPv6 APNICet larequête whois IPv6 APNICidentifient 2001:df7:e680::/48 comme GEEKY-BD, décrit comme Geeky Cloud, pays BD, statut assigné portable.

Ce sont des faits significatifs. Un numéro AS et des enregistrements d'adresses portables ne prouvent pas en eux-mêmes le nombre de clients, l'emplacement des racks ou la qualité du service, mais ils montrent une identité de réseau contrôlée par les enregistrements APNIC plutôt qu'un simple site marketing. Pour un FAI, cela importe. Cela signifie qu'il existe une identité routable qui peut être observée, mesurée et liée aux contacts du registre public. Cela donne également aux clients et aux pairs un endroit où signaler les abus, les problèmes de dépannage et les questions de routage.

Les dates d'enregistrement sont utiles pour le contexte de maturité. Les enregistrements de ressources IPv4 et IPv6 datent d'octobre 2021, tandis que les enregistrements d'organisation et de contact ont subi des modifications ultérieures, y compris des mises à jour en 2026 pour l'organisation et la validation des abus. Cela suggère un historique d'exploitation antérieur à une nouvelle page d'atterrissage. Cela ne nous dit pas comment le réseau a évolué, combien de clients sont actifs, ou si l'entreprise s'est étendue au-delà de l'accès local, mais cela établit une continuité dans les enregistrements publics de numéros Internet.

La réserve est l'échelle. Un /24 IPv4 contient 256 adresses. Un /48 IPv6 est une taille normale pour un réseau d'accès afin de numéroter les clients et l'infrastructure, mais il s'agit toujours d'une seule allocation IPv6 visible. Un fournisseur peut servir de vrais clients avec cette empreinte. Les données publiques ne permettent pas de le décrire comme une plateforme hébergée étendue avec de nombreux blocs routables, de nombreux emplacements périphériques ou plusieurs pools d'adresses indépendants. Le registre donne de la substance à Geeky Cloud. Il cadre également la limite supérieure de ce que les observateurs extérieurs peuvent vérifier.

Les données de routage montrent à la fois l'accessibilité et la concentration

RIPEstat confirme que l'AS de Geeky Cloud est actif. L'aperçu AS pour AS148974indique que la ressource est annoncée et identifie le titulaire comme GEEKY-AS-AP - Geeky Cloud. Lavue des préfixes annoncésmontre deux ressources actuelles pendant la fenêtre d'observation: 103.175.17.0/24 et 2001:df7:e680::/48. Lavue d'état de routage ASrapporte un préfixe IPv4, 256 adresses IPv4, un /48 IPv6 et un voisin observé.

Cette combinaison est le fait technique le plus important du profil. Le réseau est visible. L'ensemble de routes est réduit. Le nombre de voisins est concentré. Un réseau d'accès local peut très bien fonctionner avec un seul handoff upstream lorsque cet upstream est stable, dispose de capacités suffisantes et est localement approprié. Mais un acheteur ne doit pas confondre « visible à l'échelle mondiale » avec « résilient de manière indépendante ».

Si l'unique chemin upstream observé tombe en panne, est filtré, devient congestionné, subit un problème d'alimentation, fait l'objet d'un litige politique ou retire la route, les clients de Geeky Cloud ont besoin soit d'un chemin de secours caché non visible dans ces données, soit d'un plan de restauration manuel. Les documents publics ne prouvent ni l'un ni l'autre.

Les données au niveau des préfixes confortent la même lecture. Lavue d'ensemble du préfixe RIPEstat pour 103.175.17.0/24indique que le préfixe est annoncé par AS148974 et lié à Geeky Cloud. Lavue d'état de routage pour 103.175.17.0/24montre l'origine AS148974, la couverture de l'objet de route APNIC et la visibilité vers l'ensemble complet de pairs IPv4 dans cette vue au moment de la requête. Lavue d'ensemble du préfixe pour 2001:df7:e680::/48indique de même le préfixe IPv6 comme annoncé par AS148974, tandis que lavue d'état de routage IPv6montre l'origine AS148974 et une visibilité IPv6 complète dans l'ensemble de rapports.

La sécurité de l'origine de route est un signe positif. Lerésultat de validation RPKI pour 103.175.17.0/24rapporte une origine valide pour AS148974 avec une longueur max de 24. Lerésultat de validation RPKI pour 2001:df7:e680::/48rapporte une origine valide avec une longueur max de 48. Cela réduit l'ambiguïté de l'origine de route. Cela ne prouve pas la disponibilité, la capacité de réserve, une réputation d'adresse propre, la tolérance aux DDoS ou des réparations rapides. C'est de l'hygiène, pas de la résilience.

Les données de chemins observés pointent vers la frontière upstream. Lavue looking-glass RIPEstat pour 103.175.17.0/24montre des chemins de collecteur se terminant par AS139901 puis AS148974. Lavue looking-glass pour 2001:df7:e680::/48montre le même handoff effectif dans les échantillons IPv6. Lavue whois RIPEstat pour AS139901et larequête APNIC pour AS139901identifient cet AS upstream comme Apple Communication Ltd. au Bangladesh. AS139901 peut être un upstream sensé pour un fournisseur d'accès à Khulna, mais la vue publique concentre toujours la question de la réparation: que se passe-t-il lorsque ce handoff upstream est défaillant?

Lavue de cohérence de routage AS RIPEstatajoute un autre indice utile. Elle indique que les deux préfixes sont présents à la fois dans BGP et dans le whois, et elle identifie AS139901 comme un pair vu dans BGP mais non répertorié comme pair d'import/export dans la vue de politique whois. Cela n'est pas inhabituel dans les enregistrements de la région APNIC, où la politique de registre peut être éparse. Cela signifie que les acheteurs doivent se fier aux données observées et aux réponses directes du fournisseur plutôt que de supposer que la politique de registre répertorie toute la connectivité active.

Les racks et le transit sont le produit derrière la fiche de forfait

La fiche de forfait grand public de Geeky Cloud vend des vitesses et du support, mais le service fourni dépend d'actifs physiques. Une connexion résidentielle ou professionnelle à Khulna nécessite de la fibre sur le dernier kilomètre, des commutateurs d'accès, des coupleurs ou des armoires, des équipements d'agrégation, du backhaul, de l'alimentation, de la surveillance, des optiques de rechange, des techniciens de terrain et un moyen d'atteindre l'Internet plus large.

Si l'entreprise prend également en charge des services multimédia, des réseaux de vidéosurveillance ou des équipements clients hébergés, alors les racks, les serveurs, le stockage, la capacité de cache locale et le refroidissement des installations font partie du service même si le client ne les voit jamais.

Le site public mentionne un réseau en fibre optique, la vitesse BDIX et CDN, l'IPv6 à la demande et des upstreams ou sauvegardes multiples pour le service dédié. Ce sont des revendications précieuses pour les utilisateurs. Elles nécessitent également une interprétation prudente. « Vitesse BDIX et CDN » indique à un client que le contenu local ou mis en cache peut bien fonctionner, pas que chaque route internationale n'est pas congestionnée. « IPv6 à la demande » est encourageant car le préfixe IPv6 est visible, mais cela ne prouve pas que chaque plan d'accès reçoit l'IPv6 par défaut ou que les routeurs clients sont correctement configurés.

« Upstreams et sauvegarde multiples » est une revendication de service, tandis que la vue BGP publique montre actuellement un voisin observé pour AS148974. Les deux faits peuvent coexister si les chemins de secours sont privés, dormants, manuels, en aval uniquement ou en dehors de la fenêtre d'observation, mais les preuves publiques ne prouvent pas une diversité active.

La géographie physique est importante. Geeky Cloud répertorie des bureaux à Khulna, et les enregistrements APNIC placent ses contacts à Khulna. C'est utile pour le support local: une équipe de terrain peut se rendre sur les sites clients, réparer les branchements de fibre, échanger les équipements clients et collecter les paiements. Cela crée également une concentration locale. Un incident électrique, une coupure de câble, un problème de voirie, une défaillance d'agrégation ou un événement météorologique violent dans la zone de service peut affecter de nombreux clients à la fois.

Le dossier ne nomme pas le point de présence principal, la route de backhaul hors de Khulna, la disposition de secours électrique, l'autonomie du générateur ou l'installation où se trouve l'équipement de routage.

Le site web lui-même n'est pas un indicateur fiable du réseau d'accès. Le site final.com.bd se résout en 5.77.50.137 lors de vérifications DNS locales, tandis que le domaine.net est servi par Cloudflare et redirige vers le site.com.bd. Cela signifie que les pages marketing et de support peuvent reposer sur une pile d'hébergement en dehors de l'espace d'adressage visible de Geeky Cloud. C'est courant et souvent judicieux. Cela signifie également que la disponibilité du site web ne prouve pas la santé du réseau d'abonnés.

Un abonné peut perdre l'accès tandis que la page publique reste en ligne ailleurs, ou la page publique peut tomber en panne tandis que les abonnés continuent de router normalement.

Pour les acheteurs de capacité hébergée, la question clé est la capacité installée par rapport à la capacité utilisable. Un fournisseur peut avoir une bande passante d'accès suffisante pour des pics de trafic ordinaires mais pas assez de capacité de réserve pour des clients exceptionnellement lourds. Il peut avoir une capacité multimédia locale mais un stock de serveurs limité. Il peut avoir un seul /24 IPv4 public et devoir rationner soigneusement les adresses publiques. Il peut prendre en charge l'IPv6 mais encore dépendre des équipements clients, des politiques upstream et des pratiques de support pour rendre l'IPv6 utile.

Aucune de ces limites n'est disqualifiante. Elles signifient simplement que la fiche de forfait est une invitation à poser des questions opérationnelles, pas un contrat de fiabilité complet.

Le chemin de défaillance upstream est le premier risque à tester

Le premier chemin de défaillance à tester est l'accessibilité upstream. La vue BGP publique pointe vers AS139901 comme voisin observé de Geeky Cloud. Si AS139901 subit une maintenance, un problème de filtre de route, de la congestion, un litige commercial ou un problème d'alimentation, les préfixes publics de Geeky Cloud peuvent être affectés, à moins qu'un autre chemin ne soit prêt.

Un client utilisant Geeky Cloud comme unique connexion de bureau, unique chemin multimédia ou unique dépendance d'accès hébergé devrait demander s'il existe une autre route de transit, si le basculement est automatique et combien de temps la restauration prend habituellement.

Le deuxième chemin de défaillance est l'agrégation locale. Un FAI local peut avoir une route mondiale propre alors qu'un commutateur de quartier, une armoire, une épissure, un OLT, un backhaul sans fil ou une liaison d'agrégation de bureau tombe en panne. Le site de Geeky Cloud met en avant l'internet résidentiel, professionnel et dédié, ce qui signifie que la réparation sur le terrain compte autant que le routage.

Le client doit savoir comment les tickets d'incident sont priorisés, si la ligne d'assistance est dotée en personnel en dehors des heures normales, comment les liaisons professionnelles sont escaladées et si les plans dédiés bénéficient d'un objectif de réparation différent des forfaits résidentiels.

Le troisième chemin de défaillance est l'alimentation électrique. Le point faible d'un petit réseau n'est souvent pas la configuration du routeur. C'est l'électricité au bureau, au point de présence, dans l'armoire, au bâtiment client ou au handoff upstream. La page publique ne publie pas d'informations sur le générateur, la batterie ou l'alimentation double. Elle ne sépare pas non plus les revendications de disponibilité par couche de service. Une revendication de disponibilité de 90 % sur une fiche de forfait public n'est pas un objectif formel de haute disponibilité pour les services hébergés.

En fait, si on la prend au pied de la lettre, une disponibilité de 90 % permettrait bien plus d'indisponibilité que ce que la plupart des clients professionnels n'attendent. Les acheteurs devraient demander ce que la disponibilité signifie pour chaque service et sur quelle période de mesure.

Le quatrième chemin de défaillance est la rareté des adresses. Un seul /24 IPv4 peut prendre en charge un réseau d'accès local via du NAT, des plans d'adressage partagés et une attribution prudente, mais les adresses IPv4 publiques sont limitées. Si un client a besoin d'adressage public statique, de DNS inverse, de livraison de courrier, d'hébergement de serveur ou d'accès entrant, le fournisseur doit allouer des adresses rares et gérer la réputation. Un seul bloc d'adresses endommagé peut affecter le courrier, les paiements, les vérifications de risque de connexion et l'accès au contenu.

La validité RPKI aide à protéger la légitimité de l'origine; elle ne protège pas la réputation ni ne garantit des adresses de remplacement.

Le cinquième chemin de défaillance est le chemin de sortie du client. Les clients d'accès peuvent parfois changer de FAI, mais les migrations professionnelles sont rarement instantanées. Une entreprise peut dépendre d'une adresse IP publique Geeky Cloud, d'une route de backhaul de vidéosurveillance, d'une dépendance multimédia locale, d'entrées DNS, de la configuration du routeur client ou du calendrier de paiement. Si le service est en panne pendant des jours, qu'est-ce que le client emporte ailleurs? La page publique ne publie pas d'engagements de portabilité ou d'exportation de configuration.

Un acheteur prudent conserve des notes de configuration indépendantes du fournisseur, un accès de secours, un DNS indépendant et des sauvegardes à jour pour tout serveur ou application lié à la liaison.

Le sixième chemin de défaillance est la porte d'entrée du service. Les pages de contact et de médias sont actives, tandis que certaines suppositions d'URL renvoient une 404. Cela rappelle que la communication client ne devrait pas dépendre d'un seul chemin web. Si un client ne peut pas atteindre le site, les canaux téléphonique, WhatsApp, e-mail et de bureau physique font partie de la résilience. Inversement, si le canal téléphonique est surchargé lors d'une panne locale, l'absence de page d'état publique peut laisser les clients dans l'incertitude.

Un fournisseur local peut améliorer la confiance rapidement en publiant une simple page d'état et un historique des pannes.

Ce que les forfaits d'accès disent de l'économie de l'hébergement

Les prix publics de Geeky Cloud sont bas par rapport aux standards de la connectivité professionnelle mais significatifs pour le marché de détail local. La page d'accueil indique des forfaits résidentiels mensuels d'environ 630, 735, 1050 et 1575 taka pour les niveaux de vitesse visibles, avec 5 % de TVA inclus sur les fiches de forfait. La valeur promise n'est pas une automatisation cloud profonde; c'est un accès abordable, des performances locales, du support et un ensemble de services de proximité qui rendent l'internet résidentiel et professionnel utilisable.

Cette échelle de prix détermine ce que les clients doivent attendre. Un plan d'accès mensuel à bas prix ne peut pas inclure de l'ingénierie sur mesure illimitée, du routage personnalisé, du personnel de support dédié, du matériel de rechange pour tous les cas particuliers et des crédits de service de type entreprise, à moins que ces fonctionnalités soient facturées séparément. Le fournisseur doit normaliser. Il doit réutiliser l'installation d'accès, les scripts de support, les modèles de routeur, les flux de facturation et les visites sur le terrain. C'est l'économie normale des FAI.

Cela ne devient risqué que lorsqu'un client utilise un produit d'accès de base comme s'il s'agissait d'une plateforme de haute disponibilité gérée.

La section internet dédié est plus pertinente pour la dépendance professionnelle. Geeky Cloud indique que l'internet haut débit dédié s'accompagne d'un langage sur des upstreams multiples et des sauvegardes, ainsi que d'une référence de disponibilité de 90 %. Un acheteur professionnel devrait décomposer cette revendication par écrit. « Dédié » signifie-t-il une bande passante garantie ou simplement un type de plan? Sauvegarde signifie-t-elle un deuxième upstream depuis le même emplacement, un deuxième chemin physique, une sauvegarde sans fil ou un engagement de support? La sauvegarde est-elle active, en veille à chaud ou manuelle?

Le chiffre de disponibilité s'applique-t-il à la liaison client, au cœur du fournisseur, à l'upstream, au site web ou à l'ensemble du service? La page ne répond pas à ces questions.

Les revendications de vitesse BDIX et CDN relèvent également de l'économie de l'hébergement. L'échange local et le contenu mis en cache peuvent améliorer le streaming, les téléchargements de logiciels, les médias sociaux et le contenu populaire. Ils ne garantissent pas de performances vers toutes les destinations distantes. Un client hébergeant un service pour des utilisateurs en dehors du Bangladesh, ou dépendant de SaaS internationaux, doit tester les chemins qui importent pour cette charge de travail. Lavue de longueur de chemin AS RIPEstatmontre des observations de route depuis de nombreux emplacements de collecteurs, mais la longueur du chemin n'est pas une garantie de performance client. C'est un indice de visibilité de routage.

Le signal de marché d'APNIC Labs doit également être utilisé avec prudence. Letableau des populations AS du Bangladesh d'APNIC Labsa placé AS148974 dans le tableau du Bangladesh le 1er juillet 2026 avec une estimation de 5 089 utilisateurs et une petite part nationale. Il s'agit d'une estimation de mesure, pas d'un dépôt d'abonné. Cela suggère que Geeky Cloud a un trafic utilisateur visible dans les données d'APNIC Labs, mais ne permet pas de déterminer le nombre de clients, les revenus, la capacité ou la santé commerciale. C'est utile comme signal que l'AS n'est pas purement décoratif.

Le tableau économique public est donc modeste et cohérent. Geeky Cloud semble être un véritable fournisseur d'accès local avec des ressources routées, une gamme de forfaits grand public, une surface de service multimédia et des bureaux locaux. Cela peut soutenir une valeur client réelle. Cela ne soutient pas une revendication selon laquelle Geeky Cloud disposerait d'un vaste inventaire cloud, d'une résilience multi-région étendue ou d'un riche parc de calcul hébergé. Les acheteurs doivent aligner le risque de charge de travail sur le prix et les preuves publiques.

La localité des données est à la fois un argument de vente et une question

La souveraineté des données et la localité ne sont pas seulement des questions de droit national. Pour un FAI local, la localité signifie là où le trafic est échangé, là où les dossiers clients se trouvent, là où le contenu hébergé est stocké, là où le personnel de support travaille et quelles parties peuvent affecter le service. La zone de service de Geeky Cloud est clairement locale dans sa présentation. Les bureaux, les prix des forfaits, les contacts de support et le langage de Khulna pointent vers des clients bangladais. Les ressources APNIC sont enregistrées en BD. L'upstream visible est un AS bangladais.

Ces faits soutiennent une lecture de connectivité locale.

En même temps, le chemin du site web complique la localité. Le domaine.net est derrière Cloudflare et redirige vers geekycloud.com.bd. Le site final.com.bd est hébergé sur une adresse en dehors de l'allocation APNIC visible de Geeky Cloud. Le certificat TLS pour geekycloud.com.bd est délivré par Let's Encrypt. Rien de tout cela n'est inhabituel. De nombreux fournisseurs locaux hébergent leurs sites web ailleurs, utilisent des services DNS et de certificats mondiaux, et séparent le trafic client des pages marketing publiques.

Mais si un client se soucie de l'emplacement des données de compte, des messages du formulaire de contact, des journaux de support ou des références de paiement, la page publique n'apporte pas de réponse complète.

La même question s'applique aux médias et à la capacité hébergée. Un serveur multimédia peut être local sur le réseau d'un FAI, hébergé dans un centre de données tiers, placé derrière un cache partenaire, ou servi depuis un autre réseau tout en étant lié depuis le site du FAI. La page publique du serveur multimédia prouve une surface visible, pas son emplacement, sa propriété ou ses pratiques de stockage. Un client devrait demander où le contenu multimédia est stocké, qui exploite le serveur, comment les données utilisateur sont journalisées, et ce qui se passe si le système multimédia est indisponible.

Pour les clients professionnels, la localité inclut également la responsabilité juridique et opérationnelle. Le site public de Geeky Cloud utilise un domaine bangladais, une adresse à Khulna et un langage de FAI agréé par la BTRC. L'APNIC répertorie une organisation bangladaise et des contacts bangladais. Cela donne aux clients un chemin de responsabilité locale. Mais le dossier public ne montre pas de contrat complet, de politique de confidentialité, de déclaration de conservation des données, de politique de sauvegarde, de liste de sous-traitants ou de conditions formelles de niveau de service.

Ces lacunes sont importantes si un client utilise la liaison pour des systèmes métier sensibles, du backhaul de vidéosurveillance, des données de santé, des paiements ou des services publics.

L'IPv6 est un point positif avec des réserves. Geeky Cloud dispose d'un /48 IPv6 visible et annonce l'IPv6 à la demande dans les fiches de forfait. De nombreux petits fournisseurs d'accès sont en retard sur l'IPv6, donc une IPv6 visible est un signe positif. Mais « à la demande » signifie que les clients peuvent devoir la demander, et les pratiques de support détermineront si elle fonctionne correctement. Un client doit vérifier la taille du préfixe, la configuration du routeur, les paramètres de pare-feu par défaut, le DNS inverse si nécessaire et si le support IPv6 persiste après les changements de forfait.

La conclusion sur la localité des données est équilibrée. Geeky Cloud dispose de suffisamment de preuves sur le Bangladesh et Khulna pour être traité comme un fournisseur d'accès local, et non comme une marque cloud offshore sans visage. Mais la localité n'est pas entièrement documentée pour les couches hébergées ou de données client. Les clients qui se soucient de la localité doivent poser des questions au-delà de la page d'accueil: où se trouve le rack, où se trouve la sauvegarde, où se trouve le journal, où se trouve le handoff upstream, et qui peut restaurer le service?

Ce que les clients devraient vérifier avant de s'appuyer sur Geeky Cloud

Un utilisateur résidentiel à faible risque peut ne pas avoir besoin d'un long exercice de diligence. Si le service est bon marché, assez rapide et soutenu localement, le test pratique est de savoir s'il fonctionne à l'adresse. Mais le sujet ici est la capacité hébergée et la dépendance, donc le profil de l'acheteur est plus strict: une petite entreprise, une école, une clinique, un développeur, un commerce, un utilisateur multimédia ou un bureau qui peut compter sur Geeky Cloud pour plus que de la navigation occasionnelle.

Le premier point de vérification est la frontière exacte du service. Le client achète-t-il uniquement l'accès Internet, ou aussi du stockage hébergé, un service multimédia, une IP statique, un routeur géré, un pare-feu, un backhaul de vidéosurveillance ou un emplacement de serveur? Chaque couche a un mode de défaillance différent. Le site public regroupe plusieurs services sous une même marque, l'acheteur doit donc demander une description écrite du service acheté et des parties qui sont exclues.

Le deuxième point de vérification est la diversité de l'upstream. Demandez à Geeky Cloud d'identifier la configuration live de l'upstream pour les plans professionnels et dédiés, d'expliquer si AS139901 est le seul handoff de production visible dans la table mondiale, et d'indiquer ce qui se passe en cas de panne upstream. Si le fournisseur dispose d'une connectivité de secours, demandez si elle est active dans BGP, activée manuellement, disponible uniquement pour certains clients, ou utilisée uniquement pour les opérations de bureau. La réponse doit être opérationnelle, pas seulement commerciale.

Le troisième point de vérification est la résilience électrique et des installations. Demandez où se trouve l'équipement principal qui dessert le client, combien de temps les batteries peuvent le maintenir, si des générateurs sont disponibles, si les armoires de terrain ont une alimentation de secours, et si le handoff upstream partage le même domaine d'alimentation. Un fournisseur peut avoir un routage valide et néanmoins échouer au niveau de l'alimentation.

Le quatrième point de vérification est le personnel de réparation. Geeky Cloud annonce un support rapide et donne la ligne d'assistance, WhatsApp et les chemins de contact du bureau. Les clients doivent tester la réactivité avant une migration critique. Ouvrez un ticket non urgent, appelez la ligne d'assistance, demandez comment les pannes sont escaladées et confirmez si les clients professionnels bénéficient d'une prise en charge différente des plans résidentiels. La force d'un fournisseur local peut être la réactivité sur le terrain; le seul moyen de l'apprendre est de la tester.

Le cinquième point de vérification est la gestion des adresses. Si le client a besoin d'une adresse IPv4 publique, demandez si elle est dédiée, partagée, statique, portable lors des changements de plan, protégée contre les problèmes de réputation et accompagnée d'un DNS inverse si nécessaire. Pour l'IPv6, demandez quelle taille de préfixe est déléguée et s'il survit au remplacement du routeur. Si le service doit héberger des applications entrantes, testez depuis des réseaux extérieurs avant de vous y fier.

Le sixième point de vérification est la sauvegarde et la sortie. Si Geeky Cloud héberge un service client quelconque, le client doit maintenir des sauvegardes indépendantes et des étapes de reconstruction documentées. Si Geeky Cloud n'est que le fournisseur d'accès, le client doit tout de même conserver une solution de secours mobile ou une deuxième ligne fixe pour les travaux critiques. Le risque de dépendance n'est pas éliminé par une relation avec un fournisseur local; il est géré en disposant d'un deuxième chemin lorsque le premier est défaillant.

Ce qui améliorerait la note des preuves publiques

Geeky Cloud pourrait améliorer substantiellement l'assurance publique sans révéler de détails sensibles. Une page réseau nommant les upstreams actuels, le statut de peering, les ressources IPv4 et IPv6 et la zone de service générale serait utile. Une page d'état publique serait encore plus utile. Même une simple page qui sépare la maintenance planifiée, les incidents d'accès, les incidents upstream et les incidents de service multimédia permettrait aux clients de distinguer les problèmes de site web des problèmes de réseau.

Une page SLA serait également utile, à condition qu'elle définisse la mesure. Le langage actuel des forfaits publics est trop large pour une dépendance professionnelle. Une page plus solide indiquerait quels plans ont des objectifs de disponibilité, ce qui compte comme une indisponibilité, comment la maintenance est annoncée, quels crédits s'appliquent et quels événements sont exclus. Elle séparerait l'accès résidentiel des liaisons professionnelles dédiées et de tout service hébergé.

Une déclaration sur les installations et l'alimentation serait utile. Geeky Cloud n'a pas besoin de publier les coordonnées exactes des racks. Il pourrait indiquer si le réseau central est hébergé dans des locaux en propre, en colocation louée, dans des installations upstream ou un mélange. Il pourrait indiquer s'il existe une alimentation de secours sur le site principal et si les agences sont uniquement en contact avec la clientèle ou font également partie des opérations réseau. Cela réduirait l'incertitude quant aux fenêtres de réparation.

Une déclaration sur les données et la portabilité serait utile. Pour tout service multimédia, d'hébergement ou d'équipement client, l'entreprise pourrait dire à qui appartiennent les données, combien de temps les journaux sont conservés, comment les sauvegardes sont gérées, si les clients peuvent exporter les configurations et comment le service est résilié. Une telle déclaration importerait pour les clients professionnels qui considèrent Geeky Cloud comme plus qu'une simple ligne haut débit.

Enfin, une page de transparence de routage serait utile. Geeky Cloud dispose déjà d'enregistrements APNIC publics, d'une RPKI valide et d'une IPv6 visible. Publier une petite note de routage permettrait aux clients de comprendre pourquoi la table publique montre un seul voisin observé, si une sauvegarde existe et comment le fournisseur gère les incidents de routage. Pour un réseau de cette taille, la transparence peut être plus précieuse que l'échelle.

En résumé

Geeky Cloud doit être lu comme un véritable fournisseur de réseau axé sur Khulna, avec des ressources de numéros Internet publics, un routage actif et un site de service client local. Les preuves sont plus solides qu'une simple entrée d'annuaire nominative. L'APNIC identifie AS148974 et les ressources GEEKY-BD. RIPEstat montre un /24 IPv4 et un /48 IPv6 annoncés par cet AS. La validation RPKI est valide pour les deux préfixes visibles. Le site public vend de l'internet résidentiel, professionnel et dédié, annonce des performances BDIX/CDN et l'IPv6 à la demande, et fournit des détails sur le support local et les bureaux.

Les preuves ne sont toujours pas assez solides pour qualifier Geeky Cloud d'opérateur d'infrastructure cloud éprouvé. L'ensemble de routes publiques est réduit, le nombre de voisins observés est de un, PeeringDB n'a pas de profil réseau public pour AS148974 dans larecherche API PeeringDB, et le site ne publie pas de détails sur le VPS, le bare metal, le stockage, la sauvegarde, les installations, les incidents ou la diversité de transit. Le site web public et le réseau client routé semblent également être des chemins distincts, ce qui est normal mais important.

Cela donne une note actuelle Moyenne plutôt que Forte. Geeky Cloud dispose de preuves réseau réelles, d'une surface de service active et de signaux d'exploitation locaux au Bangladesh. La dégradation vient du dossier public mince en matière de capacité hébergée et de la vue de routage concentrée.

Les clients peuvent utiliser Geeky Cloud pour des besoins d'accès local appropriés et des besoins adjacents à l'hébergement à faible risque, mais ils ne devraient pas en faire un point de défaillance unique pour les systèmes métier sans sauvegardes indépendantes, connectivité alternative, IPv6 et attribution IP testées, détails d'escalade du support et un plan de migration clair.