Identifier le fournisseur VPN derrière une IP grâce à sa propre liste de serveurs

Nous avons récupéré la liste des relais de Mullvad à 05:22 UTC le 13 octobre 2026. Elle contenait 566 relais, 553 serveurs WireGuard et 13 bridges, et Mullvad n'en marque que 124 comme du matériel qui lui appartient. L'un de ceux qui lui appartiennent, 185.213.155.73 à Francfort, est enregistré dans le WHOIS au nom de « 31173 Services Germany », n'a pas de DNS inverse et est annoncé par AS39351. Rien dans son enregistrement réseau ne dit « Mullvad ». Seule la liste le dit.

C'est toute l'astuce derrière chaque outil « à quel VPN appartient cette IP », et presque aucun ne le dit. Ci-dessous, nous listons les endpoints où les fournisseurs publient leurs serveurs, donnons un script de correspondance Python testé, et montrons ce que notre API a renvoyé pour les serveurs listés par les fournisseurs que nous avons interrogés, ainsi que des cas témoins, échecs compris. L'article se termine par un tableau de politique. Pour le volet détection, c'est-à-dire comment un VPN est détecté tout court, lisez comment fonctionne la détection des VPN, signal par signal.

Peut-on savoir à quel VPN appartient une adresse IP ?

Oui, lorsque l'IP figure sur une liste que le fournisseur publie. Une application VPN doit savoir où se trouvent ses serveurs avant de pouvoir se connecter, donc les fournisseurs servent cette liste à leurs applications, et la plupart de ces listes sont publiques. Si l'adresse ne figure sur aucune liste, vous pouvez généralement savoir qu'il s'agit d'un VPN grâce aux sondes et aux signaux d'hébergement, mais pas duquel.

Voici 185.213.155.73 retracée de bout en bout. La liste de Mullvad, sur api.mullvad.net/www/relays/all/, contient une ligne pour elle avec hostname « de-fra-wg-001 », type « wireguard », city_name « Frankfurt », owned true et provider « 31173 ». Ce dernier champ est l'hébergeur, et ici c'est celui de Mullvad elle-même.

Le registre raconte une autre histoire. L'enregistrement RDAP du RIPE, que nous avons ouvert à 05:28 UTC, nomme la plage NET-31173-185-213-155-0-24 et le titulaire « 31173 Services Germany ». L'objet route du whois RIPE donne l'origine AS39351. Nous avons exécuté dig -x 185.213.155.73 et n'avons obtenu aucune réponse.

Nous l'avons ensuite interrogée dans notre API à 05:27 UTC. Voici une copie abrégée, valeurs non modifiées :

Regardez whois.has_vpn_keywords. Il vaut false, sur un serveur Mullvad, et il valait false sur chaque adresse que nous avons interrogée. Le texte WHOIS ne mentionne jamais de VPN. Le nom « Mullvad » vient de la correspondance avec la liste, et vpn_confidence 95 est la valeur que notre API attribue à ce chemin. Le blocage vient des preuves : une entrée de liste fournisseur marquée WireGuard, sur une adresse d'hébergement.

Pourquoi le WHOIS, le DNS inverse et l'ASN nomment l'hébergeur, pas le VPN

La plupart des serveurs VPN tournent sur des machines louées, donc l'enregistrement réseau décrit le bailleur. Dans notre échantillon, M247 (AS9009) héberge des serveurs listés de NordVPN, PIA, AirVPN, IVPN et FastestVPN. Datacamp (AS212238) héberge un serveur Mullvad à New York et un serveur IVPN à Buenos Aires. Une règle qui dit « M247 signifie VPN » est une supposition sur un hébergeur. La liste du fournisseur est une preuve concernant un serveur.

Mullvad le démontre pour nous. Sa liste marque chaque relais owned true ou false et nomme l'hébergeur dans provider. Le 13 octobre, 124 de ses 566 relais étaient owned: true, et les hébergeurs les plus fréquents étaient DataPacket (128 relais), Tzulo (127) et M247 (98). Nous avons interrogé deux relais Mullvad loués à 05:33 UTC :

