Limites de connexions VPN : état en direct ou historique conservé
Une limite de trois connexions exige un état des emplacements en direct, pas un historique de navigation : ce que le mécanisme doit stocker, ce qu'il peut écarter et où cet état va ensuite.
Trois connexions simultanées constituent une décision d'admission, et pour y répondre il faut savoir quels emplacements sont occupés à l'instant présent, et non ce qui s'est passé le mois dernier. Un service peut refuser une quatrième session à partir d'une petite table d'enregistrements actifs sans jamais construire de chronologie. C'est une affirmation sur le mécanisme, pas sur l'opérateur, et la différence compte lorsqu'on lit une politique de confidentialité. Le modèle ci-dessous montre ce dont la décision a besoin et ce qu'elle peut écarter.
Le mécanisme : une table d'emplacements, pas un journal
L'implémentation la plus simple associe un abonnement à trois enregistrements de session actifs au plus. Chaque session admise occupe un emplacement, et l'emplacement est libéré lorsque le service décide que cette session est terminée. L'enregistrement a besoin d'une identité suffisamment spécifique pour que la libération d'une connexion ne libère pas l'emplacement d'une autre connexion ; c'est pourquoi l'identifiant de session importe plus que le nom du compte.
L'occupation et l'historique sont des structures de données différentes. L'occupation répond à une question par oui ou non sur le présent, et elle peut être écartée au moment même où la session se termine. Un historique est un flux d'événements en ajout seul, et il survit parce que quelqu'un a choisi de le conserver. Un service peut avoir l'un, les deux ou aucun.
La distinction est invisible de l'extérieur. Une limite de connexions visible est compatible avec un minuscule compteur en mémoire, une table de base de données partagée et une archive complète d'événements avec un tableau de bord. Rien dans la limite ne vous dit laquelle est en service.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
Pourquoi le modèle en direct a quand même besoin de coordination
Une connexion perdue peut ne pas être reconnue comme terminée tout de suite. La passerelle attend un délai d'expiration, une défaillance de keepalive ou un arrêt de la comptabilité, et jusqu'à ce que l'un de ces signaux arrive, l'emplacement reste occupé. Un utilisateur qui se reconnecte pendant cette fenêtre voit un refus qui n'a rien à voir avec un quatrième appareil.
Un serveur redémarré doit réconcilier son état, et plusieurs passerelles servant le même compte ont besoin d'une décision commune. Sinon, un compte peut dépasser son quota en se connectant à des emplacements différents. Un état partagé ou récupérable règle cela, et l'état partagé est une exigence de conception, non une preuve de surveillance.
Rien de cette coordination n'exige d'historiques de navigation. Une passerelle qui transfère des paquets n'a pas besoin de savoir quels sites une session a visités pour compter les sessions, et les deux flux de données sont généralement traités par des composants totalement différents.
Garder un compteur en mémoire ne rend pas non plus les faits associés anonymes. Pendant que le service tourne, un enregistrement lié à l'abonnement révèle qu'un compte a des connexions actives, et l'accès à cet état comme sa durée de vie méritent tous deux d'être questionnés.
Où va cet état ensuite
La question de confidentialité n'est pas de savoir si le serveur peut compter. Demandez ce qu'il advient d'une session terminée : l'enregistrement est-il supprimé, ou devient-il un événement dans une série de supervision ? Demandez ensuite quels autres composants ont vu le même événement, car les journaux d'authentification, les enregistrements comptables et les sauvegardes peuvent chacun conserver une copie que le chemin d'application a écartée.
La comptabilité RADIUS en est l'exemple le plus clair. Une paire Start et Stop existe pour prendre en charge la facturation et le contrôle des sessions, et elle crée un enregistrement de la connexion, que quelqu'un l'interroge un jour comme historique ou non. Un service qui applique des limites via la comptabilité conserve donc par construction plus qu'une table d'emplacements.
La suppression a aussi une forme. Un enregistrement retiré de la table en direct peut subsister dans une sauvegarde prise une heure plus tôt, et la durée de conservation de cette sauvegarde est sa propre déclaration de principe. Ne lire que le stockage principal donne une réponse incomplète.
Poser la question en termes de champs
Les recommandations de minimisation des données du RFC 6973 lient les données collectées et stockées à la finalité servie. Appliquée ici, la question utile est de savoir quels champs la tâche d'admission simultanée exige réellement, et quelle finalité justifie de conserver chacun après la fin de cette tâche.
Un énoncé de service précis sépare l'état de connexion en direct utilisé pour appliquer le quota de tout enregistrement conservé après la fin, et il nomme les autres systèmes dans le périmètre de la promesse. Une phrase qui dit seulement que trois connexions sont appliquées n'établit ni qu'une archive existe ni qu'il n'en existe aucune.
Lorsque le cycle de vie n'est pas clair, consignez-le comme une question de conservation sans réponse plutôt que comme un verdict. La présence d'une limite n'est pas la preuve d'un historique caché, et une explication plausible de l'état en direct n'est pas un audit du fournisseur.