Let me say up front that this chapter is going to be a bit more technical. But these topics are very fundamental to the home lab. When you first set up your home lab, you will be accessing virtually all of your services, dashboards, user interfaces, etc. by using an IP address. So let’s say you have your home network, and the IP address of your router is 192.168.1.1 (and in my home lab and for the sake of this blog, I only use IPv4 addresses. I do not use IPv6 at all). When you connect your first computer to the network, the router will assign that computer an IP address, probably something like 192.168.1.2. All of the computers on the same network segment will have 192.168.1.XXX addresses. As soon as you change any of the first three octets (the numbers before the periods), that denotes a different network segment, and different network segments may or may not be able to communicate depending on your router and firewall settings. When you add your device (and it doesn’t have to be a computer, these many things connect to the internet like refrigerators, TVs, phones, etc.), it will get the next sequential number, such as 192.168.1.3. Here’s where the difficulty arises. In my home, there are 25-30 different devices connected to the internet all the time. Then you add in another 20-30 IP address for all the stuff I have running in my home lab, and it gets very confusing, very quickly. You have to remember the IP address for each and every one of the servers or interfaces you want to access. If I want to log into my primary Proxmox server, it is 192.168.1.193. If I want to log into my Synology NAS, I have to log into 192.168.1.45. How do you keep all of those numbers straight? Well the answer is you don’t have to, there is an easier way. You can assign host names to any of your devices. For instance, in my home, I can just go to https://pve-02.louielab.cc to get to my main Proxmox server. Jay has two awesome videos explaining this. They overlap a bit but I find both to be very useful:
If you are serious about your home lab, I definitely recommend buying a domain name for your lab. Mine is louielab.cc. I have registered this host name through Cloudflare and it cost me $8.00 per year to own that name…barely more than a single drink at Starbucks. I think anyone can afford it. Using my pfSense router, every device in my home lab has a fully qualified domain name (e.g. synology.louielab.cc) so I do not have to remember any IP addresses. I have the DNS resolver in pfSense set up as Jay describes in the second video.
Owning a domain name is also important if you want to use Cloudflare tunnels to expose any of your services (or websites) to the internet. Cloudflare tunnels require a domain name to work. That is an externally facing domain name. In my case that is louperugini.com. I could have used my louielab.cc domain name, but I elected to have internal and external domains to keep it simpler for me. So in my case, when you type in www.louperugini.com Cloudflare is redirecting your traffic to my server at website.louielab.cc. But you don’t need to know any of those details to access my blog. All you need to know is www.louperugini.com.
I highly recommend using Cloudflare tunnels to expose your services to the internet. I feel it is more secure. Without a Cloudflare tunnel, you would have to publish your public IP address that corresponds to your website URL through a DNS server. Then every bad actor would know where you are in the internet and be able to attack your IP address. With Cloudflare tunnels, an IP address at Cloudflare gets published to the DNS servers, and bad actors try to attack Cloudflare instead. To me this is a good thing. Some folks have concerns that Cloudflare can see whatever data is going in and out of your website, and that is true. But to me it is a lesser concern. I mean what sensitive data am I hosting on this blog? None is the answer. I covered Cloudflare tunnels a bit earlier in the networking chapter, but here is a different video from Tom Lawrence that does a spectacular job of explaining how Cloudflare tunnels work and how to set them up
As much as I like and trust Cloudflare tunnels, I still take precautions to keep everything that goes out through the Cloudflare tunnel segregated. In my case that means anything I use to support my WordPress instance is isolated to a specific VLAN, my “untrusted” VLAN. I have a separate NAS server that sits on this VLAN, the VMs that host wordpress are on that VLAN, and I never “cross the streams” so to speak. For example, I could have only one NAS, and I could have created a firewall rule to allow my WordPress instance access to that NAS, but I didn’t want to take the risk. So I actually have two physical NAS machines, one on my trusted VLAN and one on my untrusted VLAN. This may not be the most economical or efficient way to do things, but it is what I feel comfortable with. So, if heaven forbid that someone breaks into my WordPress server via Cloudflare somehow, all they will be able to reach is that one virtual machine and the storage for that machine. Because of the firewall rules and network segmentation I have, they will never be able to reach my trusted VLAN where all my sensitive information lives.
Finally there is the issue of SSL certificates and HTTPS. SSL certificates and HTTPS mean that all the traffic between my server and who ever is viewing my website is secure and encrypted. This avoids things like packet sniffing, man in the middle attacks, etc. Every website should use HTTPS. To do that your need to obtain a SSL certificate from a trusted certificate authority. Granted, Cloudflare tunnels cover you in this regard, but only from the web browser to Cloudflare. After the traffic leaves Cloudflare and enters my network, it won’t be encrypted unless I have a certificate on my server. It might seem like a small risk, but I have SSL certificates on EVERYTHING in my home lab, even services on the trusted VLAN. Certificates are free if you use Letsencrypt, and they are not that hard to obtain. I have to get my certificates a number of different ways, depending on which device I am putting them on, and it is too much to document here. The Letsencrypt documentation is very comprehensive, and can walk you through it. Although in general I am either using Acme (as in this video below) or I use Certbot in my Debian server instances. The only twist to either of these services that because my louielab.cc domain isn’t publicly exposed to the world, I have to use DNS credentials to prove I own the domain. Its a bit of an extra step, but not too terrible. This video explains it pretty well.