Peer-to-peer-VPN'er har stadig centrale afhængigheder

Peer-to-peer beskriver, hvordan applikationspakker rejser, og intet andet. Peerne skulle stadig finde hinanden, bevise hvem de er og nogle gange falde tilbage til et relay, når en direkte sti ikke kunne bygges. Det er tre separate tjenester, og en udrulning kan være peer-to-peer for data, mens den er fuldstændig centraliseret for alt andet. At sammenligne designs betyder at sammenligne de opgaver, ikke pilen på diagrammet.

Et diagram uden en central videresendelsespil kan skjule en tilmeldingsmyndighed, en opdagelsestjeneste og et relay, som alle er operationelle afhængigheder.

Direkte sti, fælles kontrolplan

To maskiner, der udveksler pakker direkte, kan stadig afhænge af en fælles myndighed, der har udstedt deres certifikater, og af en tjeneste, der fortalte hver især, hvor den anden er. Ingen af rollerne videresender applikationstrafik, og derfor udelader topologitegningen dem. Når den myndighed eller tjeneste er nede, kan eksisterende sessioner fortsætte, mens en ny peer ikke kan tilslutte sig. Forskellen mellem at starte en session og at fortsætte den er det første spørgsmål, man bør stille til ethvert design.

Tegn hver opgave separat, selv når en enkelt vært udfører dem alle. Ellers viser tegningen et decentralt dataplan og skjuler den operationelle virkelighed, at enhver ny peer har brug for de samme to tjenester.

Opdagelse, tillid og relay er tre opgaver

Nebulas design er et nyttigt eksempel, fordi dokumentationen holder dem adskilt. Værter bærer certifikater for identitet, fyrtårne svarer på hvor-er-spørgsmålet og hjælper med NAT-gennemtrængning, og relays videresender trafik, når en direkte sti ikke kan etableres. Relayrollen er bevidst adskilt fra fyrtårnsrollen, så et tilgængeligt fyrtårn lover ikke, at et bestemt par kan tale sammen. Andre produkter trækker grænserne andre steder, og derfor er dette et eksempel og ikke en skabelon.

For en foreslået udrulning skal du skrive den understøttede tilbagefaldsløsning ned for et par, der ikke kan forbinde direkte. Et mislykket hole-punch er et datapunkt om et netværk, ikke et bevis på, at to NAT-peers aldrig kan mødes; det modsatte udsagn, at direkte forbindelse virker under vilkårlig politik, er lige så uunderbygget.

Hvad hver afhængighed fejler på

Vurder fire tilfælde hver for sig, mens den afhængighed, der testes, er utilgængelig: eksisterende peertrafik, en helt ny peerforbindelse, en peer hvis endepunkt er ændret, og adgang, der netop er tilbagekaldt. Hver af dem afhænger af forskellige tjenester og fejler forskelligt. Eksisterende sessioner kan overleve et opdagelsesudfald, mens en tilbagekaldt nøgle stadig afvises, og en ny peer kan fejle af grunde, der intet har med videresendelse at gøre. Test dem enkeltvis i stedet for at konkludere ud fra ét tilfælde.

En forbindelse, der overlever et enkelt udfald, etablerer ikke ubestemt uafhængighed. Den etablerer, at det udfald, du forårsagede, ikke var det, der bryder den sti, hvilket stadig er nyttig information, forudsat at du skrev ned, hvad du forårsagede.

Spørg, hvilket udfald du kan overleve

Krav, der lyder ens, fører til forskellige designs. At undgå en enkelt videresendelsesflaskehals er ikke det samme som at undgå et kontrolplan hostet hos en leverandør, og ingen af delene svarer til at fortsætte driften, mens en koordinator er nede. Navngiv, hvilket af de tre udrulningen skal opfylde, og kontrollér derefter mappingen. Et design, der opfylder det første og fejler det andet, er almindeligt og ikke uærligt, så længe ingen kalder det fuldt decentraliseret.

Notér, hvem der driver opdagelse, tillid og relays, og hvordan hver af dem erstattes. Den registrering er det, der gør det muligt for den næste person at besvare et reelt spørgsmål: hvilke fejl overlever dette netværk, og hvem vedligeholder den tilstand, der forbliver delt?

Ordet decentraliseret fortjener sin plads, når det navngiver de fejl. Uden den liste beskriver det et diagram i stedet for et system.