Alojar un servicio onion de Tor (v3) en un VPS

Cinco líneas de torrc, backends solo en localhost, copias de las claves, auth de clientes. Core sale a $6/mes, $4.80 en plazo anual, pago en criptomonedas. Publica tu onion.

La dirección es un par de claves, no un servidor

Casi todo en la administración de servidores se apoya en un nombre que alquilas a otra persona. Un servicio onion v3 invierte esa lógica: la cadena .onion es aritmética pura, derivada de un par de claves ed25519 que Tor genera en su primer arranque, y la máquina de debajo es un hardware intercambiable. Trata la dirección como un archivo que posees y no como un recurso que alquilas, y varios de los errores clásicos de los hidden services dejan de tener sentido antes de que tengas ocasión de cometerlos.

El formato v3 empaqueta en la dirección una clave pública de 32 bytes, un checksum de dos bytes y un campo de versión de un byte, y luego codifica el resultado en base32 en la conocida cadena de 56 caracteres que termina en d. En esa construcción no participa ningún registro, ninguna autoridad certificadora ni ningún resolvedor — la maquinaria que describe la RFC 1035 sencillamente nunca se ejecuta para este nombre, y por eso no hace falta nunca un registro DNS ni un puerto redirigido.

La publicación funciona igual, una capa más arriba. El servicio firma un descriptor y lo sube a relays de directorio redundantes; un cliente descarga ese descriptor, averigua qué puntos de introducción usa el servicio en ese momento y construye un circuito de rendezvous para que ambos lados se encuentren en medio. La IPv4 de tu servidor no aparece en ninguna parte del proceso — la especificación de rendezvous v3 define todo ese baile sin un solo socket público en el host. Lo que queda en disco es mínimo: el HiddenServiceDir contiene hostname, la clave pública y la clave privada, y nada más.

El error típico se deduce directamente de esa inversión. Operadores que copian el archivo hostname a un gestor de contraseñas, borran la máquina en una reconstrucción de rutina, reinstalan Tor y ven aparecer una dirección nueva en /var/lib/tor/. La cadena antigua sigue existiendo — sigue siendo aritmética válida — pero el par de claves que la convertía en tuya se ha perdido, y no hay procedimiento de recuperación porque no queda nada de qué recuperar. Cada enlace publicado, cada código QR y cada marcador apuntan ahora a un fantasma.

Todo lo que sigue — cinco líneas de torrc, sockets atados a localhost, copias de seguridad congeladas, autorización de clientes — es detalle ordenado en torno a este único hecho: la identidad vive en tus archivos, y el servidor es solo el lugar donde esos archivos ejecutan este mes.

La ubicación es una decisión de operaciones, no de accesibilidad

Como ningún resolvedor consulta nunca la dirección del rack, las doce ciudades con datacenter sirven un .onion igual de bien; no hay una bandera «Tor-friendly» que perseguir ni un suplemento por ubicación que valga la pena pagar por accesibilidad. Lo que esa bandera decide de verdad es tu latencia de ida y vuelta mientras editas configuraciones de madrugada, la ley penal que rige el disco y el multiplicador de la factura — Reikiavik y Oslo llevan x1.2, Zúrich x1.35, Luxemburgo x1.15, y todas las demás sedes facturan a tarifa base.

La accesibilidad la decide la construcción del circuito. Un cliente arma una ruta por tres relays hasta un punto de rendezvous, el servicio construye su propia ruta de tres relays hasta el mismo punto, y el par de rutas se encuentra ahí — seis relays de extremo a extremo, y el rack solo habla con su propio guard. La latencia que notas en el navegador la domina la ruta del cliente y el salto de rendezvous, no si el datacenter está en Tokyo o en Frankfurt.

Elige pues por los criterios que sobreviven al contacto con el uso diario. La latencia administrativa importa cuando empujas cambios de configuración veinte veces por semana; un sitio europeo gestionado desde Europa justifica un rack europeo solo por el tiempo de tecleo. La ley del datacenter importa aún más: Islandia no obliga a retención de datos, Suiza aplica su propia ley federal de protección de datos fuera de la UE, y una ciudad de la UE pone la jurisprudencia del GDPR al alcance de cualquier denunciante. Las FAQ de servicios onion del Tor Project responden por el lado del protocolo; el lado jurisdiccional lo decides tú, una vez y por escrito, antes de que llegue la primera factura.

