Geeky Cloud vend de la 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 d'entreprise, l'internet dédié, la vidéosurveillance, la configuration réseau et la sécurité réseau, répertorie des bureaux à Nirala, Gollamari et Bagmara à Khulna, et se décrit comme un FAI approuvé par la BTRC.
• Les preuves de réseau les plus solides sont réelles mais limitées. LeRDAP de l'APNIC pour AS148974et lavue whois de l'APNICidentifient GEEKY-AS-AP comme Geeky Cloud au Bangladesh, tandis que lesdonnées de préfixes annoncés de RIPEstatmontrent 103.175.17.0/24 et 2001:df7:e680::/48 comme les ressources annoncées visibles pendant la fenêtre d'examen.
• La hygiène de routage est meilleure que l'histoire de résilience publique. Lesvalidations RPKI de RIPEstat pour 103.175.17.0/24etpour 2001:df7:e680::/48marquent toutes deux l'origine actuelle comme valide, mais lesdonnées de statut de routage de RIPEstat pour AS148974signalent un préfixe IPv4, un /48 IPv6 et un voisin observé.
• Le risque pratique est la concentration des dépendances. Geeky Cloud peut plausiblement servir les clients d'accès locaux et les petits cas d'utilisation hébergés ou adjacents aux médias, mais les documents publics ne prouvent pas de sites de centres de données nommés, de racks possédés, de stock de serveurs de rechange, de basculement multi-opérateur, d'historique d'incidents public, de sauvegardes client portables ou d'une voie documentée pour s'éloigner du fournisseur si l'amont, le réseau d'accès, le contact de facturation ou la file d'attente de réparation échoue.

Pourquoi Geeky Cloud a besoin d'une lecture étroite

Le nom Geeky Cloud invite à une lecture de service cloud, mais les preuves publiques en demandent une plus prudente. Une entreprise peut utiliser un langage cloud tandis que son activité visible est l'accès local, la connectivité gérée, la livraison de médias ou un mélange de petits services hébergés derrière une marque de FAI de quartier. Dans ce cas, le dossier public pointe d'abord vers l'accès Internet à Khulna. Le propresite Bangladesh de Geeky Cloudest écrit principalement pour les clients locaux: il vend de l'internet résidentiel, de l'internet d'entreprise et de l'internet dédié, donne des vitesses de forfait résidentiel, fait la publicité de la vitesse BDIX et CDN, répertorie les canaux de contact pour le support et le paiement des factures, et place l'entreprise à Khulna plutôt que sur un marché de centre de données nommé.

Cela ne rend pas l'entreprise non pertinente pour la capacité hébergée. Les FAI locaux ne se limitent souvent pas au haut débit de détail. Ils peuvent héberger des sites Web clients, gérer des services de cache et de médias, fournir des réseaux de bureau, placer 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 » et « dépendance cloud » peut être mince.

Si le fournisseur d'accès héberge également un serveur multimédia, maintient un espace d'adressage, exécute le DNS client ou transporte la seule liaison de bureau haut débit abordable, le service numérique du client reste lié aux racks, à l'électricité, au transit amont 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. Ce n'est pas le cas. 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 registres APNIC montrent que Geeky Cloud a son propre numéro AS et des ressources d'adressage portables. RIPEstat montre que ces ressources sont visibles dans le routage global. Le site Web de l'entreprise montre une surface de vente au détail et de support active.

Mais le même registre ne montre pas de noms d'installations publiques, de propriété de racks, d'amonts redondants au-delà du seul voisin observé, de page de statut, d'objectifs de réparation, de garanties d'exportation client ou de limites de capacité transparentes.

