Transmission в Linux: ограничете изходящия трафик по собственик на процеса

Блокирането на входящия порт на Transmission не е VPN политика. Торент клиентът отваря изходящи връзки към партньори и тракери, разрешава имена и може да поддържа слушател за дистанционно управление, и всеки от тези потоци може да излезе през интерфейс, който не сте предвидили. Преминете през петте проверки по ред и считайте за граница правилото на защитната стена, а не настройките на клиента. Последните две проверки обикновено се пропускат и именно те решават дали гаранцията се запазва, когато тунелът падне.

Назовете процеса, който притежава прехвърлянето

Настолното приложение и системният демон работят под различни акаунти, а правило по собственик следва акаунта, а не името на програмата. Разберете кой от двата работи, преди да напишете правило. Отделен служебен акаунт дава на политиката точен субект, докато настолният потребител споделя самоличността си с браузъри, редактори и всичко останало в сесията. Потвърдете UID, вместо да предполагате, че името на акаунта от пакета е използваното.

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

Ако акаунтът още не съществува, създайте го за тази цел и не му давайте нищо друго за изпълнение. Запишете акаунта и UID в коментара на правилото, защото правило без субект е правило, което никой не може да редактира безопасно.

Разделете полетата за слушане от маршрута

Transmission 4.x документира адресите за слушане на партньори отделно от rpc-bind-address, и тази разлика е важна. Настройката RPC управлява само слушателя за дистанционно управление, така че промяната ѝ не избира маршрут за партньорския трафик. Четенето на двете настройки като една е най-честата причина конфигурация, която изглежда внимателна, все още да изтича. Същата документация описва резервен вариант, когато адрес за слушане на партньори е невалиден, тоест недостъпният адрес е документиран резервен случай, а не гарантиран отказ.

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

Използвайте средствата на клиента по предназначение и поставете гаранцията в защитната стена. Настройката за слушане все още може да е полезна, но тя не доказва, че връзката с тракерите, локалното откриване или делегираното търсене излизат през тунела. Когато двете се разминават, решава защитната стена.

Запишете съвпадението по собственик в правилната верига

Ръководството на Netfilter за съвпадението по собственик обяснява как локално създадените пакети се приписват на потребителя или групата, които притежават файла на сокета. Това приписване не обхваща препращания трафик, а съпоставянето на допълнителни групи изисква явна опция. Четете ръководството за разширението, което действително използвате, а не първия намерен пример.

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

Редът е също толкова важен, колкото съвпадението. Широко разрешение по-горе във веригата обезсмисля точно забранено по-долу, затова прегледайте цялата верига, вместо да добавите правило и да се надявате. Включете двете семейства адреси, ако хостът работи с IPv6, защото политика само за v4 оставя отворен път, който никой не следи. Пазете правилата инсталирани при рестартиране както на клиента, така и на тунела.

Решете какво се случва, когато tun0 изчезне

Политиката при отказ е същината на упражнението. Ако тунелът изчезне и същата кука премахне правилата, клиентът е свободен да използва физическия интерфейс, докато нещо друго не го спре. Безопасният дизайн запазва правилата и им позволява да отказват, и точно това прави границата независима от здравето на тунела. Кука за демонтаж, която също изтрива правилата, е точно обратното на политика при отказ.

ip link show tun0
iptables -S OUTPUT

Тествайте го нарочно: спрете тунела, започнете прехвърляне, което е безопасно да изоставите, и наблюдавайте дали нещо излиза. След това върнете тунела и потвърдете, че желаният път отново работи.

Покрийте пътищата, които правилото не вижда

Разрешаването на имена може да се обработва от отделен процес резолвер, а именно пространство или отделен шлюз могат да дадат друга граница, ако пътищата им за споделяне и зареждане са проектирани за това. Решете кой компонент отговаря за DNS и дали следва същото правило за изход. След това погледнете RPC: ако се използва rpc-whitelist, одобрената мрежа за управление е част от договора, а широк диапазон RFC1918 не е.

ss -tunp | grep -i transmission

Броячите на интерфейса могат да потвърдят наблюдение, но не могат да докажат кой процес е създал байтовете. Направете прехвърляне, което ви е позволено да изоставите: първо по работещия път, после без тунел при стартиране, след това през прекъсване, повторно свързване и новосъздаден интерфейс. Тествайте както нов опит, така и вече отворена връзка, защото правилото може да не е приложено към по-стария сокет. Запишете датата, акаунта и резултата заедно с теста.

Поставянето на пример, който изчиства цялата верига, заменя една дупка с няколко, затова добавяйте правила, вместо да ги изтривате. Когато и петте проверки минат, гаранцията е явна: трафикът на клиента излиза през тунела или никак, и правилото, което го налага, преживява собствения отказ на тунела.