Dónde se rompe esto: operadores que eligen una sede lejana por razones folclóricas y luego pagan 180 ms por pulsación durante toda la vida del proyecto, o que trasladan el servicio entre países cada mes y no entienden por qué la rotación de guards hace que la dirección parezca inestable. El movimiento frecuente de circuitos también republica descriptores, lo que no compra nada y añade un retardo de arranque de decenas de segundos tras cada reinicio.

Elige la sede una sola vez, por una latencia que puedas tolerar y una ley que hayas leído de verdad, y deja el mapa tranquilo: dedica la atención ahorrada a la capa de sockets, que es donde suele esconderse la exposición real.

Cinco líneas de torrc, y ninguna es la parte difícil

La gente espera que alojar un onion sea un laberinto; el camino real de instalación es un repositorio, dos directivas y un reload. El laberinto está en otra parte — en sockets abiertos al mundo, en claves sin copia de seguridad, en paquetes desactualizados. Deja las cinco líneas bien a la primera y el resto de la hora de trabajo es higiene, que es lo que decide de verdad si el servicio sobrevive a su primer año. Todo lo que viene asume una imagen KVM con root, donde tú controlas el kernel, el gestor de paquetes y el firewall, porque un contenedor restringido te pondrá pegas en cada uno de estos pasos.

Instala desde el repositorio propio del Tor Project y no desde el canal base de la distribución, porque las funciones del daemon avanzan rápido: las defensas contra denegación de servicio en los puntos de introducción y la autorización de clientes moderna requieren 0.4.3 o superior. Luego la declaración mínima son dos líneas — HiddenServiceDir /var/lib/tor/app/ y HiddenServicePort 80 127.0.0.1:8080 — seguidas de systemctl reload tor@default, según el manual de systemctl. En segundos el directorio contiene un archivo hostname, y el servicio ya es alcanzable por el túnel incluso antes de terminar la aplicación.

Dos declaraciones pequeñas se ganan su sitio en una máquina de solo servicios. SocksPort 0 cierra el proxy SOCKS local que no estás usando, lo que elimina de la auditoría un socket a la escucha entero, gratis. Fijar HiddenServiceVersion 3 mantiene los archivos de configuración antiguos portables entre actualizaciones del daemon, y dejar el valor por defecto de tres puntos de introducción ya es razonable para la mayoría de los lanzamientos — súbelo solo cuando los datos de tráfico, y no la ansiedad, lo digan.

El fallo clásico: un operador instala el daemon viejo de años de la distro, escribe directivas de la era v3 y recibe un error de configuración que parece un problema de protocolo. El segundo clásico: apuntar HiddenServicePort a un backend que aún no está a la escucha, ver fallar curl y concluir que el onion está roto cuando lo que pasa es que la aplicación simplemente no está levantada. Lee journalctl -u tor@default antes de tocar nada más; el log dice sin rodeos qué lado del túnel rechazó la conexión.

Con el daemon al día y las dos directivas en su sitio, el túnel existe — ahora todo el proyecto restante consiste en asegurar que nada en la máquina responda a nadie excepto a ese túnel.

Ata el servicio a localhost, o el onion es decoración

Un onion delante de una aplicación que además escucha en 0.0.0.0 es una puerta con cerradura colgada de una pared abierta: Tor tunela puntualmente el tráfico hacia 127.0.0.1:8080 mientras el mismo puerto responde a cada escáner que recorre el rango IPv4 durante la noche. El túnel añade una entrada privada; no elimina la pública que dejaste entreabierta, y nada en lo discreto que fluye tu tráfico esconde la dirección impresa en la factura que pagaste.

Audita primero los sockets a la escucha, porque son la verdad de terreno: ss -tlnp debería mostrar la aplicación atada a 127.0.0.1:8080 y nada más en direcciones públicas. Si la aplicación no puede atarse a una dirección de loopback por configuración, cierra el puerto en el firewall con nft de modo que solo exista el camino de loopback. La solución más limpia, cuando el stack lo permite, prescinde del TCP por completo: HiddenServicePort 80 unix:/run/app.sock le entrega a la aplicación un socket Unix que no tiene presencia en la red en absoluto.

