Comment on Help with Getting My Reverse Proxy to Forward the Correct IP Address
ampersandrew@lemmy.world 14 hours ago I can take a look after work, but won’t that just change the proxy’s IP listed in my logs instead of properly forwarding along the source IP address?
lemmyvore@feddit.nl 14 hours ago
Yep, you’ll have to fix that by telling your proxy to put the client IP in a header that the target app can recognize and use.
But, also, it’s a good idea to have Docker network ranges that don’t overlap your LAN. That would make me uncomfortable too.
You can also look into using IPv4 link-local addresses for Docker bridges (169.254.). Here’s an explanation: github.com/11notes/RTFM/blob/master/…/daemon.md#n…
That frees you from accidental overlaps with pretty much everything else, but it comes with its own gotcha: link-local isn’t routable. This can come back to bite you if you have an app that relies on announcing a public UDP ip:port to a peer and announces the link-local IP. When a peer tries to connect back, it won’t work. So you have to either tweak the app’s config to make sure you announce a non-169.254. IP, or put the app container on a bridge/macvlan network so it auto-detects and announces a routable IP. There’s all kinds of apps that can be affected by this kind of peer-to-peer behavior (file transfer apps, games, VoIP apps etc.)
But TBH I’ve been using link-local ranges for a while now and only got bitten once (Deluge).
I thought that’s what I was trying to do by adjusting both NPM proxy host settings as well as informing Jellyfin where to expect proxy headers from.
Does it overlap my LAN? Is 192.168.65.X not distinguishable from my defined subnets with a 24-bit mask, now that I know where they’re coming from?
And to be honest, you’ve talked past my understanding with a lot of that paragraph, so I’ll have to comb through it later tonight when I have more time. Keep in mind that all of my Docker network settings are default, so it’s a setting I’ve never dabbled with. From what I can tell from the settings it defined on its own, these containers created a 172.17.0.X address, and somehow the proxy responds with (“announces”?) a 192.168.65.1 address. Are you saying that I need to define for it an unused address that’s on my existing 10 VLAN? Somehow all of the tutorials I’ve found in the past months to set up services behind a reverse proxy never mentioned any of these gotchas with Docker and networks.
lemmyvore@feddit.nl 13 hours ago
Yeah that’s because most people are under the impression that Docker only allocates 172. addresses for its bridge network. I was under that impression too.
Turns out it also allocates 192.168 addresses.
The problem is that the default says
192.168.0.0/16, so it can also generate overlapping addresses. The fact it generated a 192.168.65.x address instead of an 192.168.1.x address was pure luck.The common-sense assumption is that you will adjust your Docker daemon settings so that you prevent overlap with your LAN. (Also, I expect lots of tutorials aren’t that high quality to begin with.)
If you edit daemon.json like I explained and explicitly only put 172. ranges in there you should be safe from overlaps in the future.
I would say a high quality tutorial doesn’t assume that I know anything about Docker, and most of them didn’t (which is good, because I don’t), but they also didn’t seem to expect me to want better logging out of my hosted services. Thanks, the /16 subnetting makes sense. I’ll try to edit that json file later today. But we seemingly don’t expect this to fix the problem by itself, so other than telling Jellyfin to expect a proxy at the new reported IP address, what should I expect for next steps?