There is a problem you have been carrying since 06-03 without solving it completely. PostgreSQL listens on 10.0.2.15:5432 and ufw only allows it from 10.0.2.0/24, which is fine as long as you are inside that network. The HAProxy statistics panel from 07-07 has the same restriction. And when Marta needs to look at a report from home, or when you have to diagnose something on a Sunday, the only route is SSH to the server and work from there — which works, but does not scale and is no use for a graphical tool.

The obvious temptation is to open 5432 to the world with a strong password. That is exactly what you do not do: you would be exposing the database engine to the automated scanners that sweep the internet, and the day an authentication vulnerability appears in PostgreSQL — they have appeared — your entire database would be at stake while you applied the patch.

This lesson builds the correct alternative: a VPN with WireGuard. By the end, the internal network will be reachable from anywhere with a single UDP port open, PostgreSQL and the statistics panel will be closed to the outside, and you will have the same mechanism ready for reaching the media server from 08-03 from a hotel.

1. What a VPN solves and what it does not
2. Use cases and which one Tramontana needs
3. WireGuard versus OpenVPN and IPsec
4. How WireGuard works: interface, peers and cryptokey routing
5. AllowedIPs: routing and access control at the same time
6. Installation and key generation
7. Server configuration
8. Client configuration: laptop and phone
9. Routing, NAT and split tunnelling versus full tunnelling
10. DNS inside the tunnel
11. Integration with the firewall and closing ports
12. Verification
13. Client management: adding, removing and rotating
14. Security: what it protects and what it does not
15. Automation with Ansible
16. Operation and common problems

A virtual private network creates an encrypted tunnel between two points so that the traffic travelling inside it is undecipherable and unalterable to anybody observing from outside, and the endpoints appear as if they were on the same local network.

That is all it does. And it is worth stating precisely, because the marketing of commercial VPNs has created a cloud of false expectations:

The two most important rows on the right:

"It does not encrypt beyond the VPN server." The traffic goes encrypted from Marta's laptop to the server. From there it leaves like any other traffic. If it goes to PostgreSQL without TLS, it travels in the clear across the internal network. The VPN moves the point of trust, it does not remove it — and that is why in 08-02 you configured hostssl for replication.

"It does not turn an internal network into a secure one." It is the conceptual mistake with the worst consequences, and we will come back to it in section 14.

Tramontana needs the first one: remote access. The concrete, bounded objective:

• That Marta reaches the HAProxy statistics panel and the reports from home.
• That you reach PostgreSQL on 10.0.2.15:5432 with a graphical tool, without exposing it.
• That SSH access stops depending on having port 22 published on the internet.
• That, as a consequence, 5432 and 8404 can be closed to the outside.

