Transmission pe Linux: impune ieșirea pe proprietarul procesului

A bloca portul de intrare al Transmission nu este o politică VPN. Un client torrent deschide conexiuni de ieșire către parteneri și trackere, rezolvă nume și poate expune un ascultător de control la distanță, iar fiecare dintre acestea poate ieși printr-o interfață la care nu v-ați gândit. Parcurgeți cele cinci verificări în ordine și tratați regula de firewall, nu setările clientului, ca fiind granița. Ultimele două verificări sunt cele pe care lumea le sare, și ele decid dacă garanția rezistă atunci când tunelul cade.

Numiți procesul care deține transferul

Aplicația desktop și demonul de sistem rulează sub conturi diferite, iar o regulă bazată pe proprietar urmează contul, nu numele programului. Aflați care dintre ele rulează înainte de a scrie vreo regulă. Un cont de serviciu dedicat dă politicii un subiect precis, în timp ce un utilizator desktop își împarte identitatea cu browsere, editoare și tot restul sesiunii. Confirmați UID-ul în loc să presupuneți că numele de cont din pachet este cel folosit.

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

Dacă contul nu există încă, creați-l în acest scop și nu îi dați nimic altceva de rulat. Scrieți contul și UID-ul în comentariul regulii, pentru că o regulă fără subiect este o regulă pe care nimeni nu o poate edita în siguranță.

Separați câmpurile de ascultare de rută

Transmission 4.x documentează adresele de ascultare pentru parteneri separat de rpc-bind-address, iar diferența contează. Setarea RPC controlează doar ascultătorul de control la distanță, așa că modificarea ei nu alege o rută pentru traficul către parteneri. Citirea celor două setări ca una singură este cel mai frecvent motiv pentru care o configurație aparent îngrijită încă mai scapă. Aceeași documentație descrie o soluție de rezervă atunci când o adresă de ascultare pentru parteneri este invalidă, așa că o adresă indisponibilă este un caz de rezervă documentat, nu un refuz garantat.

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

Folosiți controalele clientului pentru ceea ce sunt și puneți garanția în firewall. O setare de ascultare poate merita în continuare, dar nu stabilește că legătura cu trackerele, descoperirea locală sau o rezoluție delegată trec toate prin tunel. Când cele două nu sunt de acord, firewallul este cel care decide.

Scrieți potrivirea de proprietar în lanțul corect

Manualul Netfilter despre potrivirea de proprietar explică modul în care pachetele generate local sunt atribuite utilizatorului sau grupului proprietar al fișierului socket. Această atribuire nu se extinde la traficul redirecționat, iar potrivirea grupurilor suplimentare necesită o opțiune explicită. Citiți manualul extensiei pe care o folosiți de fapt, nu primul exemplu pe care îl găsiți.

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

Ordinea contează la fel de mult ca potrivirea. O acceptare largă mai sus în lanț anulează un refuz precis mai jos, așa că revedeți tot lanțul în loc să adăugați o regulă și să sperați. Includeți ambele familii de adrese dacă gazda rulează IPv6, pentru că o politică doar v4 lasă deschisă o cale pe care nimeni nu o supraveghează. Păstrați regulile instalate peste repornirile atât ale clientului, cât și ale tunelului.

Decideți ce se întâmplă când tun0 dispare

Politica de eșec este miezul exercițiului. Dacă tunelul dispare și același hook elimină regulile, clientul este liber să folosească interfața fizică până când altceva îl oprește. Designul sigur păstrează regulile și le lasă să refuze, iar asta face granița independentă de sănătatea tunelului. Un hook de demontare care șterge și regulile este opusul unei politici de eșec.

ip link show tun0
iptables -S OUTPUT

Testați-l intenționat: opriți tunelul, porniți un transfer pe care vă puteți permite să îl abandonați și urmăriți dacă iese ceva. Apoi readuceți tunelul și confirmați că traseul dorit funcționează din nou.

Acoperiți căile pe care regula nu le vede

Rezolvarea numelor poate fi gestionată de un proces resolver separat, iar un namespace sau un gateway dedicat pot oferi o altă graniță dacă traseele lor de partajare și de pornire sunt proiectate pentru asta. Decideți ce componentă deține DNS-ul și dacă urmează aceeași regulă de ieșire. Apoi priviți RPC: dacă rpc-whitelist este în uz, rețeaua de administrare aprobată face parte din contract, iar un interval RFC1918 larg nu.

ss -tunp | grep -i transmission

Contoarele de interfață pot corobora o observație, dar nu pot dovedi ce proces a produs octeții. Faceți un transfer pe care aveți voie să îl abandonați: mai întâi pe calea care funcționează, apoi fără tunel la pornire, apoi printr-o întrerupere, o reconectare și o interfață creată de curând. Testați atât o încercare nouă, cât și o conexiune deja deschisă, pentru că regula poate să nu fi fost aplicată socketului mai vechi. Notați data, contul și rezultatul împreună cu testul.

A lipi un exemplu care golește tot lanțul schimbă o gaură pe mai multe, așa că adăugați reguli în loc să le ștergeți. Când trec toate cele cinci verificări, garanția este explicită: traficul clientului iese prin tunel sau deloc, iar regula care o impune supraviețuiește defecțiunii tunelului însuși.