Comment fonctionne réellement la détection des VPN et des proxys, signal par signal

Toutes les équipes fraude, abus et conformité finissent par se poser la même question : cette adresse IP cache-t-elle quelque chose ? (Si vous voulez d'abord les bases, commencez par ce qu'est un VPN et comment détecter le trafic VPN. Cet article entre dans le détail de la mécanique.) La réponse honnête est qu'aucune vérification ne peut, à elle seule, vous le dire. Un VPN commercial, un proxy SOCKS en datacenter, un proxy résidentiel loué à un botnet et un nœud de sortie Tor ont tous une apparence différente sur le réseau (la présentation des types de proxys couvre chaque famille), et chacun déjoue une méthode de détection naïve différente.

Ce guide passe en revue les signaux sur lesquels s'appuient les systèmes de détection de niveau production, y compris deux d'entre eux (les vérifications de latence et la modélisation comportementale) que GeoIPHub n'utilise pas. GeoIPHub construit ses propres verdicts à partir de sept familles de méthodes de vérification qui couvrent le même terrain. Pour chaque couche, vous verrez ce qu'elle peut et ne peut pas voir, et comment les résultats sont fusionnés dans les champs de réponse que vous utilisez réellement : is_vpn, is_proxy, is_residential_proxy et is_tor.

Listes de serveurs des fournisseurs

La preuve la plus fiable est la plus directe : les fournisseurs de VPN publient leur infrastructure de serveurs. Les applications ont besoin de listes de points de terminaison pour se connecter, et de nombreux fournisseurs exposent des API officielles ou des paquets de configuration qui recensent chaque nom d'hôte et chaque IP de serveur.

Les systèmes de détection parcourent ces sources en continu. Lorsqu'une IP figure dans la liste de serveurs publiée par NordVPN ou Mullvad, la correspondance nomme le fournisseur, mais uniquement lorsque cette IP exacte figure sur une liste que nous détenons. Un serveur absent des listes peut tout de même être repéré par les signaux ci-dessous, sans être nommé. C'est pourquoi une bonne API peut renvoyer non seulement is_vpn: true mais aussi le nom du fournisseur lui-même, et pourquoi elle ne renvoie parfois aucun nom pour un serveur qu'elle a signalé.

La limite, c'est la couverture. Les listes publiées ne repèrent que les fournisseurs qui publient, ce qui signifie que cette couche est la plus forte pour les grands VPN commerciaux, qui représentent l'essentiel du trafic VPN grand public, et la plus faible pour les VPN privés ou auto-hébergés.

ASN et infrastructure d'hébergement

Chaque IP appartient à un système autonome (AS), le réseau qui l'annonce sur Internet. L'ASN vous indique qui exploite le réseau, et c'est un a priori puissant :

• Une IP annoncée par AS396982 (Google Cloud) est presque certainement un serveur, pas une personne assise sur son canapé.
• Une IP annoncée par un FAI résidentiel (Comcast, Deutsche Telekom, Jio) est probablement une connexion d'utilisateur final.
• Un ASN d'hébergement ou de colocation de longue date, avec un historique de points de terminaison VPN, relève l'a priori pour chaque IP de ses plages.

La détection des datacenters suffit à elle seule à repérer une très grande part des VPN et des proxys, car la plupart des infrastructures d'anonymisation louent des serveurs cloud. Mais elle ne permet pas de distinguer un point de terminaison VPN d'un serveur web ordinaire. Pour cela, il faut la couche suivante.

Sondage actif des protocoles

C'est la couche que la plupart des bases de données de recherche IP ignorent, et c'est elle qui fait la différence entre deviner et vérifier. Un serveur VPN doit répondre aux négociations des protocoles VPN ; c'est son rôle. Un système de détection peut donc frapper à la porte et voir qui répond :

• OpenVPN répond à une négociation TLS ou UDP caractéristique sur son port d'écoute.
• IKEv2/IPsec répond sur UDP 500/4500 avec des charges utiles identifiables.
• PPTP et L2TP répondent à leurs requêtes de canal de contrôle.
• Les proxys SOCKS5 et HTTP mènent à bien leurs séquences d'accueil respectives.

WireGuard est l'exception : un serveur reste silencieux tant que le premier message ne provient pas d'une clé qu'il connaît déjà, si bien qu'aucune sonde extérieure ne peut le confirmer. La méthode wireguard_open de GeoIPHub provient de la liste de serveurs publiée par le fournisseur, qui indique que ce serveur utilise WireGuard, et non d'une négociation.

