Royal Army College

Lesson Overview

Lesson 01 set out what a digital Principality runs on, the services, the records, the identity system, and the people who keep them safe. This lesson follows a single ordinary act, typing a domain into a browser and reaching the page you wanted, and pulls it apart slowly so that nothing about it stays mysterious. That short journey, from a phone or laptop to a service running on a server somewhere, passes through more careful machinery than most people ever notice: a network, a naming system, a guard that routes the traffic and locks it, a certificate that proves identity, a firewall that decides what is even reachable, and a packaged service waiting to answer. Understanding that journey is the foundation for everything else in this course.

The aim here is not to make you an engineer in an hour. It is to give you an honest, accurate mental model, in plain words, of the parts and how they fit, so that when you later hear "the reverse proxy is down" or "the certificate expired" or "that port is blocked at the firewall", you know what is being talked about and roughly where to look. None of this requires you to touch a live system. It requires you to understand one, which is the first duty of anyone who will one day help run it.

This is the knowledge layer. It explains the parts and the path between them so that the picture makes sense and sticks. The hands-on part, looking at a real reverse-proxy route, reading a certificate's details, checking which ports a firewall allows, or starting and stopping a container under instruction, is done and signed off in person, under supervision, where the course requires it and where supervision allows. By the end you will be able to explain the difference between a client and a server and between a service and the server it runs on; describe how a request travels from a client through DNS and the reverse proxy to a service and back; define IP address, port, DNS, LAN, and WAN in plain terms and say what each contributes; explain what a reverse proxy does and why it handles TLS and HTTPS for the services behind it; explain what a certificate proves and how Let's Encrypt automates one; describe what a firewall controls and why "reachable" and "allowed" are different things; and explain what a container is and why packaging a service that way lets it run the same on any Linux server.

Key Terms

Client: a device that asks for something, the phone, laptop, or tablet a person uses to open a page or an application. The client starts the conversation.
Server: a computer, usually always-on and kept in a data centre or on a rented machine, whose job is to run services and answer the clients that ask. A server is a role, not a size; one physical machine can host many servers' worth of work.
Service: a piece of software that does a defined job and waits to answer requests, for example a website, a records system, a chat server, file storage, or the identity service. Several services can run on one server at once.
Daemon: the background form a service takes on a Linux server, a program that keeps running quietly, started at boot, listening for work rather than being opened by a person. The records system "running as a daemon" simply means it is always up and waiting.
IP address: the numeric address of a device on a network, the equivalent of a postal address, so that data can be delivered to the right machine and a reply sent back. Every client and every server has one.
Port: a numbered door on a server that a particular service listens behind, so that one machine with one address can run many services without confusion. Web traffic over HTTPS uses port 443.
LAN (Local Area Network): the local network in one place, the devices on one site or one office talking to each other and to a local router, usually trusted and close together.
WAN / internet: the wide-area network beyond the local one, the public internet that ties distant networks together. A non-territorial Principality lives almost entirely on the WAN, with its people and its servers in different places.
DNS (Domain Name System): the internet's directory, the system that turns a human-friendly name such as a domain into the numeric IP address a machine needs, the way a phone book turns a name into a number.
Domain: the human-readable name of a service, the thing a person types or clicks. Names are easy to remember and to publish; the machinery underneath translates them to addresses.
Reverse proxy: a service that sits in front of other services, receives every incoming request, decides which service it belongs to, forwards it there, and brings the answer back. It also commonly handles HTTPS for all the services behind it. Traefik and Nginx are two such tools.
TLS / HTTPS: Transport Layer Security is the encryption that protects traffic in transit so it cannot be read or altered on the way; HTTPS is simply HTTP, the web's request language, carried inside TLS. The padlock in a browser means TLS is in use.
Certificate: a signed electronic document that proves a server really is the owner of the name you asked for, and carries the key used to set up the encryption. It is what stops an imposter from convincingly pretending to be the genuine site.
Certificate authority (CA): a trusted organisation that issues certificates after checking the requester controls the name. Let's Encrypt is a free, automated certificate authority widely used to issue and renew certificates without human effort.
Firewall: a control that decides what network traffic is allowed to reach a machine or a network, and what is refused, so that only the services meant to be reachable are reachable from outside.
Container: a lightweight, self-contained package that holds a service together with everything it needs to run, so it runs the same way on any compatible server. Docker is the common tool for building and running containers.
Linux: the open-source operating system that most servers and most self-hosted services run on, managed largely through a command line and organised around users, permissions, packages, and background services.

