Peer-to-peer VPN и даље има централне зависности

Peer-to-peer описује како путују пакети апликација, и ништа више. Партнери су и даље морали да пронађу један другог, докажу ко су и, понекад, посегну за релејом када директна путања није могла да се изгради. То су три одвојене услуге, а имплементација може бити peer-to-peer за податке док је за све остало потпуно централизована. Упоређивати дизајне значи упоређивати те послове, а не стрелицу на дијаграму.

Дијаграм без централне стрелице прослеђивања може сакрити регистрациони орган, услугу откривања и релеј, који су сви оперативне зависности.

Директна путања, заједничка контролна раван

Две машине које директно размењују пакете могу и даље зависити од заједничког органа који је издао њихове сертификате и од услуге која је свакој рекла где се налази она друга. Ниједна од две улоге не прослеђује саобраћај апликација, зато их цртеж топологије изоставља. Када је тај орган или та услуга недоступна, постојеће сесије могу се наставити док нови партнер не може да приступи. Разлика између започињања сесије и њеног настављања је прво питање које треба поставити сваком дизајну.

Нацртајте сваки посао одвојено, чак и када их све обавља један хост. У супротном цртеж приказује децентрализовану податковну раван и скрива оперативну стварност да сваком новом партнеру требају исте две услуге.

Откривање, поверење и релеј су три посла

Дизајн Nebula је користан пример јер његова документација држи ове ствари одвојеним. Хостови носе сертификате за идентитет, светионици одговарају на питање где и помажу при проласку кроз NAT, а релеји прослеђују саобраћај када се директна путања не може успоставити. Улога релеја је намерно одвојена од улоге светионика, па доступан светионик не обећава да одређени пар може да разговара. Други производи повлаче границе негде другде, зато је ово пример, а не шаблон.

За предложену имплементацију запишите подржану резервну путању за пар који не може да се повеже директно. Неуспешно пробијање рупе је једна податковна тачка о једној мрежи, а не доказ да се два партнера иза NAT-а никада не могу срести; супротна тврдња, да директна повезаност функционише под било којом политиком, једнако је непоткрепљена.

На чему свака зависност пада

Процените четири случаја одвојено док тестирана зависност није доступна: постојећи саобраћај између партнера, потпуно нова партнерска веза, партнер чија се крајња тачка променила и приступ који је управо опозван. Сваки се ослања на друге услуге и пада другачије. Постојеће сесије могу преживети испад откривања док се опозвани кључ и даље одбија, а нови партнер може пасти из разлога који немају никакве везе са прослеђивањем. Тестирајте их појединачно уместо да закључујете из једног.

Веза која преживи један испад не успоставља неограничену независност. Она успоставља да испад који сте проузроковали није био онај који прекида ту путању, што је и даље корисна информација под условом да сте записали шта сте проузроковали.

Питајте који испад можете преживети

Захтеви који звуче слично воде до различитих дизајна. Избећи једно уско грло прослеђивања није исто што и избећи контролну раван коју хостује добављач, а ниједно од тога не одговара наставку рада док је координатор недоступан. Именујте који од та три имплементација мора да испуни, а затим проверите мапирање. Дизајн који испуњава први и пада на другом је чест и није нечасан, све док га нико не назива потпуно децентрализованим.

Запишите ко управља откривањем, поверењем и релејима и како се сваки замењује. Тај запис је оно што следећој особи омогућава да одговори на стварно питање: које испаде ова мрежа преживљава и ко одржава стање које остаје заједничко?

Реч децентрализовано заслужује своје место када именује те испаде. Без тог списка описује дијаграм, а не систем.