Jak zapisywać i weryfikować używany adres wyjściowy VPN
Aplikacje klienckie pokazują nazwę lokalizacji, a nie adres, z którego wyszły Twoje dane. Przechwyć adres IP wyjścia przy połączeniu i porównaj go z bezpośrednim punktem odniesienia.
Zapytaj klienta VPN na komputer, z jakich serwerów korzystałeś, a uczciwa odpowiedź to zwykle nazwa lokalizacji. Ta nazwa to punkt wejścia, który wybrałeś, a adres, z którego wyszły Twoje dane, może należeć do zupełnie innej maszyny. Nic w aplikacji nie jest zaprojektowane do przechowywania drugiego numeru, więc zapis trzeba zbudować w momencie użycia. Istnieją dwa podejścia i tylko jedno z nich przetrwa kontakt ze sprawą wsparcia.
Dwa zapisy, z których istnieje tylko jeden
Widok samego klienta to w najlepszym razie lista wybranych lokalizacji ze znacznikami czasu. To decyzja projektowa, a nie przeoczenie: adresy są szczegółem operacyjnym, rotują między przypisaniami, a ujawnienie mapowania utrudnia zarówno wsparcie, jak i obsługę nadużyć. Dostawcy stawiają instancje chmurowe przed swoimi sieciami właśnie po to, by punkt końcowy mógł się przenieść bez informowania nikogo. To, co pokazuje aplikacja, to Twój wybór, a nie trasa, którą poszły dane.
Zapis, który możesz zbudować, to lokalny plik z jednym adresem publicznym i jednym znacznikiem czasu UTC w każdej linii. Jest mniejszy, brzydszy i znacznie użyteczniejszy, bo opisuje dokładnie to, co może zobaczyć także zewnętrzny obserwator.
Wariant A: przechwyć adres wyjścia samodzielnie
Usługa echa zwraca adres źródłowy, z którego przyszło żądanie, a to z definicji adres wyjścia. Uruchom przechwytywanie po tym, jak tunel zgłosi połączenie, bo klient, który mówi „połączono” zanim trasy i DNS się ustabilizują, zapisze adres sprzed tunelu i zatruje log już od pierwszej linii.
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"Dwa szczegóły czynią ten fragment użytecznym, a nie ozdobnym. Znacznik czasu i adres dzielą jedną linię, więc późniejsze przetwarzanie nie musi łączyć rekordów, a umask 077 utrzymuje plik prywatnym od chwili utworzenia. Uruchamiaj go raz na połączenie, a nie raz na rozruch, i trzymaj jeden plik na urządzenie.
Log notuje, kiedy użyłeś tunelu i z jakiej sieci się pojawiłeś, co jest bliższe historii przeglądania niż licznikowi. Wybierz okres przechowywania, którego potrafisz bronić, trzymaj plik poza współdzielonymi folderami synchronizacji i usuwaj go świadomie.
Wariant B: poproś dostawcę o historię
Niektórzy dostawcy prowadzą logi połączeń i odpowiedzą na pytanie wsparcia znacznikiem czasu i nazwą serwera. Ten zapis opisuje ich infrastrukturę, a nie Twój ruch, i jest wart tylko tyle, ile warte są ich okno przechowywania i chęć zajrzenia. Opisuje też sesję, a nie żądanie. Okno jest zwykle krótkie i mierzy się je od strony dostawcy tunelu.
Dostawcy, którzy reklamują brak logów, nie mogą tego wytworzyć na żądanie, a lista ostatnich lokalizacji po stronie klienta to nie to samo. Proszenie dostawcy bez logów o adres wyjścia zwykle kończy się wyjaśnieniem, dlaczego tych danych nie ma.
Co każdy zapis może udowodnić w sprawie wsparcia
Oba zapisy odpowiadają na różne pytania i to w tabeli porównanie przestaje być akademickie.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
Tylko pierwsza kolumna jest pod Twoją kontrolą. Zapis dostawcy może potwierdzić, że konto było połączone w danym momencie, ale nie potwierdzi, które żądania korzystały z tunelu, i nie wskaże adresu, który dostawca traktuje jako szczegół operacyjny. Żaden z zapisów nie identyfikuje osoby, bo współdzielony adres wyjścia może nieść wielu klientów w tej samej minucie.
Porównaj oba z punktem odniesienia, zanim zaufasz któremukolwiek
Sam adres niczego nie dowodzi. Przechwyć adres bezpośredni przed połączeniem, adres tunelowany po nim, i porównaj je. Identyczne wartości oznaczają, że tunel nie przenosi tego żądania, czy to z powodu tunelu dzielonego, nadrzędnego proxy, czy klienta, który przeszedł na ścieżkę bezpośrednią.
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1Powtórz porównanie dla DNS i dla IPv6, bo echo adresu dowodzi ścieżki jednego żądania HTTP i niczego o tym, który resolver odpowiedział. Urządzenie, które przecieka w jednym z tych przypadków, może wyglądać całkiem zdrowo w drugim.