Comment enregistrer et vérifier l’adresse de sortie VPN utilisée

Demandez à un client VPN de bureau quels serveurs vous avez utilisés : la réponse honnête est généralement un nom de lieu. Ce nom est le point d’entrée que vous avez composé, et l’adresse par laquelle votre trafic est sorti peut être une tout autre machine. Rien dans l’appli n’est conçu pour conserver le second numéro, la trace doit donc être construite au moment de l’usage. Il existe deux approches, et une seule survit à un dossier de support.

Deux traces, dont une seule existe

La vue du client est au mieux une liste de lieux choisis avec des horodatages. C’est un choix de conception et non un oubli : les adresses relèvent de l’exploitation, elles tournent entre les affectations, et exposer la correspondance complique aussi bien le support que le traitement des abus. Les fournisseurs placent des instances cloud devant leurs réseaux précisément pour que le point de sortie puisse bouger sans prévenir. Ce que l’appli vous montre, c’est le choix que vous avez fait, pas la route suivie.

La trace que vous pouvez construire est un fichier local contenant une adresse publique et un horodatage UTC par ligne. Elle est plus petite, plus laide et bien plus utile, parce qu’elle décrit exactement ce qu’un observateur extérieur peut voir aussi.

Option A : capturer vous-même l’adresse de sortie

Un service d’écho renvoie l’adresse source d’où la requête est arrivée, ce qui est par définition l’adresse de sortie. Lancez la capture après que le tunnel signale la connexion, car un client qui annonce connecté avant que les routes et le DNS soient stabilisés enregistrera l’adresse d’avant le tunnel et empoisonnera le journal dès sa première ligne.

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

Deux détails rendent cet extrait utilisable plutôt que décoratif. L’horodatage et l’adresse partagent une ligne, si bien qu’une analyse ultérieure n’a pas à réapparier les enregistrements, et umask 077 garde le fichier privé dès sa création. Lancez-le une fois par connexion plutôt qu’une fois par démarrage, et gardez un fichier par appareil.

Le journal note quand vous avez utilisé un tunnel et depuis quel réseau vous apparaissiez, ce qui est plus proche d’un historique de navigation que d’un compteur. Choisissez une durée de conservation que vous pouvez assumer, gardez le fichier hors des dossiers de synchronisation partagés et purgez-le délibérément.

Option B : demander un historique au fournisseur

Certains fournisseurs tiennent des journaux de connexion et répondront à une question de support avec un horodatage et un nom de serveur. Cette trace décrit leur infrastructure et non votre trafic, et elle ne vaut que ce que valent leur fenêtre de conservation et leur volonté de regarder. Elle décrit aussi une session, pas une requête. La fenêtre est généralement courte, et elle se mesure du côté fournisseur du tunnel.

Les fournisseurs qui annoncent l’absence de journalisation ne peuvent pas produire cela sur demande, et une liste de lieux récents côté client n’est pas la même chose. Demander une adresse de sortie à un fournisseur sans journal aboutit le plus souvent à une explication de l’absence de ces données.

Ce que chaque trace peut prouver dans un dossier de support

Les deux traces répondent à des questions différentes, et c’est dans le tableau que la comparaison cesse d’être théorique.

Seule la première colonne est sous votre contrôle. Une trace du fournisseur peut confirmer qu’un compte était connecté à un instant donné, mais elle ne peut pas confirmer quelles requêtes ont emprunté le tunnel, et elle ne nommera pas une adresse que le fournisseur traite comme un détail d’exploitation. Aucune des deux traces n’identifie une personne, car une adresse de sortie partagée peut porter de nombreux clients à la même minute.

Comparez les deux à une référence avant de faire confiance à l’une ou l’autre

Une adresse seule ne prouve rien. Capturez l’adresse directe avant la connexion, l’adresse tunnelisée après, et comparez-les. Des valeurs identiques signifient que le tunnel ne porte pas cette requête, que ce soit à cause d’un split tunnel, d’un proxy prioritaire ou d’un client qui est retombé sur un chemin direct.

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

Répétez la comparaison pour le DNS et pour IPv6, car un écho d’adresse prouve le chemin d’une seule requête HTTP et rien sur le résolveur qui a répondu. Un appareil qui fuit sur l’un des deux peut sembler parfaitement sain sur l’autre.