Peer-to-peer VPN još uvijek ima centralne zavisnosti

Peer-to-peer opisuje kako putuju paketi aplikacija, i ništa više. Partneri su i dalje morali pronaći jedan drugog, dokazati ko su i, ponekad, posegnuti za relejem kada se direktna putanja nije mogla izgraditi. To su tri odvojene usluge, a implementacija može biti peer-to-peer za podatke dok je za sve ostalo potpuno centralizovana. Upoređivati dizajne znači upoređivati te poslove, a ne strelicu na dijagramu.

Dijagram bez centralne strelice prosljeđivanja može sakriti registracioni organ, uslugu otkrivanja i relej, koji su svi operativne zavisnosti.

Direktna putanja, zajednička kontrolna ravnina

Dvije mašine koje direktno razmjenjuju pakete mogu i dalje zavisiti od zajedničkog organa koji je izdao njihove certifikate i od usluge koja je svakoj rekla gdje se nalazi ona druga. Nijedna od dvije uloge ne prosljeđuje promet aplikacija, zato ih crtež topologije izostavlja. Kada je taj organ ili ta usluga nedostupna, postojeće sesije mogu se nastaviti dok novi partner ne može pristupiti. Razlika između započinjanja sesije i njenog nastavljanja je prvo pitanje koje treba postaviti svakom dizajnu.

Nacrtajte svaki posao odvojeno, čak i kada ih sve obavlja jedan host. U suprotnom crtež prikazuje decentralizovanu podatkovnu ravninu i skriva operativnu stvarnost da svakom novom partneru trebaju iste dvije usluge.

Otkrivanje, povjerenje i relej su tri posla

Dizajn Nebula je koristan primjer jer njegova dokumentacija drži ove stvari odvojenim. Hostovi nose certifikate za identitet, svjetionici odgovaraju na pitanje gdje i pomažu pri prolasku kroz NAT, a releji prosljeđuju promet kada se direktna putanja ne može uspostaviti. Uloga releja je namjerno odvojena od uloge svjetionika, pa dostupan svjetionik ne obećava da određeni par može razgovarati. Drugi proizvodi povlače granice negdje drugdje, zato je ovo primjer, a ne šablon.

Za predloženu implementaciju zapišite podržanu rezervnu putanju za par koji se ne može povezati direktno. Neuspješno probijanje rupe je jedna podatkovna točka o jednoj mreži, a ne dokaz da se dva partnera iza NAT-a nikada ne mogu sresti; suprotna tvrdnja, da direktna povezanost funkcioniše pod bilo kojom politikom, jednako je nepotkrijepljena.

Na čemu svaka zavisnost pada

Procijenite četiri slučaja odvojeno dok testirana zavisnost nije dostupna: postojeći promet između partnera, potpuno nova partnerska veza, partner čija se krajnja točka promijenila i pristup koji je upravo opozvan. Svaki se oslanja na druge usluge i pada drugačije. Postojeće sesije mogu preživjeti ispad otkrivanja dok se opozvani ključ i dalje odbija, a novi partner može pasti iz razloga koji nemaju nikakve veze s prosljeđivanjem. Testirajte ih pojedinačno umjesto da zaključujete iz jednog.

Veza koja preživi jedan ispad ne uspostavlja neograničenu nezavisnost. Ona uspostavlja da ispad koji ste prouzrokovali nije bio onaj koji prekida tu putanju, što je i dalje korisna informacija pod uslovom da ste zapisali šta ste prouzrokovali.

Pitajte koji ispad možete preživjeti

Zahtjevi koji zvuče slično vode do različitih dizajna. Izbjeći jedno usko grlo prosljeđivanja nije isto što i izbjeći kontrolnu ravninu koju hostuje dobavljač, a nijedno od toga ne odgovara nastavku rada dok je koordinator nedostupan. Imenujte koji od ta tri implementacija mora ispuniti, a zatim provjerite mapiranje. Dizajn koji ispunjava prvi i pada na drugom je čest i nije nečastan, sve dok ga niko ne naziva potpuno decentralizovanim.

Zapišite ko upravlja otkrivanjem, povjerenjem i relejima i kako se svaki zamjenjuje. Taj zapis je ono što sljedećoj osobi omogućava da odgovori na stvarno pitanje: koje ispade ova mreža preživljava i ko održava stanje koje ostaje zajedničko?

Riječ decentralizovano zaslužuje svoje mjesto kada imenuje te ispade. Bez tog spiska opisuje dijagram, a ne sistem.