Architecture serveur d'un fournisseur : peering, IP partagées, serveurs en RAM, audits

Le comportement d'un VPN dépend autant du serveur que du client. La page d'accueil décrit le chemin d'un paquet jusqu'au serveur ; cette page regarde ce qui se passe à l'arrivée : le réseau qui achemine le trafic, la manière dont les adresses sont attribuées, la façon dont les serveurs sont provisionnés, et ce qu'un audit permet réellement de vérifier.

Le réseau : transit et peering

Internet est un maillage de systèmes autonomes qui s'échangent du trafic selon deux modèles : le transit, où l'on paie un opérateur pour joindre le reste du monde, et le peering, où deux réseaux s'interconnectent directement, souvent dans un point d'échange. Un fournisseur de VPN dont les serveurs sont bien peerés atteint les grandes plateformes en quelques sauts, avec une latence basse ; un fournisseur qui dépend de longues chaînes de transit ajoute des allers-retours. C'est pourquoi la latence réelle dépend davantage de la qualité du raccordement d'un serveur que de sa distance géographique : un serveur « proche » mal connecté peut être plus lent qu'un serveur lointain bien peeré.

La capacité annoncée — « serveurs à 10 Gbit/s » — est une capacité de lien, partagée entre tous les utilisateurs connectés à ce serveur au même moment. Le débit que vous obtenez dépend du taux de remplissage, de la politique de répartition de charge du fournisseur, et de la capacité du fournisseur à ajouter des serveurs quand la demande croît.

Serveurs loués, colocalisés ou possédés

Trois modèles d'infrastructure coexistent. Le plus courant : louer des serveurs dédiés chez des hébergeurs tiers dans chaque pays. C'est souple et rapide à déployer, mais le fournisseur ne contrôle pas physiquement la machine, et l'hébergeur relève du droit local. La colocation : le fournisseur possède ses serveurs et les installe dans des centres de données tiers, ce qui donne le contrôle du matériel sans celui du bâtiment. La propriété complète de l'infrastructure réseau est rare et réservée à quelques acteurs. Aucun modèle n'est intrinsèquement supérieur ; ce qui compte est que le fournisseur documente lequel il applique et comment il durcit les machines qu'il ne possède pas.

Adresses IP partagées ou dédiées

Sur un serveur, des centaines d'abonnés sortent le plus souvent par la même adresse IP publique, grâce à une traduction d'adresses côté serveur. Cette mutualisation dilue votre trafic dans celui des autres : rattacher une action précise à un abonné devient difficile en l'absence de journaux détaillés. Pour gérer les signalements d'abus, certains fournisseurs attribuent à chaque session une plage de ports sur l'adresse partagée, ce qui permet de répondre à une plainte sans journaliser l'activité. À l'inverse, une adresse IP dédiée — proposée en option — vous réidentifie de fait : elle n'est utilisée que par vous. Pour la confidentialité, l'adresse partagée est préférable.

Serveurs sans disque

Plusieurs fournisseurs font démarrer leurs serveurs entièrement en mémoire vive, depuis une image système signée récupérée au démarrage, sans aucun stockage local persistant. L'intérêt réel : une saisie physique du matériel ne livre rien, et un simple redémarrage remet la machine dans un état connu et propre, ce qui complique la persistance d'un implant. Les limites : un serveur en mémoire vive traite tout de même les données en clair pendant qu'il route le trafic, il peut toujours envoyer des journaux vers un système central, et une extraction de la mémoire d'une machine allumée reste théoriquement possible. « Sans disque » est un bon point d'hygiène, pas une garantie d'absence de journalisation.

Le multi-saut

Le multi-saut fait transiter le trafic par deux serveurs successifs avant la sortie. L'objectif est de contrer la corrélation entrée-sortie : un observateur qui voit à la fois votre entrée dans le premier serveur et la sortie du second ne peut plus les relier aussi facilement. Le bénéfice n'est réel que si les deux serveurs relèvent d'opérateurs et de juridictions différents ; deux serveurs du même fournisseur dans le même pays n'apportent presque rien. Le coût est une latence doublée et un débit réduit, ce qui réserve cette option à des besoins précis.

Le DNS du fournisseur

Un fournisseur sérieux fait résoudre les noms par ses propres résolveurs, joints à l'intérieur du tunnel, plutôt que de déléguer à un tiers. Certains ajoutent un filtrage optionnel des domaines publicitaires ou malveillants. Le point de vigilance est que ce résolveur voit, par construction, chaque nom de domaine demandé : sa politique de journalisation compte autant que celle du service VPN lui-même, et devrait être couverte par le même audit.

La juridiction de l'entité opératrice

Ce qui compte n'est pas seulement le pays d'un serveur, mais celui où est enregistrée la société qui l'exploite : c'est là que s'exercent la contrainte judiciaire et le pouvoir réglementaire. Selon la juridiction, cette société peut être soumise à une obligation de conservation des données de connexion, à des réquisitions, à des injonctions d'interception assorties d'une interdiction d'en parler. Une structure de holding opaque, sans propriétaire identifiable, ou un rachat récent par un groupe dont l'activité principale est le marketing, sont des signaux à prendre au sérieux — d'autant qu'une politique technique irréprochable ne pèse rien face à une obligation légale.

Le nombre de serveurs, un chiffre à relativiser

« Plus de 5000 serveurs dans 60 pays » est l'argument de vente le plus répandu, et l'un des moins informatifs. Un « serveur » peut être une machine physique, une instance virtuelle, ou une simple adresse IP annoncée dans un pays mais physiquement hébergée ailleurs — un serveur virtuel. Ce qui détermine votre expérience, c'est la capacité réelle disponible sur les emplacements que vous utilisez, la qualité de leur raccordement, et le taux de remplissage aux heures de pointe : trois données qu'aucun compteur global ne reflète. Un parc plus modeste mais bien dimensionné et bien peeré vaut mieux qu'un grand nombre affiché.

Ce qu'un audit vérifie réellement

Les audits ne se valent pas. Un audit de non-journalisation inspecte la configuration des serveurs et les procédures pour confirmer qu'aucune donnée d'activité individuelle n'est conservée. Un audit de sécurité applicative examine le code des clients et des serveurs à la recherche de vulnérabilités. Un audit d'infrastructure regarde le durcissement des machines et la gestion des accès. Pour être exploitable, un audit doit nommer le cabinet, décrire son périmètre et sa méthode, être daté, et être publié en entier — pas résumé dans un communiqué. Il constitue une photographie à un instant donné : un audit d'il y a trois ans dit peu de l'infrastructure actuelle, d'où l'importance d'une répétition régulière.

Les autres signaux de transparence

Un rapport de transparence recensant les demandes légales reçues et les suites données, un « avertissement canari » renouvelé, un programme de récompense des vulnérabilités, le code source ouvert des applications clientes et, idéalement, des composants serveur : aucun de ces éléments n'est indispensable isolément, mais leur accumulation réduit la part de confiance aveugle demandée à l'utilisateur.

Ce qu'il faut retenir

Côté serveur, la latence dépend du peering plus que de la distance, les adresses partagées protègent mieux que les dédiées, les serveurs sans disque sont un bon point d'hygiène sans être une garantie, et le multi-saut n'a de sens qu'entre opérateurs distincts. Le seul moyen de vérifier les promesses est un audit indépendant au périmètre clair, publié et renouvelé. Ce que le client, de son côté, doit garantir est traité sur les pages fuites et routage.