Una VPN peer-to-peer ha ancora dipendenze centrali

Peer-to-peer descrive come viaggiano i pacchetti delle applicazioni, e nient’altro. I peer dovevano comunque trovarsi, dimostrare chi sono e, a volte, ricorrere a un relay quando non si poteva costruire un percorso diretto. Sono tre servizi separati, e un’implementazione può essere peer-to-peer per i dati pur essendo del tutto centralizzata per tutto il resto. Confrontare progetti significa confrontare queste attività, non la freccia del diagramma.

Un diagramma senza una freccia centrale di inoltro può nascondere un’autorità di iscrizione, un servizio di scoperta e un relay, che sono tutte dipendenze operative.

Percorso diretto, piano di controllo condiviso

Due macchine che scambiano pacchetti direttamente possono comunque dipendere da un’autorità condivisa che ha emesso i loro certificati e da un servizio che ha detto a ciascuna dove si trova l’altra. Nessuno dei due ruoli inoltra il traffico delle applicazioni, ed è per questo che il disegno della topologia li omette. Quando quell’autorità o quel servizio è inattivo, le sessioni esistenti possono continuare mentre un nuovo peer non riesce a unirsi. La differenza tra iniziare una sessione e continuarla è la prima domanda da porre a qualsiasi progetto.

Disegna ogni attività separatamente anche quando un solo host le esegue tutte. Altrimenti il disegno mostra un piano dati decentralizzato e nasconde la realtà operativa che ogni nuovo peer ha bisogno degli stessi due servizi.

Scoperta, fiducia e relay sono tre attività

Il progetto di Nebula è un esempio utile perché la sua documentazione li tiene separati. Gli host portano certificati per l’identità, i fari rispondono alla domanda su dove e aiutano con il traversal NAT, e i relay inoltrano il traffico quando non si può stabilire un percorso diretto. Il ruolo di relay è deliberatamente distinto dal ruolo di faro, quindi un faro raggiungibile non promette che una determinata coppia possa parlarsi. Altri prodotti tracciano i confini altrove, ed è per questo che questo è un esempio e non un modello.

Per un’implementazione proposta, annota il ripiego supportato per una coppia che non può connettersi direttamente. Un hole-punch fallito è un dato su una rete, non una prova che due peer dietro NAT non possano mai incontrarsi; l’affermazione opposta, che la connettività diretta funzioni con qualsiasi politica, è altrettanto infondata.

Dove fallisce ciascuna dipendenza

Valuta quattro casi separatamente mentre la dipendenza in prova non è disponibile: il traffico esistente tra peer, una connessione peer del tutto nuova, un peer il cui endpoint è cambiato e un accesso appena revocato. Ognuno si basa su servizi diversi e fallisce in modo diverso. Le sessioni esistenti possono sopravvivere a un guasto della scoperta mentre una chiave revocata viene ancora rifiutata, e un nuovo peer può fallire per motivi che non hanno nulla a che vedere con l’inoltro. Provali singolarmente invece di concludere da un solo caso.

Una connessione che sopravvive a un singolo guasto non stabilisce un’indipendenza indefinita. Stabilisce che il guasto che hai causato non era quello che rompe quel percorso, il che resta un’informazione utile a patto di aver annotato ciò che hai causato.

Chiedi a quale guasto sopravvivi

Requisiti che suonano simili portano a progetti diversi. Evitare un singolo collo di bottiglia dell’inoltro non è lo stesso che evitare un piano di controllo ospitato da un fornitore, e nessuno dei due equivale a continuare a funzionare mentre un coordinatore è inattivo. Nomina quale di questi tre l’implementazione deve soddisfare, poi controlla la corrispondenza. Un progetto che soddisfa il primo e fallisce il secondo è comune e non è disonesto, purché nessuno lo chiami del tutto decentralizzato.

Annota chi gestisce scoperta, fiducia e relay, e come ciascuno viene sostituito. Quella registrazione è ciò che permette alla persona successiva di rispondere a una domanda reale: quali guasti sopravvive questa rete, e chi mantiene lo stato che resta condiviso?

La parola decentralizzato si guadagna il suo posto quando nomina quei guasti. Senza quell’elenco descrive un diagramma anziché un sistema.