Cette scission est la conclusion centrale de l'article. Geeky Cloud n'est pas une coquille vide. Il a un site de service visible, des pages de contact accessibles et une identité routée 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 réseau local réel avec un ensemble de routes publiques limité et une couche d'assurance mince autour des revendications de capacité hébergée. C'est une catégorie utile mais dégradée: assez crédible pour enquêter, trop peu documenté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 Internet dans la ville de Khulna, avec des forfaits pour les maisons 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 d'entreprise, l'internet dédié, la vidéosurveillance, la configuration réseau et la sécurité réseau. Les cartes de forfait listent des vitesses allant jusqu'à 40, 50, 70 et 100 Mbps, des prix en taka bangladais, un langage de réseau fibre optique, des revendications de vitesse BDIX et CDN, une 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 donne également plusieurs indices opérationnels. Premièrement, elle met l'accent sur le paiement des factures et l'utilisation responsable des connexions, ce qui est un territoire courant pour les FAI de détail. Deuxièmement, elle met en avant le streaming 4K, les jeux, Facebook, la vitesse BDIX et CDN, qui intéressent un client résidentiel ou de petit bureau. Troisièmement, elle répertorie une hotline, un centre d'appels et un numéro de support, les détails de paiement marchand Bkash-Nagad et un contact WhatsApp.

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

Le site contient une entrée « serveur multimédia », et lapage du serveur multimédiarenvoie une page active. Cela compte 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 de serveur multimédia n'est pas la même chose qu'un catalogue de produits cloud public. Le site public n'affiche pas de plans VPS, d'inventaire de serveurs nus, 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 de 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 de route courantes comme les pages de paiement, à propos et forfaits ont renvoyé des réponses 404 lors de cet examen, bien que le contenu des forfaits soit visible sur la page d'accueil. Ce n'est pas une faute majeure en soi. Les petits sites de FAI gardent souvent la plupart du contenu sur une seule page. Mais cela montre pourquoi les acheteurs devraient éviter de lire les étiquettes de menu comme une 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 protégé par Cloudflare, tandis que la page.com.bd finale répond directement depuis un serveur Web Apache sur une adresse distincte en dehors du préfixe visible propre à Geeky Cloud, 103.175.17.0/24. La route du site Web n'est donc pas la même que la route du réseau d'accès client. Un visiteur peut atteindre un site public via un chemin tandis que l'accès Internet d'un abonné, une session de serveur multimédia ou un 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 le visage public de Geeky Cloud est une marque de FAI et de connectivité gérée desservant les clients de Khulna. La 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 la rendent pas vérifiable en tant que plateforme cloud large. L'article traite donc le nom « cloud » comme une affirmation à examiner via des preuves de routage et de dépendance, pas comme une garantie de résilience de type cloud.

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

Les preuves concrètes les plus solides se trouvent dans l'APNIC. Leregistre RDAP de l'APNIC pour AS148974identifie le déclarant comme Geeky Cloud et place l'AS au Bangladesh. Larequête whois de l'APNIC pour AS148974donne l'aut-num comme AS148974, le nom 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 liste également le contact d'abus lié à la boîte mail ipabu de Geeky Cloud et montre l'aut-num modifié pour la dernière fois en 2022.

Le registre 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, liste le pays BD et fournit une adresse à Khulna. Unerequête de mainteneur APNIC distincte pour MAINT-GEEKY-BDassocie le mainteneur à Geeky Cloud au Bangladesh et pointe vers la même famille de contacts administratifs. Leregistre RDAP IPv4 de l'APNICet larequête whois IPv4 de l'APNICidentifient 103.175.17.0/24 comme GEEKY-BD, décrit comme Geeky Cloud, pays BD, statut alloué portable. Leregistre RDAP IPv6 de l'APNICet larequête whois IPv6 de l'APNICidentifient 2001:df7:e680::/48 comme GEEKY-BD, décrit comme Geeky Cloud, pays BD, statut attribué portable.

Ce sont des faits significatifs. Un numéro AS et des registres 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é réseau contrôlée via les registres APNIC plutôt que seulement un site Web marketing. Pour un FAI, cela compte. Cela signifie qu'il existe une identité routable qui peut être observée, mesurée et liée à des contacts de registre publics. Cela donne également aux clients et aux pairs un endroit pour diriger les questions d'abus, de dépannage et de routage.

Les dates d'enregistrement sont utiles pour le contexte de maturité. Les registres de ressources IPv4 et IPv6 datent d'octobre 2021, tandis que les registres d'organisation et de contact ont des modifications ultérieures, y compris des mises à jour de 2026 pour l'organisation et la validation des abus. Cela suggère un historique d'exploitation plus ancien qu'une nouvelle page d'accueil. Cela ne nous dit pas comment le réseau a changé, 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 registres de numéros Internet publics.

