VPN Gate i własny serwer SoftEther to nie to samo

Zespół instaluje serwer SoftEther, eksportuje ustawienie połączenia, a później ktoś znajduje ten sam protokół w publicznym katalogu VPN Gate i pyta, czy firma prowadzi teraz publiczny przekaźnik. Zamieszanie jest zrozumiałe: klient wygląda identycznie, protokół jest identyczny, a oba pojawiają się w tym samym rodzaju listy połączeń. Różnica nie jest techniczna, jest operacyjna. Serwer, który wdrażasz, należy do tego, kto go wdrożył, a VPN Gate to osobny projekt wolontariacki, który publikuje własne punkty końcowe.

Ten sam klient, dwóch różnych operatorów

Trzy pytania oddzielają oba wdrożenia i na żadne z nich nie odpowiada oprogramowanie. Warto je zapisać, zanim ktoś porówna klientów.

Środkowy wiersz rozstrzyga większość sporów. Na własnym serwerze lista kont jest czymś, co kontrolujesz, więc członkostwo coś znaczy; w węźle wolontariackim każdy użytkownik katalogu jest potencjalnym równorzędnym na tym samym punkcie końcowym. Tego wiersza nie da się też wywnioskować z klienta, dlatego dwie osoby z identycznym oprogramowaniem mogą opisywać zupełnie różne sieci.

Przeczytaj, kto opublikował punkt końcowy

Zacznij od źródła ustawienia połączenia. Wpis w katalogu z wolontariacką nazwą hosta, zmiennym adresem i publiczną listą to inny obiekt niż konfiguracja wyeksportowana przez administratora z twoją własną nazwą hosta i certyfikatem. Jeśli punkt końcowy pojawia się na publicznej liście, traktuj go jako publiczny, bo dokładnie to oznacza lista. Nic w protokole nie zmienia odpowiedzi.

Wpis w katalogu nie jest też dostępem administracyjnym. Możliwość połączenia z węzłem nie mówi nic o jego interfejsie zarządzania, a próbowanie danych administracyjnych na wolontariackim hoście jest zarówno nieskuteczne, jak i niestosowne. Używaj metody połączenia oferowanej przez listę i niczego więcej.

Rejestrowanie idzie za operatorem, nie za protokołem

SoftEther jako oprogramowanie może rejestrować połączenia, a administrator serwera decyduje, co jest przechowywane i jak długo. VPN Gate publikuje własne strony o modelu wolontariackim i o rejestrowaniu przeciw nadużyciom, i te strony są jedynym dokładnym stwierdzeniem o tym projekcie. Czytanie ich to inny akt niż założenie, że jakakolwiek usługa oparta na SoftEther nic nie przechowuje, co jest twierdzeniem, którego oprogramowanie nie może poprzeć.

Dla własnego serwera równoważne stwierdzenie wynika z twojej konfiguracji i polityki przechowywania. Może to być więcej rejestrowania niż przechowuje publiczny węzeł, albo mniej, i w każdym razie to twoja odpowiedzialność. Kto mówi, że protokół gwarantuje anonimowość, opisuje nadzieję, a nie projekt.

Publiczne wyjście nie jest członkostwem w sieci prywatnej

Praktyczna porażka nadchodzi, gdy ktoś potrzebuje usługi wewnętrznej i sięga po darmowe publiczne wyjście zamiast po bramę firmową. Publiczny węzeł może zmienić adres, z którego wygląda, że pochodzi twój ruch. Nie może uczynić cię członkiem sieci, do której nigdy nie dostałeś dostępu, i żadne ustawienie klienta tego nie zmienia. Osiągalny zbiór jest definiowany po drugiej stronie, przez tego, kto prowadzi bramę.

Polityka bezpieczeństwa też tu należy. Ruch przez nieznany wolontariacki host podlega praktykom tego hosta, a decyzja o zaufaniu jest kategorycznie inna niż w przypadku ruchu przez bramę, którą twoja organizacja prowadzi i audytuje. Wybór darmowego wyjścia przenosi zaufanie, nie usuwa go.

Zdecyduj, co faktycznie wdrażasz

Trzy pytania to rozstrzygają. Kto będzie prowadził punkt końcowy? Kto może się z nim łączyć? Czyja polityka rejestrowania i przechowywania dotyczy ruchu? Jeśli odpowiedź na którekolwiek z nich brzmi „kto to znajdzie”, wdrożenie jest publiczne, cokolwiek mówi plik protokołu.

Zapisz odpowiedzi obok wdrożenia, wraz z operatorem, dozwolonymi użytkownikami i polityką przechowywania. Gdy następna osoba znajdzie ten sam protokół w publicznym katalogu, ta notatka będzie całym wyjaśnieniem i oszczędzi sporu o to, czy firma prowadzi przekaźnik.