Un contrôle d'ASN sur l'un ou l'autre dit « hébergeur ». La liste dit Mullvad. Le relais de New York us-nyc-wg-301, 143.244.47.65, raconte la même histoire chez Datacamp.

Le DNS inverse est encore plus faible. Nous avons exécuté dig -x sur 20 des adresses listées par les fournisseurs à 05:28 UTC. Onze n'ont rien renvoyé, et aucune des neuf autres ne nommait une marque de VPN :

Le nom de Riseup évoque le logiciel VPN, LEAP et Bitmask, pas une marque. Le nom de l'IVPN de Vienne dit « adsl », ce qui ressemble à une connexion domestique, sur un serveur qu'IVPN liste. C'est le danger de surinterpréter un PTR.

L'ASN ne nomme le VPN que lorsque le fournisseur exploite son propre réseau, comme Mullvad avec AS39351 et Riseup avec AS16652. Si vous voulez le contexte, voici ce qu'est un ASN et qui il désigne. Notre API maintient une courte table des réseaux exploités par des fournisseurs VPN, où figure AS39351 de Mullvad, et cette table est l'un des quatre chemins de nommage décrits ci-dessous.

Où les fournisseurs VPN publient les IP de leurs serveurs

Voici les listes que lisent les propres applications des fournisseurs. « Récupérée aujourd'hui » signifie que notre réseau a obtenu une réponse 200 le 13 octobre 2026 ; « inaccessible aujourd'hui » signifie que la requête a échoué depuis notre réseau après deux essais.

Les quatre que nous n'avons pas pu atteindre sont de vrais endpoints. Nous les connaissons grâce aux clients officiels ou open source des fournisseurs, et le code NordVPN de gluetun indique même en commentaire que le champ station « is, it seems, the entry IP address » (est, semble-t-il, l'adresse IP d'entrée). Leurs API bloquent les requêtes provenant de datacenters, là où tourne notre scanner, et le 13 octobre elles n'ont pas non plus répondu au réseau que nous avons utilisé pour cet article.

Notre API nomme donc les VPN à partir des propres listes de serveurs des fournisseurs, plus une liste publique tierce. Pour NordVPN, PIA et Windscribe, notre scanner se rabat sur des copies enregistrées de leurs réponses d'API, datées du 4 octobre 2026. Nous n'avons aucune copie pour Surfshark. La liste tierce est gluetun-servers, les données de serveurs maintenues par la communauté derrière gluetun, un conteneur client VPN open source. Nous chargeons ses fichiers pour plus de 20 fournisseurs, et c'est notre seule source pour FastestVPN. Les quatre de ses fichiers que nous avons récupérés aujourd'hui, pour ExpressVPN, FastestVPN, NordVPN et PIA, portent tous un horodatage du 6 août 2026.

Identifier vous-même un fournisseur VPN par IP : Mullvad et NordVPN

Téléchargez la liste du fournisseur et cherchez une correspondance exacte sur l'adresse. Mullvad est le cas facile, car sa liste a répondu chaque fois que nous l'avons demandée. Voici le script que nous avons exécuté à 05:29 UTC le 13 octobre 2026, sous Python 3.9.6, bibliothèque standard uniquement :

Nous lui avons passé sept entrées en ligne de commande, et il a affiché :

Nous avons aussi fait passer par stdin trois lignes avec des lignes vides et des espaces de remplissage, comme vous le feriez avec une colonne de logs, et il a associé 45.83.220.70 à se-mma-wg-103. Pointé vers une URL qui renvoie 404, il a affiché « could not load Mullvad's list: HTTP Error 404: Not Found » et s'est terminé avec le code 1. Deux mises en garde : une entrée invalide est signalée comme absente de la liste plutôt que comme une erreur, et les 13 bridges sont eux aussi mis en correspondance, donc lisez la colonne type.

