The Fortress

Welcome to Part IV. By now you have real services running (Part II) and a way to reach them from your phone (Part III). But everything you've built so far lives on top of something you probably haven't looked at directly yet: your home network. This is the invisible plumbing that connects every device in your house, and understanding it is the difference between a hobbyist who hopes things work and a sovereign builder who knows they do. Don't worry — there is no math here, and by the end of this module the words "IP," "port," "subnet," and "VLAN" will feel as ordinary as "kitchen" and "front door."

Let's start with the box that everything runs through.

You have a box in your house — maybe from your internet provider, maybe one you bought — that your internet connection plugs into. That box is your router. Think of it as the front desk of a big office building. Every piece of mail (data) that comes in from the outside world, and every piece of mail your devices send out, passes through that front desk. The router's job is to make sure the right mail gets to the right room.

Inside your house, your laptop, your phone, your server, your smart TV, and your printer are all "rooms" in the building. The router knows where each one is and directs traffic between them and out to the internet. When your phone loads a website, that request goes to the router, out to the internet, comes back, and the router hands it to your phone — not your printer, not your neighbor's house. The router keeps everyone's mail straight.

Your router does one more crucial thing: it stands as a wall between your cozy home and the wild open internet. The outside world cannot see directly into your house. It can only see the router's public face. This is a natural first layer of protection, and we'll build more layers on top of it.

Every "room" in the building needs an address so the front desk knows where to send its mail. That address is called an IP address (IP stands for "Internet Protocol," but you never need to remember that). It looks like four numbers separated by dots, for example 192.168.1.42.

Here is the single most important idea in this whole module: there are two kinds of IP addresses, and confusing them is where beginners get lost.

A private IP address is the address a device has inside your house. It's like an apartment number — "Apartment 42." It only means something inside your building. Every home network uses private addresses, and they almost always start with 192.168. or 10.. Your laptop might be 192.168.1.42 and your server might be 192.168.1.50. These are the addresses your devices use to talk to each other.

A public IP address is the single address your whole house shows to the internet — the street address of the whole building. Your internet provider gives this to your router. When any device in your house talks to the internet, the outside world sees only this one public address, not the individual apartment numbers. This is why, in Part III, you needed a tunnel to reach your server from outside — the outside world can't dial "Apartment 50" directly; it only knows the building's street address.

When you see an address starting with 192.168. or 10., relax — that's a private, in-your-house address. It can never be reached directly from the internet. That's a safety feature, not a limitation.

A subnet (short for "sub-network") is just the group of addresses that belong to one network — one building. In most homes, the subnet is written as 192.168.1.0/24. Don't panic at the /24. In plain English it means: "every address from 192.168.1.1 to 192.168.1.254 is in this building, and they can all talk to each other freely."

The first three numbers being the same (192.168.1.___) is what tells devices they're neighbors on the same subnet. If your laptop is 192.168.1.42 and your server is 192.168.1.50, they share the first three numbers, so they're on the same subnet and can chat directly. This is why, when you set up a service in Part II, you could reach it from another computer in your house by typing its private IP — they were neighbors.

A well-run home lab keeps everything on one subnet — say 192.168.1.0/24 — so every machine (the rig, the hub, the NASes) lives inside it. Keeping everything on one known subnet is exactly the kind of discipline that makes a network easy to reason about.

An IP address gets mail to the right building and the right apartment. But inside one apartment, there might be many different people expecting different mail — a web service, a file service, a chat service, all on the same server. A port is like the specific mail slot or department within that apartment. It's a number, and it tells the server "this mail is for the web service" versus "this mail is for the file service."

You've already been using ports without thinking about it. When your app runs on :8080 or :3000, that number after the colon is the port. So 192.168.1.42:8080 means "the machine at apartment .42, please deliver this to the service listening on mail slot 8080." Websites use port 443 for secure connections and 80 for plain ones by default, which is why you rarely type them — your browser assumes them.

