Co twój dostawca nadal widzi, gdy torrentujesz przez VPN
Tunel ukrywa cele, a nie sam fakt tunelu. Sprawdź powiązanie klienta, resolver oraz to, czego i tak dowiadują się peery i prywatne trackery.
Przejdź przez pytania po kolei: co może zaobserwować sieć dostępowa, co opuszcza tunel bez niej, co ujawnia wyszukiwanie nazw i czego i tak dowiadują się peery oraz trackery. Każda odpowiedź jest niezależna od pozostałych, a VPN w pełni rozwiązuje tylko pierwszą. Czwarta to miejsce, w którym większość oczekiwań po cichu zawodzi, bo żaden tunel nie usuwa nazwy konta.
Zacznij od decyzji, który obserwator cię niepokoi, bo odpowiedź zmienia się wraz z obserwatorem.
Jedno połączenie zastępuje wiele
Gdy klient naprawdę jest w tunelu, sieć dostępowa widzi jedno stałe szyfrowane połączenie z jednym adresem VPN. Wolumen, czas i fakt korzystania z VPN pozostają widoczne; nazwy hostów trackerów, adresy peerów i nazwy plików nie. To realna poprawa, i węższa, niż sugeruje marketing. Operator tunelu siedzi pośrodku i widzi więcej niż sieć dostępowa.
Deklaracja braku logów opisuje politykę przechowywania, a nie techniczną widoczność. To różne twierdzenia i tylko pierwsze jest czymś, co dostawca może obiecać.
Wyciek bierze się z powiązania, a nie z tunelu
BitTorrent tworzy strumień krótkotrwałych połączeń TCP i UDP do peerów, trackerów, węzłów DHT i lokalnego wykrywania. Powiąż klienta z fizycznym adapterem albo uruchom go ponownie po upadku tunelu, a powstały ruch jest dokładnie tym, po co tunel istniał. Reguły zapory to słabsza kontrola, niż wyglądają: reguła pasująca tylko do trasy domyślnej, tylko do IPv4 albo tylko do nowych połączeń zostawia ścieżki otwarte. Powiązanie klienta z interfejsem tunelu i weryfikacja tego powiązania to mocniejszy wzorzec.
Sprawdź, celowo zatrzymując tunel i obserwując, czy transfery się zatrzymują. Jeśli trwają, klient nigdy nie był w środku. Powtórz po restarcie klienta i po wybudzeniu laptopa, bo wtedy powiązania zwykle giną.
DNS nazywa witrynę, nie dotykając transferu
Jeśli wyszukiwanie nazw nadal trafia do lokalnego resolvera, samo zapytanie ogłasza witrynę, podczas gdy transfer pozostaje szyfrowany. Przeniesienie rozwiązywania do tunelu lub jego szyfrowanie zamyka tę lukę. Żadne z nich nic nie robi dla klienta, którego pakiety wychodzą poza tunel. Sprawdź, który resolver jest używany i przez który interfejs wychodzi zapytanie; obie kontrole odpowiadają na różne pytania.
Nazwa rozwiązywana przez tunel i transfer respektujący powiązanie to odrębne właściwości, a każda z nich może zawieść samodzielnie.
Rój i tracker widzą różne rzeczy
Wymiana adresów jest częścią protokołu, więc peery zapisują to, co widzą. Połączenie z wyjścia daje im wyjście; połączenie bezpośrednie daje adres domowy. DHT i wymiana peerów rozprzestrzeniają tę obserwację dalej, a późniejsza sesja bez tunelu może powiązać ten sam port klienta i wersję. Tracker może wiedzieć jeszcze więcej: klucz dostępu w adresie URL ogłoszenia identyfikuje konto niezależnie od tego, z którego wyjścia przyszły pakiety.
Szyfrowanie znów obejmuje inną oś. HTTPS chroni żądanie od wyjścia dalej; zwykły HTTP wystawia linię żądania każdej sieci na drodze, i dlatego jeden protokół można kształtować, a drugiego nie.
Odpowiedz na cztery pytania dowodami, nie ikoną. Ikona mówi ci tylko, że tunel istnieje.