La limite est l'échelle. Un /24 IPv4 contient 256 adresses. Un /48 IPv6 est une taille normale pour qu'un réseau d'accès numérote les clients et l'infrastructure, mais c'est toujours une seule allocation IPv6 visible. Un fournisseur peut servir de vrais clients avec cette empreinte. Il ne peut pas être décrit à partir de données publiques comme une plateforme hébergée large avec de nombreux blocs routables, de nombreux sites périphériques ou plusieurs pools d'adresses indépendants. Le registre donne de la substance à Geeky Cloud. Il encadre également la limite supérieure de ce que les étrangers peuvent vérifier.

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

RIPEstat confirme que l'AS Geeky Cloud est actif. Lavue d'ensemble AS pour AS148974signale la ressource comme 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 du statut de routage ASsignale 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 petit. Le nombre de voisins est concentré. Un réseau d'accès local peut très bien fonctionner avec une seule interconnexion amont si cet amont est stable, bien dimensionné et localement approprié. Mais un acheteur ne doit pas confondre « visible mondialement » avec « résilient de manière indépendante ».

Si le seul chemin amont observé échoue, est filtré, devient congestionné, connaît un problème d'alimentation, a un différend de 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. Le registre public ne prouve ni l'un ni l'autre.

Les données au niveau du préfixe soutiennent la même lecture. Lavue d'ensemble du préfixe RIPEstat pour 103.175.17.0/24signale le préfixe comme annoncé par AS148974 et lié à Geeky Cloud. Lavue du statut de routage pour 103.175.17.0/24montre l'origine AS148974, la couverture d'objet de route APNIC et la visibilité à 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::/48signale de même le préfixe IPv6 comme annoncé par AS148974, tandis que lavue du statut de routage IPv6montre l'origine AS148974 et une visibilité IPv6 complète dans l'ensemble de rapport.

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

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

Lavue de cohérence de routage AS de RIPEstatajoute un autre indice utile. Elle signale les deux préfixes comme présents à la fois dans BGP et whois, et identifie AS139901 comme un pair vu dans BGP mais non listé comme pair d'import/export dans la vue de politique whois. Ce n'est pas inhabituel dans les registres 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 liste toute la connectivité active.

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

La carte de forfait de détail de Geeky Cloud vend des vitesses et du support, mais le service livré dépend d'actifs physiques. Une connexion résidentielle ou professionnelle à Khulna a besoin de fibre de dernier kilomètre, de commutateurs d'accès, de répartiteurs ou d'armoires, d'équipement d'agrégation, de backhaul, d'électricité, de surveillance, d'optiques de rechange, de techniciens de terrain et d'un moyen d'atteindre l'Internet plus large.

Si l'entreprise prend également en charge les services multimédias, les réseaux de vidéosurveillance ou les é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 fibre optique, la vitesse BDIX et CDN, une IPv6 à la demande et plusieurs amonts ou secours pour le service dédié. Ce sont des affirmations précieuses pour les utilisateurs. Elles nécessitent aussi une interprétation prudente. « Vitesse BDIX et CDN » indique au client que le contenu local ou mis en cache peut bien fonctionner, pas que chaque route internationale est non 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 IPv6 par défaut ou que les routeurs clients sont correctement configurés.

« Plusieurs amonts et secours » est une affirmation 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, descendants uniquement ou en dehors de la fenêtre d'observation, mais les preuves publiques ne prouvent pas une diversité active.

La géographie physique compte. Geeky Cloud liste des bureaux à Khulna, et les registres APNIC placent ses contacts à Khulna. Cela est utile pour le support local: une équipe de terrain peut atteindre les sites clients, réparer les départs de fibre, échanger les équipements clients et collecter les paiements. Cela crée également une concentration locale. Un événement électrique, une coupure de câble, un problème de travaux routiers, une panne d'agrégation ou un événement météorologique sévère dans la zone de service peut affecter de nombreux clients à la fois.

