Peer is sometimes 172.17.0.1, a docker-internal address, blocking additional peers

pwinnski commented 5 months ago

Support guidelines

[X] I've read the support guidelines

I've found a bug and checked that ...

[X] ... the documentation does not mention anything about my problem
[X] ... there are no open or closed issues that are related to my problem

Description

Sometimes a torrent will connect to peer 172.17.0.1, a docker-internal address

Expected behaviour

I expect all peers to connect with actual IP addresses, not blocking subsequent peers.

Actual behaviour

Not always, but often, a torrent will connect to peer 172.17.0.1. When it does so, no additional peers can connect after that, so when the first peer connects like that, it become the only peer.

172.17.0.1 is a docker-internal address, not a real peer address. The only way I've found to workaround this is to stop and restart the torrent. Sometimes I have to do that more than once.

Steps to reproduce

Be me? [possibly optional]
Pay close attention to peer lists
Notice that sometimes a peer connects via what I think of as "fake reverse NAT"

Docker info

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 7
  Running: 7
  Paused: 0
  Stopped: 0
 Images: 19
 Server Version: 20.10.23
 Storage Driver: btrfs
  Build Version: Btrfs v4.0
  Library Version: 101
 Logging Driver: db
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs db fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: b23a389d8c181697302d163356e97dec04eb8d88
 runc version: 5af893d
 init version: ed96d00
 Security Options:
  apparmor
 Kernel Version: 4.4.302+
 Operating System: Synology NAS

 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.32GiB
 Name: octonas
 ID: JMZ6:WII5:22VK:FVUL:BQ7Q:TMT2:QXZC:LWMD:4FZA:6F7D:5BVH:RXDH
 Docker Root Dir: /volume1/@docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No kernel memory TCP limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support

Docker Compose config

No response

Logs

2024/04/26 16:33:29 [info] 1151#1151: *6706684 client closed connection while waiting for request, client: 172.17.0.1, server: 0.0.0.0:8080
172.17.0.1 - - [26/Apr/2024:16:33:29 +0000] "POST /plugins/httprpc/action.php HTTP/1.1" 200 13539 "http://192.168.254.122:8144/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"
172.17.0.1 - - [26/Apr/2024:16:33:29 +0000] "POST /plugins/httprpc/action.php HTTP/1.1" 200 2 "http://192.168.254.122:8144/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"
172.17.0.1 - - [26/Apr/2024:16:33:29 +0000] "POST /plugins/httprpc/action.php HTTP/1.1" 200 57 "http://192.168.254.122:8144/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"
172.17.0.1 - - [26/Apr/2024:16:33:29 +0000] "GET /plugins/cpuload/action.php?_=1714135541899 HTTP/1.1" 200 13 "http://192.168.254.122:8144/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"

Additional info

I first noticed this months ago when I was connecting to a torrent I knew had two seeds, a slow one and a very fast one, and I kept getting only the slow one. The fast seeder told me they weren't seeing any traffic from me at all. Since that first time, I've seen it many, many times, including a few minutes ago. The tracker reported three seeds, but I saw only the one slow connection. I stopped and restarted it, and fortunately this time it was the third connection that came in as 172.17.0.1, and one of the other seeders was much faster. File finished in a few minutes, rather than 13 hours.

newadventure079 commented 5 months ago

I see this too.

Probably the same as https://github.com/crazy-max/docker-rtorrent-rutorrent/issues/145

Logiar commented 4 months ago

Since it's a synology NAS, this may be relevant to your issue https://www.pedrolamas.com/2020/11/04/exposing-the-client-ips-to-docker-containers-on-synology-nas/ It seems like an issue with how Synology handles docker traffic rather than an issue with the images.

pwinnski commented 4 months ago

@Logiar is absolutely correct, this appears to be a Synology configuration issue. I made sure I understood the iptables commands in the linked article, then issued them, and immediately a torrent that had been stuck on a single 172.17.0.1 peer started adding additional peers. The difference was startling.

This worked for me:

sudo iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
sudo iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER

Thank you, @Logiar!

crazy-max / docker-rtorrent-rutorrent