Welcome to my site. I enjoy playing with tech, it’s my hobby. I figured some of the random things I come up with might help others so I decided to blog about it. I plan to discuss the thought process more than the tech because this is where the tradeoffs are made. In tech, there are many ways to accomplish a goal and the tradeoffs made along the way tend to get lost in the shuffle.

Homelab

I have a homelab with a few powerful machines and a fast internet connection. In this lab, I experiment and run a bunch of services. This makes me consider tradeoffs, which I think is useful for an SRE. Unfortunately, my provider only gives me one IPv4 address and no native IPv6. Since I like to experiment, this isn’t enough for me. I had to choose for my experiments.

TL;DR I chose to use an IPv4 address from a cheap ($25/year) VPS in my homelab. More info on how to do that is available in this repo.

Tradeoffs

I thought I’d share some of the reasoning behind my thoughts. These are the options I came up with for myself. There may be other options that I didn’t consider. My solution works for me, but others may come to a different conclusion for their circumstances.

Option 1 - The Cloud

I could run my experiments in the Cloud. This would be easy for spinning things up and down. Internet reachability should be solved since it would come with an IPv4 address. But this could get expensive if I decide to keep it going. Besides, many of my experiments are in scaling or failure analysis of use cases, this means a lot of instances. This can quickly get expensive, a cost that feels unnecessary to me since I have a fast connection and idle gear.

Option 2 - IPv6 Only

I could go IPv6 only for my experiments. As I have no native IPv6, it would mean using my ISP provided IPv6 tunnel or Hurricane Electric’s TunnelBroker. Most clients and browsers prefer IPv6 first and tunneling on either seems to limit my bandwidth to 10% of the line speed.

My ISP tunnel doesn’t provide an API for updating my side of the tunnel when my IP changes. This means that my dynamic IPv4 address changing can disable my IPv6 tunnel. The lack of an API means I could have unexpected outages. I guess I could monitor this and alert but I didn’t feel like building a brittle solution.

TunnelBroker has a DynDNS API for updating my IPv4 endpoint. But Netflix marked my connection as a VPN. The Netflix thing could be worked around by only enabling IPv6 on my homelab subnet. But another problem is that TunnelBroker blocks Cloudflare, meaning I wouldn’t be enabling them as an IPv4 to IPv6 proxy. Effectively I wouldn’t be able to access my homelab at home.

In the best-case scenario, my ISP tunnel could work and I could get Cloudflare to proxy but that still limits me to http and https use cases.

Option 3 - Mesh VPN

I could run these hosts with a mesh network like ZeroTier or Nebula. This would add a layer of security since I would have to approve hosts or install certs to make this work. But what if I am playing with a VPN or need this service accessible on a machine that isn’t mine? I just didn’t like this option enough to pursue it very hard. I am confident it could work for known stuff, but not for the random experiments I run.

Option 4 - Steal IPv4 from Cheap VPS

This option involves spinning up a cheap VPS and using its IP address within my homelab. This is relatively simple and cheap. I found a cheap VPS for $25/year with two IPv4 addresses. It isn’t very strong with 1 core and 512MB of RAM but it will only run wireguard so that’s not a big problem.

Conclusion

I picked Option 4. I grabbed an IPv4 address from a cheap VPS. It’s relatively cheap and gave me the level of reachability I desired for my lab.