Responsibility of the Network

Good Morning from my Robotics Lab! This is Shadow_8472, and today I have a doozy of a network week to cover. Let’s get started!

Meet the Computers

  • Cerberus – the main star today. It is our new hardware firewall running OPNsense
  • Red Router – a tp-link gaming Wi-Fi router fancied up beyond what it should have been
  • LAB – my homelab with a few servers
  • LAN – everything else connected via Wi-Fi or Ethernet

Network Implosion

It all started with revisiting a .lan domain. Cerberus’ extensive webUI left me with the hunch I’d need one machine in charge of DHCP assigning dynamic IP addresses. Red Router’s “operation mode” to work as an access point was hidden in literally the last menu to click through.

It was afternoon and no one would be using the network for the 30 seconds to 5 minutes I estimated switching the LAB and LAN Ethernet cables from Red Router over to Cerberus would take. Nope. No traffic made it through. DHCP mis-configuration? Cue a slow back and forth, bopping a setting from a workstation and trying a different physical configuration. Eventually, Cerberus ended up on my desk with Red Router talking directly to our ISP’s gateway/modem.

Order of events is a bit fuzzy from here, but when the Wi-Fi stopped working, I was without a good access to online answers. I worked the problem into the night. Around 1:00 AM, I knew I had done too much for a clean reversion. For two hours, I worked in loops hoping to spot something different. So much waiting! Cerberus would behave on my desk, then fail when redeployed. Worse: when I re-connected all the wires to Red Router, it started dancing between 192.168.0.1 and 192.168.1.1 every 45 seconds or so. I configured its IP manually, but gave up on Internet by morning at 3:00 AM, preparing to concede to my father’s suggestion earlier about hiring a professional to untangle my mess.

The Next Day

Newtork Loop. In my brain fog, I had Red Router talking to itself on a cable leftover from removing Cerberus for the night. With the house to myself for several hours, I alternated between bursts of intense diagnostics and mental processing. Somewhere in there, I rebooted the ISP’s modem.

Around noon, I realized the extra ports on Cerberus aren’t a switch as is Red Router’s default configuration, but were following firewall rules – which explained its behavior the previous day when I tried a computer from LAB without anything in-between. At around 3 PM, I got a Discord notification while mentally checked out, letting me know the network was back on.

6 PM on the second day: I situated my workstation in Cerberus’ LAN port and a Raspberry Pi in one I named LAN2. I’d previously copied firewall rules from LAN to LAN2 and LAB, but to no obvious effect – until I had the two computers ping each other. LAN2 failed as expected, but LAN’s ping was returned. I corrected the interfaces’ rules to allow them to reach out, and that was it.

Fallout

Without going into too much detail, a subnet shift like this is a major undertaking for networks with static IP servers on them. Not only do the network and computers need to be adjusted, but all traces of the old subnet need to be corrected. NFS clients needed to be told where the server was now, and the NFS server shares needed to be updated about what IP’s were allowed to mount them. I also still have Bitwarden to clients to update at my leisure.

Takeaway

OPNsense is a heavy weight in terms of configuration options. It has a learning curve compared to products simple enough to for Grandma and Grandpa to use. I may have solved my own emergency, but it may be wise to get someone looking at it professionally anyway to grade my work and give me some pointers on rootless Podman mounting NFS shares, or other long-term places where I’ve gotten stuck.

Final Question

I admit: networking is more fun than I gave it credit for before I knew basically anything. I still find it a bit taxing to mentally reach around my mental map, but I manage. How do you visualize networks?

I Switched My Operations to Caddy Web Server

Good Morning from my Robotics Lab! This is Shadow_8472, and today I am rebuilding my home server, Button Mash, from the operating system up. Let’s get started!

Caddy Over Nginx

I spent well over a month obsessing over Nginx, so why would I start over now? As far as I am concerned, Caddy is the piece of software for my use case. While I am sure Nginx is great at what it does, I keep slamming into its learning curve – especially with integrating Let’s Encrypt, a tool for automating SSL encryption (HTTPS/the green padlock). Caddy builds that functionality in while still doing everything I wanted Nginx for.

The official Caddy install instructions [1] for Fedora, Red Hat, and CentOS systems are as follows:

$ dnf install ‘dnf-command(copr)’
$ dnf copr enable @caddy/caddy
$ dnf install caddy

First of all, new command: copr. Background research time! COPR (Cool Other Package Repositories) is a Fedora project I feel comfortable comparing to the Arch User Repository (AUR) or Personal Package Archive (PPA): it lets users make their own software repositories.

