Была задача протестировать клиент transmission заместо qbittorrent. Оба клиента должны были работать на сервере без X11, тоесть в виде службы/демона на сервере.

По началу все настраивается достаточно просто по этой инструкции. Или похоже на нее, но на русском тут.

После некоторого ковыряния с правами пользователя чтобы transmission мог создавать файлы/папки и выставление нужных настроек не забываем в настройка включить опцию:

lpd-enabled

Она отвечает за обнаружение клиентов в локальной сети и по каким-то причинам она персоначально выключена.

Далее идёт самое интересно. У меня никак не хотел работать проброс портов. В web-интерфейсе упорно было написан статус порта:

Closed

Проверил что:
настройки transmission и проброса правильные, если проверять статус порта отдельной(не через web-интерфейс transmission, то порт открыт)
пробовал менять peer port
менял peer-port-random с диапазонами открытых портов
включал опцию port-forwarding
проверял что порт действительно прослушивается на linux
на аналогичном клиенте, но на другой машине(windows) точно такой же порт работал, работал в том числе на этом же порте и qbittorrent
никакой фаервол и прочее явно не мешает


Что выяснилось:

1) Transmission проверяет доступность порта через
portcheck.transmissionbt.com
Аналогично можно проверить тоже самое самому через curl Проверка порта 80 для IPv4:

curl -v -4 https://portcheck.transmissionbt.com/80

Проверка порта 80 для IPv6:

curl -v -6 https://portcheck.transmissionbt.com/80

Но проверяет он его по умолчанию по IPv6.
Способа 'правильно' выключить ipv6 в transmission 3.0 я не нашел. Скорее всего такой опции просто нету. Варианты решения:
a) Выключаем ipv6 на машине совсем
b) Меняем
bind-address-ipv6
с

"bind-address-ipv6": "::",

на

"bind-address-ipv6": "fe80::",

В случае с изменением через конфиг это скорее 'хак'. Т.к. transmission пытается 'забиндиться' на этот адрес и не может по итогу используя вместо этого ipv4.

И вот вроде бы проблему решили, но проблемы тем не менее на этом не закончились.

2) Как уже было написано ранее порт проверяется через portcheck.transmissionbt.com и если выполнить такой же запрос через curl, то он завершается с ошибкой невалидного сертификата.

Скорее всего дело в том что ubuntu относительно старый, а сертификаты letsencrypt уже 'протухли'.

Исходники transmission поменять мы не можем(можем конечно, но кто будет собирать его из исходников?), а способ взять свежий transmission 4.x с ppa репозитория у меня с 'пол пинка' не заработало. Поэтому решил таки настроить версию 3.0 до конца.

Варианты решения:
1) Обновить корневые сертификаты в ubuntu
2) Отключить проверку сертификатов

Добавлять новые корневые сертификаты в ubuntu я не стал хотя и обновил пакет ca-certs через apt который закреплен за дистрибутивом ubuntu которым я пользоватлся, но этого видимо было мало. У нас все таки не сайтик работает, а bittorrent клиент, посему я решил воспользоваться вариантом 2.

Исходники мне не собираем и перехват трафика делать мы не будем. Можно конечно поменять адрес локально для другого сервера чтобы на другом сервере проверять порт, но мы сделаем попроще. Воспользумеся переменными окружения.

Интересующая нас опция называется

CURLOPT_SSL_VERIFYPEER=false

Добавляем мы её в systemd юнит

transmission-daemon.service

Будет выглядеть это так

[Service]
Environment="CURLOPT_SSL_VERIFYPEER=false"

Сохраняем изменения. Не забываем выполнить

systemctl daemon-reload

и вновь запускаем transmission.

Радуемся надписи 'Open' в статусе проброса порта!