Transmission en Linux: forzar a saída por propietario do proceso

Bloquear o porto de entrada de Transmission non é unha política de VPN. Un cliente de torrents abre conexións de saída cara aos pares e aos rastrexadores, resolve nomes e pode expor un escoitador de control remoto, e cada unha desas saídas pode saír por unha interface que non previra. Percorra as cinco comprobacións en orde e trate a regra da devasa, non os axustes do cliente, como a fronteira. As dúas últimas comprobacións son as que a xente salta, e son as que deciden se a garantía se mantén cando o túnel cae.

Nomear o proceso propietario da transferencia

A aplicación de escritorio e o daemon do sistema execútanse con contas distintas, e unha regra baseada no propietario segue a conta en vez do nome do programa. Avereigüe cal dos dous está en execución antes de escribir calquera regra. Unha conta de servizo dedicada dá á política un suxeito preciso, mentres que un usuario de escritorio comparte a súa identidade con navegadores, editores e todo o demais da sesión. Confirme o UID en lugar de supoñer que o nome de conta do paquete é o que se usa.

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

Se a conta aínda non existe, créaa para este fin e non lle dea nada máis que executar. Escriba a conta e o UID no comentario da regra, porque unha regra sen suxeito é unha regra que ninguén pode editar con seguridade.

Separar os campos de escoita da ruta

Transmission 4.x documenta os enderezos de escoita de pares por separado de rpc-bind-address, e a diferenza importa. O axuste RPC só controla o escoitador de control remoto, así que cambialo non escolle unha ruta para o tráfico de pares. Ler os dous axustes como un só é a razón máis común de que unha configuración de aspecto coidadoso siga filtrando. A mesma documentación describe un retroceso cando un enderezo de escoita de pares non é válido, así que un enderezo non dispoñible é un caso de retroceso documentado, non unha negativa garantida.

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

Use os controis do cliente para o que son e poña a garantía na devasa. Un axuste de escoita pode seguir merecendo a pena, pero non establece que o contacto cos rastrexadores, o descubrimento local ou unha resolución delegada saian todos polo túnel. Cando os dous discrepan, é a devasa a que decide.

Escribir a coincidencia de propietario na cadea correcta

O manual de Netfilter sobre a coincidencia de propietario explica como os paquetes xerados localmente se atribúen ao usuario ou grupo propietario do ficheiro de socket. Esa atribución non se estende ao tráfico reenviado, e a coincidencia de grupos suplementarios necesita unha opción explícita. Lea o manual da extensión que realmente está a usar en lugar do primeiro exemplo que atope.

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

A orde importa tanto como a coincidencia. Unha aceptación ampla máis arriba na cadea anula un rexeitamento preciso máis abaixo, así que revise toda a cadea en vez de engadir unha regra e esperar. Inclúa ambas as familias de enderezos se o hospedador executa IPv6, porque unha política só de v4 deixa aberto un camiño que ninguén vixía. Manteña as regras instaladas a través dos reinicios tanto do cliente como do túnel.

Decidir que pasa cando o tun0 desaparece

A política de fallo é o centro do exercicio. Se o túnel desaparece e o mesmo hook retira as regras, o cliente queda libre de usar a interface física ata que algo máis o deteña. O deseño seguro conserva as regras e déixaas rexeitar, e é iso o que fai a fronteira independente da saúde do túnel. Un hook de desmontaxe que tamén borra as regras é o contrario dunha política de fallo.

ip link show tun0
iptables -S OUTPUT

Próbeo a propósito: pare o túnel, inicie unha transferencia que poida abandonar sen risco e observe se sae algo. Despois devolve o túnel e confirme que o camiño previsto volve funcionar.

Cubrir os camiños que a regra non ve

A resolución de nomes pode tratarse nun proceso resolvedor separado, e un espazo de nomes ou unha pasarela dedicada poden ofrecer outra fronteira se os seus camiños de compartición e de arranque están deseñados para iso. Decida que compoñente é propietario do DNS e se segue a mesma regra de saída. Despois mire o RPC: se se usa rpc-whitelist, a rede de xestión aprobada forma parte do contrato, e un intervalo RFC1918 amplo non.

ss -tunp | grep -i transmission

Os contadores de interface poden corroborar unha observación, pero non poden demostrar que proceso produciu os bytes. Faga unha transferencia que teña permiso para abandonar: primeiro polo camiño que funciona, despois sen túnel ao arrancar, e logo a través dunha interrupción, unha reconexión e unha interface creada de novo. Probe tanto un intento novo como unha conexión que xa estaba aberta, porque pode que a regra non se aplicase ao socket máis antigo. Anote a data, a conta e o resultado coa proba.

Pegar un exemplo que baleira toda a cadea troca un burato por varios, así que engada regras en vez de borralas. Cando pasan as cinco comprobacións, a garantía é explícita: o tráfico do cliente sae polo túnel ou non sae, e a regra que o impón sobrevive ao fallo do propio túnel.