Tor ou VPN: decidide por quen vos obriga a confiar cada camiño
Unha VPN acumula a vosa confianza nun só operador; Tor repártea entre repetidores. Decidide pola cobertura, por quen vos pode vincular a un sitio e polo que podedes verificar.
Escoller entre Tor e unha VPN redúcese a que parte podedes tolerar que vexa os dous extremos dunha conexión. Unha VPN concentra esa visión nun operador que escolliches. Tor repártea entre repetidores, así que ningún repetidor individual debe saber quen sodes e que descargastes.
Ningunha das dúas disposicións vos fai anónimos por si soa. Escollede a que vos permita nomear en voz alta a confianza que lle queda e despois corrixide as partes que deixa ao descuberto.
Contade quen vos pode vincular a un destino
Cunha VPN, cada fluxo cuberto chega á saída do operador antes de chegar ao destino. Ese operador ve necesariamente o voso enderezo de orixe e, para todo o que non estea cifrado a través del, o destino que pedistes. TLS mantén o contido da páxina fóra desa visión pero adoita deixar visible o nome de host mentres se establece a conexión. Unha parte pode, por tanto, vincularvos a un sitio, e ese vínculo é precisamente a confianza que outorgades.
Tor separa esas metades entre tres repetidores: un gardián que coñece o voso enderezo pero non o voso destino, un repetidor intermedio que non coñece ningún dos dous extremos e unha saída que coñece o destino pero non a vós. O deseño supón que ningún repetidor combina ambos os feitos, o que é unha suposición máis feble e máis útil que confiar nunha soa empresa. Non supón que os repetidores sexan honestos e non derrota un observador que vixía os dous extremos do camiño.
Ambos os deseños comparten un punto feble, e atópase no destino. Se iniciades sesión, o servizo vincula esa sesión á vosa conta calquera que sexa a ruta que tomaron os paquetes. O encamiñamento cambia de onde parece vir unha petición, non o que a páxina vos pide proporcionar.
A cobertura importa máis que o diagrama de encamiñamento
Unha VPN encamiña na capa de rede, así que cada aplicación do dispositivo herda o túnel a menos que a excluades a propósito. Esa amplitude é a razón pola que funciona á vez para un cliente de correo, un xestor de paquetes e un navegador.
O navegador Tor é un paquete, e as súas proteccións viven sobre todo dentro do navegador: unha pegada uniforme, illamento entre sitios e scripts limitados por un nivel de seguridade en lugar de polas extensións que instalastes. Dirixir Chrome a un porto SOCKS compra o encamiñamento sen nada diso, que é unha fonte habitual de confianza mal colocada.
O resto do escritorio queda intacto. Un cliente de sincronización, un actualizador ou un documento descargado aberto noutro programa conéctase como estea configurado ese programa, e nada diso pasa polo escoitador SOCKS a menos que o configuredes alí. Enumerade as aplicacións que falan coa rede e despois preguntade cales cobre realmente a ferramenta escollida. A cobertura é unha propiedade da vosa configuración, non da vosa intención.
Escollede con tres condicións
A decisión adóitase resolver con tres preguntas: o tráfico vén dunha aplicación ou de todo o dispositivo, o destino debe ser incapaz de identificar o voso enderezo, e necesitades chegar a unha rede privada? Respondede en esa orde e a ferramenta case sempre se escolle soa.
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
Cando dous requisitos entran en conflito, sopesade cal podedes impor. Un túnel de dispositivo cunha lista de exclusións con fugas é peor que unha ruta só de navegador que poidades demostrar.
A verificación é barata para ambos os camiños, e debería ocorrer antes de que confiedes en calquera dos dous:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Un resultado falso do primeiro comando significa que a petición saíu fóra do circuíto, que é o fallo que paga a pena atrapar cedo. Comparade o segundo co enderezo que vos asignou o provedor, non co que recordades da semana pasada.
O que non repara ningunha das dúas opcións
O cifrado de aplicacións segue facendo un traballo que ningunha ruta realiza. O HTTP simple que cruza unha rede de privacidade segue sendo lexible na saída, e HTTPS segue sendo o único que protexe a carga de extremo a extremo. TLS tampouco di nada sobre o nome de host que escribistes, por iso o destino segue visible para quen remata o camiño.
As contas identifícano, e ningunha elección de encamiñamento cambia iso: o servizo sabe quen iniciou sesión independentemente do enderezo na cabeceira. A correlación por parte dun observador que ve suficiente rede, o compromiso do voso propio dispositivo e todo o que escribides nun formulario sobreviven a ambos os deseños. Tratade as dúas ferramentas como formas de mover a confianza, non de eliminala.
Comezade pola configuración predeterminada que documenta cada proxecto, confirmade a ruta cos dous comandos anteriores e só entón considerade apilar unha VPN baixo Tor. Aniñalas é unha configuración cos seus propios modos de fallo, non unha actualización gratuíta.