Le registre ne nomme pas le point de présence principal, la route de backhaul hors de Khulna, la disposition d'alimentation de secours, la durée de fonctionnement du générateur ou l'installation où l'équipement de routage est hébergé.

Le site Web lui-même n'est pas un proxy fiable pour le réseau d'accès. Le site.com.bd final résout vers 5.77.50.137 lors des vérifications DNS locales, tandis que le domaine.net est protégé par Cloudflare et redirige vers le site.com.bd. Cela signifie que les pages marketing et 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 sensé. 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 alors que la page publique reste en ligne ailleurs, ou la page publique peut échouer alors que les abonnés sont encore routés 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 suffisamment de bande passante d'accès pour les pics normaux mais pas assez de capacité de réserve pour des clients inhabituellement lourds. Il peut avoir une capacité médiatique locale mais un stock de serveurs limité. Il peut avoir un /24 IPv4 public et devoir rationner soigneusement les adresses publiques. Il peut prendre en charge IPv6 mais encore dépendre des dispositifs clients, de la politique amont et de la pratique de support pour rendre IPv6 utile.

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

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

Le premier chemin de défaillance à tester est l'accessibilité amont. La vue BGP publique pointe vers AS139901 comme voisin observé de Geeky Cloud. Si AS139901 a un événement de maintenance, un problème de filtre de route, une congestion, un différend 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 seule connexion de bureau, seul chemin médiatique ou seule 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 prend la restauration habituellement.

Le deuxième chemin de défaillance est l'agrégation locale. Un FAI local peut avoir une route globale propre tandis qu'un commutateur de quartier, une armoire, une épissure, un OLT, un backhaul sans fil ou un lien d'agrégation de bureau tombe en panne. Le site de Geeky Cloud met en avant l'internet résidentiel, d'entreprise 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 de problème sont priorisés, si la hotline est dotée en personnel en dehors des heures normales, comment les liaisons professionnelles sont escaladées, et si les plans dédiés reçoivent un objectif de réparation différent des forfaits résidentiels.

Le troisième chemin de défaillance est l'alimentation électrique. Le point le plus 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, à l'armoire, au bâtiment client ou au transfert amont. 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 affirmations de disponibilité par couche de service. Une affirmation de disponibilité de 90 % sur une carte de forfait publique n'est pas un objectif formel de haute disponibilité pour les services hébergés.

En fait, si elle est prise littéralement, une disponibilité de 90 % permettrait beaucoup plus de temps d'arrêt que ce que la plupart des clients professionnels attendent. Les acheteurs devraient demander ce que signifie la disponibilité pour chaque service et sur quelle période de mesure.

Le quatrième chemin de défaillance est la rareté des adresses. Un /24 IPv4 peut supporter un réseau d'accès local via NAT, des plans d'adressage partagés et une assignation prudente, mais l'IPv4 publique est limitée. 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 IP publique Geeky Cloud, d'une route de backhaul de vidéosurveillance, d'une dépendance médiatique locale, d'entrées DNS, de la configuration du routeur client ou du moment du paiement. Si le service échoue 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 hors fournisseur, un accès alternatif, 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 médias sont actives, tandis que certaines suppositions de route renvoient 404. Cela rappelle que la communication client ne doit pas dépendre d'une seule route Web. Si un client ne peut pas atteindre le site, le téléphone, WhatsApp, l'e-mail et les canaux 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 d'une page de statut publique peut laisser les clients deviner.

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

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

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

Cette échelle de prix façonne ce que les clients devraient attendre. Un plan d'accès mensuel bas ne peut pas inclure une ingénierie sur mesure illimitée, un routage personnalisé, un personnel de support dédié, du matériel de rechange pour chaque cas extrême et des crédits de service de style entreprise, sauf si ces fonctionnalités sont facturées séparément. Le fournisseur doit standardiser. Il doit réutiliser le réseau d'accès, les scripts de support, les modèles de routeur, les flux de facturation et les visites sur le terrain. C'est une économie de FAI normale.

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

