haugene / docker-transmission-openvpn

Docker container running Transmission torrent client with WebUI over an OpenVPN tunnel
GNU General Public License v3.0
4.08k stars 1.2k forks source link

pull request 2196 breaking-change; privoxy only listens to eth0 (not eth1, eth2 etc.) #2398

Closed planetrocky closed 1 year ago

planetrocky commented 1 year ago

Is there a pinned issue for this?

Is there an existing or similar issue/discussion for this?

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Docker run config used

N/A

Current Behavior

privoxy no longer listens to eth1

Expected Behavior

privoxy used to listen to eth1

How have you tried to solve the problem?

rolled back to release 4.0

Log output

N/A

HW/SW Environment

- OS:
- Docker: yes

Anything else?

No response

planetrocky commented 1 year ago

https://github.com/haugene/docker-transmission-openvpn/pull/2196

edgd1er commented 1 year ago

proxy used to listen to all adresses (0.0.0.0) including vpn, turning your container into an open proxy, not sure this is what you want. You can either push a merge request to specify interface to listen to or define a way to listen to all safe interfaces.

samuv commented 1 year ago

I was using this as a proxy too 🤔 , I use this image inside my QNAP NAS with docker-compose, something like:

version: '3.7'

services:
  transmission:
    image: haugene/transmission-openvpn:latest
    container_name: transmission
    networks:
      - media_server
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
        - "net.ipv6.conf.all.disable_ipv6=0"
    restart: unless-stopped
    ports:
      - 9091:9091
      - 8888:8888
      - 5055:5055 #myservice
    dns:
      - 8.8.8.8
      - 1.1.1.1
    volumes:
      - transmission:/data
    environment:
      - PUID=1000
      - PGID=0
      - TZ=Europe/Rome
      - CREATE_TUN_DEVICE=true
      - OPENVPN_PROVIDER=PROTONVPN
      - OPENVPN_USERNAME=
      - OPENVPN_PASSWORD=
      - OPENVPN_CONFIG=ch.protonvpn.com.udp,es.protonvpn.com.udp
      - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
      - WEBPROXY_ENABLED=true
      - WEBPROXY_PORT=8888
      - LOCAL_NETWORK=192.168.0.0/16
      - HEALTH_CHECK_HOST=google.com
      - TRANSMISSION_BLOCKLIST_ENABLED=true
      - TRANSMISSION_BLOCKLIST_URL=https://github.com/Naunter/BT_BlockLists/raw/master/bt_blocklists.gz
      - TRANSMISSION_RATIO_LIMIT=0.1
      - TRANSMISSION_RATIO_LIMIT_ENABLED=true
      - TRANSMISSION_SPEED_LIMIT_UP=2000
      - TRANSMISSION_SPEED_LIMIT_UP_ENABLED=true
      - TRANSMISSION_WEB_UI=flood-for-transmission

  other-service:
    image: myservice
    container_name: myservice
    network_mode: service:transmission
    depends_on:
      - transmission
    environment:
      - PUID=1000
      - PGID=0
      - TZ=Europe/Rome
    volumes:
      - stuff/config:/config
    restart: unless-stopped

networks:
  media_server:
    driver: bridge

and now I'm stuck in boot loop, could be related to this change?

haugene commented 1 year ago

@samuv I think your boot loop could be the combination of devices and CREATE_TUN_DEVICE. Would need to get some logs as well but have a look at #2393 and #2389

samuv commented 1 year ago

@samuv I think your boot loop could be the combination of devices and CREATE_TUN_DEVICE. Would need to get some logs as well but have a look at #2393 and #2389

Ok thanks @haugene, after your advice, I have tried different things:

I have removed from the config the device and left CREATE_TUN_DEVICE=true, but the error persisted, so I tried to also remove the sysctls and set OPENVPN_OPTS= to empty, and it works 🥳

I should try again, enabling one change at a time to understand what the problem was, but this config works for me:

version: '3.7'

services:
  transmission:
    image: haugene/transmission-openvpn:latest
    container_name: transmission
    networks:
      - media_server
    cap_add:
      - NET_ADMIN
    restart: unless-stopped
    ports:
      - 9091:9091
      - 1111:1111 #other-service
    dns:
      - 8.8.8.8
      - 1.1.1.1
    volumes:
      - /share/transmission/:/data
      - /share/open-vpn:/etc/openvpn/custom
    environment:
      - PUID=1000
      - PGID=0
      - TZ=Europe/Rome
      - CREATE_TUN_DEVICE=true
      - OPENVPN_PROVIDER=PROTONVPN
      - OPENVPN_USERNAME=
      - OPENVPN_PASSWORD=
      - OPENVPN_CONFIG=ch.protonvpn.net.udp,lv.protonvpn.net.udp
      - OPENVPN_OPTS=
      - VPN_CONFIG_SOURCE=auto
      - LOCAL_NETWORK=192.168.0.0/16
      - HEALTH_CHECK_HOST=google.com
      - TRANSMISSION_BLOCKLIST_ENABLED=true
      - TRANSMISSION_BLOCKLIST_URL=https://github.com/Naunter/BT_BlockLists/raw/master/bt_blocklists.gz
      - TRANSMISSION_RATIO_LIMIT=0.1
      - TRANSMISSION_RATIO_LIMIT_ENABLED=true
      - TRANSMISSION_SPEED_LIMIT_UP=2000
      - TRANSMISSION_SPEED_LIMIT_UP_ENABLED=true
      - TRANSMISSION_WEB_UI=flood-for-transmission
    logging:
      driver: json-file
      options:
        max-size: 10m

  other-service:
    image: myservice
    container_name: myservice
    network_mode: service:transmission
    depends_on:
      - transmission
    environment:
      - PUID=1000
      - PGID=0
      - TZ=Europe/Rome
    volumes:
      - stuff/config:/config
    restart: unless-stopped

networks:
  media_server:
    driver: bridge
planetrocky commented 1 year ago

proxy used to listen to all adresses (0.0.0.0) including vpn, turning your container into an open proxy, not sure this is what you want. You can either push a merge request to specify interface to listen to or define a way to listen to all safe interfaces.

My setup has the proxy on eth1, so this is a breaking change for me - everything stopped working on latest pull, had to debug.

Rolled back to "image" : "haugene/transmission-openvpn:4.0", until privoxy listens to all eth* addresses. It's jus the tun0 interface I think you are trying to avoid?

I don't have time to debug each release here; will stay on "haugene/transmission-openvpn:4.0"

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

stale[bot] commented 1 year ago

Feel free to re-open this issue if you think it deserves another look.

dchidell commented 11 months ago

I still see this as an issue - surely a common setup is to route other container traffic through a conveniently listening proxy service (that this provides) with a collection of containers running within a single bridged network.

Having the web proxy listen on all interfaces should not be an issue unless the container is running in host mode only. Typically ports are forwarded specifically whilst in bridge mode. In this case, connecting to the exposed port via the docker host works.

The above behaviour does not however function when it's desirable to have other containers within the same bridge network using the proxy. Currently there is no mechanism to allow this scenario.