Compte VPN partagé : une limite d’appareils n’est pas une isolation des clients

Huit connexions simultanées est un chiffre tiré d’une page de licence, et il ne dit rien de ce que ces huit appareils peuvent se faire entre eux. Une connexion partagée peut coexister avec des clés par session, et elle peut aussi coexister avec une passerelle qui transmet volontiers le trafic d’un client à l’autre. L’erreur est de traiter le compte comme une frontière de sécurité. Posez plutôt quatre questions distinctes : ce qui a été acheté, ce qui protège le tunnel, ce qui peut franchir la frontière entre pairs et ce qui peut faire tomber le lien local.

Ce qu’une limite de connexions promet vraiment

Une limite d’appareils compte combien de sessions le fournisseur acceptera pour un abonnement. C’est un contrôle commercial et opérationnel, pas un énoncé sur l’identité ou l’isolation. Certains fournisseurs délivrent un certificat distinct par appareil sous un seul compte ; d’autres réutilisent un identifiant unique pour chaque connexion. La différence apparaît à la révocation, car des identifiants séparés vous permettent de couper un appareil, tandis qu’un identifiant partagé ne vous laisse pas cette possibilité.

Lisez comment le fournisseur délivre les identifiants avant de supposer quoi que ce soit sur la séparation des clés. Le nom du compte n’en révèle rien.

Vérifiez si la passerelle transmet entre clients

L’accessibilité entre pairs est une décision côté serveur. Sur OpenVPN le commutateur concerné est absent sauf s’il figure dans la configuration, mais le déport moderne du plan de données change l’endroit où la règle s’applique.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Une configuration sans cette directive laisse le trafic entre pairs au pare-feu de l’hôte, qui peut encore l’autoriser. Quand le déport est actif, le noyau gère l’interface du tunnel plutôt que le processus en espace utilisateur, vérifiez donc les compteurs de règles au lieu de faire confiance au fichier. Bloquer le trafic transmis entre adresses du tunnel isole les clients sans toucher à leur accès à la passerelle. Confirmez-le par une sonde d’un client vers un service chez un autre, avant et après la règle.

Protégez la session avant les pairs

La protection du tunnel et l’accès entre pairs sont des propriétés différentes, et un chiffrement fort n’implique pas l’isolation. En mode TLS, chaque client dérive ses propres clés de session, si bien qu’un client ne peut pas lire le trafic d’un autre même lorsque la passerelle le relaie. L’ancien dispositif à clé statique partage une clé unique entre tous, ce qui rend la réutilisation d’une connexion bien plus grave. Inspectez le mode configuré plutôt que la page marketing, puis jugez si le partage du compte convient aux données concernées.

L’authentification du service sur chaque hôte reste importante, car le tunnel prouve seulement qu’un client a atteint le réseau, non qu’il doive atteindre un démon précis.

Les pannes de Wi-Fi local ne sont pas des compromissions du VPN

Une connexion tombée prouve que le lien local a échoué, pas que quelqu’un a brisé le tunnel. Les interférences, un bail DHCP perdu et un transfert d’itinérance mettent fin à une session sans toucher aux identifiants ni au texte chiffré. Traitez la déconnexion comme un constat de disponibilité et gardez-la à part des constats de confidentialité et d’accès entre pairs. Là où le réseau local n’est pas fiable, protégez le trafic de bout en bout au lieu de vous appuyer sur le seul tunnel.

Notez les quatre réponses : limite, modèle de clés, politique entre pairs et dépendance au lien local. Cette note transforme une inquiétude vague sur un compte partagé en contrôles précis.