Table of Contents
Lab setup
Goal
Prepare a repeatable environment for observing healthy systems before diagnosing faults.
The practice server is already provisioned. Your PC acts as the remote client. A second VM is not required.
| Item | Value supplied by the mentor on 2026-10-09 |
|---|---|
| Name | tibi-vps-1 |
| Address | 192.168.20.50 |
| Operating system | Debian 13 |
| Resources | 1 vCPU, 2 GB RAM, 40 GB disk |
| Learner account | tibi, with password-based sudo |
| Internet gateway | 192.168.20.110 |
Installed tools: iproute2, iputils-ping, bind9-dnsutils (dig and nslookup), curl, openssh-server, sudo, nginx, and qemu-guest-agent.
LAN clients can initiate connections to the VM. The VM can reach the internet, but outbound connections to other LAN hosts are blocked.
Preserve these restrictions. Failed VM-to-LAN connections are not faults to repair. Do not change routing, DNS, or firewall rules for these exercises.
Prepare with your mentor
Use the learner account. Ask your mentor to confirm recovery access before any fault exercise. No additional installation is required for the examples below.
From your PC, connect with SSH:
ssh tibi@192.168.20.50
If the VM is unreachable, report the failure to your mentor. Access requires connectivity to the homelab LAN.
On the VM, inspect the healthy state:
ip -br addr
ip route
sudo nginx -t
systemctl status nginx --no-pager
ss -ltn
curl --connect-timeout 3 --max-time 10 http://127.0.0.1/
From your PC's browser, open http://192.168.20.50/. Expect the configured nginx page. Investigate setup failures before starting exercises.
127.0.0.1 means the machine making the request. In the PC's browser it refers to your PC; inside the SSH session it refers to the VM.
Your mentor should confirm whether a working snapshot or another recovery method is available before introducing faults.
Completion check
Show the VM's address, nginx checks, and a successful request from your PC. Record this healthy baseline.