Cloudflare has made it too easy to access your homelab on the internet(kibibyte.in)
kibibyte.in
Cloudflare has made it too easy to access your homelab on the internet
https://kibibyte.in/blog/2024/08/06/cloudflare-has-made-it-too-easy-to-access-your-homelab-on-the-internet/
25 comments
Unfortunately, you can't use this to tunnel multiple subdomains, unless you tunnel an entire domain. That's because Cloudflare won't let you issue third-level wildcard certificates, so you can't proxy *.lab.mydomain.com. Maybe I should just get my homelab a domain and be done with it, but right now running everything over Tailscale seems like a better solution.
FYI you can get third-level certs wildcard or not if you subscribe to their Advanced Certificate Manager product.
I once had a project where I had more than one person trying to play an emulated game online through a custom Dolphin Emulator build on the same LAN segment. Due to the nature of how the client was trying to use ports, port forwarding was not helping due to overlap (clients wanted the exact same ports open and could not be distributed). I eventually gave up trying to do port forwarding and instead had each person get a VM with an extra IP assigned to it in a local data center. Linux supports different network configs per application and I managed to use TincVPN as an Ethernet bridge between the VM's Ethernet and each local machine, where I assigned the 2nd IP from the VM to the end of the tunnel and created a custom routing table only for Dolphin to be started with that used the VMs routing configuration. Effectively, it looked like they were playing their games from inside the data center.
Cloudflare tunnels is a nightmare to work with. I had the famous experience of "it worked fine at my home, I don't know why it's not working in the lab" and couldn't ever resolve the problem, running on Ubuntu. As of March 2024, Cloudflare tunnels was very, very unrefined (on Ubuntu). QUIC doesn't work and you have to read through forums to find how to change protocol to http2. The logs are insufficient to pinpoint issues. Remote administration workflow seems broken. I should also mention that I used my own domain, not the free one, and used Cloudflare for dns.
I am very interested in Tailscale SSH as an alternative to CloudflareTunnel + SSH. If anyone has experiences with Tailscale SSH, please share (https://tailscale.com/tailscale-ssh)
I am very interested in Tailscale SSH as an alternative to CloudflareTunnel + SSH. If anyone has experiences with Tailscale SSH, please share (https://tailscale.com/tailscale-ssh)
You probably don't need Tailscale ssh - you can just install the Tailscale client on your devices, setup a regular ssh server like the one baked into your distro, and just use regular ssh keys to get into machines.
This is also pretty easy with nothing but SSH, setting up a tunnel through any server to which you have SSH access (including extremely cheap/free ones.)
I like Zrok.io for this stuff, not that I have much experience with this kind of thing.
Brother, wait until you hear about Tailscale...
Which is also point to point for the traffic.
Which is also point to point for the traffic.
I wasn't aware of Tailscale Funnel, but I'll give it a try. It was easy to set up since I already have a lot of things on Cloudflare.
How the **** do you decline cookies on this site??!!!
Hey, earlier it was going into Manage and unchecking the Google Analytics. I realized that was a bad design and have it updated now. Now, you can simply reject the cookies :)
Call me crazy, but I don't think "tunnel all your traffic through a third party corporation's service" is the correct solution to "my IP changes sometimes." Maybe just set up DDNS instead?
If you really are trying to run a server behind a CGNAT, then I guess you have no other options, but I'd consider this kind of thing to be a last resort.
If you really are trying to run a server behind a CGNAT, then I guess you have no other options, but I'd consider this kind of thing to be a last resort.
Not quite, some ISPs lock down their routers and you can't expose the relevant ports publically. That's when Cloudflare Tunnels combined with a reverse proxy save the day.
Another really useful service is being able to protect everything behind a SSO like Github, allowing at least the most basic form of intrusion prevention that would secure your homelab from the majority of attacks.
Another really useful service is being able to protect everything behind a SSO like Github, allowing at least the most basic form of intrusion prevention that would secure your homelab from the majority of attacks.
> Not quite, some ISPs lock down their routers and you can't expose the relevant ports publically.
Here in Italy our public Communications Regulatory Authority (AGCOM) has sentenced that ISPs cannot mandate a specific router type and MUST provide technical details so that any subscriber can be able to use a modem/router of choice. This was after quite a bit of lobbying by the "Free Modem Alliance (https://www.freemodemalliance.it/)
So I guess that at the end of the day i guess it's mostly a matter of political activism.
I love this, and run my own WRT3200ACM with OpenWRT
Here in Italy our public Communications Regulatory Authority (AGCOM) has sentenced that ISPs cannot mandate a specific router type and MUST provide technical details so that any subscriber can be able to use a modem/router of choice. This was after quite a bit of lobbying by the "Free Modem Alliance (https://www.freemodemalliance.it/)
So I guess that at the end of the day i guess it's mostly a matter of political activism.
I love this, and run my own WRT3200ACM with OpenWRT
CGNAT is pretty common unfortunately and sure makes things harder.
I've opted to do this myself by buying a VPS for ~$5/month with Digital Ocean. It runs a Wireguard server and nginx, and then my home lab router connects via Wireguard. Nginx acts as a reverse proxy to serve content from my home lab. I have (relatively speaking) complete control over the entire path.
When running Cloudflare tunnels, opening a port on your router, or having a VPS+Wireguard, it's important to think about security and covering your butt. I run everything in a DMZ subnet that has firewall/ACL rules on both the DMZ and my other networks to restrict any access. I put bandwidth caps on individual VMs/containers. I also use Wireguard to reroute all outbound Internet requests from the DMZ so that my home lab doesn't use my home IP address at all.
Maybe I'm paranoid, but the last thing I need is to forget about some web project I was experimenting with in my lab and suddenly the Internet connection I pay for is being used by some bad actor to participate in ddos or to resell access to my trusted residential IP for scamming purposes.
When running Cloudflare tunnels, opening a port on your router, or having a VPS+Wireguard, it's important to think about security and covering your butt. I run everything in a DMZ subnet that has firewall/ACL rules on both the DMZ and my other networks to restrict any access. I put bandwidth caps on individual VMs/containers. I also use Wireguard to reroute all outbound Internet requests from the DMZ so that my home lab doesn't use my home IP address at all.
Maybe I'm paranoid, but the last thing I need is to forget about some web project I was experimenting with in my lab and suddenly the Internet connection I pay for is being used by some bad actor to participate in ddos or to resell access to my trusted residential IP for scamming purposes.
I have a VPS running BGP, along with my own ASN and a /24 block. My home network is tunneling out to the VPS from a VM and routing the /24 over wireguard. The /24 is then made available on its own VLAN.
No doubt all this stuff is a violation of residential TOS agreements.
No doubt all this stuff is a violation of residential TOS agreements.
How does someone go about doing something like this? Do you have a blog? I would love to read more.
I don't have a blog, but if you google "personal ASN" you'll find a few!
Curious how you have all this set up. This architecture makes a lot of sense but it seems a bit fiddly to set up. Do you manage routes, IPs, and ports manually or is there some magic docker thingy that facilitates this architecture?
Personally I currently just use DDNS for stuff hosted on consumer connections (AKA home lab). And docker nginx-proxy to multiplex various self-hosted web apps (either in a home lab or on a VPS).
Personally I currently just use DDNS for stuff hosted on consumer connections (AKA home lab). And docker nginx-proxy to multiplex various self-hosted web apps (either in a home lab or on a VPS).
[Guix/Ansible/Chef/Nix/Puppet] + systemd-networkd + firewalld/nftables. It's not much different than setting up any old load-balancer or reverse proxy on an internal network.
Why not Docker? Since routes are kernel-level and shared between containers, using Docker here typically complicates things rather than making them simpler. Unless you already know about most of the "network magic" Docker does by default, in best case you'll waste a lot of time figuring all of that out and in worst-case you'll apparently have it working but actually vulnerable in some subtle way. And at the point where you're running with "--net=host --user=root --privileged", you're not gaining much from containers for these specific use-cases.
Yes, you _can_ do stuff like this with just containers with CNI/custom networking but VMs are typically cleaner and easier unless you're strongly personally motivated to learn about the underpinnings of container networking.
> And docker nginx-proxy to multiplex various self-hosted web apps (either in a home lab or on a VPS).
That's probably fine, and you might be able to do something similar without even touching that part (aside from closing off the public entrypoint when/if you get the tunneling working). You'd set up the WG+routing either on the same box or on a dedicated tunnel/proxy endpoint, as well as on the remote side. You can either add an additional L7 LB (like nginx) at the entrypoint or redirect traffic straight to your existing nginx. The former is probably the safer and easier, but less efficient approach.
Why not Docker? Since routes are kernel-level and shared between containers, using Docker here typically complicates things rather than making them simpler. Unless you already know about most of the "network magic" Docker does by default, in best case you'll waste a lot of time figuring all of that out and in worst-case you'll apparently have it working but actually vulnerable in some subtle way. And at the point where you're running with "--net=host --user=root --privileged", you're not gaining much from containers for these specific use-cases.
Yes, you _can_ do stuff like this with just containers with CNI/custom networking but VMs are typically cleaner and easier unless you're strongly personally motivated to learn about the underpinnings of container networking.
> And docker nginx-proxy to multiplex various self-hosted web apps (either in a home lab or on a VPS).
That's probably fine, and you might be able to do something similar without even touching that part (aside from closing off the public entrypoint when/if you get the tunneling working). You'd set up the WG+routing either on the same box or on a dedicated tunnel/proxy endpoint, as well as on the remote side. You can either add an additional L7 LB (like nginx) at the entrypoint or redirect traffic straight to your existing nginx. The former is probably the safer and easier, but less efficient approach.
If you're not serving HTTP/S you may also opt to use iptables to blanket port forward through wireguard.
I'm pretty happy with Tailscale for private access.