Identifier le fournisseur cloud : audit croisé ASN, virtualisation et empreinte de latence

Utilisez trois niveaux de vérification croisée pour identifier le véritable fournisseur cloud multiplateforme.

Mis à jour 2026-08-07 · CloudWorth

Identification du fournisseur cloudAudit multiplateformeASNVirtualisationEmpreinte de latenceCloudWorthSteal TimeSurvente VPSBenchmark VPS

Triple validation ASN, virtualisation et empreinte de latence pour identifier clairement le véritable fournisseur cloud.

Identifier le fournisseur cloud via l'ASN

Quand vous obtenez un serveur cloud, ne vous précipitez pas sur les benchmarks. Commencez par vérifier l'attribution ASN — c'est l'astuce la plus « économique » dans un audit multiplateforme. Une seule commande : whois $(curl -s ifconfig.me | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}') ou directement curl ipinfo.io/asn. La sortie ressemble à AS45102 Alibaba (US) Technology Co., Ltd. et le fournisseur apparaît immédiatement.

Mais il y a de nombreux pièges : un même bloc d'IP peut être partagé par plusieurs fournisseurs cloud, par exemple les ASN d'AWS et de CloudFront se chevauchent ; les nœuds CDN sont souvent déguisés en serveurs d'origine. Ne vous fiez donc pas à un seul ASN : croisez-le avec les données de routage objectives (comme l'historique des préfixes BGP) et les empreintes de virtualisation. Si l'ASN indique « Alibaba » mais que la couche de virtualisation est KVM avec une courbe de latence étrange, restez vigilant.

Avec CloudWorth /app, vous pouvez automatiquement collecter les trois couches d'empreintes : ASN, type de virtualisation et steal time, évitant ainsi d'assembler des commandes manuellement. La prochaine section abordera l'identification de la virtualisation, ce qui fait la transition.

Détection du type de virtualisation

Le type de virtualisation est la deuxième empreinte pour identifier le fournisseur de cloud sur un serveur. Une même plage d'adresses IP peut partager un ASN, mais l'implémentation de la virtualisation sur l'hôte est difficile à déguiser. Sous Linux, j'exécute d'abord systemd-detect-virt, qui lit les informations CPUID et DMI ; KVM renvoie généralement kvm, Xen xen, OpenVZ openvz. J'utilise ensuite lscpu pour examiner le vendor de l'hyperviseur : la plupart des fournisseurs de cloud exposent leur véritable identité, comme Xen/KVM pour AWS, KVM pour Alibaba Cloud et Tencent Cloud. Si une sortie étrange apparaît (par exemple Microsoft pour Hyper-V), il faut se méfier : s'agit-il d'Azure ou d'un panneau d'habillage ?

Lors d'un audit multiplateforme, sous Windows, vous pouvez utiliser systeminfo pour consulter la version du BIOS et le modèle ; sous macOS, cela est plus rare mais vous pouvez utiliser sysctl -n machdep.cpu.features pour compléter le diagnostic. Notez que les VPS conteneurisés affichent docker ou lxc, ce qui présente un risque élevé de sur-allocation ; il faut donc les vérifier plus en détail avec Steal Time. J'ai déjà écrit un guide d'audit multiplateforme et vous pouvez y combiner les commandes ; vous pouvez également utiliser l'outil de détection CloudWorth pour croiser directement les empreintes de virtualisation et les données de latence.

Dès que les trois couches — ASN, virtualisation et latence — correspondent, le fournisseur de cloud ne peut pas échapper à la détection, et il est plus facile de repérer les produits de revente qui ne sont pas ce qu'ils prétendent être.

Validation croisée par empreinte de latence

L'ASN et la virtualisation nous disent « qui a construit la salle des machines », mais l'empreinte de latence nous dit « comment cette machine vit en ce moment ». Dans un audit multiplateforme pour identifier le fournisseur cloud d'un serveur, j'ai l'habitude de considérer la latence comme un « détecteur de mensonge » au niveau physique : elle est difficile à déguiser, car la vitesse de la lumière et les effets de file d'attente ne trompent personne.

Voici quelques petites méthodes :

• Ligne de base RTT et gigue : effectuez 500 pings consécutifs et enregistrez min/moyenne/max/mdev. Si mdev dépasse 5 ms sur une longue période, cela signifie que le voisin ou la machine hôte est chargé ; si la moyenne est nettement supérieure à celle d'une nouvelle machine dans le même centre de données, il peut s'agir de surréservation ou d'un routage détourné.
• Délai de poignée de main TCP vs délai ICMP : certains fournisseurs cloud limitent spécifiquement l'ICMP. Dans ce cas, utilisez nc -vz host port ou curl -w pour mesurer le délai réel de la poignée de main ; un écart trop important indique une mise en forme du trafic.
• Dernier saut de Traceroute : si l'avant-dernier saut est une passerelle publique et que le dernier saut aboutit directement à une adresse IP interne, il s'agit probablement d'une machine hôte partagée ; s'il y a un saut supplémentaire ou une couche NAT, méfiez-vous du relais.