Si une IP mène à bien une négociation OpenVPN, elle exécute OpenVPN. Aucune inférence statistique n'est nécessaire. GeoIPHub sonde 8 protocoles et enregistre précisément quelle négociation a abouti, de sorte que la preuve derrière is_vpn est nommée et auditable.

Ici, openvpn_open et ipsec_open dans detection_methods indiquent que cette adresse a répondu aux sondes OpenVPN et IPsec, en plus d'une correspondance avec des données de serveurs VPN connus. vpn_provider vaut ici "none" : aucune marque n'est attribuée ; le verdict repose sur des preuves de protocole nommées plutôt que sur une étiquette de fournisseur.

Le sondage actif a un coût : il demande de l'infrastructure et du temps, c'est pourquoi il s'exécute en continu en arrière-plan plutôt qu'à chaque requête. Les résultats des sondes sont mis en cache et actualisés pour que l'API puisse répondre en quelques millisecondes.

Empreintes de ports et de services

Même lorsqu'une négociation complète n'est pas possible, la forme des services ouverts d'une IP est instructive. Une connexion résidentielle n'expose généralement rien. Un point de terminaison VPN expose un petit ensemble caractéristique de ports. Une ferme de proxys expose des panneaux d'administration, du SSH et des ports de proxy sur des sous-réseaux entiers.

L'empreinte des services repère aussi les outils d'anonymisation mal configurés ou sans marque : un serveur qui répond sur le port TCP 1080 avec une bannière SOCKS est un proxy, qu'une liste le mentionne ou non.

Cohérence de la latence et de la localisation

La géographie laisse des empreintes dans la physique. Si une IP prétend (d'après ses données d'enregistrement) se trouver à São Paulo, mais que ses temps d'aller-retour mesurés depuis des points d'observation répartis dans le monde la situent par triangulation à Amsterdam, quelque chose relaie le trafic. Les vérifications fondées sur la latence sont particulièrement utiles contre :

• Les serveurs VPN à géolocalisation usurpée : des fournisseurs qui vendent des serveurs « Brésil » physiquement situés à Miami.
• Les relais GRE/tunnels qui acheminent le trafic vers une localisation réelle cachée.

Cette couche se déclenche rarement seule, mais elle constitue une forte corroboration lorsqu'elle est combinée aux signaux d'hébergement.

Comportement des proxys résidentiels

Les proxys résidentiels constituent la catégorie la plus difficile, car l'IP de sortie appartient réellement à un FAI grand public. Les vérifications par liste passent. Les vérifications d'ASN passent. Le sondage ne trouve rien à l'écoute, puisque le « serveur » est un SDK enfoui dans l'application mobile gratuite de quelqu'un.

La détection se déplace donc de l'infrastructure vers le comportement dans le temps :

