VPN antes de Tor: que cambia realmente a orde

Conectar primeiro a VPN produce unha cadea concreta: dispositivo, extremo da VPN, entrada de Tor, circuíto de Tor, destino. A túa rede local ve unha conexión cifrada á VPN, e o nodo de entrada de Tor ve a saída da VPN como orixe inmediata en lugar do enderezo do teu provedor. O operador da VPN, pola súa banda, ve conexións cara á infraestrutura de entrada de Tor e pode inferir o uso de Tor a partir dos destinos. Cada observador perde algo e gaña algo, por iso a orde é un intercambio e non unha mellora.

Nada nesa cadea cambia o que o sitio web aprende da túa conta, das cookies ou dos datos que escribes.

Que cambia a orde

A rede local e o provedor de internet perden a visibilidade directa do teu tráfico de Tor, porque o primeiro salto é agora un túnel cifrado cara a un provedor. O gardián de entrada de Tor perde o teu enderezo de casa e ve a saída da VPN. O provedor da VPN gaña os metadatos que antes tiña o teu provedor: a que enderezos contactas, a que horas e cantos datos se moven.

Máis aló do gardián de entrada, o circuíto compórtase como antes. Os relés seguen separando os papeis de entrada, medio e saída, e a VPN non ve o contido final máis do que o vía o teu provedor.

Confirma a ruta que se usa realmente

O encamiñamento dividido é o motivo habitual de que a cadea prevista non sexa a real.Se o Tor Browser queda excluído do túnel, ou un segundo perfil encamiña doutro xeito, o gardián de entrada volve ver o enderezo do provedor mentres a interface aínda parece conectada. Comproba a ruta e a saída observada, non a icona.

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'

A petición SOCKS polo porto 9150 respóndea o propio cliente do Tor Browser, así que unha resposta IsTor true confirma o circuíto do navegador, non que calquera outro programa o use. Paga a pena rexistrar a saída do resolutor porque o DNS pode saír por unha ruta que o túnel non cobre. Conserva ambas as saídas cunha marca de tempo. Son a liña de base para a seguinte comparación.

Compárao cunha petición directa desde un terminal normal: se tamén informa de Tor, algo máis redirixe o tráfico e a cadea non é a que supuña o deseño.

Observa que ocorre cando cae o túnel

Un cliente que volve en silencio á interface local cambia a orixe que ve o gardián de entrada, e o usuario normalmente non o sabe porque a páxina aínda carga. Ese é o fallo que paga a pena probar, non o camiño feliz. Desconecta o túnel a propósito e observa se o tráfico de Tor se detén ou continúa sen protección.

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

As regras de devasa que bloquean o tráfico saínte fóra do túnel son o único control de reserva fiable, e deben cubrir tanto o cliente SOCKS do navegador como calquera outro programa que che importe. Unha extensión do navegador non é unha VPN de dispositivo e non afecta outros programas nin observadores externos.

Decide se a capa extra merece a súa confianza

O Proxecto Tor desaconsella apilar unha VPN baixo Tor a non ser que poidas avaliar ti mesmo a configuración. O motivo que dan é a dependencia engadida: outra parte, outra conta e outro modo de fallo. Se o obxectivo é impedir que o teu provedor vexa que usas Tor, a VPN diríxese precisamente a ese observador. Se o obxectivo é un anonimato máis forte fronte a un observador global, a VPN non o proporciona.

Tamén existe a orde inversa, e os nomes non son intercambiables:Tor sobre VPN e VPN sobre Tor describen relacións de confianza distintas e comportamentos de fallo distintos. Le a comparación antes de mesturalos.

Anota que observador intentas mover, despois verifica que a ruta real coincide co deseño, despois verifica o comportamento de fallo. Se esas tres respostas non xustifican a conta e a configuración adicionais, a configuración documentada do Tor Browser ten menos pezas que equivocar.