Lorsque plusieurs internautes partagent la même adresse IP VPN pour consulter les mêmes sites, comment les réponses retrouvent-elles leur destinataire ? Derrière ce qui ressemble à un sac de nœuds, les serveurs effectuent un travail de tri permanent, à l’aide d’adresses internes, de numéros de port et de tables de correspondance.
Quand plusieurs personnes se connectent au même serveur VPN, elles peuvent accéder à Internet derrière une même adresse IP publique. Une manière d’améliorer leur confidentialité, puisque les sites consultés ne peuvent pas les identifier individuellement sur la seule base de cette adresse. Mais si deux personnes ouvrent la même page au même instant, comment le serveur VPN fait-il pour ne pas s’emmêler les pinceaux et remettre les réponses à la bonne personne ? Fort heureusement, il ne fait pas ça au pif, mais s’appuie sur une technique que votre box Internet utilise déjà pour permettre à plusieurs appareils de partager une connexion : la traduction d’adresses réseau, ou NAT.
Une IP commune, des ports pour départager les connexions
Sur votre réseau domestique, l’ordinateur, le smartphone et la télévision disposent chacun d’une adresse IP privée, mais accèdent généralement à Internet derrière une même adresse IPv4 publique. C’est le rôle du NAT : lorsque ces appareils envoient des données vers Internet, la box remplace leurs adresses privées par cette adresse commune, puis effectue la traduction inverse au retour pour que chacun reçoive ses réponses.
Le serveur VPN fonctionne selon un principe comparable, mais à plus grande échelle. Les appareils des abonnés communiquent avec lui par l’intermédiaire de tunnels chiffrés et disposent, dans une configuration classique, d’une adresse IP interne au réseau VPN. Avant de transmettre leurs paquets vers les sites consultés, le serveur remplace cette adresse par sa propre IP publique.
Les adresses IP ne sont toutefois pas les seules informations utilisées pour acheminer les données. Pour les communications TCP et UDP, les paquets comportent également deux numéros de port, l’un pour l’expéditeur (source), l’autre pour le destinataire. Lorsqu’un navigateur ouvre une connexion HTTPS, par exemple, il utilise un port source attribué par son appareil pour contacter généralement le port 443 du serveur distant. Associées aux adresses IP et au protocole utilisé, ces informations permettent de distinguer les différents échanges réseau.
Or, sur un serveur VPN, des centaines d’internautes peuvent consulter le même site au même moment. À l’intérieur du VPN, le serveur sait encore à quel client rattacher chaque paquet grâce aux adresses internes et aux informations associées aux connexions chiffrées. Mais lorsqu’il transmet les paquets vers Internet, le serveur remplace ces adresses internes par sa propre IP publique. Si les ports source étaient également identiques, certaines connexions vers un même site deviendraient alors impossibles à distinguer.
Pour éviter ce conflit, le serveur peut attribuer des ports source différents, par exemple 45 101 pour une connexion et 45 102 pour une autre. Le site reçoit ainsi deux requêtes provenant de la même adresse IP, mais depuis deux ports différents, auxquels il pourra adresser ses réponses.
Cette opération porte le nom de NAPT, pour Network Address and Port Translation, une forme de NAT qui traduit à la fois les adresses IP et les numéros de port. Le serveur inscrit chaque correspondance dans une table temporaire, qui lui permettra de retrouver la connexion interne d’origine lorsque les réponses arriveront.
Même sans logs, un VPN a besoin de mémoire
Lorsque le site répond, les données sont envoyées à l’adresse IP publique du VPN et au port attribué à la connexion. Le serveur retrouve alors, dans sa table NAPT, l’adresse et le port internes correspondants, puis effectue la traduction inverse de celle réalisée à l’aller. Les paquets peuvent ainsi être acheminés vers l’appareil concerné, à travers son tunnel chiffré.
Cette dernière étape dépend aussi du protocole VPN utilisé. Avec WireGuard, par exemple, les adresses IP autorisées dans les tunnels sont associées aux clés publiques des clients. Une fois l’adresse interne retrouvée, le protocole peut déterminer quelle session cryptographique utiliser pour chiffrer les paquets et les transmettre au bon appareil.
On l’a vu, ces opérations nécessitent de conserver un temps des informations sur les connexions en cours, mais elles n’imposent pas de garder un historique de l’activité des internautes. Les entrées des tables NAPT servent à acheminer les données et expirent lorsque les connexions se terminent ou après un certain délai d’inactivité. Leur présence en mémoire ne signifie donc pas que le fournisseur VPN conserve des journaux de navigation
Quant aux sites consultés, ils continuent de voir les connexions arriver depuis une adresse IP commune, sans avoir accès aux informations internes qui permettent au VPN de les séparer. Ils peuvent néanmoins reconnaître les internautes par d’autres moyens, notamment les comptes auxquels ils se connectent ou les cookies enregistrés dans leur navigateur. Le partage d’adresse IP améliore certes la confidentialité, mais il ne garantit pas l’anonymat qui, de toute façon, n’est que relatif sur Internet.
