Przekierowany port VPN: co mogą zobaczyć odwiedzający i dostawca
Mapowanie przychodzące daje usłudze publiczną tożsamość, a nie Twoje imię. Oddziel to, co odwiedzający może powiązać, co wie dostawca i jak długo to trwa.
Przekierowanie portu daje obcym drogę do usługi przez publiczny adres dostawcy. Ta jedna zmiana wpływa jednocześnie na ekspozycję i rozpoznawalność, a żadna z nich nie publikuje nazwiska osoby prowadzącej usługę. Trzymanie obu osobno pozwala uniknąć przeciwnych błędów: traktowania 'przekierowania' jako anonimowości i traktowania go jako identyfikacji. Trzy pytania czysto je rozdzielają, a odpowiedzi pochodzą z różnych dowodów.
Trzy obiekty, trzy różne pytania
Trzymaj publiczny adres osobno od aplikacji, która odpowiada za nim, a oba osobno od osoby lub organizacji, która tym zarządza. Każde ma własną publiczność i własne dowody. Mieszanie ich daje wnioski, które brzmią porządnie i są błędne.
Przejdź przez nie w tej kolejności. Pierwsze to pytanie o osiągalność, drugie o tożsamość aplikacji, a trzecie o przypisanie, które pierwsze dwa naświetlają tylko częściowo. Gdy ktoś pyta, czy przekierowanie portu jest prywatne, zapytaj, które z trzech ma na myśli. Odpowiedzi naprawdę się różnią, a strona polityki zwykle omawia tylko jedną z nich.
Co odwiedzający może powiązać między punktami końcowymi
Odwiedzający łączy się z punktem końcowym i widzi to, co aplikacja legalnie prezentuje: 'nazwę hosta', nazwę certyfikatu, stronę logowania, opublikowaną treść. Te szczegóły identyfikują usługę nawet wtedy, gdy jej zwykły adres dostępu jest ukryty za tunelem. Dwa punkty końcowe prezentujące tę samą nazwaną witrynę dają obserwatorom podstawę do powiązania ich. Nic w tym zachowaniu nie jest wyciekiem, ponieważ aplikacja została zaprojektowana tak, by była widoczna.
Zgodność certyfikatów, przekierowań i treści stron między dwoma punktami końcowymi to silny sygnał, że należą do jednej usługi. Pozostaje to stwierdzeniem o usłudze, a nie o człowieku, dopóki inny zapis nie połączy obu.
Wytyczne IETF dotyczące prywatności opisują, jak trwałe identyfikatory pozwalają korelować interakcje w czasie. Korelacja nie jest przypisaniem, ponieważ jedną usługą może zarządzać kilka osób, a adres może przechodzić między niepowiązanymi abonentami. Właśnie ta różnica nie pozwala, by ustalenie korelacji stało się oskarżeniem.
Co musi wiedzieć dostawca przekierowania
Aby dostarczyć połączenie przychodzące, system dostawcy musi utrzymywać aktywną relację między publicznym punktem wejścia a celem wewnętrznym. Ten fakt operacyjny różni się od tego, co widzi odwiedzający, i znów różni się od tego, co dostawca decyduje się zachować. Trzymaj oba pytania osobno, czytając stronę polityki, ponieważ jedno jest nieuniknione, a drugie jest decyzją. Stwierdzenie, że nie przechowuje się historii przeglądania, nic nie mówi o historii mapowań.
Czy historyczne mapowania, powiązania konta lub zapisy połączeń pozostają, to pytanie o rzeczywistą politykę i implementację dostawcy. Przekierowanie nie dowodzi, że każda kategoria jest rejestrowana. Zapytaj konkretnie, które pola przetrwają po wycofaniu mapowania i jak długo.
Osiągalność przychodząca jest też oddzielona od routingu wychodzącego klienta, DNS i zachowania przy awarii. Dodanie mapowania nie opisuje, jak wychodzi reszta ruchu klienta.
Jak długo trwa mapowanie, zmienia ekspozycję
Mapowanie może trwać przez sesję, przez rezerwację lub zgodnie z polityką dostawcy, która je zmienia. Nie należy zakładać ani stałego przypisania, ani ciągłej rotacji; przeczytaj udokumentowane zachowanie produktu i zapisz to, co obserwujesz. Dwie obserwacje w odstępie tygodnia mówią o 'rotacji' więcej niż jakiekolwiek zdanie marketingowe na stronie produktu. Zapisz zaobserwowany interwał obok punktu końcowego w notatkach, ponieważ interwał jest częścią ekspozycji.
Czas życia zmienia to, jaka korelacja jest możliwa. Stabilny punkt końcowy zaprasza do długoterminowego śledzenia jednej usługi, a rotujący sprawia, że każdą obserwację trudniej połączyć z poprzednią. Żadna z tych właściwości nie jest gwarancją co do zapisów dostawcy i żadna nie zastępuje decyzji o tym, co publikuje sama usługa.
Publikuj świadomie, a potem zamknij oboje drzwi
Potwierdź, że dostawca zezwala na potrzebny protokół, że odbiorca docelowy to ten, którego miałeś na myśli, i że mechanizmy kontroli hosta i aplikacji nadal ograniczają dostęp. Przed publikacją sprawdź, co usługa pokaże obcemu. Te dwie komendy pokazują certyfikat i nagłówki, które otrzymuje odwiedzający.
openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/
Opublikowanie czegoś nie usprawiedliwia ujawnienia jego stron administracyjnych ani porzucenia logowania aplikacji, a tłumaczenie nie dostarcza TLS usłudze, która nigdy go nie miała. Utrzymuj zaszyfrowany protokół i jego kontrole tożsamości serwera na miejscu, niezależnie od tego, jak przychodzi ruch. Następnie sprawdź nagłówki odpowiedzi, ponieważ 'baner' lub strona debugowania może powiedzieć obcemu więcej, niż usługa zamierza. To, co zwracają dwie komendy, to ten sam widok, który otrzymuje obserwator.
Wycofanie usługi oznacza dwa zamknięcia, a nie jedno: wycofaj mapowanie przez jego właściciela, a następnie potraktuj odbiorcę i uprawnienie jako osobne pozycje. Zapisany w zakładkach punkt końcowy, który przestaje odpowiadać, nie unieważnia poświadczeń i nie odzyskuje już dostarczonych informacji.