Transmission sur Linux: devigi eliron laŭ la procesposedanto

Blokado de la envena pordego de Transmission ne estas VPN-politiko. Torrent-kliento malfermas elirajn konektojn al samuloj kaj spuriloj, solvas nomojn kaj povas malkaŝi malproksiman regan aŭskultanton, kaj ĉiu el tiuj povas eliri tra interfaco, kiun vi ne intencis. Trapasu la kvin kontrolojn en ordo kaj traktu la fajroŝirman regulon, ne la agordojn de la kliento, kiel la limon. La lastaj du kontroloj estas tiuj, kiujn homoj preterlasas, kaj ili decidas, ĉu la garantio teniĝas, kiam la tunelo falas.

Nomu la proceson, kiu posedas la transigon

La labortabla aplikaĵo kaj la sistema demono funkcias sub malsamaj kontoj, kaj regulo bazita sur posedanto sekvas la konton anstataŭ la programan nomon. Eltrovu, kiu el la du funkcias, antaŭ ol skribi ajnan regulon. Dediĉita servo-konto donas al la politiko precizan subjekton, dum labortabla uzanto dividas sian identecon kun retumiloj, redaktiloj kaj ĉio alia en la seanco. Konfirmu la UID anstataŭ supozi, ke la pakaĵa konta nomo estas la uzata.

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

Se la konto ankoraŭ ne ekzistas, kreu ĝin por ĉi tiu celo kaj donu al ĝi nenion alian por funkciigi. Skribu la konton kaj la UID en la komenton de la regulo, ĉar regulo sen subjekto estas regulo, kiun neniu povas sekure redakti.

Apartigu la aŭskultajn kampojn de la vojo

Transmission 4.x dokumentas samulajn aŭskultajn adresojn aparte de rpc-bind-address, kaj la diferenco gravas. La agordo RPC regas nur la malproksiman regan aŭskultanton, do ŝanĝo de ĝi ne elektas vojon por samula trafiko. Legi la du agordojn kiel unu estas la plej ofta kialo, ke ŝajne zorgema agordo ankoraŭ likas. La sama dokumentaro priskribas rezervan solvon, kiam samula aŭskulta adreso estas nevalida, do nehavebla adreso estas dokumentita rezerva kazo, ne garantiita rifuzo.

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

Uzu la regilojn de la kliento por tio, kio ili estas, kaj metu la garantion en la fajroŝirmilon. Aŭskulta agordo povas ankoraŭ indi uzi, sed ĝi ne pruvas, ke spurila kontakto, loka malkovro aŭ delegita serĉo ĉiuj eliras tra la tunelo. Kiam la du malkonsentas, la fajroŝirmilo decidas.

Skribu la posedantan kongruaĵon en la ĝusta ĉeno

La Netfilter-manlibro pri la posedanta kongruaĵo klarigas, kiel loke generitaj pakaĵoj atribuiĝas al la posedanta uzanto aŭ grupo de la soketa dosiero. Tiu atribuo ne etendiĝas al plusendita trafiko, kaj kongruigo de pliaj grupoj bezonas eksplicitan opcion. Legu la manlibron por la etendaĵo, kiun vi efektive uzas, anstataŭ la unuan ekzemplon, kiun vi trovas.

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

La ordo gravas same kiel la kongruaĵo. Larĝa akcepto pli frue en la ĉeno nuligas precizan rifuzon pli poste, do revizu la tutan ĉenon anstataŭ aldoni regulon kaj esperi. Inkluzivu ambaŭ adresajn familiojn, se la gastiganto funkciigas IPv6, ĉar politiko nur por v4 lasas malfermitan vojon, kiun neniu observas. Tenu la regulojn instalitaj tra restartoj de la kliento kaj de la tunelo.

Decidu, kio okazas, kiam tun0 malaperas

La fiask-politiko estas la kerno de la ekzerco. Se la tunelo malaperas kaj la sama hoko forigas la regulojn, la kliento rajtas uzi la fizikan interfacon, ĝis io alia haltigas ĝin. La sekura dezajno konservas la regulojn kaj lasas ilin rifuzi, kaj tio faras la limon sendependa de la sano de la tunelo. Malkonstrua hoko, kiu ankaŭ forviŝas la regulojn, estas la malo de fiask-politiko.

ip link show tun0
iptables -S OUTPUT

Testu ĝin intence: haltigu la tunelon, komencu transigon, kiun vi rajtas forlasi, kaj observu, ĉu io eliras. Poste redonu la tunelon kaj konfirmu, ke la intencita vojo denove funkcias.

Kovru la vojojn, kiujn la regulo ne vidas

Nomosolvado povas esti pritraktata de aparta solvila proceso, kaj nomspaco aŭ dediĉita pordego povas provizi alian limon, se ĝiaj dividaj kaj startaj vojoj estas dizajnitaj por tio. Decidu, kiu komponento posedas DNS kaj ĉu ĝi sekvas la saman eliran regulon. Poste rigardu RPC: se rpc-whitelist estas en uzo, la aprobita administra reto estas parto de la kontrakto, kaj larĝa RFC1918-gamo ne estas.

ss -tunp | grep -i transmission

Interfacaj nombriloj povas subteni observon, sed ili ne povas pruvi, kiu proceso produktis la bajtojn. Faru transigon, kiun vi rajtas forlasi: unue sur la funkcianta vojo, poste sen tunelo ĉe lanĉo, kaj poste tra interrompo, rekonekto kaj nove kreita interfaco. Testu kaj novan provon kaj konekton, kiu jam estis malfermita, ĉar la regulo eble ne aplikiĝis al la pli malnova soketo. Notu la daton, la konton kaj la rezulton kune kun la testo.

Alglui ekzemplon, kiu malplenigas la tutan ĉenon, interŝanĝas unu truon kontraŭ pluraj, do aldonu regulojn anstataŭ forviŝi ilin. Kiam ĉiuj kvin kontroloj pasas, la garantio estas eksplicita: la trafiko de la kliento eliras tra la tunelo aŭ tute ne, kaj la regulo, kiu devigas tion, postvivas la fiaskon de la tunelo mem.