Настройка Transmission-Daemon (серверный торрент-клиент) на использование прокси-сервера


Администрирование операционных систем на базе Linux (Debian/Ubuntu и Centos/RedHat) VPN-технологии для объединения офисов и обхода блокировок
127.0.0.1:9091 cv debian rpc-whitelist server transmission transmission daemon transmission-daemon ubuntu web гите настройка transmission настройка transmission-daemon порт 9091
 
 

* В этом блоге я описываю свою повседневную рабочую практику, поэтому все статьи в блоге написаны лично мной и при копировании их на свой сайт пожалуйста указывайте ссылку на страницу откуда вы скопировали.
* Если какая-то статья вам помогла, то вы можете дать мне немного денег вместо простого спасибо (ссылка на форму поддержки проекта внизу страницы), если вы что-то не поняли или у вас что-то не получается, то вы можете нанять меня и я вам все подробно расскажу (расценки и ссылки в конце статьи).


(последние правки 3 недели, 5 дней)

После сборки моего домашнего микро-сервера на базе BananaPI M1 с Ubuntu Server на борту, я естественно захотел загрузить его какой-то полезной работой и первое что приходит в голову, это настроить торрент-клиент который будет постоянно включен и будет управляться как со стационарного ПК, так и со смартфона.

Я уже раньше настраивал такую конструкцию когда у меня был свой торрент-трекер и серверная часть торрент-клиента была одним постоянно-активным сидом, что стоит отметить выгодно отличает от других мелких говнотрекеров где файл скачать невозможно потому как никто его не раздает.

Сейчас я попробую повторить, то что раньше уже делал и продемонстрирую, что сложного в такой реализации ничего особо то и нет.

WEB-интерфейс управления торрент-трекером Transmission

Начинаем с установки transmission-daemon при помощи типовой команды для Ubuntu Server:

# aptitude install transmission-daemon

После выполнения этой команды WEB-интерфейс управления торрент-трекер клиентом будет доступен на порту 9091, но он будет доступен для авторизации только с Localhost и вы можете удостовериться, что он работает выполнив SSH-подключение с пробросом порта:

# ssh -L9091:127.0.0.1:9091 root@192.168.3.216

При использовании проброса порта подключаться вам надо будет на свой локал-хост по адресу http://127.0.0.1:9091, в этом случае все откроется корректно, а пароль и логин по умолчанию для торрент-клиента Transmission:

  • Логин: transmission
  • Пароль: transmission

Естественно, что в реальной жизни использовать пробросы портов для подключения к торрент-клиенту, это откровенный перебор и сейчас мы его настроим. Все параметры торрент-демона находятся в файле /etc/transmission-daemon/settings.json и при его редактировании из консоли есть один небольшой нюанс на который надо обратить внимание.

Если вы отредактируете этот файл и выполните команду перезапуска демона, то все внесенные изменения будут утеряны и вносить правки в этот файл требуется при отключенном демоне. Отключите трансмиссон-демон при помощи команды:

# /etc/init.d/transmission-daemon stop

После чего внесите требуемые правки и снова его включите при помощи команды:

# /etc/init.d/transmission-daemon start

Согласен, что это неудобно, но так уж придумали его авторы, кстати это связано с механизмом сохранения настроек из WEB-интерфейса приложения.

Настройки сервера из Web-приложения

Часть настроек вы можете провести из Web-интерфейса, но не все и большинство необходимых базовых настроек скрыто под капотом в конфигурационном файле. Итак, погнали и начнем с авторизации и доступа к web-интерфейсу из локальной сети, а отвечают за это следующие параметры в конфигурационном файле:

    "rpc-authentication-required": true, 
    "rpc-bind-address": "0.0.0.0", 
    "rpc-enabled": true, 
    "rpc-host-whitelist": "", 
    "rpc-host-whitelist-enabled": false, 
    "rpc-password": "{d0a0f2d3wngp934yhnbae4044b16737745806WmozEuB", 
    "rpc-port": 9091, 
    "rpc-url": "/transmission/", 
    "rpc-username": "admin", 
    "rpc-whitelist": "127.0.0.1", 
    "rpc-whitelist-enabled": false,