Clients and servers, services and machines

Start with the simplest split, because every other idea hangs off it. On one side is the client, the device in a person's hand or on their desk, a phone, a laptop, a tablet. On the other side is the server, a computer kept always on whose job is to answer. The client asks; the server answers. When you open a page, your client sends a request out across the network, and a server somewhere receives it, does the work, and sends a reply back. That call-and-answer pattern is the whole shape of the web, repeated billions of times a second across the world.

It is worth being precise about two words people often blur. A server is a machine, or more exactly a role a machine plays, the answering side of the conversation. A service is the software running on it that actually does a job: a website, a records system, a chat server, file storage, the identity service. One server can run many services at once, the way one building can house many offices, and one busy service can be spread across several servers. So when someone says "the records server", they usually mean the machine, and when they say "the records service", they mean the program; in a small estate these are often the same box, but keeping the words straight saves confusion later.

On a Linux server a long-running service usually takes the form of a daemon, a program that starts when the machine boots and then sits quietly running in the background, listening for requests rather than being opened by a person clicking an icon. You do not "launch" the records system the way you launch a word processor; it is simply always up, waiting. That always-on, always-listening quality is exactly what lets a client reach it at any hour, and it is also why keeping servers patched, monitored, and backed up, the subject of later lessons, matters so much: the service never closes for the night.

A non-territorial Principality leans on this picture more heavily than most organisations, because it has no single building where everyone and everything sits together. Its people are clients spread across many places; its services run on servers spread across the internet; and the network between them, rather than any corridor or campus, is what holds the state together.

The network: addresses, the LAN, and the wide world

For a client to reach a server, both must be findable, and they are found by their IP address, a numeric address rather like a postal address. Every device that talks on a network has one. When your client sends a request, it is addressed to the server's IP, and it carries your own IP as the return address so the answer knows where to come back. Addresses are how data finds the right machine among the millions on the internet, and nothing reaches the right place without one.

Networks come in two scales worth naming. The LAN, the local area network, is the small, near, usually trusted network in one place: the devices in one office or on one site, talking through a local router. The WAN, the wide-area network, is the big one, the public internet, tying distant networks together across the world. The crucial security difference follows from that: traffic on your own LAN stays mostly among known devices, while traffic on the WAN crosses untrusted ground where it could be observed or tampered with, which is exactly why encryption in transit, covered shortly, matters so much.

A Principality with no territory does almost everything over the WAN. Its members sign in from wherever they are; its servers sit on rented machines reached across the public internet; there is no single trusted office LAN that contains the state. This is liberating, the state can be run from anywhere, and demanding, because you must assume traffic can be seen unless you protect it and that machines can be probed unless you guard them. Hold that thought, because it is the reason every later part of this lesson exists.

   TWO SCALES OF NETWORK

   LAN (Local Area Network)              WAN / INTERNET (Wide Area)
   one site, near, mostly trusted        the public internet, far, untrusted
   +--------------------------+
   |  laptop   phone   printer|                  +----------+
   |     \      |      /       |                 |  Server A |
   |      \     |     /        |   ~~~~~~~~~~~~~  +----------+
   |       [ local router ]----|---->( the WAN )--+----------+
   |          (your site)      |   ~~~~~~~~~~~~~  |  Server B |
   +--------------------------+                   +----------+
                                                  (rented, elsewhere)

   On the LAN, devices are close and known.
   On the WAN, traffic crosses untrusted ground:
   assume it can be seen unless encrypted, and probed unless guarded.
   A non-territorial state lives almost entirely on the WAN.

From a name to an address: what DNS does

People do not remember numbers; they remember names. You type a domain, a friendly name, not a string of digits. But the network only routes by IP address, so something must turn the name you typed into the number the network needs. That something is DNS, the Domain Name System, the internet's directory. It works like a phone book in reverse-old style: you give it a name, it gives you back the address.

The sequence is quick and worth picturing once. Your client takes the domain you typed and asks DNS, "what is the IP address for this name?" DNS looks it up and answers with the address. Only then can your client send its request, now addressed to that IP, out across the network to the right server. DNS does not carry your page or your data; it does one job, name to address, and then steps aside. But it is a job everything else depends on, which is why a DNS problem looks, to a user, exactly like the whole service being down: if the name cannot be turned into an address, the request never leaves.