• La même IP résidentielle apparaît comme sortie sur des places de marché de proxys connues.
• Une diversité de sessions improbable : une seule IP domestique présentant des dizaines d'empreintes d'appareils par heure.
• Des schémas de renouvellement qui correspondent à la rotation d'un réseau de proxys plutôt qu'à un renouvellement DHCP.
• Une incohérence de type de FAI : des IP d'opérateur mobile produisant des volumes de requêtes soutenus dignes d'un datacenter (le guide pour repérer les proxys mobiles explique pourquoi les IP d'opérateurs sont un cas particulier).

C'est pourquoi les sorties résidentielles ont un champ distinct de is_proxy : la nature de la preuve est différente, et l'action appropriée aussi. Soyez clair sur ce qu'une requête IP peut voir ici. Le champ is_residential_proxy de GeoIPHub est une inférence grossière fondée sur l'ASN, pas une observation directe de l'appartenance à un réseau de proxys : traitez-le donc comme un indice plutôt que comme une preuve. Si du trafic de FAI grand public paraît soudain suspect dans vos journaux, pourquoi les proxys résidentiels apparaissent sans cesse dans votre trafic passe en revue les causes habituelles. Une détection de proxy résidentiel sur un parcours de paiement est un signal de fraude bien plus fort qu'une détection de VPN grand public.

Données de l'annuaire Tor

Tor est le cas facile, par conception. Le réseau Tor publie son consensus de relais et de nœuds de sortie, actualisé en permanence. Le croisement avec la liste publique des sorties donne une précision quasi parfaite pour is_tor, avec une réserve : le timing. Les nœuds de sortie apparaissent et disparaissent, l'annuaire doit donc être réingéré selon un calendrier serré, pas une fois par semaine.

Les relais de confidentialité sont le cas inverse. Apple publie toutes les adresses de sortie d'iCloud Private Relay, si bien qu'un relais peut lui aussi être identifié exactement ; mais, à lui seul, un relais relève de allow, pas d'une liste de blocage. Nous couvrons ces deux relais, et la raison pour laquelle Cloudflare ne publie aucune liste de sortie WARP, dans la détection d'iCloud Private Relay et de Cloudflare WARP.

Confiance croisée entre signaux

La dernière couche est la fusion. Chacune des couches précédentes produit des preuves dont le profil de fiabilité diffère :

Un verdict défendable pèse ces éléments ensemble. Un seul signal de confiance moyenne ne devrait pas faire basculer un booléen ; deux signaux indépendants de confiance élevée, si. Ce que vous attendez d'une API de détection tient donc en trois éléments : les booléens pour les décisions de routage, les méthodes de détection nommées pour l'auditabilité, et un score de risque qui exprime à quel point les signaux se corroborent. Les méthodes nommées sont aussi ce dont a besoin un utilisateur signalé à tort : notre analyse de pourquoi une IP est signalée comme VPN ou proxy les lit sur des adresses réelles.

Mettre la détection des VPN en pratique : décider sur des combinaisons

Trois enseignements pratiques :

1. Ne traitez pas is_vpn comme une liste de blocage à lui seul. De nombreux clients payants utilisent des VPN grand public (voir comment signaler le trafic anonymisé sans refouler de vrais clients). Décidez sur des combinaisons : VPN + datacenter + historique d'abus est une situation très différente d'un VPN seul.
2. Accordez un poids important aux signaux de proxy résidentiel, en sachant qu'ils sont inférés. Personne ne loue des sorties résidentielles pour protéger sa vie privée ; le taux de base d'usage légitime est minuscule comparé à celui des VPN. Un indicateur résidentiel au niveau de l'IP reste toutefois une inférence grossière : associez-le à vos propres signaux de session.
3. Préférez une détection vérifiée à des listes statiques. Demandez à n'importe quel fournisseur comment il sait qu'une IP est un VPN. Si la réponse est « une base de données sous licence », les données se dégradent déjà. Le sondage actif et des listes de fournisseurs parcourues en continu suivent le rythme du renouvellement de l'infrastructure.

Vous pouvez voir vous-même le résultat de chaque couche : passez n'importe quelle IP dans l'outil gratuit de recherche IP ou testez votre propre connexion VPN, sans inscription.

Questions fréquentes

La détection des VPN peut-elle être fiable à 100 % ?

Non. La détection est probabiliste. Les VPN commerciaux dont l'infrastructure est publiée sont détectés avec une très grande confiance, tandis que les petits VPN privés hébergés sur des IP cloud récentes sont plus difficiles à repérer. C'est pourquoi une bonne API renvoie les preuves signal par signal et un niveau de confiance plutôt qu'un simple booléen.

Quelle est la différence entre un proxy et un VPN du point de vue de la détection ?

Un VPN fait transiter tout le trafic dans un tunnel au niveau de la couche réseau et répond généralement à des négociations de protocole spécifiques (OpenVPN, WireGuard, IKEv2) sur son serveur. Un proxy relaie le trafic au niveau applicatif (HTTP, SOCKS) et expose d'autres ports et d'autres empreintes. Les systèmes de détection sondent ces deux familles séparément.

Pourquoi les proxys résidentiels sont-ils si difficiles à détecter ?

Parce que l'IP de sortie appartient réellement à un FAI grand public : les vérifications fondées sur des listes et sur l'ASN passent. La détection repose donc sur des preuves comportementales : la même IP qui apparaît dans des réseaux de proxys, des schémas de réutilisation anormaux et des incohérences entre le type de FAI et le trafic observé.

Bloquer tous les utilisateurs de VPN a-t-il un sens pour la prévention de la fraude ?

En général, non. De nombreux utilisateurs légitimes naviguent via un VPN pour protéger leur vie privée. Une meilleure approche consiste à traiter l'usage d'un VPN comme une entrée pondérée parmi d'autres dans un score de risque, et à n'escalader que lorsqu'il coïncide avec d'autres signaux comme un hébergement en datacenter, un historique d'abus ou un déplacement impossible.

À quel point les données de détection des VPN doivent-elles être fraîches ?

Très fraîches. Les fournisseurs de VPN font tourner leurs serveurs chaque jour et les réseaux de proxys renouvellent leurs IP d'heure en heure. Une détection adossée à un re-sondage continu et à des listes de fournisseurs re-parcourues reste exacte ; les jeux de données statiques se dégradent en quelques semaines.