Testowanie twierdzenia o prywatności VPN: zachowaj dowody, które się utrzymają
Zapisz twierdzenie, obserwatora i konfigurację, zanim spojrzysz na wynik. Test routingu pokazuje wyjście; nigdy nie pokazuje, co operator zatrzymuje.
Test zaczyna się od zdania, które ktoś chce mieć prawdziwe, a dowody albo wspierają jego wąską wersję, albo nic. Sprawdzenie adresu publicznego pokazuje, którego wyjścia użyło jedno żądanie. Nie pokazuje, co zachowuje dostawca, kto może to przeczytać ani co dzieje się z sesją, która nigdy się nie kończy. Gdy wykonujesz test jako udokumentowaną procedurę, nie twierdzisz więcej, niż pomiar może unieść.
Wybierz jedno obserwowalne twierdzenie
Zapisz twierdzenie jako jedno sprawdzalne zdanie, zanim otworzysz jakiekolwiek narzędzie: dla tego profilu, w tej sieci żądania do echa adresu publicznego wychodzą przez zadeklarowane wyjście dostawcy. To zdanie nazywa podmiot, warunek i obserwację, i właśnie to czyni je obalalnym. Twierdzenie, że VPN chroni prywatność, nie ma obserwowalnej formy, więc żaden pomiar nie może go rozstrzygnąć. Zachowaj drugie zdanie na to, czego test nie obejmie, ponieważ przechowywanie, dostęp stron trzecich i korelacja ruchu pozostają poza testem w przeglądarce.
Zapisz to drugie zdanie z góry, a nie po otrzymaniu wyniku. O wiele łatwiej być szczerym co do zakresu, dopóki wynik jest jeszcze nieznany, niż po tym, jak do zgłoszenia trafi uspokajający zrzut ekranu. Notatka o zakresie dodana później zwykle opisuje wynik, a nie pytanie.
Fakty konfiguracji potrzebne czytelnikowi do powtórzenia pomiaru
Konfiguracja jest tym, co czyni wynik odtwarzalnym, i właśnie ją ludzie pomijają, gdy odpowiedź wygląda dobrze. Ciągi wersji, nazwy profili, sieć dostępu i rodziny adresów należą do notatki, wraz z każdą regułą podziału tunelu, która mogłaby wyprowadzić ruch z tunelu. Nazwij też testowane zdarzenie, ponieważ działające połączenie, nieoczekiwane zerwanie, ręczne rozłączenie i przełączenie sieci stosują różne reguły. Test, który miesza te zdarzenia, dowodzi niewiele o którymkolwiek z nich.
Używaj ruchu nie wrażliwego w środowisku, w którym masz uprawnienia do testowania. Przechwytywanie niepowiązanych pakietów sprawia, że zapis wygląda technicznie, i dodaje ekspozycję bez dodawania dowodów. Skieruj przechwytywanie tylko na interfejs tunelu i ustaw limit rozmiaru pliku, aby długie uruchomienie nie zapełniło dysku. Zatrzymaj przechwytywanie, zanim cokolwiek zmienisz, aby plik odpowiadał zapisanej przez ciebie linii konfiguracji.
Powiedz, co zmierzono i co to znaczy
Zapisz, co narzędzie wydrukowało i co narzędzie mogło zobaczyć. Odpowiedź resolvera, wynik echa adresu i wyszukanie trasy odpowiadają na różne pytania, a etykieta lokalizacji na stronie internetowej jest wnioskiem o bazie danych, a nie faktem o wyjściu. Zapisz polecenie, które wytworzyło każdą linię, obok niej, ponieważ wartości bez jej polecenia nie da się odtworzyć. Trzymaj znacznik czasu w tej samej strefie czasowej co zgłoszenie zmiany, inaczej sekwencja stanie się nieczytelna tydzień później.
curl -s https://icanhazip.com
curl -s https://ipinfo.io/ip; echo
resolvectl status --no-pager | head -15Dwie niezależne usługi echa, które się zgadzają, są silniejsze niż jedna, a rozbieżność sama w sobie jest ustaleniem wartym zapisania. Wyjście resolvera pokazuje, czy DNS podążał za tunelem, czy nadal korzystał z sieci lokalnej, co jest twierdzeniem odrębnym od adresu wyjścia. Zapisz surowe wyjście ze znacznikiem czasu i zachowaj wyniki przeciwne zamiast najbardziej uspokajającego zrzutu ekranu. Gdy zmiana przesuwa wynik, stosuj jedną zmienną naraz, ponieważ zmiana serwera i klienta jednocześnie uniemożliwia powiedzenie, która miała znaczenie.
Co należy do zapisu, a co trzeba usunąć
Zachowaj metodę, niewrażliwe na ujawnienie wyjście i ograniczenia, a następnie usuń resztę. Profile zawierające poświadczenia, prywatne nazwy hostów i identyfikatory kont nie muszą podróżować z dowodami, a zapis testu, który je ujawnia, uszkodził to, co miał wykazać. Pięć pól poniżej to najkrótsza forma, która jeszcze przetrwa przekazanie.
| Field | What to write |
|---|---|
| Claim | One testable sentence naming the profile, the network and the observation |
| Observer and scope | Who could see the traffic or the record, and under which conditions |
| Setup | Client and server versions, profile name, access network, address families, split-tunnel rules, event under test |
| Raw result | Tool output with a timestamp, exit addresses from both echo services, resolver answer |
| What it does not support | Retention, third-party access, correlation, untested address families |
Dołącz deklarację polityki, z którą porównujesz, wraz z jej datą i zakresem. RFC 6973 ujmuje analizę prywatności wokół nazwanych obserwatorów i określonego zakresu, a ta rama pasuje do zapisu testu: kto mógł obserwować co, w jakich warunkach i które części pozostały niezbadane.
Zakończ jednym akapitem, który stwierdza, co dowody wspierają, a czego nie. Ten akapit jest wynikiem, a wszystko powyżej istnieje po to, by uczynić go uczciwym. Jeśli nie da się go napisać bez łagodzenia każdej klauzuli, test zmierzył mniej, niż twierdzi zgłoszenie.