What is not needed: joining sites (there is only one), or exiting via another IP (nobody needs it, and setting it up would mean routing all of Marta's personal traffic through the company server, which also has privacy implications we do not want).

The choice is WireGuard, and the reasons in order of weight:

1. The 4,000 lines of code are not a curiosity: they are the reason it can genuinely be audited and the reason the attack surface is tiny. OpenVPN and IPsec have had serious vulnerabilities; with twenty-five times less code, there are twenty-five times fewer places to hide them.
2. The cryptography is not configurable, and that is an advantage. There is no algorithm negotiation, no weak suites to disable, no downgrade attacks. Most of the insecure VPNs in the world are not insecure because of a software flaw, but because of a badly done configuration; WireGuard eliminates that entire category of mistake.
3. It runs in the kernel, without copying every packet into user space. On a 2 vCPU server, the difference shows.
4. The configuration fits on one screen and can be understood in its entirety, which means it can be reviewed.

And the two honest reasons for choosing something else:

• If you need a username, a password and a second factor, WireGuard does not do it: it authenticates by public key, full stop. There are layers you can put on top, but it is not native. In a company with a hundred employees and staff turnover, OpenVPN with LDAP and TOTP may be better.
• If the destination network blocks UDP — some corporate and hotel networks only let 80 and 443 out over TCP — WireGuard simply will not connect. OpenVPN over TCP/443 gets through almost anywhere disguised as HTTPS.

For Tramontana, with two or three trusted people and control over the devices, WireGuard is clearly the right option.

Here are the three concepts that make WireGuard either click or not. They are worth reading slowly.

OpenVPN is a daemon that runs, is configured, starts, stops and maintains connections. WireGuard is not a daemon: it is a type of kernel network interface, like eth0 or a VLAN interface.

The practical consequences are large:

• It is configured with ip and with wg, the network tools you have always used.
• The routing is normal Linux routing: ip route, tables, metrics. Everything from 06-01 applies as it is.
• The firewall treats it like any other interface: the nftables rules from 06-03 work the same.
• There is no "server" and no "client" in the protocol. Both ends are identical peers. What we call the server is simply the peer that has a fixed public IP and does not specify an Endpoint for the others.

There is no certificate authority, no certificates, no revocation lists, no PKI. Each device generates a Curve25519 key pair. For two devices to talk, each one needs the other's public key. That is the whole of identity management.

Here is the idea that makes WireGuard different from everything else. In a classic VPN there are two separate mechanisms: one decides where a packet goes (routing) and another decides whether it is allowed (access control). WireGuard fuses them into one.

Each peer has a list of IP addresses associated with it: AllowedIPs. And that list is used in both directions, with two different meanings:

Read in words:

• When sending, AllowedIPs works as a routing table: the packet is encrypted with the key of the peer whose list contains the destination IP.
• When receiving, AllowedIPs works as an anti-spoofing filter: a packet correctly decrypted with luis's key whose source IP is not in luis's AllowedIPs is discarded.

That second part is what makes WireGuard secure by design. Even if Luis's laptop is compromised and his private key stolen, the attacker cannot send packets pretending to be 10.8.0.99 or 10.0.2.15: the cryptography and the routing are tied together, and the kernel discards the packet before it reaches anywhere.

WireGuard has no "connect" and no "disconnect". The interface exists or it does not. When there is a packet to send, WireGuard performs a one-round-trip handshake — if it has not done one in the last two minutes — and sends it. If there is no traffic, there are no packets.

This has three very practical consequences:

• Changing network drops nothing. A phone that moves from Wi-Fi to 5G carries on working: WireGuard detects the change of origin in the next valid packet and updates the endpoint automatically (roaming).
• An inactive peer is indistinguishable from one that is switched off. wg show tells you when the last handshake was, not whether it is "connected".
• WireGuard is silent to anybody without keys. A packet that does not decrypt correctly is discarded without any reply. To a port scanner, WireGuard's UDP port is indistinguishable from a closed port. That property, on its own, already justifies preferring it to exposing services.

The module has been in the kernel since version 5.6, so on Ubuntu 24.04 with kernel 6.8 there is nothing to compile.

The three commands deserve a note: wg genkey generates a Curve25519 private key in base64; wg pubkey derives the public one by reading the private one from standard input; wg genpsk generates 32 random bytes for the preshared key. The derivation is one-way: you cannot get back from the public key to the private one.

The server's private key never leaves the server. Each client's private key never leaves the client. That means that, ideally, it is the client who generates its own pair and sends you only the public key. In practice, for a phone, it is usually generated on the server and transferred by QR code; that is an acceptable compromise if the transfer is direct and the file is deleted afterwards.

Before writing anything, you have to decide the VPN's range. It must not overlap with any network the clients might use:

That 10.0.0.0/24 in the last row is a real trap: it is the default range of many routers, and if a client is on a 10.0.2.0/24 network — the same as Tramontana's internal one — it will have an unsolvable routing conflict. Choosing uncommon ranges for your own infrastructure avoids that problem for ever.

Four details of that configuration worth understanding:

Address = 10.8.0.1/24, with /24 and not /32. The mask determines the route wg-quick adds automatically: with /24, all of 10.8.0.0/24 is routed via wg0. With /32 you would have to add the routes by hand.

The rules go in their own inet wg table. It is the application of what you learned in 06-03: a separate table is removed in one go with nft delete table and does not interfere with the rules ufw manages. The alternative — adding rules to the existing table — leaves leftovers accumulating every time the interface is restarted.

The private key is read from a file with PostUp. Putting it directly in wg0.conf works just the same, but it mixes secret and configuration in a single file, which complicates managing it with Ansible without no_log on everything. Separating them lets you version the configuration and handle the key separately.

AllowedIPs = 10.8.0.2/32 for each client, with /32. It is the correct thing to do and it is where most people go wrong. See section 9.

The official WireGuard apps for Android and iOS read the configuration from a QR code, which saves typing forty-four base64 characters three times:

An important warning about the QR code: it contains the private key in the clear. It is not sent by email, or by WhatsApp, and it is not left in /tmp. It is displayed in the terminal, scanned in front of the phone, and deleted:

A WireGuard QR code photographed over your shoulder is complete access to the internal network.

In the mobile app it is also worth enabling "on-demand VPN" excluding the office Wi-Fi network: that way the tunnel comes up automatically outside and does not get in the way inside.

By default, Linux does not forward packets between interfaces: it is a machine, not a router. For the traffic arriving over wg0 to go out towards 10.0.2.0/24, it has to be enabled:

IPv6 is deliberately left disabled: if you do not use it, enabling it opens a path you are not watching. It is the same logic as 06-06.

Marta, from 10.8.0.3, queries PostgreSQL on 10.0.2.15. Without NAT, the packet reaches PostgreSQL with source 10.8.0.3, PostgreSQL replies to 10.8.0.3... and its routing table does not know where that network is, so it sends the reply to the default gateway and it gets lost.

There are two solutions:

At Tramontana, with everything inside 10.0.2.0/24 and the VPN server being the same machine, masquerading simplifies things and the cost is acceptable. On a larger network, the static route on the router is better: it lets pg_hba.conf tell Marta from Luis by their VPN IP, and it makes the access logs useful.

It is the design decision with the most consequences in the whole lesson, and it is taken with a single line: AllowedIPs on the client.

For Tramontana the decision is the split tunnel, and with three arguments:

1. Bandwidth. All the traffic of three people passing through a 2 vCPU server on a shared connection would degrade everybody's browsing and compete with the bookings application, which is what pays the bills.
2. Privacy. With a full tunnel, all of Marta's personal browsing — including what she does out of hours on her company laptop — passes through a company server and appears in its logs. That has data-protection implications and, above all, it is not necessary for the objective.
3. The objective is to reach the internal services, not to protect general browsing. HTTPS and common sense on public networks are there for that.

When a full tunnel does make sense: a corporate laptop that has to comply with the company's filtering policy wherever it is, or somebody who habitually works from networks that cannot be trusted and needs everything to be encrypted. In that case, AllowedIPs = 0.0.0.0/0 on the client, and the server's masquerading rules already support it exactly as they are written.

With a split tunnel a detail appears that is easy to overlook: internal names.

The client's DNS = 10.0.2.15 directive makes wg-quick configure the resolver while the tunnel is active. On Ubuntu with systemd-resolved, wg-quick uses resolvectl and does something elegant:

With ~tramontana.example as the search domain, only queries for that domain would go to the internal DNS and the rest would carry on via the normal DNS — which is called split DNS and is the ideal arrangement with a split tunnel:

The DNS leak is the symmetrical problem: if the client carries on using the hotel's DNS for everything, that server sees which internal names you look up, which reveals information about your infrastructure. Checking it:

A prerequisite, of course: that there is an internal DNS resolving those names. With three machines, dnsmasq on srv-tramontana is more than enough.

This is the section where the VPN pays for itself, closing ports that had been open since Module 6.

And now the important part. Before closing anything, you have to verify that the VPN works — it is literally the case of "never close the door you are coming in through":

That last decision deserves defending, because the temptation to close 22 is strong. SSH is not closed until you have a second, tested access route. If WireGuard fails after a kernel update, or if the configuration gets corrupted, or if the module does not load, port 22 open with LIMIT and fail2ban is the difference between a scare and a physical trip to the data centre. It is exactly the lesson from 06-02.

The final result:

What has changed, and it is the summary of the project:

How to read wg show, which is the main diagnostic tool:

Check 6 is the one that demonstrates the value of the whole setup: two captures of the same communication, one unreadable on the public network and the other readable inside the tunnel. It is what to show somebody when they ask what exactly a VPN does.

And 7 is the one that confirms the split-tunnel decision: Marta's normal browsing carries on going out over her own connection, as it should.

The key line is wg syncconf: it applies the changes without bringing the interface down, so that adding a new client does not cut off the ones that are connected. With wg-quick down && wg-quick up they would all be cut off, and it is a frequent mistake.

Why removing the peer is enough, and it is an architectural advantage of WireGuard: there is no revocation list, no certificates that remain valid, no expiry window. The server only accepts packets from public keys that are in its configuration. As soon as the key disappears, that device is indistinguishable from any stranger on the internet: its packets are discarded without a reply.

Compare that with OpenVPN, where revoking a certificate requires updating the CRL, making sure the server reads it, and that there are no active sessions. Here it is one command that takes effect on the next packet.

Rotating the server's key is the disruptive operation, because its public key is in every client's configuration. The procedure without interruptions: bring up a second interface wg1 on another port with the new key, migrate the clients one by one, and retire wg0 when the last one has migrated.

It is the basic principle, and it has a concrete operational implication: the correct approach is for the client to generate its own key pair and send you only the public key. The public key can be emailed without any problem at all.

The vpn_add_client.sh script generates the pair on the server because for a phone that is the practical thing to do. It is a conscious compromise, and that is why the script insists on deleting the file once it has been handed over.

It is a 256-bit symmetric layer of encryption mixed into the key derivation, on top of the Curve25519 exchange.

What it protects against, which is a future threat rather than a current one: a sufficiently large quantum computer could break Curve25519 using Shor's algorithm. It does not exist today, nor is it close, but there is a threat model called "harvest now, decrypt later": an adversary with resources captures and stores encrypted traffic today in order to decrypt it in fifteen years' time. The preshared key, being symmetric, is resistant to that attack — Grover only reduces the effective security from 256 to 128 bits, which is still out of reach.

What it does not protect against: anything happening today. It adds no security against classical attackers. It is a cheap insurance policy against a distant risk, and that is why it is in the configuration: it costs one line.

A VPN does not turn an internal network into a secure network.

It is the most important conclusion of the lesson, and the most ignored. With the VPN up, anybody who arrives through the tunnel is inside 10.0.2.0/24 and sees everything a machine on that network sees. If Luis's laptop gets infected with a trojan, that trojan has direct access to PostgreSQL, to the statistics panel and to any service that trusts the internal network.

What follows from that table is the zero-trust architecture: every service authenticates and encrypts on its own account, without trusting the network. In practice, for Tramontana, it means that the VPN replaces nothing you already have: pg_hba.conf still demands scram-sha-256, the statistics panel still needs its restriction, SSH still uses keys and fail2ban, and TLS is still needed on the inside. The VPN is one more layer, not a perimeter that lets you relax the rest.

And an additional restriction that the VPN does let you do well, using AllowedIPs as access control:

Since each peer has a fixed IP guaranteed by the protocol itself — remember: AllowedIPs stops it being spoofed — this rule is reliable in a way it would not be on a normal network.

The public and preshared keys live in Vault, integrated with pass as in 07-06:

Two details of this role sum up what was learned in 07-06: the creates: that prevents the server key being regenerated on every run — which would lock out every client at once — and the handler with wg syncconf instead of a restart, which is the WireGuard version of reload rather than restart from 08-01.

1. Overlapping AllowedIPs — the most common error and the most baffling.

WireGuard resolves the routing by most specific prefix, just like the routing table. With that configuration, traffic to 10.8.0.3 goes to Marta (more specific), but Luis can send packets forging any IP in 10.8.0.0/24, because his inbound filter allows it. That is a security hole, not just a routing problem.

Worse still: AllowedIPs = 0.0.0.0/0 in a peer on the server means "all internet traffic goes via this peer". It is correct in the configuration of a client with a full tunnel and catastrophic in the server's: it breaks all of its connectivity.

Rule: on the server, each client carries only its /32. 0.0.0.0/0 only appears in the client's configuration, never in the server's.

2. The handshake never happens.

In order of probability: the UDP port does not get through (the server's firewall, the router's, or the client's provider); the keys do not correspond (the client's public key on the server is not derived from its private one); the Endpoint is wrong or the DNS does not resolve; or there is a PresharedKey on one side and not on the other.

3. A correct handshake but no traffic. The tunnel is up and nothing goes through. It is almost always one of three things: net.ipv4.ip_forward=1 is missing, the masquerading rule is missing, or the destination network is missing from the client's AllowedIPs.

4. It drops after a few minutes of inactivity. It is NAT: the client's router or the mobile carrier forgets the association. The solution: PersistentKeepalive = 25 on the client.

5. Fragmentation and MTU. The symptom is characteristic and misleading: ping works, SSH connects and then hangs when listing a large directory, web pages load halfway.

• Putting AllowedIPs = 0.0.0.0/0 in a peer on the server. It breaks all of its connectivity. Only the client's /32 goes there.
• Overlapping AllowedIPs between peers. It is not just a routing problem: it lets one client spoof another's IP.
• Choosing 192.168.1.0/24 or 10.0.0.0/24 for the VPN. It will clash with somebody's home network or a hotel's, and the conflict cannot be fixed from your side.
• Sending the QR code or the configuration file by email or messaging. It contains the private key in the clear: it is complete access to the internal network.
• Generating the keys without umask 077. They are born with 644 permissions, even if only for an instant.
• Closing the SSH port the same day you build the VPN. If WireGuard fails after a kernel update, you are locked out. A second, tested route first.
• Forgetting net.ipv4.ip_forward=1. The tunnel comes up perfectly and not a single packet reaches the internal network.
• Forgetting PersistentKeepalive on phones. The tunnel "drops" a few minutes after going idle.
• Using wg-quick down && up to add a client. It cuts off everybody connected, including you if you are administering over the VPN. Use wg syncconf.
• Regenerating the server key on every Ansible run. It locks out every client at once. creates: or a stat first.
• Believing that the VPN makes the internal network secure. An infected laptop comes in through the tunnel with full permissions. Every service authenticates on its own account.
• Removing TLS from internal services "because it already goes over the VPN". The encryption ends at the VPN server, not at the service.
• Diagnosing without tcpdump. Seeing whether the UDP packets even reach the server separates network problems from configuration problems in a minute.
• Ignoring the MTU. The symptom — it connects and then hangs on large transfers — looks like anything but fragmentation.
• A tip on method. Before closing a port, verify from the client that you already get through over the VPN. The course's rule admits no exceptions: never close the door you are coming in through.

Marta calls you from a hotel: "the VPN says it is connected but I cannot get into the panel". Diagnose the problem systematically, from the most likely cause to the least, and solve it.

Design the complete response procedure for the loss of Marta's phone with the VPN configured, in the form of a runbook, and include what has to be done afterwards so that the incident does not repeat itself in the same way.

Marta asks whether with the VPN "we are safe now" and whether other measures can be simplified now that the network is protected. Draft the reply.

Solution 1

Method: from the outside in, and from the most likely to the least. Each step rules out a whole layer, and that order saves most of the time.

There is a recent handshake: the tunnel is cryptographically established, the key is correct, the UDP port gets through and the hotel's Wi-Fi lets it pass. That rules out the four most frequent causes in one go.

But look at 0 B sent: the server receives from Marta and sends her nothing. That detail points straight at routing or filtering, not at the VPN.

Three SYNs with no reply. Marta's packet crosses the tunnel correctly and reaches the server. The problem is after the VPN: something between the server and port 8404 is not answering. The VPN is completely ruled out.

There it is. IN=wg0 OUT=enp0s3 means the packet is being forwarded, not delivered locally: the HAProxy panel lives on 10.0.2.20, which is another machine. And ufw denies forwarding by default — the allow ... to any port 8404 rule applies to the input chain, not to the forward chain.

Confirmed. Step 11 of the lesson was applied by halves: the traffic to the server was allowed but not the forwarding through it.

Resolution:

Option B is the correct one and it deserves defending: it keeps the allowlist policy from 06-03, where forwarding is still denied by default and only what is needed is explicitly permitted. Option A opens up the forwarding of anything to anywhere through the VPN server, which is precisely the kind of broad permission that the threat model in 06-06 advises against.

Verification:

The decision tree in summary, which goes into the runbook for next time:

And the three lessons from this incident:

1. wg show answers the most important question in one second: if there is a handshake, the problem is not the VPN. It is the first command, always.
2. The received / sent asymmetry is a very powerful indicator that hardly anybody looks at: it tells you whether the failure is on the way out or on the way back.
3. A firewall with forwarding denied is the number one cause of "the VPN connects but I cannot reach anything", and it does not show up obviously in ufw status. The kernel's UFW BLOCK messages give it away in ten seconds.

Solution 2

Runbook: Loss or theft of a device with the VPN

Document: RB-SEC-04 · Version: 1.0 · Date: 2026-08-18 Severity: High · Target containment time: 15 minutes from the report Location: the operations file and ~/tramontana-infra/docs/. A printed copy: the response may have to be given from a phone, without access to the server.

0. Initial assessment (2 min)

Three questions, and you do not wait for the answers before starting step 1:

Question	Why it matters
Does the device have a screen lock and encryption?	It determines whether the key is accessible
Did it have other credentials saved (email, pass, SSH)?	It widens the scope far beyond the VPN
Lost or stolen?	A targeted theft implies an adversary with intent

The worst case is assumed until proven otherwise. Withdrawing the access of a device that later turns up costs five minutes of reconfiguration; not withdrawing it can cost the database.

1. Immediate containment (5 min) — do this BEFORE investigating

# 1.1 Identify the device's public key
$ grep -B3 '10.8.0.4/32' /etc/wireguard/wg0.conf
# --- marta-mobile (added: 2026-08-18) ---
[Peer]
PublicKey = eF7gH8iJ9kL0mN1oP2qR3sT4uV5wX6yZ7aB8cD9eF0g=

# 1.2 REMOVE THE PEER LIVE. Immediate effect, without cutting off anybody else.
$ sudo wg set wg0 peer 'eF7gH8iJ9kL0mN1oP2qR3sT4uV5wX6yZ7aB8cD9eF0g=' remove

# 1.3 Confirm that it has gone
$ sudo wg show wg0 peers | grep -c 'eF7gH8iJ9k'
0

# 1.4 Block the IP as well, just in case (defence in depth)
$ sudo ufw insert 1 deny from 10.8.0.4 comment 'INCIDENT 2026-08-18'

From 1.2 onwards, that device is indistinguishable from a stranger on the internet. There is no revocation list to propagate and no expiry window: WireGuard discards packets from keys it does not know without replying.

2. Making the change persistent (3 min)

# Without this, the peer comes back when the interface or the server restarts
$ sudo cp /etc/wireguard/wg0.conf /etc/wireguard/wg0.conf.bak-$(date +%F)
$ sudo sed -i '/--- marta-mobile/,/^$/d' /etc/wireguard/wg0.conf
$ sudo diff -u /etc/wireguard/wg0.conf.bak-$(date +%F) /etc/wireguard/wg0.conf
$ sudo shred -u /etc/wireguard/clients/marta-mobile.conf

And in the Ansible repository, because if it is not removed from there, the next ansible-playbook adds it back:

$ cd ~/tramontana-infra
$ vim roles/vpn/defaults/main.yml     # remove the marta-mobile entry
$ ansible-vault edit group_vars/all/vault.yml   # remove its keys
$ git commit -am "Remove marta-mobile: device lost 2026-08-18"
$ ansible-playbook site.yml --limit srv-tramontana --tags vpn --check --diff

3. Scope assessment (15 min)

# 3.1 Was there any activity after the moment of the loss?
$ sudo journalctl -t wireguard --since "2026-08-18 09:00" | tail -20

# 3.2 Database accesses from its VPN IP
$ sudo journalctl -u postgresql@16-main --since "2026-08-18 09:00" | \\
      grep '10.8.0.4'

# 3.3 Accesses to the statistics panel
$ journalctl -t nginx_access --since "2026-08-18 09:00" | grep '10.8.0.4'

# 3.4 SSH sessions
$ sudo last -i | grep '10.8.0.4'
$ sudo journalctl -u ssh --since "2026-08-18 09:00" | grep 'Accepted'

Finding	Conclusion	Additional action
No activity after the loss	Containment in time	None
Activity consistent with Marta's normal use	Probably her	Confirm with her
Anomalous activity (odd hours, bulk queries)	Compromise likely	Escalate to step 6

4. Other credentials on the device (20 min)

The VPN is almost never the only thing on a phone. Everything that was there is reviewed and rotated:

Credential	Action	Owner
Corporate email	Close remote sessions and change the password	Marta
SSH key (if it had one)	Remove from authorized_keys on every host	Operations
PostgreSQL password	Rotate in pass and with ALTER ROLE	Operations
Tramontana Bookings sessions	Invalidate all of them for that account	Luis
Password manager	Change the master password	Marta
Second factor (TOTP)	Regenerate and review the backup codes	Marta

# Example: rotating the database password
$ pass generate -f tramontana/db 32
$ sudo -u postgres psql -c "ALTER ROLE operator PASSWORD '$(pass tramontana/db)';"

5. Restoring the service (10 min)

# When Marta has a new device: a NEW key pair, a NEW IP.
# Neither the key nor the address is reused: reusing the IP would
# confuse the incident logs with the legitimate activity that comes
# afterwards.
$ sudo ~/scripts/vpn_add_client.sh marta-mobile2
[..] adding 'marta-mobile2' with IP 10.8.0.7

The QR code is scanned in person or on a video call with Marta showing the new phone's screen. Never over messaging.

6. Escalation

A full security incident is declared — and the procedure from 06-04 is followed — if any of these conditions holds:

• There is activity from the device's IP after the moment of the loss.
• The device had no screen lock or encryption.
• It contained SSH keys or administrative credentials.
• It was a targeted theft, not a mislaid device.

7. Prevention: what changes for next time

This is the part that turns an incident into an improvement, and the part almost every procedure omits.

Measure	Status	Justification
Mandatory encryption and screen lock on every device with the VPN	Pending: a policy to be written	Without encryption, the private key is readable by extracting the memory
Record who has which device and with what access	Pending: an inventory	Today you have to search wg0.conf to find out
Least privilege per peer: the phone does not need PostgreSQL	Apply now	It reduces the scope of the next loss
An automatic alert if a new or inactive peer connects	Pending (08-06)	Detection, not just prevention
A quarterly review of peers and removals	Apply now	Peers accumulate and nobody removes them
An annual rehearsal of this runbook	Apply now	An unrehearsed procedure is an assumption

# Least privilege for mobile devices, applied today
$ sudo ufw deny from 10.8.0.7 to any port 5432 proto tcp \\
      comment 'mobile: no DB access'
$ sudo ufw deny from 10.8.0.7 to any port 22 proto tcp \\
      comment 'mobile: no SSH'

8. Record

It is written up in the duty log (08-06): the date and time of the report, the time of containment, the scope assessed, the credentials rotated and the preventive measures agreed. No culprits: losing a phone is not a misdemeanour, and treating it as one guarantees that next time it will take two days for somebody to say anything — which is the only thing that would turn this incident into a disaster.

Solution 3

About the VPN: what we have gained and what does not change To: Marta Vidal · From: Systems Operations · 18 August 2026

Short answer: we have gained quite a lot, and no, we cannot simplify anything. In fact, the VPN works precisely because the rest of the measures are still in place.

---

What we have built. An encrypted tunnel that lets your laptop and your phone behave, from anywhere in the world, as if they were plugged into the office network. You need a digital key that is unique to your device; without it, the server does not even reply: to anybody scanning it from the internet, that entry point is indistinguishable from one that does not exist.

What we have gained, specifically:

Before	Now
To see the reports from home you had to ask me	You get in directly with your own tools
The database was unreachable from outside	Reachable only through the tunnel
The status panel, the same	The same
On a hotel's Wi-Fi, the internal traffic would travel in the clear	It travels encrypted end to end
Any new service you wanted to use from outside had to be published	It is already accessible, without publishing anything

The important part: we have closed doors, not opened them. Before, for you to be able to work from outside, the only option would have been to publish the database on the internet. With the VPN we have done the opposite: there is less exposed than yesterday, and even so you can reach more.

Now to the question you asked me, and the answer is no. I understand why you are asking it: if the network is protected, relaxing what is inside seems reasonable. It is a very widespread line of reasoning and it is the cause of a significant share of the security breaches that make the news.

The reason, with a concrete example. Imagine your laptop gets infected with a malicious program — through an email, a website, a USB stick. That program is inside your laptop, and your laptop is inside the tunnel. For it, the VPN is not an obstacle: it is a direct motorway to the bookings database. The VPN checks that the device is yours; it does not check what the device is doing.

That is why everything else is still necessary:

Measure	Can it be relaxed?	Why
The database password	No	It is the only thing that stops a malicious program already inside the tunnel
Encryption of the internal connections	No	The tunnel ends at the server; from there on it does not protect
Blocking repeated login attempts	No	Somebody can arrive by other routes
Backups	No	The VPN does not protect against mistakes or deletions
Security updates	No	A flaw in a program is exploited just the same from inside
Logging who accesses what	No, quite the opposite	There are now more ways in: we have to watch more

The right way to see it, and it is how the industry works today: there is no "safe inside" and "dangerous outside". Every service checks who you are and encrypts its own traffic, whoever is on the other end. The VPN is one more layer, not a wall that lets you drop your guard behind it.

What the VPN has let us do, and this is a real simplification: restrict things person by person. Because each device has a fixed address guaranteed by the system itself — it cannot be forged — I have been able to let you reach the database while Luis, who is a developer and does not need it in production, cannot. That was not reliably possible before. It is less access, better distributed.

Two things I need from you:

1. That the phone and the laptop have the screen lock and encryption enabled. The digital key lives on the device; if somebody switches it on and gets in without a password, they have the key. It is the only measure that depends on you and it is the most important of all.
2. That you tell me immediately if you lose a device, at any hour. Withdrawing its access takes me two minutes and it is instantaneous: there are no windows and no waiting. Losing a phone is not a problem; taking a day to say so is. I have the procedure written down and rehearsed.

And one more thing, for the record. I have taken the opportunity to close the database and the status panel to the outside; until now they depended on being physically on the office network. I have left the usual administrative access open, and not by oversight: if the VPN failed after an update, without that second route I would have to travel physically to the server to fix it. I will close it when we have a tested alternative, not before. It is the rule I always apply: you never close the door you are coming in through.

The VPN is up and it has paid for itself immediately: PostgreSQL and the statistics panel are closed to the outside and, at the same time, accessible from anywhere. The server exposes one more UDP port than yesterday, and that port does not answer anybody without a key, which makes it indistinguishable from a closed one to any scanner on the internet. It is the trade you were after: less exposed surface and more reach.

You understand WireGuard from the inside, which was the real objective. You know that it is a network interface and not a daemon, and that the tools from 06-01 and the rules from 06-03 therefore apply as they are. You know there is no server and no client in the protocol, only peers with public keys. And above all you understand AllowedIPs, which is the concept that separates somebody who has copied a configuration from somebody who knows what they are doing: when sending it is a routing table, when receiving it is an anti-spoofing filter, and that is why on the server each client carries its /32 and 0.0.0.0/0 only appears on the client side. That dual role is what makes each person's VPN IP a reliable identifier, and what has allowed you to give database access to some devices and deny it to others.

You have decided on the split tunnel with arguments — bandwidth, people's privacy and the real objective, which is reaching the internal services — instead of out of habit. You have verified the encryption by capturing the same packets on both interfaces: opaque on enp0s3, readable on wg0. You have automated adding clients with wg syncconf, which applies changes without cutting anybody off, and with a creates: in Ansible that prevents the disaster of regenerating the server key. And you have not closed SSH, because a second, tested access route comes before elegance.

And you take away the sentence that matters most in the whole lesson: a VPN does not turn an internal network into a secure network. It moves the point of trust, it reduces the exposure and it gives a reliable identifier per device. It does not protect against an infected laptop, or a weak password, or lateral movement once inside. Everything you built in Module 6 is exactly as necessary today as it was yesterday.

In 08-05 comes the biggest project of the module and the one that demands the most honesty: a Kubernetes cluster. The lesson is going to tell you from the first paragraph that for Tramontana it is disproportionate, and it is going to explain exactly why, with numbers. And even so you are going to do the whole of it, because it is the industry's dominant technology and because you are going to run into it at work. You will set up k3s on srv-tramontana-test, you will understand the control plane piece by piece, you will deploy Tramontana Bookings with Deployments, Services, Ingress, ConfigMaps and Secrets — and you will see that a Secret is base64, not encryption, which links directly back to 06-05 — and you will learn to read a CrashLoopBackOff instead of fearing it. With an honest closing note on the real operational complexity of keeping a cluster alive.