Servicio Onion frente a servicio VPN: modelos de acceso distintos

La gente describe un servicio Onion y un servicio accesible solo por VPN como dos variantes de la misma idea: ocultar el puerto y compartir la dirección secreta. Difieren en aquello a lo que está ligada la dirección, quién puede alcanzarla y qué debe ocurrir antes de que llegue una petición. Uno es un punto de encuentro dentro de Tor; el otro es una ruta dentro de una red privada. Tratarlos como intercambiables produce diseños que no son ni privados ni mantenibles.

El mito: ambos diseños son solo una puerta oculta

La propiedad compartida es real pero delgada: ninguno de los dos diseños coloca la interfaz administrativa en un puerto público directamente accesible. Todo lo demás diverge. Una dirección Onion se deriva de la clave propia del servicio, así que el nombre está ligado a una identidad; una dirección VPN es solo una dirección dentro de una red a la que se le admitió. Uno esconde el servicio dentro de una capa superpuesta, el otro le admite en una topología privada. Tratar el segundo como sinónimo del primero es donde empieza la confusión.

Ninguna de las dos propiedades es un control de seguridad para la propia aplicación. Un lugar oculto no parchea el software que hay detrás, y una ruta privada no añade autenticación a la página de inicio de sesión. Ambos diseños siguen necesitando los permisos propios de la aplicación, y ambos siguen necesitando a alguien responsable de las actualizaciones y la recuperación.

A qué apunta realmente una dirección Onion

Una dirección Onion de la versión v3 codifica la clave pública del servicio, por lo que nadie puede elegir una dirección para un servicio que no controla. El cliente se conecta a través de Tor a un punto de encuentro, y el servicio llega al mismo punto desde su lado; ningún nodo de salida corriente lleva esa conexión hasta el servicio. El nombre es una identidad, no un registro DNS.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

Por eso añadir una ruta o una entrada en hosts para un nombre onion no sirve de nada. La consulta no es el mecanismo; lo es el cliente de Tor y sus circuitos. Si el servicio está pensado para un grupo pequeño de personas, la autorización de cliente onion puede exigir una clave antes de aceptar la conexión, pero eso sigue sin ser el inicio de sesión de la aplicación. Publicar la dirección también es un acto deliberado, ya que cualquiera que la conozca puede intentar conectarse a menos que la haya restringido.

Deténgase si la única razón del diseño onion es evitar configurar la autenticación. La capa superpuesta no lo proporciona, y la construirá más adelante de todos modos.

Qué concede realmente una ruta VPN

Una VPN admite un dispositivo en una red y le da una ruta hacia una puerta de enlace o una subred. El servicio detrás de esa puerta de enlace ve una dirección del conjunto del túnel y aplica la autorización que tenga. La ruta no dice nada sobre quién es el usuario; dice adónde pueden ir los paquetes.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

Ese modelo encaja con un grupo conocido con dispositivos gestionados, porque la puerta de enlace puede imponer el estado del dispositivo y la red se puede auditar. Encaja mal con visitantes anónimos o ad hoc, que primero tendrían que inscribirse. El inicio de sesión de la propia aplicación sigue decidiendo qué puede leer un usuario conectado. Confundir el alcance con el permiso es como una VPN acaba concediendo una subred entera a todo el que puede conectarse.

Deténgase si el público es desconocido o cambia constantemente. Inscribir a desconocidos en una red privada para mostrarles una página es un compromiso grande comparado con publicar un servicio.

Elegir entre ambos, y qué permanece igual

Elija el modelo onion cuando el público sea técnico, el servicio no deba tener ninguna dirección pública y pueda aceptar los requisitos del cliente de Tor. Elija el modelo VPN cuando el público sea un grupo definido cuyos dispositivos gestiona y cuyo acceso quiere registrar en la capa de red. Ninguna elección elimina la necesidad de autenticación de la aplicación, parcheo o una vía de recuperación. Ninguna es automáticamente más privada en el sentido que importa a sus usuarios.

En ambos diseños, anote quién puede alcanzar el servicio, cómo se identifican y qué ocurre cuando se pierde una credencial. La respuesta para un servicio onion incluye sus claves de autorización de cliente y la propia dirección; la respuesta para una VPN incluye la cuenta, el dispositivo y la política de la puerta de enlace. Son inventarios distintos, y solo uno de ellos resultará obvio para el siguiente administrador.

La comparación termina donde empieza la aplicación. Una dirección oculta y una ruta privada son opciones de transporte, y la aplicación todavía tiene que decidir qué puede hacer una petición. Mantenga esas decisiones en documentos separados y ninguno de los dos diseños absorberá en silencio el trabajo del otro.