Peer-to-peer VPN još uvek 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 direktna putanja nije mogla da se izgradi. 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 prosleđivanja može sakriti registracioni organ, uslugu otkrivanja i relej, koji su svi operativne zavisnosti.

Direktna putanja, zajednička kontrolna ravan

Dve mašine koje direktno razmenjuju pakete mogu i dalje zavisiti od zajedničkog organa koji je izdao njihove sertifikate i od usluge koja je svakoj rekla gde se nalazi ona druga. Nijedna od dve uloge ne prosleđuje saobraćaj 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 da pristupi. 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 ravan i skriva operativnu stvarnost da svakom novom partneru trebaju iste dve usluge.

Otkrivanje, poverenje i relej su tri posla

Dizajn Nebula je koristan primer jer njegova dokumentacija drži ove stvari odvojenim. Hostovi nose sertifikate za identitet, svetionici odgovaraju na pitanje gde i pomažu pri prolasku kroz NAT, a releji prosleđuju saobraćaj kada se direktna putanja ne može uspostaviti. Uloga releja je namerno odvojena od uloge svetionika, pa dostupan svetionik ne obećava da određeni par može da razgovara. Drugi proizvodi povlače granice negde drugde, zato je ovo primer, a ne šablon.

Za predloženu implementaciju zapišite podržanu rezervnu putanju za par koji ne može da se poveže direktno. Neuspešno probijanje rupe je jedna podatkovna tač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 nepotkrepljena.

Na čemu svaka zavisnost pada

Procenite četiri slučaja odvojeno dok testirana zavisnost nije dostupna: postojeći saobraćaj između partnera, potpuno nova partnerska veza, partner čija se krajnja tačka promenila i pristup koji je upravo opozvan. Svaki se oslanja na druge usluge i pada drugačije. Postojeće sesije mogu preživeti ispad otkrivanja dok se opozvani ključ i dalje odbija, a novi partner može pasti iz razloga koji nemaju nikakve veze sa prosleđivanjem. Testirajte ih pojedinačno umesto 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živeti

Zahtevi koji zvuče slično vode do različitih dizajna. Izbjeći jedno usko grlo prosleđivanja nije isto što i izbjeći kontrolnu ravan 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 proverite 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, poverenjem i relejima i kako se svaki zamenjuje. Taj zapis je ono što sledeć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?

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