VPN dentro de Tor, Tor dentro de VPN: por que se rompe a cadea
Cando se apilan unha VPN, Tor e un proxy, a orde decide que se resolve e que se transporta. Atopa a primeira fronteira rota antes de cambiar as tres.
Apilar unha VPN, Tor e un proxy de aplicación parece multiplicar a privacidade, e multiplica o número de sitios onde unha conexión pode morrer. O resultado habitual é un navegador que xira mentres as tres ferramentas se declaran sanas. Cambiar as tres configuracións á vez elimina entón a única pista que tiñas sobre cal mente.
Debuxa primeiro o camiño previsto, en orde, nomeando que programa abre cada conexión e que nome se resolve en cada paso.
As capas non se suman, interactúan
Unha VPN antes de Tor significa que a conexión de entrada do cliente de Tor viaxa dentro do túnel. Unha VPN transportada a través de Tor significa que o propio punto final do cliente de VPN debe ser alcanzable por Tor, o que é un requisito moi distinto. O proxy do navegador engade outro salto máis que o sistema operativo descoñece. Tres disposicións, tres listas de dependencias separadas.
Cada disposición cambia que se pode resolver, que se pode transportar e quen ve o primeiro paquete. Só unha delas pode ser a configuración que tiñas en mente.
Engade tamén o camiño directo ao diagrama. Unha ruta de reserva, unha excepción de túnel dividido ou un atallo do proxy poden facer que unha páxina cargue mentres salta en silencio a cadea que querías probar, e ese éxito engana máis que o fallo.
A orde decide que se pode transportar
Tor transporta fluxos TCP pola súa interface SOCKS, e un cliente que lle pide ao proxy que resolva o nome do host mantén a consulta dentro do circuíto. UDP non viaxa así en configuracións normais, por iso un túnel WireGuard non pode aniñarse dentro de Tor sen un relé TCP adicional no medio.
OpenVPN pódese forzar a TCP, así que esa disposición polo menos é descriptible. Tamén é máis lenta e máis fráxil, e o modo de fallo cando se rompe parece idéntico a un porto bloqueado. Espera pasar máis tempo distinguindo eses dous casos que arranxando calquera deles.
A resolución é a outra metade. Con --socks5-hostname o proxy resolve o destino, mentres que o --socks5 simple pregunta primeiro ao resolutor local e filtra o nome fóra do circuíto. Ese único parámetro decide se a consulta do nome pertence á cadea ou ao teu provedor de Internet.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Localizar a primeira fronteira rota
Proba as etapas na orde en que viaxan os paquetes, con peticións inofensivas, e detente na primeira que falle. Anota que comando se executou primeiro, porque a orde forma parte da evidencia. Dous comandos separan un circuíto morto dunha saída morta:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
O primeiro informa de se unha petición chega a completarse a través do proxy SOCKS, e o segundo mostra o enderezo que a rede presenta agora mesmo. Se o primeiro falla e o segundo funciona, o problema está no cliente de Tor ou antes. Se ambos funcionan e o navegador segue fallando, a aplicación usa un camiño distinto do da consola.
Unha páxina de IP pública tamén describe só a última saída visible. Non pode dicir cantos saltos a precederon, así que combínaa coa saída de estado admitida de cada ferramenta en lugar de tratar un só número como un diagrama.
Cando deixar de engadir capas
Se non podes dicir nunha frase que achega unha capa, quitaa. Unha cadea cuxo propósito non está claro é unha cadea que ninguén pode depurar ás tres da madrugada, e a ganancia de privacidade dun salto sen explicación adoita ser menor que a dispoñibilidade que perdes.
Se unha capa si gaña o seu sitio, proba soa primeiro, despois engade a seguinte e confirma o camiño outra vez cos mesmos dous comandos. Restaura a cadea completa antes do uso normal e mantén a validación TLS e a autenticación activadas; un aviso de certificado aceptado para que cargue unha páxina é unha volta de enrutamento, non unha reparación. Anota a orde que escolliches mentres a tes fresca.
Escribe esa orde, incluído o resolutor que responde en cada etapa. Unha cadea que funciona e que podes describir sobrevive á próxima actualización, mentres que unha cadea que funciona e que montaches probando desaparece con ela. Engade a data e as versións, para que un fallo posterior poida compararse cun estado coñecido bo en lugar de discutirse de memoria. Dez liñas nun ficheiro de texto aforran unha tarde de conxecturas.