Si debe existir un espejo en clearnet, díselo a Tor Browser: publicar una cabecera Onion-Location en el sitio HTTPS, tal como describe la guía de Onion-Location, hace que el navegador ofrezca la versión onion a los visitantes que pueden usarla. La cabecera cuesta una línea en la configuración del servidor web y mueve a tus lectores más vulnerables — los que necesitan el onion y no sabían que existía — al túnel sin una sola página de redirección.

El falso positivo que hay que vigilar: probar con curl desde la máquina hacia sí misma funciona, se declara el servicio sellado, y mientras tanto ss muestra el puerto respondiendo en la interfaz pública todo el tiempo. Los paneles de staging y los exportadores de métricas reinciden — un node exporter en el 9090 o una interfaz de administración de base de datos atada en amplio sobreviven a cualquier migración a onion porque nunca fueron parte del túnel. Pide Core a tarifa de $6/mes — $4.80 en el plazo anual — y mantén todo el stack en una máquina pequeña hasta que el tráfico real diga otra cosa.

Cuando la única entrada es el túnel, cada decisión posterior — claves, defensas, autorización — se acumula en lugar de compensar, que es exactamente la posición en la que quieres tener el proyecto.

Haz copia de la clave como de una credencial, no como de un archivo de configuración

La caída irreversible más común en el hosting onion no es un fallo de hardware; es un redeploy que regenera el par de claves. Las imágenes de disco se reconstruyen, /var/lib/tor se formatea, y meses de enlaces publicados pierden su destino como efecto secundario de una sola transacción de apt. El hardware muere con estrépito y se reemplaza en menos de una hora; un par de claves borrado muere en silencio y se lleva la dirección por delante, que es una combinación estrictamente peor para ti.

Congela la identidad con un procedimiento deliberado: detén el daemon con systemctl stop tor@default, archiva el directorio completo del servicio — hostname, clave pública y hs_ed25519_secret_key — con tar czf, cifra el archivo con gpg según la documentación de GnuPG, y guárdalo en un sitio que no sea ni el servidor ni la carpeta de descargas de tu estación de trabajo. Ese mismo archivo traslada después el servicio a hardware nuevo — el patrón de migración sin caídas empieza justo aquí. Restaurar es el camino inverso: mismo directorio, mismo propietario, reiniciar, y la dirección vuelve idéntica byte a byte. Pon el directorio en 700 y los archivos en 600 antes de que el daemon arranque siquiera una vez.

La dirección del escape es la imagen especular y es peor. Quien posea hs_ed25519_secret_key puede publicar descriptores para tu dirección y recibir a tus clientes de forma indistinguible — un clon que no necesita secuestro de DNS ni fraude de certificados, porque la dirección es la clave. Rotar significa generar un servicio nuevo, publicar la dirección nueva en todas partes y quemar la antigua; no hay lista de revocación, y por eso el almacenamiento de la copia importa tanto como su existencia.

Errores típicos: archivar solo el archivo hostname, que es la cadena pública y no vale nada por sí sola; o subir el directorio de claves a git para conservarlo, donde git log lo preserva a través de cada borrado posterior y los rastreadores de repositorios públicos cosechan claves onion a destajo. Un archivo cifrado en soporte offline te cuesta diez minutos; una dirección rotada cuesta cada enlace que hayas publicado jamás.

Trata el trío de claves como el conjunto de archivos más valioso de la máquina — vale más que la aplicación, la base de datos y los logs juntos — porque durante toda la vida de la dirección, eso es exactamente lo que es.

No tener IP que inundar no es lo mismo que no tener nada que defender

Los ataques volumétricos no tienen dirección a la que apuntar — el rack nunca ata un puerto de servicio público, así que las inundaciones de clase gigabit solo encuentran el borde del proveedor, y eso es una propiedad estructural del diseño, no un producto de filtrado que hayas comprado. Lo que queda es más silencioso y más cercano a la aplicación: inundaciones de peticiones a los puntos de introducción, churn de rendezvous y agotamiento de CPU que llega de un circuito aparentemente legítimo en cada momento, facturado por minuto.

