Peer-to-peer VPN još uvijek ima centralne zavisnosti
Direktna podatkovna putanja između partnera može i dalje zahtijevati registraciju, otkrivanje i relej. Usporedite ta tri posla odvojeno prije nego što VPN nazovete decentraliziranim.
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 centralizirana. Uspoređivati dizajne znači uspoređivati te poslove, a ne strelicu na dijagramu.
Dijagram bez centralne strelice prosljeđivanja može sakriti registracijsko tijelo, uslugu otkrivanja i relej, koji su svi operativne zavisnosti.
Direktna putanja, zajednička kontrolna ravnina
Dvije mašine koje izravno razmjenjuju pakete mogu i dalje zavisiti od zajedničkog tijela koje je izdalo 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 to tijelo ili ta usluga nedostupna, postojeće sesije mogu se nastaviti dok novi partner ne može pristupiti. Razlika između započinjanja sesije i njezina nastavljanja prvo je pitanje koje treba postaviti svakom dizajnu.
Nacrtajte svaki posao odvojeno, čak i kada ih sve obavlja jedan host. U suprotnom crtež prikazuje decentraliziranu podatkovnu ravninu i skriva operativnu stvarnost da svakom novom partneru trebaju iste dvije usluge.
Otkrivanje, povjerenje i relej su tri posla
Dizajn Nebula koristan je primjer jer njegova dokumentacija drži ove stvari odvojenima. 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 namjerno je 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 predložak.
Za predloženu implementaciju zapišite podržanu rezervnu putanju za par koji se ne može povezati izravno. Neuspješno probijanje rupe jedna je podatkovna točka o jednoj mreži, a ne dokaz da se dva partnera iza NAT-a nikada ne mogu sresti; suprotna tvrdnja, da izravna povezanost funkcionira 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 jednoga.
Veza koja preživi jedan ispad ne uspostavlja neograničenu neovisnost. Ona uspostavlja da ispad koji ste prouzročili nije bio onaj koji prekida tu putanju, što je i dalje korisna informacija pod uvjetom da ste zapisali što ste prouzročili.
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 hosta 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 čest je i nije nečastan, sve dok ga nitko ne naziva potpuno decentraliziranim.
Zapišite tko upravlja otkrivanjem, povjerenjem i relejima i kako se svaki zamjenjuje. Taj je zapis ono što sljedećoj osobi omogućuje da odgovori na stvarno pitanje: koje ispade ova mreža preživljava i tko održava stanje koje ostaje zajedničko?
Riječ decentralizirano zaslužuje svoje mjesto kada imenuje te ispade. Bez tog popisa opisuje dijagram, a ne sustav.