Earst de VPN ferbine jout in spesifike keatling: apparaat, VPN-einpunt, Tor-yngong, Tor-sirkwy, bestimming. Dyn lokale netwurk sjocht ien fersifere ferbining nei de VPN, en it Tor-yngongsknooppunt sjocht de VPN-útgong as de direkte boarne ynstee fan dyn provideradres. De VPN-operator sjocht op syn beurt ferbiningen nei Tor-yngongsinfrastruktuer en kin Tor-brûk út 'e bestimmingen ôfliede. Eltse observearder ferliest wat en wint wat, en dêrom is de oarder in ruil ynstee fan in ferbettering.

Neat yn dy keatling feroaret wat de webside fan dyn akkount, koekjes of yntikte details leart.

Wat de oarder feroaret

It lokale netwurk en de ISP ferlieze direkte sichtberens fan dyn Tor-ferkear, om't de earste sprong no in fersifere tunnel nei in provider is. De Tor-yngongswachter ferliest dyn thúsadres en sjocht de VPN-útgong. De VPN-provider krijt de metadata dy't dyn ISP earder hie: hokker adressen oftst kontaktet, op hokker tiden, en hoefolle data oft der beweecht.

Foarby de yngongswachter gedraacht it sirkwy him as earder. Relays skiede noch altyd de rollen fan yngong, midden en útgong, en de VPN sjocht de úteinlike ynhâld net mear as dyn ISP.

Befêstigje it paad dat echt brûkt wurdt

Splitst tunnelearjen is de gewoane reden wêrom't de bedoelde keatling net de echte is.As Tor Browser fan 'e tunnel útsletten is, of in twadde profyl rûtet oars, sjocht de yngongswachter wer it provideradres wylst de ynterface noch ferbûn liket. Kontrollearje de rûte en de waarnommen útgong ynstee fan it ikoan.

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

It SOCKS-fersyk fia poarte 9150 wurdt beantwurde troch Tor Browser syn eigen klant, dus in antwurd IsTor true befêstiget it sirkwy fan 'e browser, net dat elk oar programma it brûkt. Resolver-útfier is it wurdich te bewarjen, om't DNS fia in paad fuortgean kin dat de tunnel net dekt. Bewarje beide útfierden mei in tiidstimpel. Se binne de basisline foar de folgjende fergeliking.

Fergelykje it mei in direkt fersyk fan in gewoane terminal: as dat ek Tor rapportearret, dan liedt eat oars it ferkear om en is de keatling net wat it ûntwerp ferûnderstelde.

Sjoch wat der bart as de tunnel falt

In klant dy't stil weromfalt op 'e lokale ynterface feroaret de boarne dy't de yngongswachter sjocht, en de brûker wit dat meastentiids net om't de side noch ladt. Dat is de flater dy't it testen wurdich is, net it lokkige paad. Skeakelje de tunnel bewust út en sjoch oft Tor-ferkear stopt of ûnbeskerme trochgiet.

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

Firewall-regels dy't útgeand ferkear bûten de tunnel blokkearje, binne de iennige betroubere fallback-kontrôle, en se moatte sawol de SOCKS-klant fan 'e browser as elk oar programma datst wichtich fynst dekke. In browser-útwreiding is gjin apparaat-VPN en hat gjin ynfloed op oare programma's of eksterne besjoggers.

Beslis oft de ekstra laach syn fertrouwen fertsjinnet

It Tor Project riedt oan om gjin VPN ûnder Tor te stapeljen, útsein asst de opset sels beoardielje kinst. Harren neamde reden is de ekstra ôfhinklikens: noch in partij, noch in akkount en noch in flatermodus. As it doel is om dyn ISP tsjin te hâlden te sjen datst Tor brûkst, rjochtet de VPN him op krekt dy observearder. As it doel sterker anonymiteit tsjin in globale observearder is, leveret de VPN dat net.

De omkearde oarder bestiet ek, en de nammen binne net útwikselber:Tor oer VPN en VPN oer Tor beskriuwe ferskate fertrouwensferhâldingen en oar flatergedrach. Lês de fergeliking foardatst se mingst.

Skriuw op hokker observearder oftst besykest te ferskowen, befêstigje dan dat it echte paad by it ûntwerp past, en befêstigje dan it flatergedrach. As dy trije antwurden it ekstra akkount en de konfiguraasje net rjochtfeardigje, hat de dokumintearre Tor Browser-opset minder dielen om ferkeard te dwaan.

Relatearre artikelen