Les VPN associatifs et les VPN commerciaux placent la confiance à des endroits différents

L'étiquette d'un service VPN en dit moins que l'arrangement qui le sous-tend. Un réseau bénévole peut regrouper des relais exploités par des personnes sans aucun lien entre elles, tandis qu'un service commercial présente généralement un seul compte et une seule politique publiée sur une infrastructure qu'il peut louer en partie. Aucune des deux formes n'est automatiquement plus privée. Ce qui change, c'est qui contrôle le point de sortie auquel vous vous connectez, et qui pourrait donc répondre à une question à son sujet.

Trois parties, pas une

Trois parties se tiennent derrière toute connexion, et ce n'est pas toujours la même organisation. L'exploitant de l'annuaire décide quels points de sortie vous pouvez trouver et distribue des profils ; le développeur du logiciel décide comment votre client parle le protocole ; l'exploitant du serveur fait tourner la machine d'où sort votre trafic. Seul le dernier est en position d'enregistrer ou de conserver quoi que ce soit, et dans un arrangement bénévole cette personne peut être une inconnue pour les deux autres.

Un arrangement commercial fusionne généralement les trois en une seule entreprise, même s'il peut louer des serveurs à un hébergeur. Lisez ce que le fournisseur dit exploiter, car l'expression notre réseau et l'expression notre politique peuvent couvrir des systèmes différents. Lorsqu'un partenaire est impliqué, la politique doit le nommer, sinon elle n'atteint pas votre trafic.

Comment un point de sortie disparaît

Un relais bénévole existe parce que son hébergeur le maintient en marche. Quand cette personne s'arrête, l'entrée quitte l'annuaire, et rien dans cet arrangement ne promet que le relais sera là demain.

Une entrée d'annuaire est une option, pas une garantie : choisir une autre entrée, c'est choisir un autre exploitant, pas se reconnecter au même service. Les services commerciaux échouent de la même manière pour d'autres raisons, qu'il s'agisse de capacité, d'une restriction régionale ou d'une panne chez un partenaire d'hébergement. Ce qui change, c'est à qui vous pouvez poser la question. Aucun des deux arrangements ne vous doit une continuité simplement parce que le profil se charge encore.

Ce que la politique couvre réellement

Les projets bénévoles publient eux aussi des règles de journalisation et de lutte contre les abus, et ces règles sont la partie intéressante. Bénévole décrit qui héberge le relais, pas une promesse que rien n'est enregistré, et un projet qui publie un traitement des abus vous dit que des enregistrements existent quelque part.

Les politiques commerciales ont le problème inverse : elles sont détaillées, et le détail est ce que vous devez lire. Une politique couvrant les serveurs propres du fournisseur ne décrit pas automatiquement l'infrastructure d'un partenaire. Une déclaration de compétence juridique n'est pas une description de la pratique. Cherchez la section qui nomme les systèmes concernés, et traitez une politique qui reste vague sur son périmètre comme du marketing plutôt que comme une preuve.

Décidez avec un relevé, pas avec une étiquette

Un client qui se connecte prouve la compatibilité de protocole et la joignabilité, et rien sur les enregistrements, car les enregistrements se font au point de sortie et au-dessus. C'est pourquoi une icône d'état verte est un signal si faible : le même client pointé vers un relais soigneux et vers un relais négligé paraît identique. Le relevé de décision doit donc être construit à partir de ce que vous pouvez justifier au sujet de l'exploitant précis, et non de l'interface. Notez la visibilité technique du chemin, les catégories de données concernées et la confiance que l'exploitant a gagnée ; si l'un de ces éléments est une supposition, la décision n'est pas terminée.

Si vous ne comparez que des connexions, consignez plutôt le point de sortie et le résultat que vous avez mesuré. Un relais dans un pays, une ressource atteinte et une réponse mesurée décrivent ce que vous avez testé sans attribuer le comportement d'un hébergeur à tout un projet.

Gardez la compatibilité du logiciel et du protocole séparée de la pratique du service tout au long, car des parties différentes en décident et elles échouent de manières différentes. Ajoutez deux champs au relevé pour cette raison : la version du client que vous avez exécutée et le protocole négocié. La comparaison suivante part alors de preuves plutôt que d'une étiquette. Un relevé qui nomme le point de sortie, le client et le résultat est la seule partie de cette décision que vous pourrez défendre plus tard.