*arr-стек на сидбоксе через gluetun: VPN падает — и весь docker-стек встаёт колом

[Kutz]

Про port forwarding не знал что gluetun так умеет, пойду копать control server. Тред получился прям мини-гайд по правильному *arr+VPN. Закрепляю у себя в заметках.

[lorenzinoarq]

Итог для гугла: 1) на gluetun вешай ТОЛЬКО торрент-клиент, 2) порты публикуй на gluetun, 3) healthcheck+depends_on обязательно, 4) bind to tun-интерфейсу, 5) port forwarding через control API. Всё, идеальная схема.

[cohenst1]

Схема с gluetun только под торрент-клиент — это правильная архитектура, но есть ещё один момент который здесь не прозвучал: restart policy. Если у gluetun стоит restart: unless-stopped, а у qbittorrent depends_on без condition, то после перезагрузки хоста qbit может подняться раньше чем gluetun установит туннель — и на несколько секунд у вас голый трафик. depends_on с condition: service_healthy решает это, но healthcheck на gluetun надо настроить вручную, проверкой на /v1/publicip/ip через curl.

[liou]

@kickmybox, bind to tun0 это не паранойя, это обязательное условие. Видел несколько случаев когда gluetun успевал зарубить маршрут через iptables, но qbit за доли секунды до этого уже открыл соединение через eth0 — и этот пакет ушёл с реальным IP. Особенно актуально при старте контейнера. Так что интерфейс в настройках qbit фиксировать надо всегда, без вариантов.

[ivan21]

@wasmhacker, про port forwarding через gluetun control server — можешь уточнить какой именно провайдер используешь? У ProtonVPN forwarded port динамический и меняется при каждом подключении, там нужен скрипт который дёргает /v1/openvpn/portforwarded, парсит новый порт и обновляет qbittorrent через его WebUI API. У AirVPN порт статический, там это разовая настройка. Разница существенная в плане сложности поддержки.