For the Principality this naming layer lets a service be published under a clear, memorable domain while the actual server, its real address, changes underneath without anyone needing to know. Move a service to a new machine, point its name at the new address in DNS, and clients keep using the same domain as before. The name is the stable public face; the address behind it is a detail DNS quietly keeps current.

The guard at the gate: the reverse proxy, TLS, and certificates

So your client has an address and sends its request across the network. It does not usually arrive straight at the records service or the chat service. It arrives first at a reverse proxy, a service whose whole job is to sit in front of the others and direct traffic. Tools such as Traefik and Nginx play this role. The reverse proxy receives every incoming request, reads which domain it was for, decides which service behind it that belongs to, forwards the request there, waits for the answer, and passes the answer back to the client. From the outside it looks as though you reached the service directly; in truth you reached the proxy, and the proxy reached the service for you.

Why put a guard at the gate at all? Because one front door is far easier to defend and manage than a dozen. The reverse proxy lets many services share a single public entry point and a single address, sorting each request to the right place by its domain. And, most importantly for security, it is the natural place to handle TLS, the encryption that protects traffic in transit. Rather than make every service implement encryption correctly on its own, the proxy terminates HTTPS at the front: it does the encryption with the client, then hands the request to the service behind it. HTTPS is simply the web's ordinary request language carried inside TLS, and the padlock a user sees in the browser is the sign that TLS is working and the connection is private.

TLS does two things at once, and both matter. It encrypts the traffic so that no one watching the untrusted WAN can read or alter what passes, and it lets the server prove its identity so the client knows it is talking to the genuine service and not an imposter. That proof is the job of the certificate, a signed electronic document that says, in effect, "the holder of this really does own this domain", and that carries the key used to set up the encryption. Without it, an attacker could stand in the middle pretending to be the genuine site and quietly capture everything. With it, the client can refuse to trust a pretender whose certificate does not match.

A certificate is only as good as the trust behind its signature, and that trust comes from a certificate authority, an organisation that issues one only after checking the requester really controls the name. Let's Encrypt is a free, automated certificate authority that has made this almost effortless: a reverse proxy like Traefik can ask for a certificate, prove control of the domain automatically, receive it, and then renew it on its own before it expires. Certificates are deliberately short-lived, so automation is not a luxury; a forgotten manual renewal is a classic cause of a service suddenly showing a browser warning and turning users away. Automated issuance and renewal quietly keep the padlock green without anyone remembering to act, which is exactly what a small force needs.

   THE JOURNEY OF A REQUEST
   (typing a domain and reaching a service)

   [1] CLIENT                you type a domain and press enter
        |
        |  "what IP is this name?"
        v
   [2] DNS  ---------------->  returns the server's IP address
        |
        |  request, now addressed to that IP, sent over the WAN
        v
   [3] FIREWALL ............  is port 443 allowed in? yes -> pass
        |                                            no  -> dropped
        v
   [4] REVERSE PROXY (Traefik / Nginx)
        |   - sets up HTTPS/TLS with you (encryption + identity)
        |   - presents the CERTIFICATE that proves it owns the name
        |   - reads the domain, picks the right service
        v
   [5] SERVICE (a container, listening on its port)
        |   does the work, builds the answer
        v
   [4] REVERSE PROXY  ------  carries the answer back, still encrypted
        |
        v
   [1] CLIENT                the page appears. Padlock = TLS worked.

   Each step does ONE job. A fault at any step looks, to the
   user, like "the site is down": name unresolved, port blocked,
   certificate expired, proxy stopped, or service crashed.

What is reachable, and what is allowed: firewalls and ports

A server may run several services, and each waits behind its own port, a numbered door on the machine. One server has one address but many ports, so that a single machine can run a website, a records system, and an identity service at once without their traffic colliding; each listens on its own port and answers only what arrives at its door. HTTPS, the encrypted web, lives on port 443, and you will meet that number constantly. A request does not just go to an address; it goes to an address and a port together, the building and the office within it.

Now the security control that governs all of this: the firewall. A firewall decides which traffic is allowed to reach a machine or a network and which is refused. This is where two ideas that sound the same pull apart. A service may be running and listening on a port, but that does not mean the wider world can reach it. The firewall stands between, and unless it permits traffic to that port from outside, the service is effectively invisible to the WAN no matter how busy it is internally. "Reachable" is a decision the firewall makes; "running" is a state the service is in; a well-run estate keeps most things running but only a few things reachable.

