Adres IP wyjścia VPN nie jest dowodem tunelu: co widzą serwery

Ktoś prosi o usługę dostępną tylko dla użytkowników VPN, a oczywistym wdrożeniem jest dopuszczenie listy adresów wyjściowych. Lista robi coś realnego: ogranicza, kto może się połączyć. Nie dowodzi, że użyto tunelu, ponieważ adres należy do tego, kto obsługuje wyjście, a ten operator może przekazywać ruch kogokolwiek. Różnica między tymi stwierdzeniami to cały problem projektowy.

Serwer widzi jeden adres na połączenie

Połączenie przychodzi z adresem źródłowym i portem docelowym, i to wszystko, co zgłasza warstwa sieciowa. Gdy klient używa tunelu, pakiety docierające do twojego nasłuchu pochodzą z wyjścia lub z tłumaczenia przed nim. Adres samego klienta, zwykle prywatny, nigdy się nie pojawia. Dlatego reguła zapory napisana dla zakresu sieci lokalnej klienta nie robi nic.

Wszystko po tym adresie źródłowym to dane aplikacji, a aplikacja może im ufać tylko w takim zakresie, w jakim je uwierzytelnia.

Sprawdź, jak wygląda twoje wyjście

Przyjrzyj się ścieżce z obu końców, zanim napiszesz regułę. Widok klienta na jego wyjście i widok serwera na połączenie to dwa fakty, które się liczą.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

Pierwsze polecenie zgłasza publiczny adres, pod którym pojawia się klient, i to jest wartość, którą musi zawierać każda lista dozwolonych. Drugie pokazuje ustanowione połączenia na serwerze wraz z adresami ich partnerów, i to właśnie z tym reguła będzie naprawdę pasować. Jeśli oba nie zgadzają się z twoim modelem mentalnym, popraw model, zanim zmodyfikujesz politykę. Zapora bazy danych w chmurze, lista dozwolonych aplikacji i równoważenie obciążenia mogą każdy widzieć inną warstwę tłumaczenia.

Wymienić można tylko jeden z dwóch zbiorów wyjść

Jeden przypadek da się sprawdzić w momencie żądania, a drugi nie, co daje bardzo różne gwarancje.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

Opublikowaną listę wyjść Tor można pobrać i porównać, zależnie od wieku listy i własnej polityki każdego wyjścia, więc reguła odmowy wobec znanych wyjść jest wykonalna i poddająca się przeglądowi. Dla komercyjnych VPN nie ma równoważnego rejestru. Adresy się zmieniają, wielu dostawców nic nie publikuje, a tunel może działać na wynajętym adresie chmurowym, który nigdy nie należał do VPN. Lista, którą zestawiasz, jest migawką zaobserwowanych adresów, a rozszerzenie jej na zakresy hostingu dodaje niepowiązane obciążenia bez dodawania dowodów.

Używaj adresów jako danych wejściowych polityki, nie jako dowodu

Zdecyduj, czemu służy reguła. Ograniczenie sieciowe powinno pozostać wąskie, zapisywać zaobserwowany adres z datą i powodem oraz dawać legalnym użytkownikom ścieżkę odzyskania, gdy ich wyjście się zmieni. Kontrola dostępu wymaga uwierzytelnionego konta lub podpisanego tokenu, ponieważ tylko one wiążą żądanie z tożsamością. Ocena ryzyka może używać adresu jako jednego zawodnego sygnału, akceptując jego fałszywe alarmy i martwe punkty. Zapisanie reguły jako decyzji produktowej jest uczciwe; zapisanie jej jako weryfikacji istnienia tunelu nie jest.

Żądanie lustrzane, czyli odzyskanie prawdziwego adresu użytkownika za VPN, zawodzi z tego samego powodu: jedno połączenie niesie jeden adres, a zmiana między sesjami jest zgodna z kilkoma wyjaśnieniami. Traktuj wcześniejszą wartość jako historię, nie jako prawdę.