Relé de Tor frente a servidor VPN: por qué no son intercambiables

Tiene una dirección, el puerto responde y un cliente la acepta sin quejarse. Nada de eso convierte un relé de Tor en un extremo de VPN, y el error sale caro porque el perfil se importa limpiamente y falla más tarde en el handshake. Uso las cuatro comprobaciones siguientes en orden; cada una tiene una condición de parada, y parar pronto es precisamente el punto. Si falla la primera comprobación, las demás no pueden ayudarle.

Compruebe qué sirve realmente el puerto

Un puerto abierto demuestra un oyente, nada más. El ORPort de un relé habla las propias celdas de Tor tras un handshake TLS, así que una sonda TLS exitosa no le dice casi nada sobre si allí se acepta un protocolo VPN:

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

Lea el certificado en lugar del hecho de que exista uno. Los relés presentan un certificado autofirmado con un nombre deliberadamente anodino, porque el tráfico del relé debe parecerse a un HTTPS corriente; el certificado de un servidor VPN lleva el nombre que su perfil espera. Si el par nunca responde al primer paquete del protocolo VPN, ninguna cantidad de edición del perfil cambiará el resultado.

Deténgase aquí si la dirección no completa el handshake que envía su cliente. Eso es una respuesta de protocolo, no un problema de configuración, y es la razón más común por la que un perfil importado se queda en 'connecting' para siempre.

Compruebe el papel del relé, no el tamaño de la red

Los papeles del relé hacen trabajos distintos. Un guard es el primer salto para los clientes, un relé intermedio reenvía circuitos entre otros relés, un exit es el que toca destinos, y un puente es un punto de entrada no público repartido mediante BridgeDB. El glosario de Tor mantiene esas definiciones separadas, y ser alcanzable forma parte de todos los papeles mientras que el permiso para servir a clientes arbitrarios no forma parte de ninguno.

La política de exit merece lectura porque es la única parte que se parece a una regla de reenvío, y rige los destinos que el exit permitirá hacia fuera, no los clientes a los que se permite entrar. Una política de exit restrictiva que bloquea el puerto 25 dice algo sobre el control del abuso saliente, no sobre si puede apuntar un cliente OpenVPN a la máquina.

Deténgase si razona desde la reputación: como los relés reenvían tráfico, la dirección tiene que aceptar el suyo. Tor elige rutas mediante consenso y su propio protocolo; un cliente VPN no es un participante y no tiene circuito al que unirse.

Compruebe si el oyente SOCKS es local o público

El cliente de Tor expone una interfaz SOCKS para aplicaciones de la misma máquina, por defecto en loopback. Ese oyente es una comodidad local, no un servicio que un relé ofrezca a internet, y tratarlo como un proxy público es como la gente acaba ejecutando un relé abierto que no pretendía:

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

La dirección de enlace es la pista. Un SocksPort en 127.0.0.1:9050 hace su trabajo; uno que escucha en 0.0.0.0 y es alcanzable desde fuera es un proxy abierto, y los controles de política de acceso del propio Tor existen justamente porque esa exposición es un problema y no una característica.

Para una aplicación que necesita Tor, apúntela al puerto de loopback y deje que Tor resuelva nombres, que es lo que hace la forma socks5h de arriba. No sustituya la dirección del relé por ese puerto; el relé no ofrece la interfaz que pide su aplicación.

Compruebe que el perfil VPN coincide con un extremo real

Un perfil VPN es un conjunto de expectativas: OpenVPN necesita el certificado del servidor o la CA, un certificado de cliente y una clave, y normalmente una clave TLS, mientras que WireGuard necesita la clave pública del par, un extremo e IP permitidas. Nada de eso puede derivarse de una dirección y un puerto abierto, y por eso un perfil construido así falla en el primer intercambio y no al conectar.

Cuando le entregan un perfil, verifíquelo contra un extremo que controle o un proveedor que pueda identificar:

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

En el registro de OpenVPN, un error de negociación TLS nombra directamente la discrepancia; en wg show, un par sin línea de handshake nunca ha completado uno. Ambos son más informativos que el indicador giratorio del cliente, y ambos apuntan al material de claves o al protocolo y no a Tor.

Compruebe qué protección necesita en realidad

Esta es la comprobación que decide la arquitectura. El navegador Tor le da aislamiento de circuitos y defensas contra huellas que una VPN no tiene; una VPN cambia la dirección que ve un destino y le autentica ante un proveedor. Elegir entre ambas es una cuestión de modelo de amenaza, no de compatibilidad, y mezclarlas produce una configuración que parece privada y no lo es.

El encadenamiento tiene un orden. Una VPN que transporta tráfico de Tor es una disposición admitida, porque el cliente de Tor solo necesita TCP saliente. Un cliente VPN tunelizado dentro de Tor no es lo mismo y no es lo que implementa el cliente de Tor, así que no planifique a partir de eso.

Antes de importar nada, confirme las cuatro cosas:

• El puerto completa el handshake de su protocolo, no solo una conexión TCP.
• Conoce el papel del host y no trata el reenvío como permiso.
• El oyente SOCKS que usa es de loopback y suyo, no un puerto público en el relé de otra persona.
• Las claves o certificados del perfil pertenecen al extremo al que se conecta.