How do you guys use Tailscale (or other VPN) with containers
https://feddit.nl/post/14446883
=> More informations about this toot | More toots from lemmyvore@feddit.nl
Have you looked here?
tailscale.com/blog/docker-tailscale-guide
=> More informations about this toot | More toots from zelifcam@lemmy.world
That guide did help me find out about TS_ env vars, which I don’t think are well documented elsewhere. From what I understand they’re container specific? I think they’re set up by containerboot, which is what the tailscale container image uses to boot.
TS_DEST_IP in particular is a game-changer. Docker needs more options for forwarding ports and interfaces. 🙁 “ports:” only forwards to the host and that’s about it.
=> More informations about this toot | More toots from lemmyvore@feddit.nl
This doesn’t exactly match your goals, but you may be able to adapt it or take pieces from it.
I have containers running on two subnets:
Subnet 1 has a DNS server, which resolves all of my services to IPs on either subnet.
I have Tailscale set up on a machine as a subnet router (directing to Subnet 1).
Result:
This is nice because my apps don’t care which network I’m on, they just use the same URL to connect. And the sensitive stuff (usually management tools) are not accessible remotely.
It’s also ridiculously simple: Only one Tailscale service is running at home.
This does not solve your issue of broadcasting vs not broadcasting, though. There’s probably other things missing as well. But maybe it’s a start?
=> More informations about this toot | More toots from d13@programming.dev
I too am playing with Tailscale at the moment. What’s working for me (although I believe you’re well past this) is just running an exit node into my network. I have Adguard and NPM forwarding and reverse proxying and as long as I don’t use .local it seems that the nameserver works on Tailscale too, although I do get some errors in my testing at work yesterday
=> More informations about this toot | More toots from Lifebandit666@feddit.uk
I tried on OpenWRT but the tailscaled binary is huge and barely fits my router’s resources. I can sort of squeeze it in if I compact the daemon binary and run the client binary temporarily only when I change config and then delete it (the daemon doesn’t need it to run).
A tiny VM might be an interesting idea though. Would also be able to simulate some scenarios in case I ever need to get a VPS.
=> More informations about this toot | More toots from lemmyvore@feddit.nl
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters
More Letters
DNS
Domain Name Service/System
IP
Internet Protocol
VPN
Virtual Private Network
VPS
Virtual Private Server (opposed to shared hosting)
[Thread #726 for this sub, first seen 30th Apr 2024, 14:05]
[FAQ] [Full list] [Contact] [Source code]
=> More informations about this toot | More toots from Decronym@lemmy.decronym.xyz
Sharing the network space with another container is the way to go IMHO. I use podman and just run the main application in one container, and then another VPN-enabling container in the same pod, which is essentially what you’re achieving with with the network_mode: container:foo directive.
Ideally, exposing ports on the host node is not part of your design, so don’t have any –port directives at all. Your host should allow routing to the hosted containers and, thus, their exposed ports. If you run your workloads in a dedicated network, like 10.0.1.0/24, then those addresses assigned to your containers need to be addressable. Then you just reach all of their exposed ports directly. Ultimately, you then want to control port exposure through services like firewalld, but that can usually be delayed. Just remember that port forwarding is not a security mechanism, it’s a convenience mechanism.
If you want DLNA, forget about running that workload in a “proper” container. For DLNA, you need the ability to open random UDP ports for communication with consuming devices on the LAN. This will always require host networking.
Your DLNA-enabled workloads, like Plex, or Jellyfin, need a host networking container. Your services that require internet privacy, like qBittorrent, need their own, dedicated pod, on a dedicated network, with another container that controls their networking plane to redirect communication to the VPN. Ideally, all your manual configuration then ends up with a directive in the Wireguard config like:
=> More informations about this toot | More toots from gencha@lemm.ee
I just posted how I handled this after spending almost a day or two trying to work it out. I’m on phone right now so I will post it when I get on my pc or you can check it from my history
=> More informations about this toot | More toots from Mir@programming.dev This content has been proxied by September (ba2dc).Proxy Information
text/gemini