Што ўсё яшчэ бачыць ваш інтэрнэт-правайдар пры торэнтах праз VPN
Тунэль хавае прызначэнні, а не сам факт тунэля. Праверце прывязку кліента, рэзалютар і тое, што ўсё роўна даведаюцца піры і прыватныя трэкеры.
Прайдзіце пытанні па парадку: што можа назіраць сетка доступу, што выходзіць з тунэля без яе, што выяўляе пошук імёнаў і што ўсё роўна даведаюцца піры і трэкеры. Кожны адказ не залежыць ад іншых, і VPN цалкам вырашае толькі першае. Чацвёртае — гэта месца, дзе большасць чаканняў ціха правальваецца, бо ніякі тунэль не прыбірае імя ўліковага запісу.
Пачніце з рашэння, які назіральнік вас турбуе, бо адказ змяняецца разам з назіральнікам.
Адно злучэнне замяняе многія
Калі кліент сапраўды знаходзіцца ўнутры тунэля, сетка доступу бачыць адно пастаяннае шыфраванае злучэнне з адным адрасам VPN. Аб'ём, час і сам факт выкарыстання VPN застаюцца бачнымі; імёны хастоў трэкераў, адрасы піраў і назвы файлаў — не. Гэта рэальнае паляпшэнне, і вужэйшае, чым мяркуе маркетынг. Аператар тунэля сядзіць пасярэдзіне і бачыць больш, чым сетка доступу.
Заява аб адсутнасці журналаў апісвае палітыку захоўвання, а не тэхнічную бачнасць. Гэта розныя зацверджанні, і толькі першае правайдар можа абяцаць.
Уцечка ідзе ад прывязкі, а не ад тунэля
BitTorrent стварае паток кароткачасовых злучэнняў TCP і UDP да піраў, трэкераў, вузлоў DHT і лакальнага выяўлення. Прывязаць кліент да фізічнага адаптара або перазапусціць яго пасля падзення тунэля — і атрыманы трафік будзе менавіта тым, што тунэль існаваў, каб хаваць. Правілы фаервала — больш слабы кантроль, чым здаецца: правіла, якое адпавядае толькі маршруту па змаўчанні, толькі IPv4 або толькі новым злучэнням, пакідае шляхі адкрытымі. Прывязаць кліент да інтэрфейсу тунэля і праверыць гэтую прывязку — больш моцны шаблон.
Праверце, наўмысна спыніўшы тунэль і назіраючы, ці спыняцца перадачы. Калі яны працягваюцца, кліент ніколі не быў унутры. Паўтарыце пасля перазапуску кліента і пасля абуджэння ноўтбука, бо менавіта тады прывязкі звычайна губляюцца.
DNS называе сайт, не кранаючы перадачу
Калі пошук імёнаў па-ранейшаму ідзе да лакальнага рэзалютара, сам запыт абвяшчае сайт, пакуль перадача застаецца шыфраванай. Перанос развязання ў тунэль або яго шыфраванне закрывае гэтую прарэху. Ні тое, ні другое не дапамагае кліенту, чые пакеты выходзяць па-за тунэль. Праверце, які рэзалютар выкарыстоўваецца і з якога інтэрфейсу выходзіць запыт; дзве праверкі адказваюць на розныя пытанні.
Імя, якое развязваецца праз тунэль, і перадача, якая паважае прывязку, — асобныя ўласцівасці, і кожная можа збанкрутаваць сама па сабе.
Рой і трэкер бачаць рознае
Абмен адрасамі — частка пратакола, таму піры запісваюць усё, што бачаць. Падключэнне з выхаду дае ім выхад; прамое падключэнне дае хатні адрас. DHT і абмен пірамі распаўсюджваюць гэта назіранне далей, і пазнейшая сесія без тунэля можа звязаць той жа порт кліента і версію. Трэкер можа ведаць яшчэ больш: ключ доступу ў URL абвяшчэння ідэнтыфікуе ўліковы запіс незалежна ад таго, з якога выхаду прыйшлі пакеты.
Шыфраванне зноў ахоплівае іншую вось. HTTPS абараняе запыт ад выхаду і далей; звычайны HTTP паказвае радок запыту кожнай сетцы на шляху, і таму адзін пратакол можна фармаваць, а другі — не.
Адказвайце на чатыры пытанні доказамі, а не значком. Значок толькі кажа, што тунэль існуе.