I’m a Bash-Loving, Rust-Curious, Java dev in Utah. I write, deploy, and maintain containerized applications to AWS regularly in my professional life. I use Linux for home and work. I have a small server rack at home where I deploy services and get a lot of value.
Currently, my services are all on my private network and have no DNS records. My networking skills are rudementary and knowledge is theoretical, so for Devember, I plan to buy my first domain, and point it to a public proxy hosted at Linode. I’ll then sort out setting up a VPN back to my home network, and and expose services one by one once I sort out firewalls and the authorization side of the equation. I would also like to get DNS straightened out so my requests for these services don’t go out to the public proxy and back into my network.
Success will look like the following:
My hugo static site generated blog available at my own domain
The Domain pointed to a Linode public ip and proxy server
A proper VPN between Linode and my home network
The site being served by my home server
DNS for my home network properly routing local requests
If I manage to make it that far, opening up additional services should be pretty straight forward. All of this will greatly expand my practical experience in maintaining some infrastructure.
I spent today working on updating dependencies and writing a blog post to confirm my current setup. Everything seems to be in order. Tomorrow I’ll sort out mirroring the site on my private server.
I went domain shopping today. Rather than deploying the site on my home machine, I did the fun/easy part. After shopping around for prices, I ended up at porkbun, and got my domain setup.
I then setup an account at cloudflare and them as my DNS.
I wrapped up by making a cname record for a subdomain and pointing that to my current github pages blog. I added that subdomain on the github pages settings page and… voila:
I finally got dynamic dns running, so my home site now has a dns record. I’m now my site dns via cloudflare using this little project.
I wanted to set up dynamic dns via my Unifi Dream machine pro, but it wasn’t worth the effort because it’s much more locked down than the USG products as far as I can tell.
I now have a Linode account and I’m investigating how to vpn between Linode instance and my UDM. Not sure if this is an Open VPN, a wireguard, or some other encrypted tunnel.
Looking into HA-Proxy, nginx, and Traefik for the actual proxy.
I set up a linode one-click instance to give open vpn a try. I was not able to get the UDM Pro to connect, and hosting an entire Website was overkill for what I was looking.
I then looked into the community scripts and found an IPSec script, which essentially ran this. It seemed promising so I set it up and followed this guide for the udm pro side.
Once connected, I tried to ping my linode instance private IP but I didn’t get anything. I ssh’d into the vpn box and pinged my home network and got nothing as well. I read over the ipsec service logs and confirmed that my UDM Pro was connected. So at this point, I believe something isn’t configrured to forward the traffic properly.
I started by reporting a minor UI bug in one of their webpages, which they quickly accepted and escalated (they even threw me a 10$ credit on my account, which was very cool).
At first I wasn’t able to ping my two linode instances via private IPs. I opened a ticket and the linode support replied with an amazing well documented response. Ultimately it boiled down to I should reboot my instances for the private IPs to work… :big_oof:
I tried some IPsec stuff and open vpn because those are build into the UDMPro UI, but they weren’t working. I assume I was doing something wrong, but configuring ipsec is quite a hassle. A similar story with Open VPN, most of the one click stuff is geared toward proxing my device traffic out linode, rather than sending traffic from the public back to my private subnet. Again, I’m sure it’s a quick fix, if you know what you’re doing, but I don’t.
Next I gave wireguard a try. I’ve heard good things about it, but it wasn’t built into the GUI of my UDM Pro, so I didn’t start there. Man was it easy to get going. The documentation is concise and straight to the point, and they lean so much on standard linux networking stuff, a great experience.
I’ve got my linode wireguard vpn instance stood up, and I’m able to connect to it’s private IP from my home network. Furthermore, I’m able to proxy through it to access my other linode instances via private ips (more on that later).
While working on this, I found I was able to persist containerized applications on my UDM pro, so I added a user space wireguard-go daemon, to create and manage the connection and restart with the box. It also plays nice with ddns.
Most of that work was done in boostchicken/udm-utilities I just had to spend some time doing configuration. Once I understood, what was going on in the boostchicken project, I went ahead and moved the cloudflare-ddns container to my UDM, and I contributed that work back up to boostchicken in this pull request:
Now, back to the wireguard networking stuff. I spent more time than, I’m comfortable admitting attempting to connect from a second linode instance, back down to my home network, via the wireguard vpn instance. I’m not a networking guy, so I didn’t have much confidence in what I was doing, but I know how to use tcpdump, and ping so I went for it. I learn a lot about modern linux netoworking commands and a bit about systemd along the way. (I’m very happy I don’t need to know how to use iptables to get stuff done). My test box was setup with a static route for my home subnet but nothing seemed to leave the box. Ping the wireguard vpn directly? no problem. Ping the test box from the home network? no problem. Ping home network from test box? nothing. It was like my pings were going to the network equivalent of /dev/null…
I considered opening a ticket, as my other linode ticket was handled amazing, but lot of duck duck go searches finally yielded this thread:
Basically, what I wanted to do was not allowed.
I suspect the solution will be to simply have my other instances all join in a wireguard network, but I haven’t made it that far yet. I’ve also signed up for the Linode vlan beta, which will probably simplify and cost cut my networking between instances in the long run.
Progress!
I finally got around to adding dns records for all the hosts on my network. I’ve got a little bit more work to do to standardize hostnames and what not but it’s mostly there. I consider all this DNS work a bit of a site quest.
I read over the code that I’m using to do ddns with cloudflare from my network gateway and I had some concerns. I opened an issue on git hub:
That issue was well received and a third party contributed an improvement and then another party cleaned up that code even more with in a day or so of me opening my issue. It was great to see open source development working so well.
I then circling back around to my Linode proxy. I did some reading around and found the caddy project:
I opted to use caddy over traefik or nginx (others) because it more directly targets the features I’m looking for today:
reverse proxy
static site hosting
automated cert renewal/management
I didn’t need a lot of the container centric features that Traefik offers, and nginx configuration files can be a little much for me. Caddy is batteries included and that suits me.
I was able to get caddy installed to my linode proxy, and configure it as a service (and write up a script to repeat the setup). I then cloned my static site repo into the static site folder and verified it was working.
Up next:
Setup HTTPS for the blog with auto renewal
Redirect my old github page to my self hosted site
Use a webhook to auto deploy new versions of the blog whenever they’re pushed
Update any deploy scripts I was using in my blog before.
Reverse proxy at least one service inside my network via caddy.
If I finish that work I’ll have met my goal for Devember. I don’t think it’s that much work so some stretch goals would be:
Setup Pi-Hole or another like minded service
Intercept DNS queries on my network, and route the requests to the local ip rather than out the public and back in.
Clean up my Heimdall dashboard with correct dns records and maybe look into how to make it public and properly route to my private services behind a login of some sort.
Https All the things, including my private network traffic.
Today I spent some time setting up a git hook to update my static site files in caddy. I had some trouble setting it up because I misconfigured my ReadWritePaths= directive and forgot to give permissions to write to the hosted directory.
Once got that working, then setup up a reverse proxy over my wireguard vpn to my home server which hosts a Gitea instance. I looked into properly locking down that now that it’s public (disabling registration, and disabling api/ui access without logging in). I haven’t yet proxied the ssh connection(s), so any ssh work will still have to be done from my VPN. Proof:
I think with all the work I’ve done, I need to go back through and document the work I’ve done and validate that my scripts that I’ve been writing along the way will correctly rebuild everything.
Some of that will end up being blog posts, so I’ll plan on cross-posting those here.
As of now, I have completed all of the goals I had when I started devember. Everything I do from here on out is extra credit in my book.
I’ll setup wireguard VPN on my laptop so it can connect through my linode instance as well. Could be useful while I’m out of the house next week…
I generated a keypair and dropped the following config into my workstation’s /etc/wireguard/wg0.conf file:
# Configuration for the client interface
# The IP address that this client will have on the WireGuard network.
Address = 10.222.0.3/32
ListenPort = 51820
# The private key you generated for the client previously.
PrivateKey = $MY_WIREGUARD_PRIVATE_KEY
[Peer]
# Configuration for the server to connect to
PublicKey = $MY_WIREGUARD_SERVER_PUBLIC_KEY
# The WireGuard server to connect to.
Endpoint = my-server.example.com:51820
# The subnet this WireGuard VPN is in control of.
AllowedIPs = 10.222.0.1/24, 192.168.1.0/24
# Ensures that a router does not kill the tunnel, by sending a ping every 25 seconds.
PersistentKeepalive = 25
I then added a matching peer in my server configuration so my workstation would connect. I restarted the service to ensure the new configuration was picked up.
I tested by running wg-quick up wg0 and pinging my home network. I then turned it off with wg-quick down wg0. I then configured my wireguard indicator app to reference the [email protected] and enabled it and did another test.
