Homelab Public Networking
A few months ago I wrote about how my homelab was in a very bad state:
Everything is in shambles.
One machine is dead and probably not coming back. Services are randomly scattered amongst the survivors. My Kubernetes project is kinda-sorta paused.
I'm happy to report that things are in a much better spot, but it took a lot to get here:
- reverted all the way back to Docker Compose everywhere
- acquired new hardware
- completely re-thought how networking should work
This post is about the last one, and in particular how I'm handling networking for my public sites.
As a quick preview, the VM that served this page to you lives on a server in my basement and has fully routable public addresses, both IPv4 and IPv6, that have no association with my current home ISP.
Computers that talk to each other over the internet are fundamentally peers, meaning they're equal members in the conversation. One computer says "hey I wanna talk to you" and the other says "ok" and then they're talking. The distinctions we make between "client" and "server" aren't baked into the low level internet protocols, they exist much higher in the stack, sometimes entirely within our minds.
In the beginning, every computer could talk to every other computer because the entire network was based on trust and everything was public. If some computer was acting antisocially you could call the operator on the phone and chew them out.
Over time we regressed to the situation we have now: machines that we physically touch (laptops, phones, refridgerators, light switches, etc) are primarily acting as clients with private IPs, accessing the broader Internet through NAT gateways.
OUTLINE
- Where we came from
- How to get IPv6? Change router!
- Maybe own IPv6? How expensive is that?
- Ok maybe lease IPs? Better
- How to make leased IPv6 usable? Vultr!
- How to get leased IPv6 to home? Wireguard! Routing rules! Firewalls! An unproductive diversion with Claude!
- Now what? Maybe IPv4? Sure why not. More firewalls.