The disciplined default is to allow as little as possible. A typical small estate exposes only the ports it must, very often just the encrypted web on 443 and a tightly guarded way for administrators to log in, and refuses everything else from the public internet. Databases, internal management interfaces, and the back ends of services are kept reachable only from inside, never from the open WAN, even though they are running the whole time. This is the network equivalent of least privilege, the same principle you met for accounts: open only the doors that a real need requires, and keep the rest shut. It shrinks dramatically the surface an attacker can even touch.

   ONE SERVER, MANY DOORS: REACHABLE vs RUNNING

                         FIREWALL
                    (decides what is reachable)
   from the      +----------------------------------+
   public WAN    |  ALLOW  443  (HTTPS)  --------->  | --> web service   (running)
   ------------> |  ALLOW  (guarded admin login) --> | --> admin access  (running)
                 |  DENY   database port  ----X      |     database       (running,
                 |  DENY   internal admin UI -X      |     internal UI     reachable
                 |  DENY   everything else  --X      |     ...             ONLY from
                 +----------------------------------+                      inside)

   Running and listening is NOT the same as reachable.
   A service can be fully up yet refused at the firewall.
   Default: expose the few ports a real need requires; deny the rest.

How services are packaged and run: containers and Linux

One question remains: what is the service, as a thing you could point at, and how does it come to be running on the server in the first place? Increasingly the answer is a container. A container is a lightweight, self-contained package that holds a service together with everything it needs to run, the program itself, its settings, and the supporting pieces it depends on, sealed into one unit. Docker is the common tool for building and running them. Because the container carries its own dependencies, it runs the same way on any compatible server: the machine that built it, a colleague's laptop, and the production server all see the same package behave identically. This is the cure for the oldest complaint in computing, "but it worked on my machine"; with a container, it works the same everywhere because it brings its own world with it.

Containers suit a small force especially well. A few servers can each run many containers side by side, each holding a different service, each isolated from the others so a fault or a compromise in one is far less able to spread. Standing up a new service can be as clean as running its container, and replacing or updating one is a matter of swapping the package. When a later lesson speaks of "force-recreating a container" or "bumping the image", it means exactly this: handling a service as a sealed, swappable package rather than a tangle of files spread across the machine.

Under the containers, almost always, is Linux, the open-source operating system that most servers and most self-hosted services run on. You do not need to be a Linux administrator to understand this course, but you should know the shape of it: Linux is managed largely through a command line rather than only by clicking; it organises everything around users and permissions, so that what each account may do is controlled precisely; software arrives as packages that install and update cleanly; and long-running services live as the background daemons met earlier. The reverse proxy, the firewall, the container engine, and the services themselves all sit on this Linux foundation. A deeper, practical grounding in it is its own study, drawing on standard references such as How Linux Works, and it is where a member growing towards real administration should head next.

Put the whole picture together and the once-mysterious act dissolves into understandable parts. You type a domain; DNS turns that name into an address; your request crosses the untrusted WAN to that address and the encrypted port behind it; a firewall lets it through only because that port is deliberately allowed; a reverse proxy meets it, proves the server's identity with a certificate from a trusted authority, sets up TLS so nothing can be read in transit, and routes the request to the right service; that service is a container running on a Linux server, listening patiently on its port; it does the work and the answer travels all the way back, still encrypted, to your screen. Nothing in that chain is magic. Every link is a part you can now name, and a part that someone, one day perhaps you, keeps working.

In Practice: A Systems Assistant Traces a Broken Page

An OR-3 Corporal serving as a systems assistant is told that one of the Principality's internal services, reached at its usual domain, has started showing a browser warning and will not open, while every other service on the same estate is fine. He has no wider access and is not asked to fix anything live; his supervisor walks him through reading the situation, because understanding the journey of a request is exactly how you find where a journey has broken.

