Ce qu'un serveur VPN peut loguer par défaut
Quiconque a configuré un daemon OpenVPN ou WireGuard sait que le comportement par défaut est de loguer. OpenVPN avec verb 3 (niveau de verbosité par défaut) enregistre chaque connexion, chaque déconnexion, les adresses IP sources, les IPs assignées aux clients, les volumes de données échangés, et les erreurs. Le système d'exploitation sous-jacent maintient ses propres logs via syslog ou journald.
Un vrai no-logs nécessite une désactivation active et délibérée de ces mécanismes — ce n'est pas l'état par défaut. Il faut explicitement passer verb 0 dans OpenVPN, désactiver syslog pour le processus VPN, s'assurer qu'aucun système de monitoring externe ne capture les données de connexion, et vérifier que les outils système (netstat, ss, les tables kernel de WireGuard) ne persistent pas les informations au-delà de la session.
# Niveau verbosité 0 = pas de logs de connexion verb 0 mute 0 # Désactiver le log système log /dev/null log-append /dev/null # Vérifier que syslog ne capture pas # /etc/rsyslog.d/ — exclure openvpn :programname, isequal, "ovpn-server" stop # NB : ces configurations ne sont pas suffisantes seules # pour une architecture no-logs robuste — voir RAM-only
L'architecture RAM-only — ce que ça signifie concrètement
Une architecture RAM-only (diskless server) utilise des serveurs sans stockage persistent : pas de disque dur, pas de SSD. L'état du serveur — y compris tous les fichiers de logs potentiels — réside uniquement en RAM. Lors d'un redémarrage, la RAM est vidée et tout l'état est perdu. Le serveur reboot sur une image immuable stockée en réseau ou sur un support read-only externe.
Cette architecture rend la conservation de logs techniquement impossible au-delà du redémarrage. Une injonction judiciaire qui ordonne la saisie des serveurs ne peut récupérer aucune donnée — les serveurs reboottés ne contiennent que l'image de démarrage. Mullvad a publicament documenté cette architecture depuis 2018 et l'a fait vérifier par des auditeurs indépendants.
La contrainte opérationnelle est significative : chaque mise à jour logicielle, chaque changement de configuration nécessite une nouvelle image déployée sur tous les nœuds via un système de provisioning centralisé. C'est une infrastructure plus complexe qu'un serveur avec disque — c'est le prix de la garantie no-logs architecturale. Pour une analyse complète de l'infrastructure des VPN commerciaux, les détails de déploiement sont développés.
WireGuard et le problème des IPs kernel
WireGuard maintient une table dans le kernel Linux qui associe chaque pair (identifié par clé publique) à sa dernière adresse IP source et au timestamp de dernière activité. Cette table est nécessaire au fonctionnement du protocole — elle permet de router les réponses vers le bon client. Elle est consultable via wg show et les interfaces /proc/net/.
Pour un service commercial qui veut une politique no-logs, cette table est un problème : elle contient les IPs réelles des clients actifs. Les solutions implémentées par les services sérieux incluent : rotation des clés WireGuard toutes les 10 minutes (ProtonVPN), assignation d'IPs virtuelles qui ne correspondent pas aux IPs réelles des clients (double NAT), et utilisation de namespaces réseau Linux qui isolent la table WireGuard par client. Aucune de ces solutions n'est parfaite — elles réduisent la fenêtre d'exposition mais ne l'éliminent pas complètement.
Les audits : ce qui est vérifiable et ce qui ne l'est pas
Un audit de sécurité d'un service VPN peut couvrir plusieurs périmètres : le client (l'application installée sur votre machine), l'infrastructure serveur, les processus internes, et la conformité de la politique de confidentialité avec l'implémentation réelle. Ces périmètres ne sont pas équivalents en difficulté ni en valeur.
Un audit du client est le plus accessible — les auditeurs reçoivent le code source et l'analysent. Un audit de l'infrastructure serveur est plus complexe — les auditeurs doivent avoir accès physique ou logique aux serveurs pour vérifier que les configurations déclarées correspondent à la réalité. C'est ce deuxième type d'audit qui est le plus précieux pour valider une politique no-logs — et c'est aussi le plus rare et le plus coûteux.
Les rapports d'audit Cure53 pour Mullvad (2020, 2022, 2024) et ProtonVPN (2019, 2021, 2023) sont publics et intégraux — y compris les vulnérabilités trouvées et les corrections apportées. C'est ce niveau de transparence qui distingue les services sérieux des services qui "ont passé un audit" sans en montrer les résultats. La sélection d'un service VPN donne une grille d'évaluation basée sur ces critères.
En 2016, les autorités turques ont saisi un serveur ExpressVPN dans le cadre d'une enquête. Les serveurs ne contenaient pas les données recherchées — ce qui a constitué une preuve involontaire de la politique no-logs du service. Ce type de validation "par défaut de données" est plus convaincant que n'importe quelle certification marketing.
Ce que la politique no-logs ne couvre pas
Même avec une architecture no-logs parfaite, plusieurs informations restent disponibles. Les données de facturation — si vous payez par carte bancaire, votre identité est liée à votre compte. Les métadonnées de connexion conservées par l'hébergeur des serveurs — pas le service VPN lui-même, mais la société qui loue les serveurs physiques. Les informations transmises au niveau des protocoles réseau sous-jacents — BGP routing, peering logs.
Pour les utilisateurs qui veulent décorréler complètement leur identité de l'utilisation du VPN, les services qui acceptent le paiement en Monero ou en cash par courrier (Mullvad) vont plus loin que la simple politique no-logs. C'est une couche supplémentaire qui résout un problème différent — l'identification par les données de facturation plutôt que par les logs de connexion.