La section Internet dédié est plus pertinente pour la dépendance professionnelle. Geeky Cloud dit que l'internet dédié haute vitesse est livré avec un langage de plusieurs amonts et secours et une référence de disponibilité de 90 %. Un acheteur professionnel devrait détailler cette affirmation par écrit. « Dédié » signifie-t-il une bande passante garantie ou seulement un type de plan? Le secours signifie-t-il un deuxième amont depuis le même endroit, un deuxième chemin physique, un secours sans fil, ou un engagement de support? Le secours est-il actif, en veille chaude ou manuel?

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

Les affirmations de vitesse BDIX et CDN appartiennent également à l'économie de l'hébergement. Le contenu local et mis en cache peut améliorer le streaming, les téléchargements de logiciels, les réseaux sociaux et le contenu populaire. Ils ne garantissent pas les performances vers toutes les destinations distantes. Un client hébergeant un service pour des utilisateurs en dehors du Bangladesh, ou dépendant d'un SaaS international, doit tester les chemins qui comptent pour cette charge de travail. Lavue de longueur de chemin AS de 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é APNIC Labs doit également être utilisé avec prudence. Latable de population AS du Bangladesh d'APNIC Labsa placé AS148974 dans la table du Bangladesh le 1er juillet 2026 avec une estimation de 5 089 utilisateurs et une faible part nationale. C'est une estimation de mesure, pas un dépôt d'abonnés. Cela suggère que Geeky Cloud a un trafic utilisateur visible dans les données APNIC Labs, mais cela ne peut pas régler le nombre de clients, les revenus, la capacité ou la santé de l'entreprise. 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 échelle de forfaits de détail, une surface de service multimédia et des bureaux locaux. Cela peut soutenir une réelle valeur client. Cela ne soutient pas une affirmation selon laquelle Geeky Cloud dispose d'un grand inventaire cloud, d'une résilience multi-région large ou d'un parc de calcul hébergé riche. Les acheteurs devraient aligner le risque de la charge de travail avec le prix et les preuves publiques.

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

La souveraineté et la localisation des données ne sont pas seulement des questions de droit national. Pour un FAI local, la localisation signifie où le trafic est échangé, où les enregistrements clients se trouvent, où le contenu hébergé est stocké, 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 la langue de Khulna pointent vers des clients bangladais. Les ressources APNIC sont enregistrées en BD. L'amont visible est un AS bangladais.

Ces faits soutiennent une lecture de connectivité locale.

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

Mais si un client se soucie de l'endroit où les données de compte, les messages de formulaire de contact, les journaux de support ou les références de paiement sont stockés, la page publique ne fournit pas de réponse complète.

La même question s'applique aux capacités multimédia et hébergées. Un serveur multimédia peut être local au réseau 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 FAI. La page publique du serveur multimédia prouve une surface visible, pas son emplacement, sa propriété ou sa pratique 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 localisation inclut également la responsabilité légale et opérationnelle. Le site public de Geeky Cloud utilise un domaine bangladais, une adresse à Khulna et un langage de FAI approuvé par la BTRC. L'APNIC liste une organisation bangladaise et des contacts bangladais. Cela donne aux clients une voie de responsabilité locale. Mais le registre 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-fournisseurs ou de conditions de service formelles.

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

IPv6 est un point positif avec des réserves. Geeky Cloud a un /48 IPv6 visible et fait la promotion de l'IPv6 à la demande dans les cartes de forfait. De nombreux petits fournisseurs d'accès sont en retard sur IPv6, donc une IPv6 visible est un signe positif. Mais « à la demande » signifie que les clients peuvent devoir demander, et la pratique de support décidera si cela fonctionne proprement. Un client devrait vérifier la taille du préfixe, la configuration du routeur, les 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 les données locales est équilibrée. Geeky Cloud a suffisamment de preuves au Bangladesh et à Khulna pour être traité comme un fournisseur d'accès local, pas comme une marque cloud offshore sans visage. Mais la localisation 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 localisation doivent demander au-delà de la page d'accueil: où est le rack, où est la sauvegarde, où est le journal, où est le transfert amont, et qui peut restaurer le service?

Ce que les clients devraient vérifier avant de compter sur Geeky Cloud

Un utilisateur domestique à 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 la mission 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 magasin, un utilisateur multimédia ou un bureau qui peut compter sur Geeky Cloud pour plus qu'une navigation occasionnelle.

