Kion via provizanto ankoraŭ vidas, kiam vi torrentas tra VPN

Trairu la demandojn laŭ ordo: kion la alirreto povas observi, kio eliras la tunelon sen ĝi, kion malkaŝas la nomserĉo, kaj kion egaluloj kaj spuriloj tamen ekscias. Ĉiu respondo sendependas de la aliaj, kaj VPN plene traktas nur la unuan. La kvara estas kie plej multaj atendoj silente fiaskas, ĉar neniu tunelo forigas kontan nomon.

Komencu decidante, kiu observanto ĝenas vin, ĉar la respondo ŝanĝiĝas kun la observanto.

Unu konekto anstataŭas multajn

Kiam la kliento vere troviĝas ene de la tunelo, la alirreto vidas unu daŭran ĉifritan konekton al unu VPN-adreso. Volumo, tempo kaj la fakto, ke VPN estas uzata, restas videblaj; gastigantnomoj de spuriloj, adresoj de egaluloj kaj dosiernomoj ne. Tio estas reala plibonigo, kaj pli mallarĝa ol la merkatado sugestas. La operatoro de la tunelo sidas meze kaj vidas pli ol la alirreto.

Deklaro pri neniuj protokoloj priskribas konservan politikon, ne teknikan videblecon. Tiuj estas malsamaj asertoj, kaj nur la unua estas io, kion provizanto povas promesi.

La liko venas de la ligado, ne de la tunelo

BitTorrent kreas fluon de mallongdaŭraj TCP- kaj UDP-konektoj al egaluloj, spuriloj, DHT-nodoj kaj loka malkovro. Ligu la klienton al la fizika adaptilo, aŭ restartigu ĝin post kiam la tunelo falis, kaj la rezulta trafiko estas ĝuste tio, por kio la tunelo ekzistis por kaŝi ĝin. Fajroŝirmilaj reguloj estas pli malforta kontrolo ol ili ŝajnas: regulo kongruanta nur la defaŭltan itineron, nur IPv4 aŭ nur novajn konektojn lasas vojojn malfermitaj. Ligi la klienton al la tunela interfaco kaj kontroli tiun ligadon estas la pli forta ŝablono.

Kontrolu per intenca haltigo de la tunelo kaj observo, ĉu transigoj haltas. Se ili daŭras, la kliento neniam estis ene. Ripetu post restartigo de la kliento kaj post vekiĝo de tekkomputilo, ĉar tiam ligadoj kutime perdiĝas.

DNS nomas la retejon sen tuŝi la transigon

Se nomserĉoj ankoraŭ iras al la loka solvilo, la demando mem anoncas la retejon dum la transigo restas ĉifrita. Movi la solvon en la tunelon, aŭ ĉifri ĝin, fermas tiun breĉon. Nek unu nek la alia helpas klienton, kies pakaĵoj eliras ekster la tunelo. Kontrolu, kiu solvilo estas uzata kaj de kiu interfaco la demando eliras; la du kontroloj respondas malsamajn demandojn.

Nomo solvata tra la tunelo kaj transigo respektanta la ligadon estas apartaj ecoj, kaj ĉiu povas fiaski sole.

La svarmo kaj la spurilo vidas malsamajn aferojn

Adresŝanĝo estas parto de la protokolo, do egaluloj registras kion ili vidas. Konektiĝi de la eliro donas al ili la eliron; konektiĝi rekte donas la hejman adreson. DHT kaj egalula interŝanĝo plu disvastigas tiun observon, kaj posta seanco sen la tunelo povas ligi la saman klientan pordon kaj version. La spurilo povas scii eĉ pli: pasŝlosilo en la anonca URL identigas la konton sendepende de tio, de kiu eliro la pakaĵoj venis.

Ĉifrado denove kovras alian akson. HTTPS protektas peton de la eliro antaŭen; ordinara HTTP elmetas la petlinion al ĉiu reto survoje, kaj tial unu protokolo povas esti formita dum la alia ne.

Respondu la kvar demandojn per pruvoj, ne per ikono. La ikono nur diras al vi, ke tunelo ekzistas.