Comment détecter NordVPN de la même façon. La liste de NordVPN place l'IP de chaque serveur dans un champ station, et notre copie enregistrée du 4 octobre en contient une par serveur. L'endpoint en direct a dépassé le délai depuis notre réseau le 13 octobre, deux fois, donc nous ne publions pas de code NordVPN que nous n'avons pas pu exécuter. Exécutez la même logique de correspondance exacte depuis un réseau auquel NordVPN répond.

Pour une adresse à la fois, vous pouvez vérifier si une IP est un VPN et quel est son fournisseur ; l'outil renvoie le nom dans detection.vpn_provider. En code, c'est une seule requête avec l'IP dans le chemin :

vpn_provider fait partie de l'offre gratuite, qui inclut tous les champs de données à 1 500 requêtes par jour. Si vous basez quoi que ce soit sur le nom, comparez son début, pas la chaîne entière : notre API a renvoyé « Mullvad » pour les serveurs listés et « Mullvad (31173 Services) » pour le chemin ASN. Voici l'extrait que nous avons exécuté à 05:34 UTC, sans clé :

C'est pour la troisième ligne qu'il faut concevoir : pas de nom, toujours un VPN, toujours un blocage.

Si vous vous posez l'autre question, à savoir si votre propre connexion apparaît comme NordVPN, ouvrez voir l'IP qu'affiche votre connexion pendant que vous êtes connecté.

Ce que notre API a renvoyé pour les IP listées par les fournisseurs

Les serveurs listés de chaque fournisseur de notre échantillon sont revenus nommés, et vpn_confidence indique lequel des quatre chemins les a nommés. Sur une ligne nommée, la valeur correspond au chemin :

Nous avons effectué ces requêtes entre 05:27 et 05:28 UTC le 13 octobre 2026. La dernière colonne ne montre que les sondes de handshake VPN qui ont répondu ; nous avons laissé le reste de detection_methods hors du tableau.

Trois lignes méritent un mot. Les serveurs NordVPN et PIA figurent sur nos copies enregistrées, mais ils sont revenus à 80, la valeur de gluetun, et tous deux figurent dans les fichiers de gluetun. Le serveur PrivadoVPN figure aujourd'hui sur l'export propre de PrivadoVPN, et pourtant il est revenu à 90, pas 95 : son nom vient de la résolution de son nom d'hôte, hkg-006.vpn.privado.io, que le fichier PrivadoVPN de gluetun contient aussi. Lisez le chemin dans vpn_confidence, pas dans la liste où vous avez trouvé l'IP. ExpressVPN ne fait pas partie des neuf fournisseurs dont nous récupérons les propres listes. Une adresse ExpressVPN listée par gluetun est revenue nommée, ce qui montre que le chemin fonctionne, pas que nous couvrons ExpressVPN.

La dernière ligne correspond au chemin ASN. 45.83.220.7 ne figure pas sur la liste de Mullvad ; la liste du jour contient .68, .69 et .70 dans ce /24, pas .7. Elle est nommée parce que son réseau, AS39351, appartient à l'opérateur de Mullvad :

Notez que known_vpn_server se déclenche ici aussi. Ce nom de méthode ne signifie pas « sur la liste d'un fournisseur » ; sur cette ligne, il provient de la table des réseaux. Lisez vpn_confidence pour connaître le chemin, et uniquement sur les lignes où vpn_provider ne vaut pas « none ».

Pourquoi certaines IP de VPN reviennent « none »

« none » signifie que l'IP ne figure sur aucune des listes dont nous disposons actuellement. Cela ne signifie pas que l'IP n'est pas un VPN, ni qu'une adresse voisine d'un fournisseur est propre.

Le serveur NordVPN pl128, 194.99.105.99, figure dans la réponse NordVPN que nous avons enregistrée le 4 octobre, indiqué comme en ligne. Aujourd'hui, il a renvoyé vpn_provider « none », mais is_vpn true, un score de 98 et block, avec ipsec_open parmi ses méthodes. Son handshake IPsec l'a trahi ; rien ne l'a nommé. Le serveur PIA du Liechtenstein, 91.90.122.25, figure dans la liste PIA du même jour. Aujourd'hui, il a renvoyé is_vpn false et un score de 64, step_up, à partir des seuls signaux de liste de blocage et d'hébergement.

