Peer-to-peer-VPN:er har fortfarande centrala beroenden

Peer-to-peer beskriver hur applikationspaket färdas, och inget mer. Peerna måste fortfarande hitta varandra, bevisa vilka de är och ibland falla tillbaka på en relay när en direkt väg inte kunde byggas. Det är tre separata tjänster, och en driftsättning kan vara peer-to-peer för data medan den är helt centraliserad för allt annat. Att jämföra designer innebär att jämföra de uppgifterna, inte pilen i diagrammet.

Ett diagram utan en central vidarebefordringspil kan dölja en registreringsmyndighet, en upptäcktstjänst och en relay, som alla är operativa beroenden.

Direkt väg, delat kontrollplan

Två maskiner som utbyter paket direkt kan fortfarande bero på en gemensam myndighet som utfärdade deras certifikat och på en tjänst som berättade för var och en var den andra finns. Ingen av rollerna vidarebefordrar applikationstrafik, vilket är varför topologiteckningen utelämnar dem. När den myndigheten eller tjänsten är nere kan befintliga sessioner fortsätta medan en ny peer inte kan ansluta. Skillnaden mellan att starta en session och att fortsätta den är den första frågan att ställa till varje design.

Rita varje uppgift separat även när en enda värd utför dem alla. Annars visar teckningen ett decentraliserat dataplan och döljer den operativa verkligheten att varje ny peer behöver samma två tjänster.

Upptäckt, förtroende och relay är tre uppgifter

Nebulas design är ett användbart exempel eftersom dokumentationen håller dem åtskilda. Värdar bär certifikat för identitet, fyrar svarar på var-finns-frågan och hjälper till med NAT-traversering, och relayer vidarebefordrar trafik när en direkt väg inte kan upprättas. Relayrollen är medvetet skild från fyrrollen, så en nåbar fyr lovar inte att ett givet par kan prata. Andra produkter drar gränserna någon annanstans, vilket är varför detta är ett exempel och inte en mall.

För en föreslagen driftsättning, skriv ned den fallback som stöds för ett par som inte kan ansluta direkt. En misslyckad hole-punch är en datapunkt om ett nätverk, inte ett bevis för att två NAT-peers aldrig kan mötas; det motsatta påståendet, att direktanslutning fungerar under godtycklig policy, är lika obelagt.

Vad varje beroende fallerar på

Utvärdera fyra fall separat medan beroendet som testas är otillgängligt: befintlig peertrafik, en helt ny peeranslutning, en peer vars ändpunkt har ändrats och åtkomst som just har återkallats. Varje fall bygger på olika tjänster och fallerar olika. Befintliga sessioner kan överleva ett upptäcktsavbrott medan en återkallad nyckel fortfarande nekas, och en ny peer kan misslyckas av skäl som inte har något med vidarebefordran att göra. Testa dem individuellt i stället för att dra slutsatser från ett fall.

En anslutning som överlever ett enskilt avbrott etablerar inte obegränsat oberoende. Den etablerar att avbrottet du orsakade inte var det som bryter den vägen, vilket fortfarande är användbar information förutsatt att du skrev ned vad du orsakade.

Fråga vilket avbrott du kan överleva

Krav som låter lika leder till olika designer. Att undvika en enda vidarebefordringsflaskhals är inte samma sak som att undvika ett leverantörshostat kontrollplan, och ingen av dem motsvarar att fortsätta driften medan en koordinator är nere. Namnge vilket av de tre driftsättningen måste uppfylla och kontrollera sedan mappningen. En design som uppfyller det första och misslyckas med det andra är vanlig och inte oärlig, så länge ingen kallar den helt decentraliserad.

Dokumentera vem som driftar upptäckt, förtroende och relayer och hur var och en ersätts. Den dokumentationen är det som låter nästa person svara på en verklig fråga: vilka fel överlever detta nätverk, och vem underhåller det tillstånd som förblir delat?

Ordet decentraliserad förtjänar sin plats när det namnger de felen. Utan den listan beskriver det ett diagram i stället för ett system.