VPN a través de Tor: primeiro a comprobación do transporte
Tor transporta TCP, non UDP. Revise o transporte, as posicións do observador e as capas de fallo antes de tratar unha VPN con Tor como navegación anónima.
Tor primeiro significa que o cliente VPN se sitúa detrás dun proxy SOCKS, así que o túnel mesmo constrúese a través de Tor e o tráfico das aplicacións sae do punto final da VPN. Ese é un orde concreto e non é o que constrúe a maioría da xente. Abrir Tor Browser xunto a un cliente VPN normal non obriga a ningún dos dous programas a usar a ruta do outro.
Percorra as comprobacións en orde. Cada unha decide se paga a pena comezar a seguinte.
Que orde está a construír en realidade
Dúas ordes confúndense na mesma conversa. Tor primeiro significa que o cliente VPN chega ao seu servidor a través dun proxy SOCKS, así que o túnel se constrúe sobre Tor. VPN primeiro significa que o tráfico de Tor sae polo túnel, que é o que a maioría constrúe por accidente e logo describe como o outro. O primeiro concentra a fronteira de reenvío no operador da VPN, o segundo concéntraa na entrada e na saída de Tor. Ningún dos dous é o que se obtén ao ter ambas as aplicacións abertas á vez.
Anote que orde necesita a tarefa antes de configurar nada, porque os dous requiren axustes de software distintos e fallan en lugares distintos. Unha orde mal etiquetada envíao a depurar a capa equivocada durante unha hora. Todo o seguinte supón Tor primeiro.
Comprobe o transporte antes ca nada
A interface SOCKS de Tor transporta fluxos TCP e non ofrece unha asociación UDP xeral. Unha VPN cuxo transporte sexa UDP non pode tratar ese proxy como unha interface de rede ordinaria, e ningún axuste do cliente cambia o que o proxy está disposto a reenviar. WireGuard na súa forma habitual é a vítima obvia. Un perfil de OpenVPN en modo TCP é a solución habitual, e aínda hai que lle dicir explicitamente que use o proxy.
ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com
Confirme que o proxy escoita e pode transportar unha petición HTTPS simple antes de depurar un túnel a través del. Se a petición simple falla, o cliente VPN nunca terá éxito e os seus rexistros non lle dirán por que.
Reescriba o mapa do observador
A entrada de Tor pode ver a fonte que se conecta a Tor a menos que algo anterior a cambiase, así que ese salto aprende o seu enderezo. O provedor da VPN recibe unha conexión que chega do lado de Tor, pero aínda pode coñecer unha conta, un rexistro de pagamento ou unha credencial que vostede enviou dentro do túnel. Os destinos alcanzados a través da VPN ven a súa saída en lugar da saída de Tor, e iso concentra a fronteira final de reenvío nun só operador.
Tampouco recrea unha ruta distribuída cara a cada destino. Tor Browser constrúe un circuíto novo por sitio; unha VPN levada sobre Tor constrúe un só túnel, e cada sitio detrás del comparte ese punto final. Trate a diferenza como un feito de deseño e non como unha limitación que haxa que eliminar.
Conte as capas de fallo cando se rompe
Unha configuración rota ten polo menos catro capas independentes: a conexión SOCKS, o intercambio TLS co servidor da VPN, o propio intercambio da VPN e despois o encamiñamento ou a resolución de nomes dentro do túnel. Cada unha falla cun síntoma distinto e cada unha necesita unha reparación distinta. Afrouxar as comprobacións de certificados porque o túnel non levanta é o diagnóstico erróneo clásico, e converte un problema de transporte nun de seguridade.
Rexiste a primeira capa que falle e detéñase aí. Un rexeitamento do proxy e unha chave rexeitada non son variacións do mesmo suceso.
Detéñase se o modelo de ameaza necesita as defensas de Tor Browser
Encamiñar aplicacións arbitrarias por unha VPN levada por Tor non dá a esas aplicacións as funcións de pegada e illamento de Tor Browser. As súas contas, identificadores e comportamento de rede propio seguen sendo relevantes, e un túnel non normaliza ningún deles. Se o obxectivo é un navegador que se mestura con outros usuarios, esta orde non o ofrece.
O propio Tor Project advirte contra combinacións que os usuarios non poden configurar correctamente, e esta vale para a maioría da xente. É un deseño deliberado para un modelo de ameaza estreito, non un atallo cara ao tráfico anónimo de todo o dispositivo.