He works along the path in order, the same path this lesson drew. First the name: he confirms the domain still resolves, that DNS still turns it into an address, so the problem is not naming. Next the network and the firewall: other services on the same server answer normally on port 443, so the port is reachable and the firewall is plainly still allowing the encrypted web through; the request is getting in. He then reads the warning the browser is actually showing, and it speaks of the certificate: the connection's identity proof has expired. Now the picture is clear. The reverse proxy fronting this service should have renewed that certificate automatically through Let's Encrypt before it lapsed; for some reason the renewal did not complete, so the proxy is presenting an out-of-date certificate and browsers are rightly refusing to trust it. The service behind it is running perfectly; the container is up and listening; nothing is compromised. What failed is one link in the chain, the automated renewal of the proof of identity.

He writes this up plainly for the administrator who holds the appointment for that system: name resolves, port reachable, service running, certificate expired, automatic renewal apparently not completing, recommend checking the proxy's renewal for this domain. He changes nothing himself, because he understands that access follows appointment and that an undocumented poke at a live proxy is exactly the kind of thing this course teaches against. But he has turned a vague "the site is down" into a precise, located fault, and he has done it only by knowing the parts and the order they sit in. The administrator restores the renewal, the padlock returns, and the assistant has learned the most useful lesson of all: when a request fails, walk the journey, and the broken step will show itself.

Check Your Understanding

Describe, in order, the journey of a request from a client typing a domain to reaching the service and getting an answer back. Name the part that does each job, DNS, the firewall, the reverse proxy, the certificate, the service, and say in one line what each contributes. Then explain why a fault at any single step tends to look, to the user, like the whole site being down.
Explain the difference between a service that is running and listening and one that is reachable, and the role the firewall plays between them. Why is the disciplined default to expose as few ports as possible, and how is that the network version of least privilege? Use port 443 as your example of a port that usually is exposed.
Explain what TLS and a certificate together provide, both the encryption and the proof of identity, and why both matter on the untrusted WAN. Then explain what a certificate authority such as Let's Encrypt does, and why automated renewal of certificates is important rather than optional for a small force.

Reflection (write a short paragraph): Before this lesson, the act of typing a domain and reaching a service was probably one indivisible thing that simply worked. Now it is a chain of named parts. Pick the one part of that journey, DNS, the network and firewall, the reverse proxy, the certificate, the container and Linux underneath, that you understood least clearly before and that this lesson changed most for you. Explain in your own words what it does and why the journey would fail without it. Then consider this: the Principality has no building you can walk into to check that its state is intact; it has only these parts, working, on the open internet. How does understanding the journey, rather than treating it as magic, change the way you would think about helping to keep that state reachable and safe?

Summary

A client asks and a server answers. A server is the machine or the answering role; a service is the software doing a job on it, and one server can run many services. On Linux a long-running service is a background daemon, always up and listening.
Devices find each other by IP address. The LAN is the near, mostly trusted local network; the WAN / internet is the wide, untrusted public network. A non-territorial Principality lives almost entirely on the WAN, so you must assume traffic can be seen unless encrypted and machines probed unless guarded.
DNS turns a human domain name into the numeric IP address the network needs, the internet's directory. It does one job and steps aside, but everything depends on it, which is why a DNS failure looks like a total outage.
A reverse proxy such as Traefik or Nginx sits in front of the services, routes each request to the right one by its domain, and handles TLS / HTTPS so traffic is encrypted in transit. This gives many services one defended front door and one place to get encryption right.
A certificate proves a server really owns the name you asked for and carries the key for the encryption, stopping an imposter from impersonating the genuine site. A certificate authority like Let's Encrypt issues certificates after checking control of the name, and automates issuance and renewal so a forgotten manual renewal never silently breaks the padlock.
A service listens on a port (HTTPS on 443), and a firewall decides what is reachable from outside. Running and listening is not the same as reachable: the disciplined default exposes only the few ports a real need requires and denies the rest, the network form of least privilege.
A container (commonly Docker) packages a service with everything it needs so it runs the same on any server, isolated from its neighbours and easy to update or replace. Under it sits Linux, organised around the command line, packages, users and permissions, and daemons, the foundation a member growing towards administration should study next.
This lesson is the partner of Lesson 01 (What Runs a Digital Principality) and leads into Lesson 03 (Accounts, Identity, and Single Sign-On) and Lesson 04 (Keeping Systems Running). The "expose as little as possible" and "access follows appointment" disciplines here are deepened in CIS 220 (Identity, Access, and Records Security), echoed in SIG 220 (Communications Security and Digital Discipline), and underpin the continuity work of HCR 220 and CIS 310.

Servers, Services, and the Network