Exécutez un petit script :

for i in {1..200}; do ping -c 1 -W 1 YOUR_IP | grep -o 'time=.*' ; sleep 0.2; done | awk -F'=' '{print $2}' | sort -n | awk '{a[NR]=$1} END {print "min="a[1], "max="a[NR], "med="a[int(NR/2)]}'

Extrayez min/médiane/max, puis vérifiez si la médiane et le maximum sont excessivement éloignés.

Ensuite, croisez l'empreinte de latence avec les résultats ASN et de virtualisation. Par exemple, si l'ASN indique Tencent Cloud et que la virtualisation est KVM, le réseau devrait normalement être très propre ; mais si la latence moyenne des pings est 30 ms plus élevée que celle des autres machines Tencent Cloud de la même région et que la gigue est importante, ne vous précipitez pas pour commander — il est fort possible que l'adresse IP que vous avez obtenue appartienne à un segment de secours à froid, ou qu'elle ait été directement absorbée par un CDN. À l'inverse, si la latence est très faible mais que l'ASN est introuvable, il peut s'agir simplement d'une couche d'accès périphérique ; il faudra alors approfondir avec l'empreinte TCP et les certificats.

Au final, je crée un tableau à trois lignes : attribution ASN, type de virtualisation, caractéristiques de latence. Les trois se confirment mutuellement avant que je puisse affirmer en toute confiance que « ce fournisseur cloud est authentique ».

Liste de contrôle d'audit multiplateforme

Que vous achetiez sur AWS, Azure, Alibaba Cloud ou Tencent Cloud, la méthodologie pour identifier le fournisseur cloud d'un serveur est identique : d'abord vérifier l'attribution ASN, ensuite examiner le type de virtualisation, et enfin effectuer une vérification croisée avec les empreintes de latence. La liste de contrôle multiplateforme ci-dessous est la procédure que je suis avant d'acheter un VPS, et elle s'applique également à l'identification de « à qui appartient réellement cette machine » pour le compte d'autrui.

1. ASN et attribution du routage

Utilisez d'abord whois ou un outil en ligne pour vérifier l'ASN de l'adresse IP, et notez le nom de l'organisation. Attention : il est courant que les fournisseurs cloud partagent le même ASN, par exemple AWS et certains proxys partagent l'AS 16509, donc l'ASN ne constitue qu'un premier niveau d'analyse et ne doit pas être considéré comme concluant. Utilisez également traceroute pour vérifier si le dernier saut se trouve sur le backbone du fournisseur cloud, et non sur un nœud de périphérie CDN. Astuce pour éviter les pièges : si l'attribution IP affiche un fournisseur CDN, mais que la latence est très faible et que la route aboutit directement au centre de données cible, il s'agit probablement d'un retour à l'origine via le CDN, et non du serveur d'origine.

2. Virtualisation et empreinte système

Après vous être connecté au serveur, utilisez systemd-detect-virt ou dmidecode -s system-manufacturer pour voir le type de virtualisation. AWS utilise couramment Xen/KVM, Azure utilise Hyper-V, et Alibaba Cloud et Tencent Cloud utilisent souvent KVM. Notez que les commandes diffèrent selon les distributions : pour Debian/Ubuntu, systemd-detect-virt est recommandé, tandis que pour CentOS/RHEL, il peut être nécessaire d'installer virt-what. Pour des comparaisons multiplateformes, vous pouvez écrire un petit script pour détecter en masse l'identifiant hyperviseur de plusieurs machines.

3. Empreinte de latence et Steal Time

La latence ping et le TTL ICMP peuvent révéler la charge des voisins : dans le même centre de données, si la gigue de latence est élevée et que st (steal time) dans vmstat dépasse souvent 5%, cela indique que la machine hôte est fortement sursouscrite. En utilisant mtr pour observer en continu les changements de route, et en combinant avec le champ steal de /proc/stat, vous pouvez indirectement évaluer le risque de sursouscription avant l'achat. Cette méthode s'applique aussi bien sur AWS que sur les clouds chinois, il suffit d'ajuster légèrement les seuils.

Enfin, exportez une liste : attribution ASN, nombre de sauts de routage, type de virtualisation, moyenne du Steal Time, écart-type de la latence. En comparant ces cinq colonnes de données, le véritable fournisseur cloud se révèle en grande partie. C'est bien plus fiable que de simplement regarder l'attribution IP ou de lancer un benchmark en ligne, et c'est aussi pratique pour des comparaisons transversales multiplateformes. Vous pouvez également utiliser l'outil d'audit de CloudWorth pour générer automatiquement un rapport.