Первым делом отключаем ограничения по IP-адресам которые смогут подключаться к Transmission и за это отвечают параметры rpc-host-whitelist-enabled и rpc-whitelist-enabled, для отключения ограничения доступа по IP-адресам клиентов просто установим их в False, а входящие подключения на порт 9091 разумнее ограничить при помощи iptables.

Парольная авторизация задается параметром rpc-authentication-required и если вы установите его в значение False, то будете авторизовываться без пароля, но для удаленного управления демоном через клиент для Андройд из интернет я бы все же оставил авторизацию, но смените логин и пароль задав из в параметрах rpc-username и rpc-password, причем в rpc-password укажите пароль просто незахэшированным текстом и при старте клиента он автоматически зашифруется.

Дальнейшие параметры настройте на ваш вкус из WEB-интерфейса или тут же в конфигурационном файле, есть еще кстати один параметр которого нет в WEB-интерфейсе, но он довольно важный и этот параметр download-queue-size, а именно длина одновременной очереди загрузки. Все, что больше длины этой очереди ставится в отложенные, а так как клиент я использую на редких раздачах где сиды появляются очень редко, то эта очередь уничтожает весь профит от использования торрент-демона.

Все параметры конфигурации вы можете найти на официальном сайте: https://github.com/transmission/transmission/wiki/Editing-Configuration-Files

Я думаю, что просмотрев список параметров каждый сможет настроить торрент-клиент под себя максимально гибко, а сейчас я перехожу к нетривиальным вопросам.

Как использовать Proxy-сервер при работе с Transmission daemon

До версии 1.4 вы могли использовать следующие параметры конфигурации:

    "proxy-authentication-required": false, 
    "proxy-port": 3128, 
    "proxy-server": "10.252.0.204", 
    "proxy-server-enabled": true, 
    "proxy-type": 0, 

Теперь эти параметры не работают и даже есть запрос в фиче-реквестах "Nice to have: add proxy support for announcers", это актуально для России где все приличные торрент-трекеры забанены Роскомнадзором и запрос данных с них возможен только через зарубежные прокси.

