VPN nie ujawnił twojego starego IP: zrobiła to zapamiętana wartość

Widok twojego starego publicznego adresu w raporcie usługi po włączeniu VPN sam w sobie nie jest dowodem wycieku. Aktywne połączenie może korzystać z wyjścia tunelu, podczas gdy aplikacja wysyła wartość, której nauczyła się przed powstaniem tunelu. To dwa różne dowody i tylko jeden opisuje bieżący pakiet. Drugi to wartość, która przetrwała ponowne połączenie, bo nic na ścieżce sieci jej nie posiada.

Dwa wyjaśnienia za jednym adresem

Sekwencja, którą ludzie sobie wyobrażają, to pakiet opuszczający interfejs fizyczny, gdy VPN jest rzekomo aktywny. Sekwencja, która często wyjaśnia raport, jest krótsza i nudniejsza: aplikacja poznała adres wcześniej i nadal go trzyma. Ułożenie zdarzeń w kolejności rozdziela te dwa.

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

Nic w tej kolejności nie wymaga aktywnego połączenia z pierwszego adresu. Zapamiętana wartość jedzie wewnątrz wiadomości, a nagłówek niesie to wyjście, które wybrała bieżąca trasa. Usługa, która rejestruje oba pola, pokaże je obok siebie i będzie wyglądać sprzecznie.

To możliwe wyjaśnienie, nie oskarżenie konkretnego klienta. Reputacja nie jest dowodem: kod, który możesz przeczytać, marka, której ufasz, albo inne wyjście nie mówią nic o tym, co jeden program zachował lub wysłał.

Pamięć aplikacji przeżywa ponowne połączenie

Połączenie z VPN zmienia trasę, którą obiera nowe połączenie. Pozostawia stan aplikacji w spokoju i nie może cofnąć informacji, które zdalna usługa już zapisała. Program może przesłać identyfikator konta, zapisaną lokalizację, nazwę urządzenia lub inną wcześniej uzyskaną wartość, a szyfrowanie chroni ten ładunek w drodze, nie usuwając z niego niczego. Ponowne połączenie to zdarzenie sieciowe; zachowana wartość to zdarzenie aplikacji.

Różnica ma znaczenie, bo oba żyją w różnych miejscach. Stan aplikacji należy do programu i przeżywa restarty, a trasa należy do systemu operacyjnego i jest odbudowywana przy każdym połączeniu. Wyczyszczenie jednego nie wpływa na drugie.

Usługa może też trzymać wartość, którą jej przekazałeś miesiące temu, i wtedy żadna lokalna zmiana jej nie usunie. To przechowywanie i znajduje się całkowicie poza tunelem.

Najpierw przeczytaj nagłówek źródłowy, potem ładunek

Zacznij od ustalenia, gdzie adres się pojawił. Dziennik połączeń serwera opisuje aktywne źródło, a pole wiadomości, profil konta lub lokalny ekran diagnostyczny mogą opisywać wartość wysłaną lub zapisaną znacznie wcześniej. Te obserwacje odpowiadają na różne pytania.

Porównaj też czasy. Jeśli stary adres pojawia się w polu poprzedzającym połączenie VPN, wyjaśnienie ładunkiem jest silniejsze. Jeśli serwer rejestruje bezpośrednie połączenie ze starego adresu, gdy tunel jest aktywny, to pytanie o routing i wymaga innego śledztwa. Posortowanie typów obserwacji najpierw nie pozwala rozciągnąć jednego adresu w dowód trzech zdarzeń.

Trzymaj je osobno w notatkach: źródło połączenia, pole wiadomości, ekran konta, diagnostyka lokalna. Jeden adres zapisany w czterech miejscach to nadal jeden adres.

Przechowywanie to inny etap niż transport

Wytyczne dotyczące prywatności w RFC 6973 traktują zbieranie, użycie, ujawnianie i przechowywanie jako odrębne etapy i ostrzegają, że ponownie użyte identyfikatory ułatwiają korelację. Nowa ścieżka sieci zmienia etap transportu i nic więcej. Zapisy, które odbiorca już ma, pozostają nietknięte, podobnie jak każdy profil, który zapisał wartość przy wejściu. Dlatego ponowne połączenie może wydawać się porażką, gdy transport działa poprawnie.

Żaden filtr pakietów nie może usunąć wartości z zapisów odbiorcy, a ponowne połączenie nie wyczyści zapisanej historii każdego programu. To problemy właściciela danych, nie tunelu, i wymagają innego rodzaju rozwiązania. Zapytaj usługę, co i jak długo przechowuje, zanim poprosisz sieć o ukrycie tego.

Co sprawdzić, zanim obwinisz tunel

Przejrzyj udokumentowane zbieranie danych i kontrolę konta w aplikacji i zdecyduj, które pola może wysyłać, jak długo usługa je przechowuje i czy konto może je wyczyścić lub poprawić. Następnie wykonaj test, który rozdziela wyjaśnienia: nowe konto lub czysty profil aplikacji. Jeśli stara wartość znika, brały w tym udział przechowywanie lub stan z pamięci podręcznej. Jeśli przetrwa czysty profil, zbadaj rzeczywiste pole żądania, zanim uznasz, że VPN zawiódł.

Jeśli bezpośrednie połączenie naprawdę istnieje, potraktuj to jako ustalenie dotyczące ścieżki sieci. Zbadaj routing, tunel dzielony i politykę klienta na ich własnych warunkach i nie mieszaj tego wyniku z wartością ładunku, która po prostu przetrwała ponowne połączenie. Obie awarie wyglądają podobnie na zrzucie ekranu i zachowują się zupełnie inaczej w przechwyceniu.