Transmission på Linux: håndhæv udgående trafik pr. procesejer
Peer-porten er ikke hele historien. Afgræns firewallreglen til klientens konto, dæk begge adressefamilier og test med tunnelen nede.
At blokere Transmissions indgående port er ikke en VPN-politik. En torrentklient åbner udgående forbindelser til peers og trackere, slår navne op og kan eksponere en fjernstyringslytter, og hver af disse kan forlade systemet gennem et interface, du ikke havde tænkt på. Gå de fem kontroller igennem i rækkefølge, og betragt firewallreglen, ikke klientens indstillinger, som grænsen. De sidste to kontroller er dem, folk springer over, og de afgør, om garantien holder, når tunnelen falder bort.
Navngiv den proces, der ejer overførslen
Skrivebordsprogrammet og systemdaemonen kører under forskellige konti, og en regel baseret på ejer følger kontoen i stedet for programnavnet. Find ud af, hvilken af de to der kører, før du skriver nogen regel. En dedikeret servicekonto giver politikken et præcist subjekt, mens en skrivebordsbruger deler sin identitet med browsere, editorer og alt andet i sessionen. Bekræft UID’en i stedet for at antage, at kontonavnet fra pakken er det, der bruges.
systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon
Findes kontoen ikke endnu, så opret den til dette formål og giv den ikke andet at køre. Skriv konto og UID i reglens kommentar, for en regel uden subjekt er en regel, som ingen kan redigere sikkert.
Adskil lyttefelterne fra ruten
Transmission 4.x dokumenterer peer-lytteadresser adskilt fra rpc-bind-address, og forskellen betyder noget. RPC-indstillingen styrer kun fjernstyringslytteren, så en ændring af den vælger ikke en rute for peer-trafik. At læse de to indstillinger som én er den mest almindelige grund til, at en omhyggeligt udseende konfiguration stadig lækker. Samme dokumentation beskriver et fallback, når en peer-lytteadresse er ugyldig, så en utilgængelig adresse er et dokumenteret fallback-tilfælde, ikke en garanteret afvisning.
grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json
Brug klientens styringer til det, de er, og læg garantien i firewallen. En lytteindstilling kan stadig være værd at bruge, men den fastslår ikke, at tracker-kontakt, lokal opdagelse eller et delegeret opslag alle forlader systemet gennem tunnelen. Når de to er uenige, er det firewallen, der bestemmer.
Skriv ejer-matchningen i den rigtige kæde
Netfilter-manualen om ejer-matchning forklarer, hvordan lokalt genererede pakker tilskrives den bruger eller gruppe, der ejer socketfilen. Den tilskrivning gælder ikke for videresendt trafik, og matchning af supplerende grupper kræver en eksplicit option. Læs manualen for den udvidelse, du faktisk bruger, i stedet for det første eksempel, du finder.
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
Rækkefølgen betyder lige så meget som matchningen. En bred accept tidligere i kæden ophæver en præcis afvisning senere, så gennemgå hele kæden i stedet for at tilføje en regel og håbe. Medtag begge adressefamilier, hvis værten kører IPv6, for en politik, der kun dækker v4, efterlader en vej åben, som ingen holder øje med. Hold reglerne installeret gennem genstart af både klient og tunnel.
Beslut, hvad der sker, når tun0 forsvinder
Fejlpolitikken er hele pointen. Hvis tunnelen forsvinder, og det samme hook fjerner reglerne, er klienten fri til at bruge det fysiske interface, indtil noget andet stopper den. Det sikre design beholder reglerne og lader dem afvise, og det er dét, der gør grænsen uafhængig af tunnelens helbred. Et teardown-hook, der også sletter reglerne, er det stik modsatte af en fejlpolitik.
ip link show tun0
iptables -S OUTPUT
Test det med vilje: stop tunnelen, start en overførsel, som det er sikkert at opgive, og se, om der kommer noget ud. Bring derefter tunnelen tilbage, og bekræft at den tilsigtede vej virker igen.
Dæk de veje, reglen ikke kan se
Navneopløsning kan håndteres af en separat resolverproces, og et namespace eller en dedikeret gateway kan give en anden grænse, hvis dens delings- og bootstrap-veje er designet til det. Beslut, hvilken komponent der ejer DNS, og om den følger samme udgående regel. Se derefter på RPC: hvis rpc-whitelist er i brug, er det godkendte administrationsnetværk en del af kontrakten, og et bredt RFC1918-interval er ikke.
ss -tunp | grep -i transmission
Interface-tællere kan underbygge en observation, men de kan ikke bevise, hvilken proces der har produceret byteene. Kør en overførsel, du må opgive: først på den fungerende vej, derefter uden tunnel ved opstart, og så gennem en afbrydelse, en genopkobling og et nyoprettet interface. Test både et nyt forsøg og en forbindelse, der allerede var åben, for reglen er måske ikke blevet anvendt på den ældre socket. Notér dato, konto og resultat sammen med testen.
At indsætte et eksempel, der rydder hele kæden, bytter ét hul for flere, så tilføj regler i stedet for at slette dem. Når alle fem kontroller består, er garantien udtrykkelig: klientens trafik forlader systemet gennem tunnelen eller slet ikke, og reglen, der håndhæver det, overlever tunnelens eget svigt.