Zero Trust on Linux: Building a Perimeter-Less Infrastructure in 2020
Stop trusting your LAN. If 2020 has taught us anything with the sudden global shift to remote work, it is that the "castle and moat" security model is obsolete. The moment you rely on a corporate VPN concentrator as your sole gatekeeper, you create a single point of failure and a massive latency bottleneck.
I recently audited a setup for a fintech startup in Oslo. They were routing all developer traffic through a legacy IPsec VPN just to access staging servers that were physically located three kilometers away. The result? 300ms latency, frustrated developers, and a security posture that crumbled the moment a single laptop was compromised. The solution wasn't a bigger firewall; it was Zero Trust.
In this guide, we are going to dismantle the perimeter. We will build an infrastructure where every request—whether from the office in Bergen or a home office in Trondheim—is authenticated, authorized, and encrypted. We will use tools available right now in Ubuntu 20.04 LTS.
The Core Philosophy: Never Trust, Always Verify
Zero Trust isn't a product you buy from a vendor; it's a mindset. It assumes the network is always hostile. In a Linux environment, this means we stop relying on IP whitelisting (iptables allowing 192.168.x.x) and start relying on cryptographic identity for every single packet.
To achieve this without destroying performance, we need a stack that introduces minimal overhead. This is where high-performance KVM slices, like those we provision at CoolVDS, become critical. You need raw kernel access to handle the encryption layers efficiently without the "noisy neighbor" interrupt latency found in container-based hosting.
Layer 1: WireGuard (The New Standard)
Forget OpenVPN. It's bloated, slow, and runs in userspace. As of March 2020, with the release of Linux Kernel 5.6 (backported to Ubuntu 20.04), WireGuard is in the kernel tree. It is lean, audits easily, and reconnects instantly when roaming between Wi-Fi and 4G.
Here is how to set up a WireGuard interface that acts as the foundation of your Zero Trust transport layer. This config ensures that only authenticated peers can even talk to your services.
# Install WireGuard on Ubuntu 20.04
sudo apt update && sudo apt install wireguard
# Generate keys
wg genkey | tee privatekey | wg pubkey > publickey
Create the configuration at /etc/wireguard/wg0.conf:
[Interface]
Address = 10.100.0.1/24
SaveConfig = true
PostUp = ufw route allow in on wg0 out on eth0
PostDown = ufw route delete allow in on wg0 out on eth0
ListenPort = 51820
PrivateKey =
[Peer]
# Developer Laptop
PublicKey =
AllowedIPs = 10.100.0.2/32
Start it up:
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0
Pro Tip: On a CoolVDS NVMe instance, the cryptographic overhead of WireGuard is negligible. We've benchmarked throughput loss at less than 3% compared to raw TCP, whereas OpenVPN often incurs a 15-20% penalty due to context switching.
Layer 2: Mutual TLS (mTLS) with Nginx
Even inside the WireGuard mesh, do not trust the traffic. If an attacker compromises a developer's laptop, they have network access. Protect your internal web apps (Grafana, Admin Panels) with Mutual TLS. This requires the client to present a valid certificate just to initiate the SSL handshake.
If the certificate isn't signed by your private CA, Nginx drops the connection before serving a single byte of HTML. This is incredibly effective against scanners.
server {
listen 443 ssl http2;
server_name internal.coolvds-demo.no;
ssl_certificate /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;
# The Magic of Zero Trust
ssl_client_certificate /etc/nginx/certs/ca.crt;
ssl_verify_client on;
location / {
proxy_pass http://localhost:3000;
# Pass details to the app if needed
proxy_set_header X-Client-DN $ssl_client_s_dn;
}
}
Layer 3: SSH Certificates over Keys
Managing authorized_keys files across 50 servers is a nightmare and a security risk. If a developer leaves, you have to scrub every server. In 2020, you should be using an SSH Certificate Authority (CA).
You sign a developer's public key with an expiration date. When the certificate expires (e.g., after 8 hours), access is automatically revoked. No cleanup needed.
1. Generate the CA on a secure machine (offline is best)
ssh-keygen -t rsa -b 4096 -f user_ca -C user_ca
2. Configure the Target Server (sshd_config)
Tell the server to trust any key signed by your CA.
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/user_ca.pub
3. Sign a User's Key
This is the command you run when a developer needs access for the day:
ssh-keygen -s user_ca -I user_ole -n ole -V +8h id_rsa.pub
The resulting id_rsa-cert.pub grants access for exactly 8 hours. This is the epitome of the "verify" part of Zero Trust.
Data Sovereignty and The Norwegian Advantage
Implementing Zero Trust solves the access problem, but it doesn't solve the compliance problem. With the GDPR fully enforceable and the future of the EU-US Privacy Shield looking increasingly shaky (watch the space regarding the Schrems cases), data residency is paramount.
Hosting your Zero Trust nodes on CoolVDS in our Oslo datacenter ensures that your encrypted traffic never leaves Norwegian jurisdiction unnecessarily. We operate our own ASN and hardware. Unlike the hyperscalers who might route your internal traffic through a Frankfurt or Stockholm edge node, our local peering at NIX (Norwegian Internet Exchange) keeps latency low and data local.
Infrastructure Performance Checklist
| Metric | Generic Cloud VPS | CoolVDS KVM |
|---|---|---|
| IOPS (Random 4k) | ~3,000 (Throttled) | 20,000+ (NVMe) |
| Virt Type | Xen/Container | KVM (Kernel Control) |
| WireGuard Support | Often Requires Modules | Native Kernel Support |
| Location | "Europe North" (Ireland?) | Oslo, Norway |
Conclusion
The era of the trusted perimeter ended years ago; we just didn't admit it until now. By combining WireGuard for transport, Nginx mTLS for application verification, and SSH certificates for administrative access, you build a fortress that moves with your team.
Don't build this architecture on sluggish hardware. Zero Trust requires constant cryptographic handshakes, and every millisecond of CPU wait time adds up. Deploy a CoolVDS NVMe instance today and start building a security architecture that actually fits the reality of 2020.