Transmission op Linux: útgeand ferkear ôftwinge per proseseigner

It ynkommende poart fan Transmission blokkearje is gjin VPN-belied. In torrentkliïnt iepenet útgeande ferbiningen nei peers en trackers, lost nammen op en kin in listener foar ôfstânbestjoering iepenje, en elk dêrfan kin fia in ynterface nei bûten gean dy’t jo net bedoelden. Wurkje de fiif kontrôles yn folchoarder ôf en beskôgje de firewallregel, net de ynstellings fan de klient, as de grins. De lêste twa kontrôles binne dy’t minsken oerslaan, en sy beslisse oft de garânsje hâldt as de tunnel fuortfalt.

Neam it proses dat de oerdracht besit

De desktopapplikaasje en de systeemdaemon rinne ûnder ferskillende akkounts, en in regel op grûn fan de eigner folget it akkount yn stee fan de programnamme. Fyn út hokker fan de twa rint ear’t jo in regel skriuwe. In taweijd serviceakkount jout it belied in presys subjekt, wylst in desktopbrûker syn identiteit dielt mei browsers, bewurkers en al it oare yn ’e sesje. Befêstigje de UID yn stee fan oan te nimmen dat de akkountnamme út it pakket de brûkte is.

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

Bestiet it akkount noch net, meitsje it dan foar dit doel oan en jou it neat oars te rinnen. Skriuw it akkount en de UID yn it kommentaar by de regel, want in regel sûnder subjekt is in regel dy’t nimmen feilich bewurkje kin.

Skied de listenerfjilden fan de rûte

Transmission 4.x dokumintearret peer-lústeradressen apart fan rpc-bind-address, en dat ferskil is wichtich. De RPC-ynstelling beheart allinnich de listener foar ôfstânbestjoering, dus it feroarjen dêrfan kiest gjin rûte foar peer-ferkear. Dizze twa ynstellings as ien lêze is de meast foarkommende reden wêrom’t in soarchfâldich lykjende konfiguraasje dochs lekt. Deselde dokumintaasje beskriuwt in weromfal as in peer-lústeradres ûnjildich is, dus in net-beskikber adres is in dokumintearre weromfalfel, gjin garandearre wegering.

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

Brûk de bedieningseleminten fan de klient foar wat se binne, en liz de garânsje yn ’e firewall. In listenerynstelling kin noch altyd de muoite wurdich wêze, mar se bewiist net dat tracker-kontakt, pleatslike ûntdekking of in delegearre opsocht alles troch de tunnel nei bûten geane. As de twa it net iens binne, beslút de firewall.

Skriuw de eigner-match yn ’e juste keatling

De Netfilter-hantlieding oer de eigner-match ferklearret hoe’t pleatslik generearre pakketten taskreaun wurde oan de brûker of groep dy’t it socketbestân besit. Dy taskriuwing rint net mei oant trochstjoerd ferkear, en it matsen fan oanfoljende groepen freget in eksplisite opsje. Lês de hantlieding foar de útwreiding dy’t jo wier brûke yn stee fan it earste foarbyld dat jo fine.

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

De folchoarder is like wichtich as de match. In brede akseptaasje earder yn ’e keatling docht in presys wegering letter te nijtte, dus besjoch de hiele keatling yn stee fan in regel ta te foegjen en te hoopjen. Nim beide adresfamyljes op as de host IPv6 rint, want in belied dat allinnich v4 dekt lit in paad iepen dat nimmen yn ’e gaten hâldt. Hâld de regels ynstallearre oer herstarts fan sawol de klient as de tunnel.

Beslút wat der bart as tun0 ferdwynt

It flaterbelied is it punt fan ’e oefening. As de tunnel ferdwynt en deselde hook ferwideret de regels, is de klient frij om de fysike ynterface te brûken oant iets oars him stoppet. It feilige ûntwerp hâldt de regels en lit se wegerje, en dat makket de grins ûnôfhinklik fan ’e sûnens fan ’e tunnel. In teardown-hook dy’t ek de regels ferwideret, is it tsjinoerstelde fan in flaterbelied.

ip link show tun0
iptables -S OUTPUT

Test it bewust: stop de tunnel, start in oerdracht dy’t feilich is om oer te jaan en sjoch oft der wat nei bûten giet. Bring de tunnel dan werom en befêstigje dat it bedoelde paad wer wurket.

Dek de paden dy’t de regel net sjocht

Namme-oplossing kin troch in apart resolverproses behannele wurde, en in namespace of tawijde gateway kin in oare grins biede as syn diel- en bootstrap-paden dêrfoar ûntwurpen binne. Beslút hokker komponint DNS besit en oft it deselde útgeande regel folget. Sjoch dan nei RPC: as rpc-whitelist yn gebrûk is, is it goedkarde beheartnetwurk diel fan it kontrakt, en in breed RFC1918-berik net.

ss -tunp | grep -i transmission

Ynterface-tellers kinne in waarnimming befêstigje, mar se kinne net bewize hokker proses de bytes produsearre hat. Doch in oerdracht dy’t jo oerjaan meie: earst op it wurkjende paad, dan sûnder tunnel by it opstarten, en dêrnei troch in ûnderbrekking, in werferbining en in nij oanmakke ynterface. Test sawol in nije poging as in ferbining dy’t al iepen wie, want de regel is mooglik net tapast op ’e âldere socket. Skriuw de datum, it akkount en it resultaat by de test.

In foarbyld plakke dat de hiele keatling leechmakket, ruilet ien gat foar ferskate, dus foegje regels ta yn stee fan se te wiskjen. As alle fiif kontrôles slagje, is de garânsje eksplisyt: it ferkear fan ’e klient giet troch de tunnel nei bûten of hielendal net, en de regel dy’t dat ôftwingt oerlibbet it falen fan ’e tunnel sels.