Los daemons actuales traen defensas justo para esa capa. HiddenServiceEnableIntroDoSDefense 1 activa el limitado de tasa en el punto de introducción, con HiddenServiceEnableIntroDoSRatePerSec 25 y una ráfaga de 200 como números de partida para ajustar contra tráfico real. Bajo más presión, la defensa de prueba de trabajo del rendezvous hace que los clientes paguen un poco de CPU para conectarse, lo que encarece las inundaciones baratas de enviar y caras de absorber — el mecanismo está especificado en la especificación de rendezvous junto al resto del protocolo.

Sabe qué cubre y qué no cubre el filtrado DDoS incluido: protege la IP de clearnet por la que viajan tu SSH y tu monitorización, en el borde del datacenter, antes de que los paquetes te lleguen. El camino onion jamás toca ese scrubber porque jamás toca la interfaz pública, así que sus defensas viven una capa más arriba, en el daemon y la aplicación. Presupuesta CPU para la comprobación de prueba de trabajo igual que presupuestarías memoria para una caché — como coste de servir, no como anomalía.

El error corre en ambas direcciones. Algunos operadores asumen que la propiedad estructural lo cubre todo, se saltan por completo los límites de tasa a nivel de aplicación y se encuentran su primera inundación de introducción sin una zona limit_req en el servidor web, según la documentación del módulo de nginx. Otros montan un filtrado tan agresivo que trata el tráfico de salida de Tor como hostil y deja fuera precisamente a los lectores para los que existe el servicio. Ajusta contra logs, no contra el miedo.

Las defensas en este camino son baratas y aburridas — una bandera, dos tasas, una zona de peticiones — y importan exactamente una vez, el día en que llega el tráfico que no invitaste.

La autorización de clientes cierra la puerta sin abrir un puerto

Un onion privado — uno que solo los lectores autorizados pueden siquiera resolver — suena como si necesitara una VPN, un firewall y una base de datos de usuarios. En v3 no necesita nada de eso: el cifrado del descriptor hacia una lista de claves de cliente hace que los usuarios de Tor Browser no autorizados no reciban absolutamente nada, y el recuento de puertos abiertos en la máquina se queda exactamente en cero. La autorización ocurre antes del primer byte de tráfico de la aplicación, así que un escáner que nunca fue autorizado ni siquiera puede llamar a la puerta, y nunca tienes que explicárselo a un auditor.

La mecánica es pequeña. Genera un par de claves x25519 para cada cliente; suelta la mitad pública en el directorio authorized_clients/ del servicio como archivo .auth; entrega al lector la mitad privada en formato .auth_private para su propio ClientOnionAuthDir. A partir de ahí el descriptor queda cifrado exactamente para ese conjunto, y el directorio del servicio muestra quién tiene acceso sin que se cree ni una sola cuenta de usuario a nivel de aplicación. La guía de autorización de clientes recorre los formatos de archivo de principio a fin.

Operativamente, un par de claves por persona o por dispositivo gana a uno compartido, porque la revocación se convierte en un borrado de archivo y un reload: elimina el archivo .auth, recarga el daemon, y el siguiente ciclo de descriptores bloquea a ese cliente en minutos. Guarda la correspondencia entre archivos de clave y personas en el mismo almacén cifrado que las claves del servicio, o la lista de acceso se convierte en arqueología en un año y estarás emitiendo credenciales que no puedes auditar.

El fallo habitual es la confusión de épocas: HiddenServiceAuthorizeClient es una directiva de la era v2 y no hace nada en un servicio v3, así que las configuraciones que mezclan ambas se ejecutan silenciosamente sin autorización alguna. El segundo fallo es del lado del cliente — un archivo .auth_private mal nombrado produce el mismo síntoma visible que un servicio muerto, y la gente depura el túnel cuando el problema es un nombre de archivo. Ambos extremos necesitan un daemon actual, 0.4.3 o superior.

Para cualquier cosa con página de facturación, panel de administración o audiencia beta, la autorización cuesta menos que cualquier alternativa y falla cerrada por diseño.

La capa de políticas se lee igual a ambos lados del túnel

