Relé de Tor fronte a servidor VPN: por que non son intercambiables

Ten un enderezo, o porto responde e un cliente acéptao sen queixarse. Nada diso converte un relé de Tor nun extremo de VPN, e o erro é caro porque o perfil se importa limpiamente e falla máis tarde no handshake. Uso as catro comprobacións de abaixo en orde; cada unha ten unha condición de parada, e parar cedo é precisamente o punto. Se falla a primeira comprobación, as demais non poden axudarlle.

Comprobe que serve realmente o porto

Un porto aberto demostra un oínte, nada máis. O ORPort dun relé fala as propias celas de Tor tras un handshake TLS, así que unha sonda TLS exitosa non lle di case nada sobre se alí 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 o certificado en lugar do feito de que exista un. Os relés presentan un certificado autosinado cun nome deliberadamente anódino, porque o tráfico do relé debe parecerse a un HTTPS corrente; o certificado dun servidor VPN leva o nome que o seu perfil agarda. Se o par nunca responde ao primeiro paquete do protocolo VPN, ningunha cantidade de edición do perfil cambiará o resultado.

Pare aquí se o enderezo non completa o handshake que envía o seu cliente. Iso é unha resposta de protocolo, non un problema de configuración, e é a razón máis común pola que un perfil importado queda en 'connecting' para sempre.

Comprobe o papel do relé, non o tamaño da rede

Os papeis do relé fan traballos distintos. Un guard é o primeiro salto para os clientes, un relé intermedio reenvía circuítos entre outros relés, un exit é o que toca destinos, e unha ponte é un punto de entrada non público repartido mediante BridgeDB. O glosario de Tor mantén esas definicións separadas, e ser alcanzable forma parte de todos os papeis mentres que o permiso para servir a clientes arbitrarios non forma parte de ningún.

A política de exit merece lectura porque é a única parte que se parece a unha regra de reenvío, e rexe os destinos que o exit permitirá cara a fóra, non os clientes aos que se permite entrar. Unha política de exit restritiva que bloquea o porto 25 di algo sobre o control do abuso saínte, non sobre se pode apuntar un cliente OpenVPN á máquina.

Pare se razoa desde a reputación: como os relés reenvían tráfico, o enderezo ten que aceptar o seu. Tor escolle camiños mediante consenso e o seu propio protocolo; un cliente VPN non é un participante e non ten circuíto ao que unirse.

Comprobe se o oínte SOCKS é local ou público

O cliente de Tor expón unha interface SOCKS para aplicacións da mesma máquina, por defecto en loopback. Ese oínte é unha comodidade local, non un servizo que un relé ofreza a internet, e tratalo como un proxy público é como a xente acaba executando un relé aberto que non pretendía:

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

O enderezo de enlace é a pista. Un SocksPort en 127.0.0.1:9050 fai o seu traballo; un que escoita en 0.0.0.0 e é alcanzable desde fóra é un proxy aberto, e os controis de política de acceso do propio Tor existen xustamente porque esa exposición é un problema e non unha característica.

Para unha aplicación que necesita Tor, apúnteo ao porto de loopback e deixe que Tor resolva nomes, que é o que fai a forma socks5h de arriba. Non substitúa o enderezo do relé por ese porto; o relé non ofrece a interface que pide a súa aplicación.

Comprobe que o perfil VPN coincide cun extremo real

Un perfil VPN é un conxunto de expectativas: OpenVPN necesita o certificado do servidor ou a CA, un certificado de cliente e unha clave, e normalmente unha clave TLS, mentres que WireGuard necesita a clave pública do par, un extremo e IP permitidas. Nada diso pode derivarse dun enderezo e un porto aberto, e por iso un perfil construído así falla no primeiro intercambio e non ao conectar.

Cando lle entregan un perfil, verifíqueo contra un extremo que controle ou un provedor que poida identificar:

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

No rexistro de OpenVPN, un erro de negociación TLS nomea directamente a discrepancia; en wg show, un par sen liña de handshake nunca completou ningún. Ambos son máis informativos que o indicador xiratorio do cliente, e ambos apuntan ao material de claves ou ao protocolo e non a Tor.

Comprobe que protección necesita en realidade

Esta é a comprobación que decide a arquitectura. O navegador Tor dálle illamento de circuítos e defensas contra pegadas que unha VPN non ten; unha VPN cambia o enderezo que ve un destino e autentícao ante un provedor. Escoller entre ambas é unha cuestión de modelo de ameaza, non de compatibilidade, e mesturalas produce unha configuración que parece privada e non o é.

A encadenación ten unha orde. Unha VPN que transporta tráfico de Tor é unha disposición admitida, porque o cliente de Tor só necesita TCP de saída. Un cliente VPN tunelizado dentro de Tor non é o mesmo e non é o que implementa o cliente de Tor, así que non planifique a partir diso.

Antes de importar nada, confirme as catro cousas:

• O porto completa o handshake do seu protocolo, non só unha conexión TCP.
• Coñece o papel do host e non trata o reenvío como permiso.
• O oínte SOCKS que usa é de loopback e seu, non un porto público no relé de outra persoa.
• As claves ou certificados do perfil pertencen ao extremo ao que se conecta.