Relé de Tor contra servidor VPN: per què no són intercanviables

Teniu una adreça, el port respon i un client l’accepta sense protestar. Res d’això converteix un relé de Tor en un extrem de VPN, i l’error és car perquè el perfil s’importa net i falla més tard a l’encaixada de mans. Faig servir les quatre comprovacions següents en ordre; cadascuna té una condició d’aturada, i aturar-se aviat és precisament el punt. Si falla la primera comprovació, la resta no us poden ajudar.

Comproveu què serveix realment el port

Un port obert demostra un oient, res més. L’ORPort d’un relé parla les cel·les pròpies de Tor després d’una encaixada de mans TLS, així que una sonda TLS que té èxit no us diu gairebé res sobre si s’hi accepta un protocol VPN:

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

Llegiu el certificat en lloc del fet que n’existeixi un. Els relés presenten un certificat autosignat amb un nom deliberadament insignificant, perquè el trànsit del relé ha de semblar HTTPS corrent; el certificat d’un servidor VPN porta el nom que el vostre perfil espera. Si el parell mai no respon al primer paquet del protocol VPN, cap quantitat d’edició del perfil no canviarà el resultat.

Atureu-vos aquí si l’adreça no completa l’encaixada de mans que envia el vostre client. Això és una resposta de protocol, no un problema de configuració, i és la raó més comuna perquè un perfil importat es quedi a 'connecting' per sempre.

Comproveu el paper del relé, no la mida de la xarxa

Els papers del relé fan feines diferents. Un guard és el primer salt per als clients, un relé intermedi reenvia circuits entre altres relés, un exit és el que toca les destinacions, i un pont és un punt d’entrada no públic repartit per BridgeDB. El glossari de Tor manté aquestes definicions separades, i ser abastable forma part de cada paper mentre que el permís per servir clients arbitraris no forma part de cap d’ells.

La política d’exit val la pena llegir-la perquè és l’única part que s’assembla a una regla de reenviament, i regula les destinacions que l’exit permetrà sortir, no els clients que es permeten entrar. Una política d’exit restrictiva que bloqueja el port 25 diu alguna cosa sobre el control d’abús de sortida, no sobre si podeu apuntar un client OpenVPN a la màquina.

Atureu-vos si raoneu des de la reputació: com que els relés reenvien trànsit, l’adreça ha d’acceptar la vostra. Tor tria camins mitjançant consens i el seu propi protocol; un client VPN no és un participant i no té cap circuit on unir-se.

Comproveu si l’oient SOCKS és local o públic

El client de Tor exposa una interfície SOCKS per a aplicacions de la mateixa màquina, per defecte al loopback. Aquest oient és una comoditat local, no un servei que un relé ofereixi a internet, i tractar-lo com un proxy públic és com la gent acaba executant un relé obert que no volia:

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

L’adreça d’enllaç és la pista. Un SocksPort a 127.0.0.1:9050 fa la seva feina; un que escolta a 0.0.0.0 i és abastable des de fora és un proxy obert, i els controls de política d’accés del propi Tor existeixen justament perquè aquesta exposició és un problema i no una característica.

Per a una aplicació que necessita Tor, apunteu-la al port de loopback i deixeu que Tor resolgui noms, que és el que fa la forma socks5h d’aquí dalt. No substituïu l’adreça del relé per aquest port; el relé no ofereix la interfície que demana la vostra aplicació.

Comproveu que el perfil VPN coincideix amb un extrem real

Un perfil VPN és un paquet d’expectatives: OpenVPN necessita el certificat del servidor o la CA, un certificat de client i una clau, i normalment una clau TLS, mentre que WireGuard necessita la clau pública del parell, un extrem i IP permeses. Res d’això no es pot derivar d’una adreça i un port obert, i per això un perfil construït així falla al primer intercanvi i no en connectar-se.

Quan us donen un perfil, verifiqueu-lo contra un extrem que controleu o un proveïdor que pugueu identificar:

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

Al registre d’OpenVPN, un error de negociació TLS anomena directament la discrepància; a wg show, un parell sense línia d’encaixada de mans mai no n’ha completat cap. Tots dos són més informatius que l’indicador giratori del client, i tots dos apunten al material de claus o al protocol i no a Tor.

Comproveu quina protecció necessiteu realment

Aquesta és la comprovació que decideix l’arquitectura. El navegador Tor us dona aïllament de circuits i defenses contra empremtes que un VPN no té; un VPN canvia l’adreça que veu una destinació i us autentica davant un proveïdor. Triar entre ells és una qüestió de model d’amenaça, no de compatibilitat, i barrejar-los produeix una configuració que sembla privada i no ho és.

L’encadenament té un ordre. Un VPN que transporta trànsit de Tor és una disposició suportada, perquè el client de Tor només necessita TCP de sortida. Un client VPN encadenat dins de Tor no és el mateix i no és el que implementa el client de Tor, així que no planifiqueu a partir d’això.

Abans d’importar res, confirmeu les quatre coses:

• El port completa l’encaixada de mans del vostre protocol, no només una connexió TCP.
• Coneixeu el paper de l’amfitrió i no tracteu el reenviament com a permís.
• L’oient SOCKS que feu servir és de loopback i és vostre, no un port públic al relé d’una altra persona.
• Les claus o certificats del perfil pertanyen a l’extrem al qual us connecteu.