Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

2-4: LAB | A Subnet Router

Lab Setup

As before, let’s understand what we’re launching by examining the podman-compose.yml file in the labs/2-4 directory. Structurally, the big difference in this lab is the addition of a new machine: the home webserver. It’s on the home network, but it will not have Wireguard installed. Instead, we need to configure the home-router device to route traffic to it (and anything else in the subnet we want).

Incidentally, pay close attention to the IP addresses assigned in the compose file. You’ll need them later, and having them handy saves a few ip a s calls.

You will see in the home-router/home-router.conf that the nft commands we discussed in the last section have been added.

Let’s get the lab up with:

just up 2-4

Once again we have a new Zellij session. This one has two tabs: os-shell for host OS commands, and lab_2-4 which has our lab machines. We’ll live in the second tab for now. Remember you can click on it, or use Ctrl+t to navigate tabs.

This time, we have four machines. Clockwise from the top left, we have:

  1. Lighthouse
  2. Roaming Peer
  3. Home router (subnet router)
  4. Home webserver

The only one without Wireguard is the home webserver, since we’re trying to expose it via the home router.

With each successive lab, we automate what we’ve come to understand manually in previous exercises. For this one, you don’t have to worry about adding keys to each config; the setup scripts for the lab have handled that. See for yourself by running cat /etc/wireguard/lab_2-4.conf in each of the Wireguard-using containers. Magically, the keys are already populated!

Note

It isn’t magic, but any sufficiently advanced Bash is indistinguishable from magic.

Now as for the home webserver. There’s a lightweight web service running on this thing. You can confirm it’s working by running this on the home router:

curl http://192.168.99.10
# OR
curl http://lab_2-4_webserver

Either hostname works thanks to container networking. Remote Peers will have to use the IP address (for now).

On the home router, have a look at the Wireguard config.

cat /etc/wireguard/lab_2-4.conf

You’ll see exactly the NFTables commands we’ve discussed for getting tables and chains set up for port forwarding and masquerading in PostUp commands. And you’ll see a small set of PostDown commands to remove those entries when the interface is destroyed. The other Peer configs look more familiar, and as mentioned, they’ve already been filled in with the necessary key and address values.

Running the Lab

On all but the webserver, bring up Wireguard.

wg-quick up lab_2-4

This is pretty simple, ultimately. From the roaming Peer, try to access the local webserver.

curl http://192.168.99.10

You should see a response! The Lighthouse->Home Router path is working! Or is it??

Podman does all sorts of weird backplane networking between containers.

Even the roaming Peer can see the webserver!

Running the Lab

On all but the webserver, bring up Wireguard.

wg-quick up lab_2-4

This is pretty simple, ultimately. From the roaming Peer, try to access the local webserver.

curl http://192.168.99.10

You should see a response! The Lighthouse->Home Router path is working! Or is it??

Podman does all sorts of weird backplane networking between containers. How do we know for sure Wireguard is doing the routing?

If you look closely at the Containerfile for this lab’s Peer images, you’ll note that we now have iputils-tracepath installed. You can use this to confirm how your packets are getting to the webserver.

tracepath 192.168.99.10

Your output should look like:

 1?: [LOCALHOST]                      pmtu 65440
 1:  172.16.100.1                                          0.328ms
 1:  172.16.100.1                                          0.410ms
 2:  172.16.100.2                                          0.780ms
 3:  192.168.99.10                                         0.853ms reached
     Resume: pmtu 65440 hops 3 back 3

The packets travel through the Wireguard subnet, demonstrating that our network is up and routing is correct.

Now, just to demonstrate that this is all self-contained in Wireguard, run the Wireguard shutdown command on all but the webserver.

wg-quick down lab_2-4

You’ll see the home router run the nft delete command that removes the port forwarding and masquerading rules. The operations only work when Wireguard is up—actually, when that specific Wireguard configuration is up.

You can also re-run the tracepath command above. Yes, Podman is still routing the traffic, but you’ll note that it’s happening over the Podman router rather than Wireguard.

Stopping the Lab

As usual, use the os-shell tab to run just down 2-4 to bring down the lab.