Transmission op Linux: dwing uitgaande verkeer per proses-eienaar af

Om Transmission se inkomende poort te blokkeer is nie ’n VPN-beleid nie. ’n Torrentkliënt maak uitgaande verbindings na peers en trackers oop, los name op en kan ’n afstandbeheer-listener blootstel, en elkeen van dié dinge kan deur ’n koppelvlak uitgaan wat jy nie bedoel het nie. Werk die vyf kontroles in volgorde deur en beskou die firewallreël, nie die kliënt se instellings nie, as die grens. Die laaste twee kontroles is die wat mense oorslaan, en hulle bepaal of die waarborg hou wanneer die tonnel wegval.

Noem die proses wat die oordrag besit

Die lessenaartoepassing en die stelseldaemon loop onder verskillende rekeninge, en ’n reël op grond van die eienaar volg die rekening eerder as die programnaam. Vind uit watter een loop voordat jy enige reël skryf. ’n Toegewyde diensrekening gee die beleid ’n presiese subjek, terwyl ’n lessenaargebruiker sy identiteit met blaaiers, redigeerders en alles anders in die sessie deel. Bevestig die UID eerder as om aan te neem dat die rekeningnaam uit die pakket die een is wat gebruik word.

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

As die rekening nog nie bestaan nie, skep dit vir hierdie doel en gee dit niks anders om te loop nie. Skryf die rekening en UID in die reël se kommentaar, want ’n reël sonder ’n subjek is ’n reël wat niemand veilig kan wysig nie.

Skei die luistervelde van die roete

Transmission 4.x dokumenteer peer-luisteradresse apart van rpc-bind-address, en die verskil maak saak. Die RPC-instelling beheer net die afstandbeheer-listener, so om dit te verander kies nie ’n roete vir peer-verkeer nie. Om die twee instellings as een te lees is die algemeenste rede waarom ’n sorgvuldig lykende konfigurasie steeds lek. Dieselfde dokumentasie beskryf ’n terugval wanneer ’n peer-luisteradres ongeldig is, so ’n onbeskikbare adres is ’n gedokumenteerde terugvalgeval, nie ’n gewaarborgde weiering nie.

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

Gebruik die kliënt se kontroles vir wat hulle is, en plaas die waarborg in die firewall. ’n Luisterinstelling kan steeds die moeite werd wees, maar dit bewys nie dat tracker-kontak, plaaslike ontdekking of ’n gedelegeerde opsoek almal deur die tonnel uitgaan nie. Wanneer die twee verskil, is dit die firewall wat besluit.

Skryf die eienaar-passing in die regte ketting

Die Netfilter-handleiding oor die eienaar-passing verduidelik hoe plaaslik gegenereerde pakkette aan die gebruiker of groep wat die socketlêer besit, toegeskryf word. Dié toeskrywing strek nie na deurgestuurde verkeer nie, en die passing van bykomende groepe vereis ’n eksplisiete opsie. Lees die handleiding vir die uitbreiding wat jy werklik gebruik eerder as die eerste voorbeeld wat jy vind.

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

Die volgorde maak net so veel saak soos die passing. ’n Breë aanvaarding vroeër in die ketting verydel ’n presiese weiering later, so hersien die hele ketting eerder as om ’n reël by te voeg en te hoop. Sluit albei adresfamilies in as die gasheer IPv6 loop, want ’n beleid wat net v4 dek laat ’n pad oop wat niemand dop nie. Hou die reëls geïnstalleer oor herstarte van beide die kliënt en die tonnel.

Besluit wat gebeur wanneer tun0 verdwyn

Die foutbeleid is die punt van die oefening. As die tonnel verdwyn en dieselfde haak verwyder die reëls, is die kliënt vry om die fisiese koppelvlak te gebruik tot iets anders dit stop. Die veilige ontwerp hou die reëls en laat hulle weier, en dit is wat die grens onafhanklik van die tonnel se gesondheid maak. ’n Afbreekhaak wat ook die reëls uitwis, is die teenoorgestelde van ’n foutbeleid.

ip link show tun0
iptables -S OUTPUT

Toets dit doelbewus: stop die tonnel, begin ’n oordrag wat veilig is om te laat vaar en kyk of iets uitgaan. Bring dan die tonnel terug en bevestig dat die beoogde pad weer werk.

Dek die paaie wat die reël nie kan sien nie

Naamoplossing kan deur ’n aparte resolverproses hanteer word, en ’n naamruimte of toegewyde gateway kan nog ’n grens bied as sy deel- en bootstrap-paaie daarvoor ontwerp is. Besluit watter komponent DNS besit en of dit dieselfde uitgaande reël volg. Kyk dan na RPC: as rpc-whitelist in gebruik is, is die goedgekeurde bestuursnetwerk deel van die kontrak, en ’n breë RFC1918-reeks nie.

ss -tunp | grep -i transmission

Koppelvlak-tellers kan ’n waarneming bevestig, maar hulle kan nie bewys watter proses die grepe geproduseer het nie. Voer ’n oordrag uit wat jy mag laat vaar: eers op die werkende pad, dan sonder tonnel by die opstart, dan deur ’n onderbreking, ’n herverbinding en ’n nuut geskepte koppelvlak. Toets beide ’n nuwe poging en ’n verbinding wat al oop was, want die reël is moontlik nie op die ouer socket toegepas nie. Teken die datum, die rekening en die resultaat saam met die toets aan.

Om ’n voorbeeld te plak wat die hele ketting leegmaak, ruil een gat vir verskeie, so voeg reëls by eerder as om hulle uit te wis. Wanneer al vyf kontroles slaag, is die waarborg uitdruklik: die kliënt se verkeer gaan deur die tonnel uit of glad nie, en die reël wat dit afdwing, oorleef die tonnel se eie faling.