Aucune de ces deux adresses ne figure dans les fichiers de gluetun, alors que les lignes NordVPN et PIA nommées plus haut y figurent toutes les deux. Nous n'avons pas pu récupérer à nouveau l'API de NordVPN ni celle de PIA aujourd'hui, donc l'un ou l'autre serveur a pu être retiré ou réadressé depuis le 4 octobre. Ce que nous pouvons affirmer est plus restreint et certain : un serveur n'est nommé que s'il figure sur une liste dont nous disposons actuellement.

Nous avons aussi un échec sur un fournisseur dont nous avons bien récupéré la liste aujourd'hui. 91.90.123.29 se trouve dans le même /24 que le relais Mullvad listé 91.90.123.2, mais elle ne figure pas sur la liste de Mullvad. La page des fournisseurs d'IPinfo l'affichait comme son IP d'exemple pour Mullvad le 13 octobre. Notre API a renvoyé is_vpn false, vpn_provider « none », un score de 12, allow. Il peut s'agir d'une sortie ou d'une adresse non listée voisine d'une adresse listée ; c'est un indice, pas une preuve. Dans tous les cas, une correspondance de liste couvre l'adresse listée et rien à côté.

Le cas témoin documenté illustre le cas non nommé mais détecté. 102.129.235.17, sur AS834 IPXO, a renvoyé is_vpn true, vpn_provider « none », un score de 92, block, avec known_vpn_server, openvpn_open et ipsec_open. Un serveur non nommé est tout de même détecté lorsqu'il mène à bien un handshake OpenVPN ou IPsec avec notre scanner ; l'article principal cité plus haut décrit les sondes.

Raisons courantes pour lesquelles une IP de VPN reste sans nom :

• Pas de liste publique. Certains fournisseurs n'en publient aucune, et un VPN auto-hébergé n'apparaît jamais sur une liste.
• Liste inaccessible. Quatre des neuf listes que nous récupérons bloquent les datacenters, donc nous travaillons à partir de copies enregistrées quand nous en avons, et à partir de gluetun.
• Rotation. Un serveur peut quitter la liste ou changer d'adresse après notre dernière copie.
• C'est un proxy, pas un VPN. Les proxys n'ont pas de liste fournisseur à comparer ; voir proxys datacenter, résidentiels et mobiles.

iCloud Private Relay et Cloudflare WARP ne sont pas des fournisseurs VPN dans ce sens. Ils ont leur propre champ, relay_provider, et leur propre politique, traitée dans iCloud Private Relay et Cloudflare WARP.

Un VPN nommé n'est pas un VPN plus risqué

Le nom indique qui exploite le serveur ; le score provient des preuves, comme les ports de handshake ouverts, l'hébergement et l'historique d'abus. Certains des scores les plus bas de notre échantillon sont allés à des serveurs nommés, et l'un des plus élevés à un serveur non nommé.

Nos tranches sont allow jusqu'à 25, review jusqu'à 50, step_up jusqu'à 75 et block au-delà de 75. Le serveur PrivadoVPN n'a répondu à aucune sonde de handshake dans nos données, donc seul known_vpn_server s'est déclenché et il est resté en review. Le serveur non nommé a répondu à deux. C'est le bon ordre des choses : une règle doit peser ce que nous avons observé, pas le logo qui figure sur le serveur. Les poids des signaux sont présentés sur la page comment le score est construit.

IP d'entrée, serveurs renouvelés et noms obsolètes

Une liste de fournisseur vous indique l'adresse à laquelle l'application se connecte. Pour la plupart des serveurs de notre échantillon, cette même adresse a répondu à nos sondes, mais nous avons seulement vérifié que les adresses listées sont nommées, pas que chaque adresse de sortie qu'utilise un fournisseur figure sur une liste.

