Relay Tor contro server VPN: perché non sono intercambiabili

Avete un indirizzo, la porta risponde e un client lo accetta senza protestare. Niente di tutto ciò rende un relay Tor un endpoint VPN, e l’errore costa caro perché il profilo si importa pulito e fallisce più tardi all’handshake. Uso i quattro controlli qui sotto in ordine; ognuno ha una condizione di arresto, e fermarsi presto è proprio il punto. Se il primo controllo fallisce, gli altri non possono aiutarvi.

Verificate cosa serve davvero la porta

Una porta aperta dimostra un listener, niente di più. L’ORPort di un relay parla le celle proprie di Tor dopo un handshake TLS, quindi una sonda TLS riuscita non vi dice quasi nulla sull’accettazione di un protocollo VPN in quel punto:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

Leggete il certificato invece del fatto che esista. I relay presentano un certificato autofirmato con un nome volutamente anonimo, perché il traffico del relay deve somigliare a un HTTPS ordinario; il certificato di un server VPN porta il nome che il vostro profilo si aspetta. Se la controparte non risponde mai al primo pacchetto del protocollo VPN, nessuna modifica al profilo cambierà l’esito.

Fermatevi qui se l’indirizzo non completa l’handshake che il vostro client invia. È una risposta di protocollo, non un problema di configurazione, ed è il motivo più comune per cui un profilo importato resta su 'connecting' per sempre.

Verificate il ruolo del relay, non la dimensione della rete

I ruoli del relay svolgono compiti diversi. Un guard è il primo salto per i client, un relay intermedio inoltra circuiti tra altri relay, un exit è quello che tocca le destinazioni, e un bridge è un punto d’ingresso non pubblico distribuito tramite BridgeDB. Il glossario di Tor tiene separate queste definizioni, e la raggiungibilità fa parte di ogni ruolo mentre il permesso di servire client arbitrari non fa parte di nessuno di essi.

La politica di exit merita lettura perché è l’unica parte che somiglia a una regola di inoltro, e governa le destinazioni che l’exit consente in uscita, non i client ammessi in entrata. Una politica di exit restrittiva che blocca la porta 25 dice qualcosa sul controllo degli abusi in uscita, non sulla possibilità di puntare un client OpenVPN verso la macchina.

Fermatevi se ragionate per reputazione: poiché i relay inoltrano traffico, l’indirizzo deve accettare il vostro. Tor sceglie i percorsi tramite consenso e il proprio protocollo; un client VPN non è un partecipante e non ha alcun circuito a cui unirsi.

Verificate se il listener SOCKS è locale o pubblico

Il client Tor espone un’interfaccia SOCKS alle applicazioni sulla stessa macchina, per impostazione predefinita su loopback. Quel listener è una comodità locale, non un servizio che un relay offre a internet, e trattarlo come un proxy pubblico è il modo in cui la gente finisce per gestire un relay aperto che non intendeva:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

L’indirizzo di bind è l’indizio. Un SocksPort su 127.0.0.1:9050 fa il suo lavoro; quello che ascolta su 0.0.0.0 ed è raggiungibile dall’esterno è un proxy aperto, e i controlli di politica di accesso di Tor esistono proprio perché quell’esposizione è un problema e non una funzionalità.

Per un’applicazione che ha bisogno di Tor, puntatela alla porta loopback e lasciate che Tor risolva i nomi, cosa che fa la forma socks5h qui sopra. Non sostituite l’indirizzo del relay a quella porta; il relay non offre l’interfaccia che la vostra applicazione chiede.

Verificate che il profilo VPN corrisponda a un endpoint reale

Un profilo VPN è un insieme di aspettative: OpenVPN ha bisogno del certificato del server o della CA, di un certificato client e di una chiave, e di solito di una chiave TLS, mentre WireGuard ha bisogno della chiave pubblica della controparte, di un endpoint e di IP consentiti. Niente di ciò può essere derivato da un indirizzo e da una porta aperta, ed è per questo che un profilo costruito così fallisce al primo scambio e non alla connessione.

Quando vi viene consegnato un profilo, verificatelo contro un endpoint che controllate o un fornitore che potete identificare:

wg show
openvpn --config client.ovpn --verb 4

Nel registro di OpenVPN, un errore di negoziazione TLS nomina direttamente la discrepanza; in wg show, una controparte senza riga di handshake non ne ha mai completato uno. Entrambi sono più informativi dell’indicatore rotante del client, ed entrambi puntano al materiale delle chiavi o al protocollo e non a Tor.

Verificate di quale protezione avete davvero bisogno

Questo è il controllo che decide l’architettura. Il browser Tor vi dà isolamento dei circuiti e difese contro le impronte digitali che un VPN non ha; un VPN cambia l’indirizzo che una destinazione vede e vi autentica presso un fornitore. Scegliere tra i due è una questione di modello di minaccia, non di compatibilità, e confonderli produce una configurazione che sembra privata e non lo è.

Il concatenamento ha un ordine. Un VPN che trasporta traffico Tor è una disposizione supportata, perché il client Tor necessita solo di TCP in uscita. Un client VPN incanalato dentro Tor non è la stessa cosa e non è ciò che il client Tor implementa, quindi non pianificate su questo.

Prima di importare qualsiasi cosa, confermate tutti e quattro:

• La porta completa l’handshake del vostro protocollo, non solo una connessione TCP.
• Conoscete il ruolo dell’host e non trattate l’inoltro come un permesso.
• Il listener SOCKS che usate è loopback e vostro, non una porta pubblica sul relay di qualcun altro.
• Le chiavi o i certificati del profilo appartengono all’endpoint a cui vi collegate.