Server Sorcery 101

No application here

This stage configures infrastructure without deploying the application. It is the baseline for comparing the later automation and deployment work.

What is here instead is the substrate every later stage inherits: the private addressing, the hardening posture, and a monitoring stack. Stage 3 will eventually make load-balancer decisions using it. The four-host topology describes that baseline; the archived Vagrantfile also contains a later backup host, noted in the reference figures.

Access controls, checked

I configured SSH keys, a dedicated devops account, UFW rules and an sshd jail. Restricting AllowUsers to devops initially locked out Vagrant's provisioning user, so that account had to be retained too. The NAT-forwarded SSH connection also needed a rule matching the guest-visible gateway address, 10.0.2.2.

The Fail2Ban test first revealed that the service was not running. After starting it, repeated failed logins produced a ban visible in fail2ban-client status sshd. The journal records access returning after ten minutes, and a later change enables the service at boot. That is a functional check of this jail, not a full security audit.

Boot-time comparison

The load balancer's recorded startup time was 7min 23.627s. After increasing its memory allocation to 2 GB, the next recorded result was 1min 28.996s. These observations helped me investigate local resource allocation; they are not a general benchmark for Nginx or virtual machines.

The seven hours

The dominant entry in the journal is a single afternoon lost to Vagrant being unable to reach VirtualBox from WSL:

Vagrant is unable to use the VirtualBox provider from the Windows Subsystem for
Linux without access to the Windows environment.

That was only the first of five distinct failures. Each looked unrelated, and together they consumed more than seven hours:

• the Windows PATH was not shared with WSL, so cmd.exe was not found
• shared folders had to be disabled because host paths must be on DrvFs
• the VirtualBox driver service was not running
• the guest's serial port had to be disconnected to avoid a raw-file error

The serial-port workaround was carried into the next project's Vagrantfile.

The one worth remembering

The most instructive failure is not a tooling problem. It is the interface that was hardened away:

The NAT adapter was disabled in order to force all egress through a central proxy. This broke Vagrant's management channel. I investigated firewall rules, bans and interface configuration, recording which hypotheses the checks supported or rejected.

The connection still timed out. This was a critical finding. It proved the issue was not a UFW rule.

The cause turned out to be a line I had changed earlier:

# /etc/netplan/50-cloud-init.yaml
dhcp4: false

The development record describes the management-channel conflict:

Flaw: This was a good security idea in principle, but it broke Vagrant's fundamental management channel, which relies on enp0s3 being active. For a Vagrant-managed environment, this approach is not viable.

The revised policy keeps the interface and uses ufw default deny outgoing with explicit allow rules instead. Same intent, no lockout.