Les noms de champs disent « in ». Mullvad utilise ipv4_addr_in, et AirVPN publie quatre adresses par serveur sous la forme ip_v4_in1 à ip_v4_in4. La liste de Surfshark ne donne que des noms d'hôte, donc quelqu'un doit résoudre les noms en IP avant que quoi que ce soit puisse correspondre. Notre chemin 90 le fait pour les noms d'hôte de serveurs présents dans les fichiers de gluetun. C'est ainsi que au-stream.jumptoserver.com de FastestVPN, 46.102.153.134, a obtenu son nom.

Les listes contiennent aussi un état qu'il faut lire. La liste de Mullvad marque aujourd'hui 24 relais active: false, dont se-mma-wg-101, 45.83.220.68, que notre API nomme toujours « Mullvad » à 95. Un serveur listé est un fait concernant la flotte du fournisseur, pas la preuve que le serveur a transporté du trafic aujourd'hui. C'est aussi pourquoi les décomptes d'IP de VPN des éditeurs divergent autant. Ils comptent des choses différentes, comme des serveurs, des adresses d'entrée listées, des adresses de sortie observées ou des plages entières, à des dates différentes. La propre liste de Mullvad est le seul décompte que nous citons. Nous ne publions pas ici de calendrier d'actualisation des listes de fournisseurs ; si vous exécutez vous-même le script de correspondance, récupérez la liste avant chaque lot.

Que faire d'un nom de fournisseur

Utilisez le nom pour la politique et l'investigation, pas comme interrupteur de blocage. Basez les décisions sur recommended_action et les preuves qui le sous-tendent, et basez les exceptions et le reporting sur le nom.

L'erreur habituelle consiste à transformer la première ligne en règle de blocage, ce qui fait des clients d'un fournisseur des faux positifs de détection VPN. Deux vérifications à mener sur vos propres logs cette semaine :

• Trouvez les règles basées sur le nom. Cherchez vpn_provider dans vos règles. Une règle comme « bloquer si un fournisseur est nommé » laisse passer le 92 non nommé et bloque le 36 nommé. Basez-vous plutôt sur l'action et les preuves, et comparez les noms par préfixe.
• Comparez vos logs à une liste. Donnez au script de correspondance Mullvad les IP d'inscription ou de connexion des 30 derniers jours et comptez les correspondances. Comparez ce chiffre au nombre de ces requêtes que vos règles ont refusées, puis vérifiez-en quelques-unes dans l'outil de recherche IP.

Questions fréquentes

Peut-on savoir à quel VPN appartient une adresse IP ?

Oui, lorsque l'IP figure sur une liste de serveurs que le fournisseur VPN publie pour ses propres applications. Si elle ne figure sur aucune liste, vous pouvez généralement savoir qu'il s'agit d'un VPN, mais pas duquel.

Existe-t-il une liste des adresses IP de NordVPN ?

Les applications NordVPN en lisent une sur api.nordvpn.com, qui donne l'IP de chaque serveur dans un champ station. Le 13 octobre 2026, elle ne répondait pas aux requêtes depuis notre réseau, nous avons donc utilisé une copie enregistrée.

Le WHOIS ou le DNS inverse indiquent-ils le fournisseur VPN ?

Rarement. La plupart des serveurs VPN se trouvent sur des réseaux d'hébergement loués comme M247, donc le WHOIS et le DNS inverse nomment l'hébergeur. Même la plage de Francfort qui appartient à Mullvad est enregistrée au nom de 31173 Services.

Que signifie vpn_provider none ?

L'IP ne figure sur aucune des listes de serveurs dont nous disposons. Cela ne signifie pas que l'IP n'est pas un VPN : vérifiez is_vpn et scoring.detection_methods.

Un VPN nommé obtient-il un score de fraude plus élevé ?

Non. Un serveur PrivadoVPN listé a obtenu 36, review, tandis qu'un VPN non nommé a obtenu 92, block. Le nom indique qui exploite le serveur ; le score provient des preuves.

Quels fournisseurs VPN publient leurs listes de serveurs ?

Mullvad, AirVPN, IVPN, PrivadoVPN et Riseup ont répondu à nos requêtes publiques le 13 octobre 2026. NordVPN, Surfshark, PIA et Windscribe publient des listes pour leurs applications mais n'ont pas répondu depuis notre réseau.