The takeaway: a device has one IP address but many ports, one for each service it runs. Later, when we build a firewall, we'll be deciding which mail slots are allowed to receive mail from where. Ports are the vocabulary of that decision, so it's worth being comfortable with them.

When a new device joins your network — say a guest's phone — it needs an apartment number. It would be a nightmare if you had to assign these by hand. So the router does it automatically through something called DHCP (you can forget the acronym; just think "the automatic address-giver"). A device connects, says "I'm new here," and the router hands it a free address from the pool. Wonderful for phones and laptops that come and go.

But there's a catch for your servers. Because DHCP hands out whatever address is free, your server might be 192.168.1.50 today and 192.168.1.63 next week after a reboot. That would break every tunnel, bookmark, and link you set up in Parts II and III, because they all point at a specific address.

The fix is a DHCP reservation (sometimes called a "static lease" or "address reservation"). You tell the router: "This particular device — I'll identify it by its unique hardware ID — always gets this exact address, forever." Now your server is guaranteed to be 192.168.1.42 every single time, and nothing breaks.

To set one up, you log into your router (usually by typing its address, often 192.168.1.1, into a browser), find a section called something like "LAN," "DHCP," or "Address Reservation," and add a reservation. You'll pick your server from a list of connected devices and assign it a fixed address. Every device has a permanent hardware fingerprint called a MAC address (a string like a4:b1:c2:d3:e4:f5) — the router uses that to recognize your server no matter what. A serious home stack uses reservations for exactly this reason: every important machine pinned to a known address so the fortress never shifts underfoot.

You'll constantly want to know "what's the address of that machine?" Here are the friendly ways.

On the Linux machine you're sitting at, open a terminal and run:

What you'll see: a wall of text describing each network connection. Look for a line that says inet followed by an address like 192.168.1.42/24. That's this machine's private address. Ignore anything that says 127.0.0.1 (that's the machine talking to itself, nicknamed "localhost" — it's always there and always the same). If the wall of text is overwhelming, this shorter command prints just the useful line:

To find every device on your network — the real map of your kingdom — the cleanest source of truth is your router's admin page, which lists every connected device with its name and address. Alternatively, a tool called nmap can scan the whole subnet and report who's home:

What you'll see: a list of every address currently responding, one block per device. (If nmap isn't installed, your package manager can add it, or just use the router page — it's friendlier anyway.) Spend five minutes with this list. Knowing exactly what lives on your network is the foundation of securing it — you can't protect what you don't know is there.

Here's the idea that turns a network from "everything can talk to everything" into a real fortress. Right now, if everything is on one subnet, your smart doorbell, your cheap smart plug, your TV, and your bank-login laptop are all neighbors in the same building — and neighbors can knock on each other's doors. That cheap smart plug was made by a company that may never patch its security holes. If a hacker gets into it, they're now inside your building, and they can try the handles on every other door, including your computer with your Bitcoin wallet on it.

A VLAN (Virtual Local Area Network — think "a separate building inside the same box") solves this. It lets your one router pretend to be several completely separate networks that cannot talk to each other unless you explicitly allow it. You put your trusted computers on one VLAN, and all the cheap, chatty, can't-be-trusted "Internet of Things" gadgets — smart plugs, doorbells, cameras, TVs — on a separate isolated VLAN.

Now if that doorbell is compromised, the attacker is trapped in the IoT wing with nothing valuable — they can't cross the hallway to your real computers. This is called network segmentation, and it's one of the highest-value moves you can make. Cameras especially belong here (we'll return to them in Module 04): a camera should watch your house, not have a road to your data.

Setting up VLANs requires a router that supports them (many provider-supplied routers don't; enthusiast routers and the one this builder uses do). The general shape is: create a new VLAN and a new Wi-Fi network attached to it, then set a firewall rule that blocks traffic from the IoT VLAN to the trusted VLAN. This is more advanced, and it's fine to circle back to it later — but plant the flag now. A sovereign home eventually separates its trusted machines from its disposable gadgets. For today, simply understanding why is the win. You now understand your network better than most IT professionals did on their first day. Onward to locking it down.