Transmission på Linux: tvinga utgående trafik per processägare

Att blockera Transmissions inkommande port är ingen VPN-policy. En torrentklient öppnar utgående anslutningar till peers och trackers, slår upp namn och kan exponera en lyssnare för fjärrstyrning, och var och en av dessa kan lämna systemet via ett gränssnitt du inte hade tänkt på. Gå igenom de fem kontrollerna i ordning och betrakta brandväggsregeln, inte klientens inställningar, som gränsen. De två sista kontrollerna är de som folk hoppar över, och de avgör om garantin håller när tunneln faller bort.

Namnge processen som äger överföringen

Skrivbordsprogrammet och systemdaemonen körs under olika konton, och en regel baserad på ägare följer kontot i stället för programnamnet. Ta reda på vilken av dem som körs innan du skriver någon regel. Ett särskilt tjänstekonto ger policyn ett exakt subjekt, medan en skrivbordsanvändare delar sin identitet med webbläsare, editorer och allt annat i sessionen. Bekräfta UID:t i stället för att anta att kontonamnet från paketet är det som används.

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

Om kontot inte finns ännu, skapa det för detta ändamål och ge det inget annat att köra. Skriv kontot och UID:t i regelns kommentar, för en regel utan subjekt är en regel som ingen kan redigera säkert.

Skilj lyssnarfälten från rutten

Transmission 4.x dokumenterar peer-lyssnaradresser separat från rpc-bind-address, och skillnaden spelar roll. RPC-inställningen styr bara fjärrstyrningslyssnaren, så att ändra den väljer ingen rutt för peer-trafiken. Att läsa de två inställningarna som en är det vanligaste skälet till att en till synes noggrann konfiguration ändå läcker. Samma dokumentation beskriver en återgång när en peer-lyssnaradress är ogiltig, så en otillgänglig adress är ett dokumenterat återgångsfall, inte ett garanterat nekande.

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

Använd klientens reglage för vad de är och lägg garantin i brandväggen. En lyssnarinställning kan fortfarande vara värd att använda, men den fastställer inte att trackerkontakt, lokal upptäckt eller en delegerad uppslagning alla lämnar systemet via tunneln. När de två är oense är det brandväggen som bestämmer.

Skriv ägarmatchningen i rätt kedja

Netfilter-manualen om ägarmatchning förklarar hur lokalt genererade paket tillskrivs den användare eller grupp som äger socketfilen. Den tillskrivningen omfattar inte vidarebefordrad trafik, och matchning av kompletterande grupper kräver ett uttryckligt alternativ. Läs manualen för det tillägg du faktiskt använder i stället för det första exemplet du hittar.

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

Ordningen spelar lika stor roll som matchningen. En bred accept tidigare i kedjan upphäver ett precist nekande senare, så granska hela kedjan i stället för att lägga till en regel och hoppas. Ta med båda adressfamiljerna om värden kör IPv6, för en policy som bara täcker v4 lämnar en väg öppen som ingen håller koll på. Håll reglerna installerade över omstarter av både klienten och tunneln.

Bestäm vad som händer när tun0 försvinner

Felstrategin är själva poängen med övningen. Om tunneln försvinner och samma hook tar bort reglerna är klienten fri att använda det fysiska gränssnittet tills något annat stoppar den. Den säkra designen behåller reglerna och låter dem neka, och det är det som gör gränsen oberoende av tunnelns hälsa. En teardown-hook som också raderar reglerna är motsatsen till en felstrategi.

ip link show tun0
iptables -S OUTPUT

Testa det med avsikt: stoppa tunneln, starta en överföring som är säker att överge och se om något lämnar systemet. Ta sedan tillbaka tunneln och bekräfta att den avsedda vägen fungerar igen.

Täck de vägar regeln inte ser

Namnuppslagning kan hanteras av en separat resolverprocess, och ett namespace eller en dedikerad gateway kan ge en annan gräns om dess delnings- och bootstrapvägar är utformade för det. Bestäm vilken komponent som äger DNS och om den följer samma utgående regel. Titta sedan på RPC: om rpc-whitelist används är det godkända hanteringsnätet en del av kontraktet, och ett brett RFC1918-intervall är det inte.

ss -tunp | grep -i transmission

Gränssnittsräknare kan styrka en observation, men de kan inte bevisa vilken process som producerade byten. Kör en överföring du får överge: först på den fungerande vägen, sedan utan tunnel vid start, därefter genom ett avbrott, en återanslutning och ett nyskapat gränssnitt. Testa både ett nytt försök och en anslutning som redan var öppen, för regeln kanske inte har tillämpats på den äldre socketen. Anteckna datum, konto och resultat tillsammans med testet.

Att klistra in ett exempel som rensar hela kedjan byter ett hål mot flera, så lägg till regler i stället för att radera dem. När alla fem kontrollerna passerar är garantin uttrycklig: klientens trafik lämnar systemet via tunneln eller inte alls, och regeln som tvingar fram det överlever tunnelns eget haveri.