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

Лічильники інтерфейсу можуть підтвердити спостереження, але не можуть довести, який процес породив байти. Проведіть передавання, яке дозволено перервати: спершу робочим шляхом, потім без тунелю під час запуску, далі через переривання, повторне підключення й щойно створений інтерфейс. Перевірте і нову спробу, і вже відкрите з’єднання, бо правило могло не застосуватися до старого сокета. Запишіть дату, обліковий запис і результат разом із перевіркою.

Вставляти приклад, який очищає весь ланцюжок, — це міняти одну діру на кілька, тож додавайте правила, а не видаляйте їх. Коли всі п’ять перевірок пройдено, гарантія явна: трафік клієнта виходить через тунель або нікуди, і правило, яке це забезпечує, переживає власний збій тунелю.