Summary
In this chapter, we took a look at networking and firewalls in the Linux world. I hope it didn't hurt your head too much, because it certainly causes me some pain.
As I alluded to earlier, networking and firewall configuration can be as complex or as simple as you want it to be, and in the ever-growing world of single-use servers, we're seeing simpler and simpler configurations in the wild.
Where you tend to find problems are around the concepts of multiple networks and multi-homed servers, because flat network structures are a lot easier to understand for the average person (myself included).
You also don't have to do everything with Linux.
Yes, Linux can act as a border firewall for an estate, but you could also use F5 devices, or Check Point boxes.
Yes, Linux can act as a router, but you're much more likely to see a Cisco or a Juniper device in the network cabinet.
These solutions have their positives, as well as their negatives.
A simple positive is that a purpose-built appliance is generally very good at the thing it was purpose-built for, and the tools to manage it are pretty much uniform in their approach (rather than the sometimes-mash we get in the Linux world).
An obvious negative is that it either means you have to learn the technology stack of the device you're incorporating into your network, or you have to hire a purpose-built-person to manage the solution for you, costing time and money.
Networking seems to be something that you either like or dislike, and I fall firmly in the latter camp. In theory, networks and firewalls "just work" once they're set up, but in practice that means the edge case problems are much more difficult to track down and correct when they do, inevitably, happen.
One final thing to mention—because I guarantee you'll have to deal with it at some point in your professional career—is the problem of locking yourself out.
It happens.
When it does, don't beat yourself up about it. Literally every engineer I've ever worked with has locked themselves out of a box once, either through a misconfigured firewall rule, or a silly mistake such as changing the SSH port without first updating the SELinux configuration.
If you lock yourself out and you have access to a console, either a remote Keyboard Video Mouse system or something like a cloud provider's web-based Terminal, you're usually fine—it just means logging in and correcting your mistake.
If you lock yourself out and the system is on the other side of the city, or country, you've got two options:
- Hop into your car and resign yourself to a long drive there and back.
- Contact the remote engineer and prostrate yourself before them, admitting your error and begging them to find a crash cart to resolve your mishap.
If you choose option two, buying them a beverage of their choice the next time you meet is more than agreeable.