Un VPN pair-à-pair conserve des dépendances centrales

Le pair-à-pair décrit comment circulent les paquets des applications, et rien de plus. Les pairs devaient toujours se trouver, prouver qui ils sont et, parfois, se rabattre sur un relais quand un chemin direct ne pouvait pas être construit. Ce sont trois services distincts, et un déploiement peut être pair-à-pair pour les données tout en étant entièrement centralisé pour tout le reste. Comparer des conceptions, c’est comparer ces tâches, pas la flèche du schéma.

Un schéma sans flèche de transfert centrale peut masquer une autorité d’enrôlement, un service de découverte et un relais, qui sont autant de dépendances opérationnelles.

Chemin direct, plan de contrôle partagé

Deux machines qui échangent des paquets directement peuvent encore dépendre d’une autorité commune qui a émis leurs certificats et d’un service qui a indiqué à chacune où se trouve l’autre. Aucun des deux rôles ne transfère le trafic des applications, c’est pourquoi le dessin de topologie les omet. Quand cette autorité ou ce service est indisponible, les sessions existantes peuvent continuer tandis qu’un nouveau pair ne peut pas rejoindre. La différence entre démarrer une session et la poursuivre est la première question à poser à toute conception.

Dessinez chaque tâche séparément, même lorsqu’un seul hôte les exécute toutes. Sinon, le dessin montre un plan de données décentralisé et cache la réalité opérationnelle selon laquelle chaque nouveau pair a besoin des deux mêmes services.

Découverte, confiance et relais sont trois tâches

La conception de Nebula est un exemple utile parce que sa documentation tient ces éléments séparés. Les hôtes portent des certificats pour l’identité, les phares répondent à la question du où et aident au franchissement du NAT, et les relais transfèrent le trafic lorsqu’un chemin direct ne peut pas être établi. Le rôle de relais est délibérément distinct du rôle de phare, si bien qu’un phare joignable ne garantit pas qu’une paire donnée puisse communiquer. D’autres produits placent les frontières ailleurs, c’est pourquoi il s’agit d’un exemple et non d’un modèle.

Pour un déploiement envisagé, notez la solution de repli prise en charge pour une paire qui ne peut pas se connecter directement. Un perçage de trou raté est un point de données sur un réseau, pas la preuve que deux pairs derrière un NAT ne pourront jamais se rencontrer ; l’affirmation inverse, selon laquelle la connectivité directe fonctionne sous n’importe quelle politique, n’est pas plus étayée.

Ce à quoi chaque dépendance échoue

Évaluez quatre cas séparément pendant que la dépendance testée est indisponible : le trafic entre pairs existant, une toute nouvelle connexion de pair, un pair dont le point de terminaison a changé, et un accès qui vient d’être révoqué. Chacun repose sur des services différents et échoue différemment. Les sessions existantes peuvent survivre à une panne de découverte tandis qu’une clé révoquée reste refusée, et un nouveau pair peut échouer pour des raisons sans rapport avec le transfert. Testez-les individuellement au lieu de conclure à partir d’un seul cas.

Une connexion qui survit à une seule panne n’établit pas une indépendance indéfinie. Elle établit que la panne que vous avez provoquée n’était pas celle qui casse ce chemin, ce qui reste une information utile à condition d’avoir noté ce que vous avez provoqué.

Demandez à quelle panne vous survivez

Des exigences qui se ressemblent mènent à des conceptions différentes. Éviter un seul goulot d’étranglement de transfert n’est pas la même chose qu’éviter un plan de contrôle hébergé par un fournisseur, et ni l’un ni l’autre ne correspond à continuer à fonctionner pendant qu’un coordinateur est indisponible. Nommez laquelle de ces trois exigences le déploiement doit satisfaire, puis vérifiez la correspondance. Une conception qui satisfait la première et échoue à la seconde est courante et n’est pas malhonnête, tant que personne ne la qualifie de totalement décentralisée.

Notez qui exploite la découverte, la confiance et les relais, et comment chacun est remplacé. Cette trace permet à la personne suivante de répondre à une vraie question : quelles pannes ce réseau survit-il, et qui maintient l’état qui reste partagé ?

Le mot décentralisé mérite sa place lorsqu’il nomme ces pannes. Sans cette liste, il décrit un schéma plutôt qu’un système.