VPN peer-to-peer wciąż ma centralne zależności

Peer-to-peer opisuje, jak podróżują pakiety aplikacji, i nic więcej. Partnerzy nadal musieli się odnaleźć, udowodnić, kim są, a czasami uciec się do przekaźnika, gdy nie można było zbudować bezpośredniej ścieżki. To trzy odrębne usługi, a wdrożenie może być peer-to-peer dla danych, będąc całkowicie scentralizowanym pod każdym innym względem. Porównywanie projektów oznacza porównywanie tych zadań, a nie strzałki na schemacie.

Schemat bez centralnej strzałki przekazywania może ukrywać urząd rejestracyjny, usługę wykrywania i przekaźnik, które są zależnościami operacyjnymi.

Bezpośrednia ścieżka, współdzielona płaszczyzna sterowania

Dwie maszyny wymieniające pakiety bezpośrednio mogą nadal zależeć od wspólnego urzędu, który wydał ich certyfikaty, oraz od usługi, która każdej z nich powiedziała, gdzie jest druga. Żadna z tych ról nie przekazuje ruchu aplikacji, dlatego rysunek topologii je pomija. Gdy ten urząd lub ta usługa jest niedostępna, istniejące sesje mogą trwać, podczas gdy nowy partner nie może dołączyć. Różnica między rozpoczęciem sesji a jej kontynuacją to pierwsze pytanie, jakie należy zadać każdemu projektowi.

Narysuj każde zadanie osobno, nawet gdy wszystkie wykonuje jeden host. W przeciwnym razie rysunek pokazuje zdecentralizowaną płaszczyznę danych i ukrywa operacyjną rzeczywistość, że każdy nowy partner potrzebuje tych samych dwóch usług.

Wykrywanie, zaufanie i przekaźnik to trzy zadania

Projekt Nebula jest użytecznym przykładem, ponieważ jego dokumentacja trzyma je osobno. Hosty noszą certyfikaty tożsamości, latarnie odpowiadają na pytanie gdzie i pomagają w przechodzeniu NAT, a przekaźniki przekazują ruch, gdy nie można ustanowić bezpośredniej ścieżki. Rola przekaźnika jest celowo odrębna od roli latarni, więc osiągalna latarnia nie obiecuje, że dana para może rozmawiać. Inne produkty rysują granice gdzie indziej, dlatego to przykład, a nie szablon.

Dla proponowanego wdrożenia zapisz obsługiwaną ścieżkę awaryjną dla pary, która nie może połączyć się bezpośrednio. Nieudane przebicie dziury to jeden punkt danych o jednej sieci, a nie dowód, że dwa hosty za NAT nigdy nie mogą się spotkać; przeciwne twierdzenie, że bezpośrednie połączenie działa przy dowolnych zasadach, jest równie nieuzasadnione.

Na czym zawodzi każda zależność

Oceń cztery przypadki osobno, gdy testowana zależność jest niedostępna: istniejący ruch między partnerami, zupełnie nowe połączenie partnerskie, partner, którego punkt końcowy się zmienił, oraz dostęp, który właśnie odebrano. Każdy opiera się na innych usługach i zawodzi inaczej. Istniejące sesje mogą przetrwać awarię wykrywania, podczas gdy odebrany klucz jest nadal odrzucany, a nowy partner może zawieść z powodów, które nie mają nic wspólnego z przekazywaniem. Testuj je pojedynczo, zamiast wnioskować z jednego przypadku.

Połączenie, które przetrwa jedną awarię, nie dowodzi nieograniczonej niezależności. Dowodzi, że awaria, którą spowodowałeś, nie była tą, która przerywa tę ścieżkę, co nadal jest użyteczną informacją, pod warunkiem że zapisałeś, co spowodowałeś.

Zapytaj, którą awarię przetrwasz

Wymagania, które brzmią podobnie, prowadzą do różnych projektów. Unikanie jednego wąskiego gardła przekazywania to nie to samo co unikanie płaszczyzny sterowania hostowanej przez dostawcę, a żadne z nich nie odpowiada dalszemu działaniu, gdy koordynator jest niedostępny. Nazwij, który z tych trzech wymogów wdrożenie musi spełniać, a następnie sprawdź mapowanie. Projekt, który spełnia pierwszy i zawodzi w drugim, jest powszechny i nie jest nieuczciwy, dopóki nikt nie nazywa go w pełni zdecentralizowanym.

Zapisz, kto obsługuje wykrywanie, zaufanie i przekaźniki oraz jak każdy z nich jest zastępowany. Ten zapis pozwala następnej osobie odpowiedzieć na prawdziwe pytanie: które awarie przetrwa ta sieć i kto utrzymuje stan, który pozostaje współdzielony?

Słowo zdecentralizowany zasługuje na swoje miejsce, gdy nazywa te awarie. Bez tej listy opisuje schemat, a nie system.