23-JUL-2024

0014

Got deploys tested, and am now serving the .canon domain on toto. I realized I need to get ifrit added to the cadaster, and it presents a wrinkle, as it is on multiple networks, and thus would need multiple canon IPs, since bonding these is not really reasonable since they need to serve actually indepentent networks in my architecture. My topology splits lab and non-lab networks, and I want my firewall to maintain that separation, while having, ideally, a single flat network that stretches across both. Moving the point of failure to my firewall, instead of the lab switch.

This is the theory, and it means that ifrit will need at least two entries. I think that’s okay, and ultimately it makes convenient the fact that I’m stealing a whole TLD for this. I can just use subdomains.

!!! CAUTION

This, by the way, is not a good way to use DNS, there are a variety of ways to exploit this kind of thing if you aren’t careful, but this lab is confined to me, for the most part, and ultimately I’m not super worried as I do plan to make sure requests for these domains never leave the network. This can itself be bad because if the domains are ‘real’ (i.e., if you’re split-horizoning a real domain), then you can block an otherwise ‘correct’ lookup. Generally you’ll be fine if you use weird TLDs and block all outgoing DNS for those TLDs (which is what I do). You can be much safer by just buying a domain and using that, but I like punned names and I don’t want to pay for a problem I’m unlikely to ever actually have.

Each independent network on ifrit can have it’s own subdomain to point to the gateway. This means that when I start serving multiple domains and layering VLANs, I can have as many subdomains as I like.

In any case, next step is to get ifrit into the cadaster and update the DNS stuff to allow for multiple subdomains for ifrit. Then I can update ifrit to point it’s clients at the DNS IP and I think I’m basically back up and running in the new setup.

1220

Looking at a new issue, toto has two IPs on the same interface, one is virtual, and iptables nor nftables-based local firewalls seem to be able to handle this case with the built-in networking module. I’m not sure I understand exactly how things are getting generated just yet, but my guess is that this is not a typical way to cut up a network and so the implementation is not robust to my particular breed of weirdo.

If I turn off the firewall, everything works, and so I know the issue is local to the machine. I tried just inspecting both the configurations generated by my config and they both look ‘fine’ in the sense that they should happily be sending packets to the specified interface, so after some consternation, I turned my attention further up the stack.

The tipoff to this was looking at the dmesg output as I tried to hit port 53 w/ an nmap scan; it shows that when I run the nmap against that port, it sees the incoming connection as originating from the enp2s0 interface, and not the enp2s0_dns virtual interface. enp2s0 does not have 53 open.

I tried opening 53 on enp2s0 itself and sure enough everything works fine. So for now I suppose I’ll just have to open the sum of all the ports I want on the enp2s0 interface and then later do something bespoke to handle my weird networking idea.

I’m now seeing what I suspect is a very straightforward “need to turn some ports on” issue on the switch, so that’s tonight’s project.

1738

Truly confusing, even with the extra port, it actually just shows the port as open, doesn’t actually respond correctly. For now I’ve just disabled the firewall entirely, I’m sure I’m doing something silly, I just can’t track down what at the moment.

2205

Got the DNS configured for both KANSAS and CONDORCET. I should probably add the wifi router and cable modem to the cadaster (and really everything in the racks, I suppose it should try to cover everything that touches my network, at least).

2212

I also updated NFS rules for nancy. This gets network storage back to functional.