На официальном гите проекта в обсуждении говориться (https://github.com/transmission/transmission/issues/344), что поддержка прокси в трансмисии дело долгое и политическое, а решать они его в ближайшее время не будут:

Proxy support has a long history in Transmission...

 

Current, you could pass http_proxy environment variable (or any other variable outlined in curl documentation under ENVIRONMENT or elsewhere) to any Transmission client or the daemon to make it use proxy server for scrapes and announces. In fact, http_proxy is even mentioned in some of the respective man pages.

 

That's where it ends for now. There are no plans to support proxy more extensively, but if you want that to happen --- feel free to discuss here and make a pull request (which may or may not be accepted depending on its quality and demand).

Собственно на этом можно было бы торрент-клиент в Российских реалиях и закопать, если бы не уточнение, что:

you could pass http_proxy environment variable (or any other variable outlined in curl documentation under ENVIRONMENT or elsewhere) to any Transmission client or the daemon to make it use proxy server for scrapes and announces. In fact, http_proxy is even mentioned in some of the respective man pages.

Следовательно все не так уж и плохо и хотя в явном виде сконфигурировать его не получится, мы можем внести переменную или в инит-скрипт (для старых систем на базе SysV Init):

#!/bin/sh -e
### BEGIN INIT INFO
# Provides:          transmission-daemon
# Required-Start:    $local_fs $remote_fs $network
# Required-Stop:     $local_fs $remote_fs $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start or stop the transmission-daemon.
# Description:       Enable service provided by transmission-daemon.
### END INIT INFO

NAME=transmission-daemon
DAEMON=/usr/bin/$NAME
USER=debian-transmission
STOP_TIMEOUT=30

export PATH="${PATH:+$PATH:}/sbin"
export http_proxy="http://10.252.0.204:3128"

Или, что более вероятно у вас используется SystemD-юнит и его так-же необходимо настроить для задания переменной окружения:

[Unit]
Description=Transmission BitTorrent Daemon
After=network.target

[Service]
User=debian-transmission
Type=notify
Environment=http_proxy="http://10.252.0.204:3128"
ExecStart=/usr/bin/transmission-daemon -f --log-error
ExecReload=/bin/kill -s HUP $MAINPID

[Install]
WantedBy=multi-user.target

Как вы видите ничего сложного, есть конечно некоторые нюансы, но их просто надо знать, а я в свою очередь хотел бы вас задавать вопросы в комментариях, что вам непонятно или какие-то проблемы возможно у вас возникли при попытке повторить настройку демона по моей инструкции. Я всегда открыт к конструктивному диалогу.

Моя официальная страница на FaceBook
Мой микроблог в твиттер

Настройка простого SOCKS5-прокси сервера в Debian Linux

Настройка простого SOCKS5-прокси сервера в Debian Linux

Фактически, мне требовалось настроить проксирование трафика для одного браузера через удаленный хост - это задача достаточно типовая, поэтому сразу перейдем к делу и рассмотрим практическую реализацию этого кейса. 3proxy не входит в штатные пакеты Debian/Ubuntu, поэтому мы соберем его из исходных кодов. Дополнительно расскажу как можно ограничить доступ к 3Proxy-серверу по IP-адресу, если ваш роутер не поддрживает полноценные ограничения по адресам источника (Source IP).


Как сделать Double VPN - Подробная инструкция

Как сделать Double VPN - Подробная инструкция

В мире анонимайзеров нововведение, - Double VPN. Основной особенностью его является то, что сервер к которому мы подключаемся и сервер точкой выхода которого будет исходящий трафик, это два разных сервера, причем желательно расположенные в разных странах. Особой сложности реализация такого механизма не представляет, хотя некоторые интересные моменты там есть. Типовая схема реализации маршрутизации трафика через OpenVPN сервер использует механизм NAT и собственно сам OpenVPN в режиме изменения основного шлюза. В этом случае весь трафик клиента перенаправляется на сервер OpenVPN, где уже направляется далее в сеть Internet с подменой адреса источника.


OpenVPN-сеть для LXD-кластера без назначения адресов клиентов (использование стороннего DHCP для управления клиентами VPN-сети)

OpenVPN-сеть для LXD-кластера без назначения адресов клиентов (использование стороннего DHCP для управления клиентами VPN-сети)

Представляю вашему вниманию небольшой экскурс в активно используемую мной технологию построения распределенных виртуальных сетей на базе OpenVPN в немного непривычной реализации. Если вы работаете с OpenVPN технологиями, то наверное обратили внимание что практически все руководства описывают OpenVPN сеть где OpenVPN-сервер выступет в качестве DHCP-сервера и назначает адреса для своих клиентов, но я сегодня хотел бы предложить вам уйти от типовых реализаций.


Разработка собственного модуля авторизации для OpenVPN

Разработка собственного модуля авторизации для OpenVPN

Как вы наверное знаете помимо стандартной авторизации по ключам и сертификатам вы можете дополнительно использовать парольную защиту как дополняющий механизм к модели сертификатов или полностью перейти исключительно на парольную авторизацию. Стоит отметить, что защищенность OpenVPN с авторизацией с использованием Login/Password будет гораздо выше чем использование механизмов PPTP например.


Как вы наверное понимаете, бесплатно сейчас работать никто не будет и если ответ на ваш вопрос потребует больше трех минут времени и вам требуется полноценная консультация, то расценки на мои услуги представленны ниже.


Есть вопросы?
Спрашивайте и я обязательно вам отвечу!

* Поля обязательные для заполнения .