Installation went smoothly. When I enabled the repository, I had to accept a GPG key that wasn’t mentioned in the instructions at all. From a user point of view, they appear to fill a similar purpose here to a SSH keys: special numbers use math to prove you are still you in case you get lost.

Caddy uses an HTML interface (a REST API – Don’t ask, I don’t understand myself) on the computer’s internal network known as loopback or localhost on port 2019. Caddy additionally serves everything over HTTPS by default. If it cannot convince Let’s Encrypt to give it a security certificate, it will sign one itself and tell the operating system to trust it. In other words, if I were not running ButtonMash headless (without a graphical interface), I’d be able to try connecting to localhost:2019 with a favorite browser, like at least one of the limited supply of Caddy tutorials did.

IP Range Transplant

I should have just done my experimentation on DerpyChips or something. Instead, I pressed on with trying to point a family-owned domain name at Button Mash. This side adventure sprouted into last week’s post. In short: ButtonMash’s static IP kept was in conflict with what my ISP-provided equipment kept trying to assign it, resulting in an estimated 50% downtime from a confused router. Upgrading to the next gateway may have allowed us to free up the IP range for the gaming router’s use, but it’s not out for our area yet. My father and I switched our network connections over to a “gaming router” we had laying about and enabled bridge mode on the gateway to supposedly disable its router part. I have my doubts about how it’s actually implemented.

Most of our computers gladly accepted the new IP range, but GoldenOakLibry and ButtonMash –having static IP’s– were holdouts. I temporarily reactivated a few lines of configuration on my laptop to set a static IP so I could talk with them directly and manually transfer them over to the new IP range, breaking NFS shares and Vaultwarden on them respectively.

In the confusion, ButtonMash lost its DNS settings; those were easy enough to fix by copying a config line to point those requests to the router. GoldenOakLibry took a bit longer to figure out because the NFS shares themselves had to accept traffic from the new IP range with settings buried deep within the web interface. Once that was sorted, I had to adjust the .mount files in or around /etc/systemd/system on several computers. Editing note: While trying to upload, I found I could not access GoldenOakLibry on at least a couple of my machines. Note 2: I had to change the DHCP settings to the new IP range on my Raspberry Pi reverse Wi-Fi router. Systemd on both goofed systems needed a “swift kick” to fix them.

sudo systemctl start <mount-path-with-hyphens>.mount

Repairs Incomplete

That left Vaultwarden. I was already in a it’s-broken:-fix-it-properly mentality from the modem/router spinoff project. I got as far as briefly forwarding the needed ports for an incompletely configured Caddy to respond with an error message before deciding I wanted to ensure Bitwarden was locked down tightly before exposing it to the Internet. That wasn’t happening without learning Caddy’s reverse proxy, as I put Vaultwarden exclusively onto a loopback port.

Speaking of loopback, I found the official Caddy tutorials lacking. They –like many others after them– never consider a pupil with a headless server. I have not yet figured out how to properly convince my other computers to trust Caddy’s self-signed certificates and open up the administration endpoint. That will come in another post. I did get it to serve stuff over HTTP by listing IP’s as http://<LAN address>, but Bitwarden/Vaultwarden won’t let me log in on plain HTTP, even over a trusted network and confine the annoying log to a file.

As far as I can tell, the administration API on port 2019 does not serve a normal web page. Despite my efforts, the most access I have gotten to it was for it to error out with “host not allowed.” I haven’t made total sense of it yet. I recognize some of the jargon being used, but its exact mechanics are beyond me for the time being.

Takeaway

Caddy is a powerful tool. The documentation is aesthetically presented and easy enough to understand if you aren’t skimming. But you will have a much better time teaching yourself when you aren’t trying to learn it over the network like I did.

Final Question

Do you know Caddy? I can tell I’m close, but I can’t know for sure if I’m there in terms of the HTTP API and just don’t recognize it yet. I look forward hearing from you in the comments below or on my Discord server.

Works Cited

[1] “Install,” Caddy Documentation. [Online], Available: https://caddyserver.com/docs/install. [Accessed: June 6, 2022].

Family Photo Chest Part 13: Early Prototype Workflow

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am merging a couple projects into one and hoping they stick. Let’s get started!

Overview

I’ve been piecing bits of my photo trunk project workflow together now for way too long. Right now, the architecture is looking like I’ll be scanning sets of pictures to a directory on a Network Attached Storage, then I can use a cluster of dedicated microcomputers from another unfinished project to separate and deskew the raw data into individual files. These files will then live permanently on the NAS.

Progress is rarely linear though. My end goal for this week hopped around quite a bit, but in the end I felt like I did nothing but figuring out how not to proceed: ground work with no structure. Routers are hard when you’re trying to learn them on a schedule!

