VPN tra Tor: unue la transporta kontrolo

Tor-unua signifas, ke la VPN-kliento sidas malantaŭ SOCKS-prokurilo, do la tunelo mem estas konstruata tra Tor kaj aplikaĵa trafiko eliras el la VPN-finpunkto. Tio estas unu specifa ordo, kaj ĝi ne estas tio, kion konstruas plej multaj homoj. Malfermi Tor Browser apud ordinara VPN-kliento devigas nek unu el la du programoj uzi la vojon de la alia.

Trairu la kontrolojn laŭ ordo. Ĉiu decidas, ĉu la sekva indas esti komencita.

Kiun ordon vi fakte konstruas

Du ordoj konfuziĝas en la sama konversacio. Tor unue signifas, ke la VPN-kliento atingas sian servilon tra SOCKS-prokurilo, do la tunelo estas konstruata super Tor. VPN unue signifas, ke Tor-trafiko eliras tra la tunelo, kion plej multaj homoj konstruas hazarde kaj poste priskribas kiel la alian. La unua koncentras la plusendan limon ĉe la VPN-operaciisto, la dua koncentras ĝin ĉe la eniro kaj eliro de Tor. Nek unu estas tio, kion vi ricevas tenante ambaŭ programojn malfermitaj samtempe.

Skribu, kiun ordon la tasko bezonas antaŭ ol agordi ion ajn, ĉar ambaŭ postulas malsamajn softvarajn agordojn kaj malsukcesas en malsamaj lokoj. Misetikedita ordo sendas vin elsperti la malĝustan tavolon dum unu horo. Ĉio sube supozas Tor unue.

Kontrolu la transporton antaŭ ĉio alia

La SOCKS-interfaco de Tor portas TCP-fluojn kaj ne donas ĝeneralan UDP-asocion. VPN, kies transporto estas UDP, ne povas trakti tiun prokurilon kiel ordinaran retan interfacon, kaj neniu klienta agordo ŝanĝas tion, kion la prokurilo pretas plusendi. WireGuard en sia kutima formo estas la evidenta viktimo. OpenVPN-profilo en TCP-reĝimo estas la kutima solvo, kaj ĝi ankoraŭ devas esti eksplicite dirita uzi la prokurilon.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

Konfirmu, ke la prokurilo aŭskultas kaj povas porti unu simplan HTTPS-peton antaŭ ol elsperti tunelon tra ĝi. Se la simpla peto malsukcesas, la VPN-kliento neniam sukcesos kaj ĝiaj protokoloj ne diros al vi kial.

Reskribu la observantan mapon

La eniro de Tor povas vidi la fonton, kiu konektiĝas al Tor, se io pli frua ne ŝanĝis ĝin, do tiu salto lernas vian adreson. La VPN-provizanto ricevas konekton alvenantan de la Tor-flanko, sed povas ankoraŭ koni konton, pagregistron aŭ akreditilon, kiun vi sendis ene de la tunelo. Celoj atingitaj tra la VPN vidas ĝian eliron anstataŭ la eliron de Tor, kaj tio koncentras la finan plusendan limon ĉe unu operaciisto.

Ĝi ankaŭ ne rekreas distribuitan vojon al ĉiu celo. Tor Browser konstruas freŝan cirkviton por ĉiu retejo; VPN portata tra Tor konstruas unu tunelon, kaj ĉiu retejo malantaŭ ĝi dividas tiun finpunkton. Traktu la diferencon kiel fakton de dezajno, ne kiel limigon foragordendan.

Kalkulu la malsukcesajn tavolojn, kiam ĝi rompiĝas

Rompita aranĝo havas almenaŭ kvar sendependajn tavolojn: la SOCKS-konekton, la TLS-manpremon kun la VPN-servilo, la VPN-manpremon mem, kaj poste enkursigon aŭ nomrezolucion ene de la tunelo. Ĉiu malsukcesas kun malsama simptomo kaj ĉiu bezonas malsaman riparon. Malstreĉi atestilajn kontrolojn ĉar la tunelo ne leviĝas estas la klasika malĝusta diagnozo, kaj ĝi transformas transportan problemon en sekurecan.

Registru la unuan tavolon, kiu malsukcesas, kaj haltu tie. Prokurila rifuzo kaj malakceptita ŝlosilo ne estas variaĵoj de la sama evento.

Haltu, se la minacmodelo bezonas la defendon de Tor Browser

Enkursigi arbitrajn aplikaĵojn tra VPN portata de Tor ne donas al tiuj aplikaĵoj la fingrespurajn kaj izolajn funkciojn de Tor Browser. Iliaj kontoj, identigiloj kaj propra reta konduto restas gravaj, kaj tunelo normaligas neniun el ili. Se la celo estas retumilo, kiu miksiĝas kun aliaj uzantoj, ĉi tiu ordo ne donas ĝin.

La Tor Project mem avertas kontraŭ kombinaĵoj, kiujn uzantoj ne povas ĝuste agordi, kaj ĉi tiu validas por plej multaj homoj. Ĝi estas intenca dezajno por mallarĝa minacmodelo, ne mallongigo al anonima trafiko de la tuta aparato.