VPN dins de Tor, Tor dins de VPN: per què es trenca la cadena
Quan una VPN, Tor i un proxy es posen un sobre l'altre, l'ordre decideix què es resol i què es transporta. Trobeu la primera frontera trencada abans de canviar les tres coses.
Apilar una VPN, Tor i un proxy d'aplicació sembla multiplicar la privadesa, i el que fa és multiplicar els llocs on una connexió pot morir. El resultat habitual és un navegador que gira mentre les tres eines es declaren sanes. Canviar les tres configuracions alhora elimina llavors l'única pista que teníeu sobre quina menteix.
Dibuixeu primer el camí previst, en ordre, dient quin programa obre cada connexió i quin nom es resol a cada pas.
Les capes no se sumen, interactuen
Una VPN abans de Tor vol dir que la connexió d'entrada del client de Tor viatja dins del túnel. Una VPN portada a través de Tor vol dir que el punt final del mateix client de VPN ha de ser abastable per Tor, que és un requisit molt diferent. El proxy del navegador afegeix encara un altre salt que el sistema operatiu no coneix. Tres disposicions, tres llistes de dependències separades.
Cada disposició canvia què es pot resoldre, què es pot transportar i qui veu el primer paquet. Només una pot ser la configuració que teníeu al cap.
Afegiu també el camí directe al diagrama. Una ruta de reserva, una exclusió de túnel dividit o un salt de proxy poden fer que una pàgina carregui mentre s'estalvia en silenci la cadena que volíeu provar, i aquest èxit enganya més que el fracàs.
L'ordre decideix què es pot transportar
Tor transporta fluxos TCP per la seva interfície SOCKS, i un client que demana al proxy que resolgui el nom de l'amfitrió manté la consulta dins del circuit. UDP no viatja així en configuracions ordinàries, per això un túnel WireGuard no es pot niar dins de Tor sense un relé TCP addicional al mig.
OpenVPN es pot forçar a TCP, així que aquesta disposició almenys és descriptible. També és més lent i més fràgil, i la manera com falla quan es trenca sembla idèntica a un port bloquejat. Espereu passar més temps distingint aquests dos casos que arreglant qualsevol dels dos.
La resolució és l'altra meitat. Amb --socks5-hostname el proxy resol la destinació, mentre que l'--socks5 normal pregunta primer al resolutor local i filtra el nom fora del circuit. Aquest sol paràmetre decideix si la consulta del nom pertany a la cadena o al vostre proveïdor d'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 |
Trobar la primera frontera trencada
Proveu les etapes en l'ordre en què viatgen els paquets, amb peticions innòcues, i atureu-vos a la primera que falli. Anoteu quina comanda s'ha executat primer, perquè l'ordre forma part de l'evidència. Dues comandes separen un circuit mort d'una sortida morta:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
La primera informa si una petició arriba a completar-se a través del proxy SOCKS, i la segona mostra l'adreça que la xarxa presenta ara mateix. Si la primera falla i la segona funciona, el problema és al client de Tor o abans. Si totes dues funcionen i el navegador encara falla, l'aplicació fa servir un camí diferent del de la consola.
Una pàgina d'IP pública també descriu només l'última sortida visible. No pot dir quants salts l'han precedida, així que combineu-la amb la sortida d'estat suportada de cada eina en lloc de tractar un sol número com un diagrama.
Quan deixar d'afegir capes
Si no podeu dir en una frase què aporta una capa, traieu-la. Una cadena el propòsit de la qual no és clar és una cadena que ningú no pot depurar a les tres de la matinada, i el guany de privadesa d'un salt no explicat sol ser menor que la disponibilitat que perdeu.
Si una capa sí que es guanya el lloc, proveu-la sola primer, després afegiu la següent i confirmeu el camí una altra vegada amb les mateixes dues comandes. Restaureu la cadena completa abans de l'ús ordinari i manteniu la validació TLS i l'autenticació enceses; un avís de certificat acceptat per fer carregar una pàgina és una solució de compromís d'encaminament, no una reparació. Anoteu l'ordre que heu triat mentre el teniu fresc.
Escriviu aquest ordre, inclòs el resolutor que respon a cada etapa. Una cadena que funciona i que podeu descriure sobreviu a la propera actualització, mentre que una cadena que funciona i que vau muntar provant desapareix amb ella. Afegiu-hi la data i les versions, perquè una fallada posterior es pugui comparar amb un estat conegut com a bo en lloc de discutir-se de memòria. Deu línies en un fitxer de text estalvien un vespre d'endevinar.