Transmission en Linux: forzar la salida por propietario del proceso

Bloquear el puerto entrante de Transmission no es una política de VPN. Un cliente de torrents abre conexiones salientes hacia pares y rastreadores, resuelve nombres y puede exponer un escucha de control remoto, y cada una de esas salidas puede irse por una interfaz que usted no pretendía. Recorra las cinco comprobaciones en orden y trate la regla del cortafuegos, no los ajustes del cliente, como la frontera. Las dos últimas comprobaciones son las que la gente se salta, y son las que deciden si la garantía se sostiene cuando el túnel se cae.

Nombrar el proceso dueño de la transferencia

La aplicación de escritorio y el demonio del sistema se ejecutan con cuentas distintas, y una regla basada en el propietario sigue a la cuenta, no al nombre del programa. Averigüe cuál de los dos está en marcha antes de escribir cualquier regla. Una cuenta de servicio dedicada da a la política un sujeto preciso, mientras que un usuario de escritorio comparte su identidad con navegadores, editores y todo lo demás de la sesión. Confirme el UID en lugar de suponer que el nombre de cuenta empaquetado es el que se usa.

systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon

Si la cuenta aún no existe, créela para este fin y no le dé nada más que ejecutar. Escriba la cuenta y el UID en el comentario de la regla, porque una regla sin sujeto es una regla que nadie puede editar con seguridad.

Separar los campos de escucha de la ruta

Transmission 4.x documenta las direcciones de escucha de pares por separado de rpc-bind-address, y la diferencia importa. El ajuste RPC controla solo el escucha de control remoto, así que cambiarlo no elige una ruta para el tráfico de pares. Leer los dos ajustes como uno solo es la razón más común de que una configuración de aspecto cuidadoso siga filtrando. La misma documentación describe un repliegue cuando una dirección de escucha de pares no es válida, así que una dirección no disponible es un caso de repliegue documentado, no una negativa garantizada.

grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

Use los controles del cliente para lo que son y ponga la garantía en el cortafuegos. Un ajuste de escucha puede seguir valiendo la pena, pero no establece que el contacto con rastreadores, el descubrimiento local o una resolución delegada salgan todos por el túnel. Cuando los dos discrepan, es el cortafuegos el que decide.

Escribir la coincidencia de propietario en la cadena correcta

El manual de Netfilter sobre la coincidencia de propietario explica cómo se atribuyen los paquetes generados localmente al usuario o grupo propietario del archivo de socket. Esa atribución no se extiende al tráfico reenviado, y la coincidencia de grupos suplementarios necesita una opción explícita. Lea el manual de la extensión que realmente está usando en lugar del primer ejemplo que encuentre.

iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT

El orden importa tanto como la coincidencia. Una aceptación amplia al principio de la cadena anula un rechazo preciso más abajo, así que revise la cadena entera en vez de añadir una regla y confiar. Incluya ambas familias de direcciones si el host ejecuta IPv6, porque una política solo de v4 deja abierto un camino que nadie vigila. Mantenga las reglas instaladas a través de los reinicios tanto del cliente como del túnel.

Decidir qué pasa cuando tun0 desaparece

La política de fallo es el centro del ejercicio. Si el túnel desaparece y el mismo hook retira las reglas, el cliente queda libre de usar la interfaz física hasta que algo más lo detenga. El diseño seguro conserva las reglas y deja que rechacen, que es lo que hace que la frontera sea independiente de la salud del túnel. Un hook de desmontaje que además borra las reglas es lo contrario de una política de fallo.

ip link show tun0
iptables -S OUTPUT

Pruébelo a propósito: detenga el túnel, inicie una transferencia que pueda abandonar sin riesgo y observe si algo sale. Luego devuelva el túnel y confirme que la ruta prevista funciona de nuevo.

Cubrir las rutas que la regla no ve

La resolución de nombres puede gestionarla un proceso resolutor aparte, y un espacio de nombres o una pasarela dedicada pueden aportar otra frontera si sus rutas de compartición y de arranque están diseñadas para ello. Decida qué componente es dueño del DNS y si sigue la misma regla de salida. Luego mire el RPC: si se usa rpc-whitelist, la red de gestión aprobada forma parte del contrato, y un rango RFC1918 amplio no.

ss -tunp | grep -i transmission

Los contadores de interfaz pueden corroborar una observación, pero no pueden demostrar qué proceso produjo los bytes. Ejecute una transferencia que tenga permitido abandonar: primero por la ruta que funciona, luego sin túnel al arrancar, después a través de una interrupción, una reconexión y una interfaz recién creada. Pruebe tanto un intento nuevo como una conexión que ya estaba abierta, porque puede que la regla no se aplicara al socket anterior. Anote la fecha, la cuenta y el resultado junto con la prueba.

Pegar un ejemplo que vacía toda la cadena cambia un agujero por varios, así que añada reglas en vez de borrarlas. Cuando pasan las cinco comprobaciones, la garantía es explícita: el tráfico del cliente sale por el túnel o no sale, y la regla que lo impone sobrevive al fallo del propio túnel.