Until the last decade, it was very common to have “one task per system”, or, when running on a shoestring, “a few tasks”, such as the case of a software firewall which also worked as a mail transport agent.

Thanks to the magic of hardware and operating system assisted virtualization, we no longer have to directly emulate a complete machine. We can literally take a system and carve it into several smaller slices, each performing it’s own isolated task.

For instance: This webserver running my website isn’t only running a handful of different websites- it has a “heartbeat” monitor system watching my other personal machines that are on the internet, and will alert me to any issue, and several other projects at any one time.

Linux is one of the top KVM virtualization hosts (along with SmartOS and Hyper-V), which allows you to run completely different operating systems beneath it. I like to run my nameservers on OpenBSD as it’s very lean, and it’s PF implementation runs circles around iptables. I now accomplish this utilizing KVM.

Nameservers are a special sort of service- it commonly uses UDP (although TCP is supported), which means that if your machine isn’t fast enough, the client will just go to another one down the list and ask it where to find what it’s looking for. This is a good example where you need to tune your firewall/host rules to keep things fast.

I run my services as NAT KVMs, rather than a bridged MAC address IP, as it keeps all services off of the internet, except those I wish to expose. This adds a bit of trivial overhead to forward the DNS requests on port 53 via TCP/UDP to the client. This can be accomplished with rules similar to the following (showing separately to illustrate what each does):

The following accepts traffic on the bridge device for both TCP and UDP and forwards it to the NAT host located at 192.168.0.100:

/sbin/iptables -A PREROUTING -t nat -i br0 -p tcp --dport 53 \
 -j DNAT --to 192.168.0.100:53
/sbin/iptables -A PREROUTING -t nat -i br0 -p udp --dport 53 \
-j DNAT --to 192.168.0.100:53

This just makes sure that data that went to the NAT host makes it back out:

/sbin/iptables -A FORWARD -p tcp -d 192.168.0.100 \
--dport 53 -j ACCEPT
/sbin/iptables -A FORWARD -p udp -d 192.168.0.100 \
--dport 53 -j ACCEPT

Now, this is fine, but this traffic can actually hit iptables TWICE. Packets on the bridge first hits iptables’ INPUT, then a second time after it sees that the destination is a local virtual MAC. So, I’ve setup this rule so it only goes through once. Keep in mind that action verbs for broute are inappropriately named (DROP means that the frame has to be routed, ACCEPT means that this frame has to be bridged):

/sbin/ebtables -t broute -A BROUTING -d the:bridge:mac:addy:goes:here \
-j redirect --redirect-target DROP

Note that I have not specified a protocol, as I only use ipv4/ipv6 on this machine. This has removed in-kernel time for manipulating this data, which is pretty important if you have a busy nameserver (which mine isn’t).

If you aren’t familiar with LEDE, don’t feel alone. It’s an embedded Linux based upon OpenWRT’s foundations.

I’ve been a fan of OpenWRT for years- it follows the Debian “Unencumbered” design (which is why it supports less devices than DD-WRT or Tomato), and leaves it up to the administrator of the device to configure it as necessary, rather than throwing in many unnecessary features or other assorted bloat.

I opted to try it on the most “baseline” system available, my ancient Airlink 101 AR-670W. This base model router has 4MB flash, and 32MB RAM, which was awesome a decade ago- not so much now.

The interface for LEDE is familiar for any OpenWRT users, and LuCI is essentially unchanged to the naked eye.

It uses a Linux 4.5.x kernel base, and as such does make the old 280Mhz CPU a little slower to start, and does have a bit more overhead. However, the problem I have with it is that it:

♦ Is not compatible with OpenWRT configuations, but blindly accepts and installs them

Granted, there should be some differences moving forward, but it will still accept a standard OpenWRT configuration backup, and obliterate itself with two clicks, requiring a config rebuild. I tried this after it pulled the next stunt on me- just to see what it would do.

♦ Various new driver/configuration issues exist

With OpenWRT Chaos Calmer (15.05.1), this machine works perfectly, allowing me to set my own MAC addresses for any physical interface. Under LEDE 17.01, it accepts the data, but continues to send the hardware MAC address- which annoyed my provider’s DHCP Radius with it’s constant requests for a couple minutes’ time, prompting them to null route me for a couple hours while I got to enjoy dealing with it.

I like that it’s a step forward with a newer code base. Hopefully in a few releases, it’ll be a worthy adversary to Tomato and DD-WRT.

It was time to renew several certificates, and I noticed that Lets Encrypt’ new certbot (as of 0.10 or 0.11) was issuing single certificates for zones grouped together, with the Alt Name set for the other DNS entries for zones sharing a single IP.

What does this mean in English? Think of an SNI SSL setup “virtual host” working like a party line (if you’re old enough to remember what those are). Everyone gets a different “ring”, and picks up when appropriate. Well, since they’re all on the same line, Lets Encrypt (LE) now sticks them all on the same certificate.

While this likely cleans a few things up on their end- having possibly only one certificate for the entire set of hosts- you may not always want that. In fact it’s quite unlikely that you do.

For instance: I run several personal, business, and other’s domains on this colocated machine. Several are “vanity” domains, and have no place being seen when someone clicks “View Certificate” on a business site. “saab.party” is cute (at least I think so), but doesn’t need to be there, just because it’s on the same machine.

A counterargument might be “Don’t use LE for business”, but for smaller businesses- it makes sense if you are using it only for web security, and not for purchasing or selling items. Many smaller business are also configured as VirtualHosts, rather than having their own machine, or even their own IP. It just isn’t part of their actual business- which can be hard to remember for those of us who live vicariously through the internet.

For now, I’m going to group my LE update and new requests separately for (www.?)domain.tld groups, the way it used to work.

I figure I might as well follow up on yesterdays’ post:

• Writing Tech 2 binaries onto a PCMCIA card is as simple as ‘dd’.

All you need to do is load Linux on a machine with a supported PCMCIA cardbus interface, load drivers, and write the image to the drive’s /dev/ entry using ‘dd’.

I used conv=dsync just to be safe- but it worked perfectly, which is more than I can say than how I would feel about shelling out hundreds of dollars to do the same under Windows.

I was able to get data from the Impala (4th digit of VIN is production series, or, ‘W’ in this case), and found that the front passenger speed sensor is not reporting. Time to check the harness and sensor!

The local pub has a $2 Taco Tuesday special- Tacos are $2, and Burgers are $2 off. It’s become a bit of a weakly followed tradition in our household. As usual, they were delicious, even a bit overloaded. I certainly wouldn’t have ordered two if I had known.

I’ve got the battery installed in the Impala, which is running perfectly- but it is still throwing an ABS light. I have owned a Tech 2 for use with my SAABs, and I have a secondary GM card which is semi-generic for all GMs through 2010ish- which I had never used.

I tried to use it today, and no go- it’s not formatted properly. The Tech 2 hangs solid after downloading it, so that just doesn’t do.

The GM image is a single binary blob, and the Tech 2 only works with linear memory, so I’m going to boot from a Puppy/DSL USB drive and DD the image directly to the flash device.

It’s about 20 degrees out and dark, so I won’t be testing anything until tomorrow.