Nazwy hostów i flagi krajów wyglądają jak fakty o serwerze, a żadne z nich nim nie jest. Nazwa wskazuje adresy, które mogą się zmieniać, a słowa w niej wybrał ten, kto ją zarejestrował. Protokół, miejsce wyjścia i zachowanie przy logowaniu potrzebują każde własnego dowodu. Zacznij od tego, na co nazwa faktycznie się rozwiązuje, a potem zdecyduj, co nadal pozostaje nieznane.

Nazwa się rozwiązuje i nic więcej nie jest ustalone

Nazwa hosta to wskaźnik w DNS, a rekordy za nią mogą się różnić w zależności od resolvera, od pory dnia i od rodziny adresów preferowanej przez klienta. Dwie osoby czytające ten sam wpis katalogowy mogą całkiem legalnie trafić na różne maszyny. Nazwa mówi, o co zapytać, a nie co odpowie.

Wyniki wyszukiwania też zmieniają się bez zapowiedzi, co ma znaczenie, gdy profil przypina adres zamiast nazwy. Profil z wpisanym na stałe starym adresem nadal zawodzi po przeniesieniu usługi przez operatora, a awaria wygląda jak zablokowany port. Trzymaj rozwiązane adresy obok profilu, żeby późniejsze porównanie miało punkt odniesienia. Nic z tego nie mówi, kto prowadzi drugi koniec.

dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1

Transport i tożsamość to osobne pytania

Otwarta strona internetowa pod nazwą hosta testuje jeden nasłuch na jednym porcie. OpenVPN, IPsec i SSTP nasłuchują gdzie indziej, na własnych portach i protokołach, więc osiągalny serwer internetowy nic o nich nie mówi.

Wpis katalogowy i profil muszą się zgadzać co do transportu, portu i danych logowania. Tożsamość jest weryfikowana łańcuchem certyfikatów albo odciskiem klucza partnera, z którym skonfigurowano klienta, a nie pisownią nazwy hosta. Nazwa zawierająca znane słowo projektu dowodzi tylko, że ktoś ją zarejestrował. Przeczytaj certyfikat przedstawiany przez usługę i porównaj wystawcę oraz podmiot z tym, czego oczekuje profil.

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

Słowa krajów nie są audytem lokalizacji

Etykieta jp lub de w katalogu to rejestracja, a bazy geolokalizacji IP dość często się nie zgadzają, by żadnej nie należało traktować jako prawdy absolutnej. Wspólny hosting, anycast i zwykła błędna konfiguracja wszystkie odsuwają obserwowane położenie od etykiety.

Praktyczny test to własna ścieżka aplikacji: który adres osiąga i co pokazuje sprawdzenie adresu wyjścia od wewnątrz sesji. Zaobserwowany adres wyjścia jest właściwością trasy w danej chwili, a nie gwarancją przypisaną do nazwy. Katalogi ochotników dodają kolejną warstwę, ponieważ osoba, która zarejestrowała wpis, nie musi być osobą, która obsługuje maszynę. Zapisz, co zmierzyłeś i kiedy, a nie co obiecywał wpis.

Sprawdź oferowaną usługę, potem operatora

Gdy transport i tożsamość są ustalone, pozostaje pytanie o zachowanie operatora, a to wymaga dowodów dokumentowych, a nie wnioskowania. Polityka prywatności, opublikowany kontakt i komunikat o przejrzystości są dowodami intencji; żaden z nich nie dowodzi praktyki, a brak wszystkich trzech też jest informacją.

W przypadku węzła publicznego lub prowadzonego przez ochotników przyjmij, że wyjście jest współdzielone, a ten, kto je prowadzi, może widzieć, co przez nie przechodzi. To założenie, a nie nazwa hosta, powinno decydować, co wysyłasz przez tunel.

curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'

Zachowaj nazwę do tego, w czym jest dobra: znajdowania punktu końcowego i łączenia się z nim. Wszystko poza tym trzeba sprawdzić osobno, w dniu, w którym to ma znaczenie.

Powiązane artykuły