Lack of Progress

In a perfect world, I would have been well on the way to configuring a cluster node by now. In a less unreasonable one, I would have had my Pi 4 OpenWRT ready to support the cluster. Late-cycle diagnostics chased me into an even more fundamental problem with the system: Wi-Fi connectivity.

During diagnostics, I’m learning about how different parts of the system work. Physical connection points can be bridged for a single logical interface, and Ethernet cables can support separate ipv4 and ipv6 connections. I can’t configure the Ethernet (on either logical interface) the way I want because that’s how I’m connecting to the Web UI and SSH. I end up stuck using two computers besides the two router Pi’s (OpenWRT and a Raspian hack router that actually works) because I don’t like switching my Ethernet cables around on the switch, but I need to do that anyway when I have to copy a large block of text. In short: the sooner Wi-Fi gets working, the better.

I understand I am essentially working with a snapshot. It’s been tidied up a bit, but bugs still exist. Wi-Fi is apparently one of those things that’s extra delicate; each country has its own region, among other complexities. On the other hand, I don’t know if that’s actually the case, as diagnostics are ongoing.

Takeaway

I’m probably going to work on this one in the background for a while. The OpenWRT help forum’s polish at least in part makes up for routers being dull to learn. If it takes too long, I do have other projects, so I may need to replace the cluster with a more readily available solution.

Final Question

Have you ever had upstream bugs that kept you from completing a task?

“Beowulf Cluster:” Part 6: OpenWRT Installed

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m installing OpenWRT Linux router distribution on a card for a Raspberry Pi 4. Let’s get started!

Background

A while ago, at the beginning of lockdown, I was gifted a few microcomputers I wanted to arrange into a cluster, maybe even turn them into a model supercomputer. I was planning on using OpenWRT, but it wasn’t –and technically still isn’t– available for the Pi 4 outside the use of snapshots. I compromised by configuring a minimal Raspian installation, but I’ve yet to figure out how to program the firewall to disallow computers on its Local Area Network (LAN) from going anywhere online without my say so in addition to keeping them hidden from the Wide Area Network (WAN).

My efforts back then were still possibly the most useful project I’ve done to date: I’ve been using that card as my main Wi-Fi receiver for my workstation. I conjecture it should be just fine with a Pi 4 (1 GB RAM), but since all my more qualified Pi 4’s are busy, my fancy Pi 400 has been serving in that capacity.

Installation

As noted above, OpenWRT for the Pi 4 is only officially available as a snapshot. These builds often lack recommended packages, including any GUI I might want to explore. This is where community builds come in. My research converged on one by wulfy23.

The GitHub’s readme’s took me a while to understand, in part because of all the options. I gathered that there were “factory” builds and “system” builds. Factory builds are for fresh installs, and system builds are for upgrading existing systems. At that time, there were as many as three builds for download, and choosing the right one seemed almost arbitrary.

My first time installing, I totally forgot to check the provided SHA256SUM before unzipping it and dd’ing it to SD card and booting. I landed in a terminal that kept mixing the prompt with other messages. Reaching out to a support thread on the OpenWRT forum, I learned about the web interface, and how to connect to it.

The URL I was given failed every time, even my workstation alone with the router on my switch. I ended up going directly for the IP: 192.168.1.1. I was met with an inadequate dark mode I couldn’t find the settings for. I expect they’re probably there, and I spent a small amount of time looking for them by tossing reasonable sounding URL’s around and hoping for the best, but comparing notes among other tabs in the interface, I think the chances of happening across the specific one I need are slim.

Installation Take Two

I went through the same process another day, and found only a single version for download from the same place. The SHA256SUM checked out, and instead of unzipping it first, I learned about zcat, a little command line utility that can unzip a file to be piped into another command. I piped it directly into dd per an example installation I spotted my first go around installing OpenWRT.

I provided a root password and found a different theme that didn’t force a partial dark mode on me in short order. I found built in tools for ad blocking network wide, settings for managing network interfaces, and most importantly to this project: a fire wall. Alas, the fire wall remains something I have little practical understanding of. I’d like to believe I have a mid-range understanding of what it can do, but my only real hope is copying lines and hoping they do what I want – the last thing one wants in a firewall intended for actual security. No. A custom firewall is at least a week in and of itself.

Takeaway

I really like trying to do two weeks worth of topics in a single week. It usually doesn’t work. Granted: I did have a rusty introduction to both parts of the topic I wished to fuse into one this week. I’m looking forward to remembering zcat in the future.

Final Question

What neat, little tips and tricks have you picked up during a larger project?