El anonimato de la dirección no reubica el disco. La política de uso aceptable se aplica a los hidden services exactamente igual que a los sitios de clearnet — solo contenido legal, nada de CSAM, phishing, spam ni tráfico de ataque — y un reporte de abuso sobre un .onion llega al host igual que llegaría uno sobre un dominio. El razonamiento completo es tema de la guía de legalidad offshore; aquí la conclusión operativa es simplemente que el túnel no es una jurisdicción, y ninguna directiva de torrc ha enmendado jamás una ley.

La gestión del abuso corre bajo la ley de la ubicación del datacenter, así que la sede que elegiste en la segunda sección es también el código legal al que responde tu disco. No es una formalidad para hojear de pasada: Islandia se lee distinto que una ciudad de la UE en materia de retención, y la lista de ubicaciones publica el nivel, el uplink y la ley aplicable de cada datacenter. Léela una vez por proyecto, no una vez en la vida, porque la ley del datacenter es la única variable de este stack que cambia sin tu participación y sin entrada en el changelog.

La higiene de la máquina es parte de la misma postura. Claves sobre contraseñas en SSH — PasswordAuthentication no en sshd_config, según el manual de sshd —, paneles alcanzados por túneles en lugar de expuestos, y un rol por máquina, porque los relays y los onions envejecen distinto y no comparten nada útil. Mover o limitar el puerto 22 compra silencio más barato que cualquier appliance, y nada de ello toca el camino del onion.

La suposición que mata proyectos silenciosamente aquí es que un pago sin KYC enmienda la capa de políticas. No lo hace: la lista de prohibiciones viaja con cada plan, y los operadores que lo ponen a prueba pierden la máquina sin importar cómo se pagó la factura. Cuando un backend crece más que la CPU compartida, o quieres una consola que funcione sin la pila de red, pide Forge a tarifa de $49/mes — $39.20 en el plazo anual — con IPMI en el nivel y la misma política adjunta.

Políticas, higiene y dimensionamiento de hardware son el mismo tema con tres sombreros: decídelos una vez, en ese orden, y el túnel deja de ser la parte interesante del proyecto.

El servicio onion, en el orden en que hay que montarlo

Ejecuta todo el camino de una sola pasada y se lee más corto que cualquier descripción. Aprovisiona una máquina KVM normal en la que sea de las doce ciudades la que encaje con tu latencia administrativa y tu lectura de la ley del datacenter — la geografía es irrelevante para la dirección, y los suplementos que existen (x1.2 Reikiavik, x1.35 Zúrich) están publicados, no se negocian. Tienes root desde el primer arranque, el registro pide un email o un token, y nada en el pago pide un nombre en ningún momento.

Segundo, instala Tor desde el repositorio del proyecto para que el daemon esté al día, y declara el servicio: HiddenServiceDir /var/lib/tor/app/ y HiddenServicePort 80 127.0.0.1:8080, reload, y lee el archivo hostname que aparece en segundos. Tercero, cierra las entradas públicas: la aplicación atada a loopback o a un socket Unix, verificado con ss -tlnp, con el firewall descartando todo lo que aún responda en una dirección pública tras el cambio.

Cuarto, congela la identidad antes de tocar cualquier otra cosa: detén el daemon, archiva y cifra el trío de claves, guárdalo fuera de la máquina, y ensaya la restauración una vez para que la dirección sobreviva a cada reconstrucción futura. Quinto, activa las defensas que de lo contrario olvidarás bajo presión — HiddenServiceEnableIntroDoSDefense 1 en los puntos de introducción, zonas de limitación de peticiones en la aplicación — y, si la audiencia es privada, autorización de clientes con un par de claves por lector en lugar de una clave compartida.

Sexto, conecta los puntos de las políticas: la AUP se aplica sin cambios, la ley del datacenter rige el disco, y la checklist de lanzamiento con datos mínimos cubre las capas que un túnel no cubre — registros del registrador, rastros de pago, certificados. Séptimo, vigila los logs durante una semana: publicación de descriptores, recuentos de circuitos, tráfico de introducción y los errores propios de la aplicación, porque un túnel que funciona delante de un backend roto es el estado final más común de un lanzamiento apresurado.

El orden importa más que cualquier paso individual: túnel primero, entradas cerradas segundo, claves congeladas tercero, defensas cuarto — porque cada etapa asume la anterior, y saltarse una etapa convierte un arreglo de cinco minutos en una reconstrucción con dirección nueva.