Melmi

Editing the systemd services seems a neat solution here. Rather than editing the package-provided service files directly, you can create overrides using systemctl edit.

Another more hacky option would be to use the PostUp directive but account for the case there’s no tailscale0 device yet. Write a simple shell script or something.

It’s the confusing mess of subscriptions and seemingly locking basic functionality behind a paywall that’s skeevy, not paying for software itself. I have happily paid for software before and would again. Plex has never appealed to me though, and they’re certainly doing nothing to make themselves more appealing.

Do you have a source for this claim that the new pricing scheme only applies to the Plex Relays? As far as I can tell it applies to anything they consider “remote access”, regardless of whether it goes through their servers or not.

It seems deeply opposed to the spirit of selfhosting to have to pay for the privilege of accessing one’s own server. If the software itself cost money, that would be one thing, but this whole monetization scheme is skeevy.

It seems like multiple things are being conflated here and I’m not sure what the reality is because I’ve never used Plex.

Some people claim this has something to do with Plex needing to pay for NAT traversal infrastructure. Okay, that seems sort of silly but at least there’s the excuse that their servers are involved in the streaming somehow.

But their wording is very broad, just calling it “remote streaming.” That led me to this article on the Plex support website, which walks people through setting up port forwarding in order to enable “remote streaming”! So that excuse doesn’t really seem to hold water. What exactly is being paid for here then? How do they define what “local streaming” is?

Tailscale is just a bunch of extra fancy stuff on top of Wireguard. If you don’t need the fancy stuff, using raw Wireguard can be more lightweight, but might require more networking knowledge.

The biggest thing Tailscale brings you the table is NAT traversal. On top of that it uses direct Wireguard tunnels as necessary instead of creating a mesh like you usually would if you were using raw Wireguard. It also offers convenient bits of sugar like internal DNS, and it handles key exchanges for you so it’s just generally easier to configure. When you do raw Wireguard you’re doing all the config yourself, which could be a pro or a con depending on your needs—and you’ll be editing config files, unlike Tailscale which has a GUI for most things. It also supports some more detailed security options like ACLs and I think SSO, while Wireguard is reliant on your existing firewall for that.

Here’s what Tailscale has to say about it: https://tailscale.com/compare/wireguard

I’ve messed around with Tailscale myself, but ultimately settled on running Wireguard. The reason I do that though is because I trust my LAN, and I only run Wireguard at the edge. Tailscale really wants to be run on every node, which in turn is something that raw Wireguard theoretically can do but would be onerous to maintain. If I didn’t trust my LAN, I’d probably switch to Tailscale.

A lot of people have suggested Tailscale and it’s basically the perfect solution to all your requirements.

You keep saying you need ProtonVPN which means you can’t use Tailscale, but Tailscale actually supports setting up an exit node which is what you need. Put Protonvpn on the Raspberry Pi, then set it up as an exit node for your tailnet. There’s a lot of people talking about how they did this online. It looks like they even have native support for bypassing the manual setup if you use Mullvad.

As long as every client has the ability to use Tailscale (I.e. no weird TVs or anything) this seems like it checks all your boxes. And since everything is E2EE from Tailscale, TLS is redundant and you can just use HTTP.

One use for wireguard in a container is that if you’re using other containers on the same host you can use container magic to route the traffic of specific containers through the wireguard tunnel, while other containers bypass the tunnel.

A big part of IPv4’s persistence I think is that people insist that IPv6 is complicated, but then refuse to learn it or think outside their IPv4-brain. It’s just different enough that it’s easier to stay in v4, even if it requires a million hackjob fixes to keep around.

If anything is to blame for that, it’s the lack of momentum behind IPv6. We’re out of IPv4, so NAT is inevitable, and IPv6 doesn’t have enough inertia for single-stack to be viable (certainly wouldn’t be described as “no drama” at least).