Transmission no Linux: impor a saída por proprietário do processo

Bloquear a porta de entrada do Transmission não é uma política de VPN. Um cliente de torrents abre ligações de saída para pares e trackers, resolve nomes e pode expor um serviço de controlo remoto, e cada uma dessas saídas pode escapar por uma interface que não pretendia. Percorra as cinco verificações por ordem e trate a regra da firewall, e não as definições do cliente, como a fronteira. As duas últimas verificações são as que se saltam, e são elas que decidem se a garantia se mantém quando o túnel cai.

Identificar o processo proprietário da transferência

A aplicação de ambiente de trabalho e o daemon do sistema correm com contas diferentes, e uma regra baseada no proprietário segue a conta e não o nome do programa. Descubra qual dos dois está em execução antes de escrever qualquer regra. Uma conta de serviço dedicada dá à política um sujeito preciso, enquanto um utilizador de ambiente de trabalho partilha a sua identidade com navegadores, editores e tudo o resto da sessão. Confirme o UID em vez de assumir que o nome de conta do pacote é o que está em uso.

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

Se a conta ainda não existe, crie-a para este efeito e não lhe dê mais nada para executar. Escreva a conta e o UID no comentário da regra, porque uma regra sem sujeito é uma regra que ninguém pode editar em segurança.

Separar os campos de escuta da rota

O Transmission 4.x documenta os endereços de escuta de pares separadamente de rpc-bind-address, e a diferença importa. A definição RPC controla apenas o serviço de controlo remoto, pelo que alterá-la não escolhe uma rota para o tráfego de pares. Ler as duas definições como uma só é a razão mais comum para uma configuração de aparência cuidada continuar a fugir. A mesma documentação descreve um recurso de reserva para quando um endereço de escuta de pares é inválido, pelo que um endereço indisponível é um caso de reserva documentado, não uma recusa garantida.

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

Use os controlos do cliente para aquilo que são e coloque a garantia na firewall. Uma definição de escuta pode ainda valer a pena, mas não estabelece que o contacto com trackers, a descoberta local ou uma resolução delegada saiam todos pelo túnel. Quando as duas coisas discordam, é a firewall que decide.

Escrever a correspondência de proprietário na cadeia certa

O manual do Netfilter sobre a correspondência de proprietário explica como os pacotes gerados localmente são atribuídos ao utilizador ou grupo proprietário do ficheiro de socket. Essa atribuição não se estende ao tráfego reencaminhado, e a correspondência de grupos suplementares exige uma opção explícita. Leia o manual da extensão que está realmente a usar em vez do primeiro exemplo que encontrar.

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 ordem importa tanto como a correspondência. Uma aceitação ampla mais acima na cadeia anula uma rejeição precisa mais abaixo, por isso reveja a cadeia inteira em vez de acrescentar uma regra e esperar. Inclua ambas as famílias de endereços se o anfitrião executar IPv6, porque uma política apenas v4 deixa aberto um caminho que ninguém vigia. Mantenha as regras instaladas ao longo dos reinícios tanto do cliente como do túnel.

Decidir o que acontece quando o tun0 desaparece

A política de falha é o objetivo do exercício. Se o túnel desaparecer e o mesmo hook remover as regras, o cliente fica livre de usar a interface física até algo mais o parar. O desenho seguro mantém as regras e deixa-as rejeitar, e é isso que torna a fronteira independente da saúde do túnel. Um hook de desmontagem que também apaga as regras é o oposto de uma política de falha.

ip link show tun0
iptables -S OUTPUT

Teste-o de propósito: pare o túnel, inicie uma transferência que possa abandonar sem risco e observe se algo sai. Depois reponha o túnel e confirme que o caminho pretendido volta a funcionar.

Cobrir os caminhos que a regra não vê

A resolução de nomes pode ser tratada por um processo resolvedor separado, e um namespace ou uma gateway dedicada podem fornecer outra fronteira se os seus caminhos de partilha e de arranque forem concebidos para isso. Decida que componente é dono do DNS e se segue a mesma regra de saída. Depois olhe para o RPC: se rpc-whitelist estiver em uso, a rede de gestão aprovada faz parte do contrato, e um intervalo RFC1918 amplo não faz.

ss -tunp | grep -i transmission

Os contadores de interface podem corroborar uma observação, mas não podem provar que processo produziu os bytes. Faça uma transferência que lhe é permitido abandonar: primeiro no caminho que funciona, depois sem túnel no arranque, a seguir através de uma interrupção, de uma reconexão e de uma interface criada de fresco. Teste tanto uma tentativa nova como uma ligação já aberta, porque a regra pode não ter sido aplicada ao socket mais antigo. Registe a data, a conta e o resultado junto com o teste.

Colar um exemplo que limpa a cadeia inteira troca um buraco por vários, por isso acrescente regras em vez de as apagar. Quando as cinco verificações passam, a garantia é explícita: o tráfego do cliente sai pelo túnel ou não sai de todo, e a regra que o impõe sobrevive à falha do próprio túnel.