Kill the VPN: A Pragmatic Guide to Zero-Trust Networking on Linux

Date: January 28, 2020

If you are still relying on a single OpenVPN gateway to protect your entire backend infrastructure, you are sitting on a ticking time bomb. The "Castle and Moat" security model—where everything inside the firewall is trusted and everything outside is hostile—is fundamentally broken. In 2020, threats don't just knock on the front door; they walk in through phishing emails on a developer's laptop and move laterally across your "trusted" LAN.

We see this constantly with legacy deployments in Oslo. A company sets up a perimeter firewall, whitelists the office IP, and assumes their database is safe. It isn't. The moment an attacker compromises a single endpoint inside that perimeter, the soft underbelly of your infrastructure is exposed.

The solution isn't a taller firewall. It's Zero Trust. Trust no one. Verify every packet. Whether the request comes from a coffee shop in Grünerløkka or a rack in your own datacenter, the authentication requirement remains identical.

The Three Pillars of Zero Trust in 2020

Implementing Zero Trust doesn't mean buying expensive "solution-in-a-box" software. As a sysadmin, you can build a robust Zero Trust architecture using standard Linux tools available right now on your CoolVDS instances. We focus on three layers:

1. Identity-Based SSH (Certificates over Keys)
2. Mutual TLS (mTLS) for Web Services
3. Micro-segmentation with WireGuard

1. Moving Beyond Static SSH Keys

Static SSH keys are a nightmare to manage. Developers leave, laptops get stolen, and keys remain authorized on servers forever. The Zero Trust approach uses SSH Certificate Authorities (CA). You sign a key for a specific duration (e.g., 8 hours). When the shift ends, access disappears.

Here is how you configure a trusted CA on your CoolVDS server running Ubuntu 18.04 LTS.

On your secure Admin workstation (The CA):

# 1. Generate the CA key (Keep this OFFLINE and SECURE)
ssh-keygen -C "CA-User-Key" -f /path/to/user_ca

# 2. Sign a user's public key (valid for 8 hours only)
ssh-keygen -s /path/to/user_ca -I "dev_user_oslo" -n root,deploy -V +8h user_key.pub

On the Target Server (`/etc/ssh/sshd_config`):

# Tell SSH to trust keys signed by your CA
TrustedUserCAKeys /etc/ssh/user_ca.pub

# Optional: Revocation list for emergency blocks
RevokedKeys /etc/ssh/revoked_keys

Restart SSH. Now, even if a developer's laptop is compromised tomorrow, the key they used today is already useless.

2. Mutual TLS (mTLS) with Nginx

For internal APIs or admin panels (like Kibana or Jenkins), a simple password login is insufficient. mTLS requires the client to present a valid certificate signed by your internal CA. If the browser (or API client) doesn't have the cert, the Nginx server drops the connection before even loading the application.

This adds virtually no latency on CoolVDS NVMe instances because the I/O overhead for the handshake is negligible compared to the security gains.

Nginx Configuration Snippet (`/etc/nginx/sites-available/secure-app`):

server {
    listen 443 ssl;
    server_name internal.coolvds-client.no;

    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # The Magic: Verify the Client
    ssl_client_certificate /etc/nginx/ssl/internal_ca.crt;
    ssl_verify_client on;

    location / {
        proxy_pass http://localhost:8080;
        # Pass SSL details to backend for auditing (GDPR compliance)
        proxy_set_header X-Client-DN $ssl_client_s_dn;
    }
}

Pro Tip: Generating certificates manually is tedious. In 2020, we are seeing tools like cfssl (from Cloudflare) becoming the standard for managing internal PKI. Don't use OpenSSL commands for everything if you value your sanity.

3. Micro-segmentation with WireGuard

IPsec is bloated. OpenVPN is slow. Enter WireGuard. Although it's currently (Jan 2020) in the process of being merged into the mainline Linux kernel (likely 5.6), it is stable enough for production use via DKMS on Ubuntu/Debian today.

WireGuard allows you to create a mesh network where every server can talk only to specific peers. Unlike a VLAN, this works across cloud providers and physical locations. A database server on CoolVDS in Oslo can have a secure, encrypted tunnel to a backup server in Bergen, dropping all other traffic.

Setup on Ubuntu 18.04:

sudo add-apt-repository ppa:wireguard/wireguard
sudo apt-get update
sudo apt-get install wireguard

Configuration (`/etc/wireguard/wg0.conf`):

[Interface]
Address = 10.0.0.1/24
PrivateKey = <Server_Private_Key>
ListenPort = 51820

# Peer: Only allow the App Server to connect
[Peer]
PublicKey = <AppServer_Public_Key>
AllowedIPs = 10.0.0.2/32

This config creates a strict whitelist. If a packet isn't from the App Server's cryptographic identity, the Database server simply doesn't respond. It's invisible.

The Hardware Reality: Why Virtualization Matters

Zero Trust relies heavily on encryption. Every packet is encrypted (WireGuard), every session is verified (mTLS), and every login is signed (SSH). This creates a computational overhead that legacy hosting environments struggle with.

This is where the distinction between "Container VPS" (like OpenVZ) and KVM (Kernel-based Virtual Machine) becomes critical. In an OpenVZ environment, you are sharing the kernel with noisy neighbors. If another user on the node gets hit with a DDoS, your encryption performance tanks because the CPU entropy and cycles are starved.

At CoolVDS, we strictly use KVM virtualization. This ensures:

Data Sovereignty and GDPR

For Norwegian businesses, the Datatilsynet is clear: you must have control over who accesses your data. The Privacy Shield framework is currently under heavy scrutiny by European courts, and relying on US-based cloud giants is becoming a legal gray area.

By implementing a Zero Trust architecture on CoolVDS servers located physically in Norway (utilizing low-latency NIX peering), you satisfy two major requirements:

1. Strict Access Logging: mTLS and SSH Certificates provide non-repudiation. You know exactly who accessed what and when.
2. Data Residency: Your encrypted tunnels terminate in Norway, keeping your data within the EEA legal framework.

Final Thoughts

The days of trusting the LAN are over. While shifting to Zero Trust requires an upfront investment in configuration, the payoff is a resilient infrastructure that assumes hostility and neutralizes it.

Don't wait for a breach to audit your network. Spin up a KVM instance on CoolVDS today, install WireGuard, and start locking down your critical services. Security is a process, not a product, but having the right foundation makes all the difference.

Ready to harden your stack? Deploy a high-performance CoolVDS instance in Oslo now.