Le premier élément de vérification est la limite exacte du service. Le client achète-t-il seulement un 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 placement de serveur? Chaque couche a un mode de défaillance différent. Le site public regroupe plusieurs services sous une même marque, donc l'acheteur devrait demander une description écrite du service acheté et des parties exclues.

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

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

Le quatrième élément de vérification est le personnel de réparation. Geeky Cloud fait la promotion d'un support rapide et donne des contacts par hotline, WhatsApp et bureau. Les clients devraient tester la réponse avant une migration critique. Ouvrez un ticket non urgent, appelez la hotline, demandez comment les pannes sont escaladées, et confirmez si les clients professionnels reçoivent un traitement différent des plans résidentiels. La force d'un fournisseur local peut être la réactivité sur le terrain; la seule façon de l'apprendre est de la tester.

Le cinquième élément 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 entre les changements de forfait, protégée des problèmes de réputation et accompagnée d'un DNS inverse si nécessaire. Pour IPv6, demandez quelle taille de préfixe est déléguée et si elle survit au remplacement du routeur. Si le service hébergera des applications entrantes, testez depuis des réseaux externes avant de vous y fier.

Le sixième élément de vérification est la sauvegarde et la sortie. Si Geeky Cloud héberge un service client, le client doit maintenir des sauvegardes indépendantes et des étapes de reconstruction documentées. Si Geeky Cloud est seulement le fournisseur d'accès, le client doit toujours garder un mobile ou un deuxième fixe de secours pour le travail critique. Le risque de dépendance n'est pas éliminé par une relation avec un fournisseur local; il est géré en ayant un deuxième chemin lorsque le premier échoue.

Ce qui améliorerait la note des preuves publiques

Geeky Cloud pourrait améliorer matériellement l'assurance publique sans révéler de détails sensibles. Une page réseau nommant les amonts actuels, le statut de peering, les ressources IPv4 et IPv6 et la zone de service large aiderait. Une page de statut publique aiderait plus. Même une page simple qui sépare la maintenance planifiée, les incidents d'accès, les incidents amont 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 aiderait aussi, à condition qu'elle définisse la mesure. Le langage actuel du forfait public est trop large pour la dépendance professionnelle. Une page plus solide dirait quels plans ont des objectifs de disponibilité, ce qui compte comme temps d'arrêt, 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 aiderait. Geeky Cloud n'a pas besoin de publier les coordonnées exactes des racks. Elle pourrait dire si le réseau principal est hébergé dans des locaux propres, une colocation louée, des installations amont ou un mélange. Elle pourrait indiquer si l'alimentation de secours existe sur le site principal et si les bureaux secondaires sont seulement orientés clients ou aussi parties des opérations réseau. Cela réduirait l'incertitude autour des fenêtres de réparation.

Une déclaration sur les données et la portabilité aiderait. Pour tout service multimédia, d'hébergement ou d'équipement client, l'entreprise pourrait dire qui possède 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 compterait pour les clients professionnels qui traitent Geeky Cloud comme plus qu'une ligne haut débit.

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

Conclusion

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 orienté client local. Les preuves sont plus solides qu'une entrée d'annuaire uniquement 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, d'entreprise et dédié, fait la promotion des performances BDIX/CDN et de l'IPv6 à la demande, et donne 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 avéré. L'ensemble de routes publiques est petit, le nombre de voisins observés est 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 VPS, bare-metal, stockage, sauvegarde, installation, incident ou diversité de transit. Le site Web public et le réseau client routé semblent également être des chemins séparés, ce qui est normal mais important.

Cela donne la note actuelle Moyenne plutôt que Forte. Geeky Cloud a de véritables preuves réseau, une surface de service active et des signaux opérationnels locaux au Bangladesh. La dégradation vient du maigre dossier public de capacité hébergée et de la vue de routage concentrée. Les clients peuvent utiliser Geeky Cloud pour un accès local approprié et des besoins hébergés à faible risque, mais ils ne doivent pas en faire un point de défaillance unique pour les systèmes professionnels sans sauvegardes indépendantes, connectivité alternative, IPv6 testé et assignation IP, détails d'escalade de support et un plan de migration clair.