The Castle is on Fire: Why Your VPN Won't Save You
For decades, we built our infrastructure like medieval castles. We dug moats (firewalls), raised drawbridges (VPNs), and assumed that anyone inside the walls was a friend. In 2021, this architecture isn't just outdated; it is negligent. The perimeter has dissolved. With remote work becoming permanent and microservices fragmenting our monoliths, the concept of a "trusted internal network" is a dangerous fallacy.
As a CTO or Lead Architect operating in the European market, you are facing a dual threat: sophisticated supply chain attacks (remember SolarWinds?) and the regulatory sledgehammer of Schrems II. If you are still relying on a single edge firewall to protect your flat network, you are one phished credential away from a full data breach. It is time to adopt a Zero Trust architecture.
Zero Trust isn't a box you buy. It is the mindset that identity is the new perimeter. Whether a request comes from a developer in Oslo or a server in a CoolVDS rack in Norway, it must be authenticated, authorized, and encrypted. Here is how we build it properly, using tools available today.
The Compliance Headache: Schrems II and Data Sovereignty
Before we touch the config files, we must address the legal landscape. The CJEU's Schrems II ruling invalidated the Privacy Shield framework. If you are hosting sensitive customer data on US-owned hyperscalers, you are navigating a legal minefield regarding GDPR compliance. Datatilsynet (The Norwegian Data Protection Authority) has been clear about the risks of data transfers.
Zero Trust dictates that we minimize trust zones. One of the most effective ways to reduce risk is to ensure your physical infrastructure resides in a jurisdiction with strong privacy laws. This is why we architect CoolVDS infrastructure strictly within Norwegian data centers. By keeping the data resident in Norway (EEA), you solve the data sovereignty layer of Zero Trust before you even boot the kernel.
Step 1: The Network Layer – WireGuard Mesh
Traditional IPsec VPNs are bloated and difficult to audit. For a Zero Trust overlay network, we need something lean. WireGuard, merged into the Linux 5.6 kernel last year, is the answer. It is cryptographically opinionated and performant.
Instead of a hub-and-spoke model where traffic hairpins through a central gateway, we build a mesh where services talk directly to each other, encrypted by default. Here is a standard configuration for a database server node hosted on a CoolVDS NVMe instance:
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.1/24
SaveConfig = true
PrivateKey =
ListenPort = 51820
# Peer: App Server 1
[Peer]
PublicKey =
AllowedIPs = 10.0.0.2/32
# Peer: Admin Laptop (Roaming)
[Peer]
PublicKey =
AllowedIPs = 10.0.0.3/32
Bring up the interface:
wg-quick up wg0
This ensures that even if your public interface is bombarded, the internal communication happens over a secure, encrypted tunnel that drops non-authenticated packets silently. No handshake? No response.
Pro Tip: Don't just install WireGuard. Optimize the MTU. On KVM-based VPS instances like ours, usually an MTU of 1360 avoids fragmentation issues inside the tunnel encapsulations.
Step 2: Killing Static SSH Keys
If your engineers are copying id_rsa.pub files to ~/.ssh/authorized_keys across 50 servers, you have lost control. You cannot revoke a key instantly without Ansible/Puppet runs, and you have no expiry mechanism.
The Zero Trust approach uses SSH Certificate Authorities (CA). You sign a user's key for a specific duration (e.g., 8 hours). When the certificate expires, access is revoked automatically.
1. Generate the CA keys on a secure offline machine:
ssh-keygen -t ed25519 -f /etc/ssh/user_ca -C "user_ca"
2. Configure the Target Server (CoolVDS Instance):
Edit /etc/ssh/sshd_config to trust your CA:
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
3. Sign a user's key (Operational workflow):
When a developer needs access, they present their public key. You sign it with a validity period:
ssh-keygen -s /etc/ssh/user_ca -I "dev_access" -n root,deploy -V +8h id_rsa.pub
This generates id_rsa-cert.pub. The developer uses this to log in. After 8 hours, the key is useless. No zombie keys left on servers.
Step 3: Micro-Segmentation with nftables
iptables is legacy. In modern distributions like Debian 10 or Ubuntu 20.04, nftables provides a unified interface for packet filtering. In a Zero Trust model, the default policy is DROP. We explicitly allow only necessary traffic.
Even inside a private network, a compromised web server should not be able to probe the database port. It should only connect if explicitly allowed.
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Allow loopback
iifname "lo" accept
# Allow established/related connections
ct state established,related accept
# Allow WireGuard VPN traffic
udp dport 51820 accept
# Allow SSH only from VPN interface (WireGuard)
iifname "wg0" tcp dport 22 accept
# Allow Web traffic on public interface
tcp dport { 80, 443 } accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}
Load this configuration using nft -f /etc/nftables.conf. Notice that SSH (port 22) is not exposed to the public internet. It is only accessible via the WireGuard interface (wg0). This drastically reduces the attack surface.
The Hardware Reality: Isolation Matters
Software configuration is only half the battle. The underlying hypervisor plays a massive role in security. Many "cheap" VPS providers still rely on container-based virtualization (like LXC/OpenVZ) where the kernel is shared among tenants. In a Zero Trust model, this is an unacceptable risk due to potential container breakout vulnerabilities.
This is why CoolVDS utilizes KVM (Kernel-based Virtual Machine) exclusively. Each instance runs its own isolated kernel. Even if a neighbor on the physical host is compromised, your memory space and CPU instructions remain protected by hardware virtualization extensions. When we talk about "NVMe speed," we aren't just talking about IOPS; we are talking about the ability to handle heavy encryption (WireGuard, TLS 1.3) without I/O wait times killing your latency.
Comparison: Traditional VPS vs. Zero Trust Ready Architecture
| Feature | Generic Cloud | CoolVDS Architecture |
|---|---|---|
| Virtualization | Often Shared Kernel (Container) | Full KVM Isolation |
| Data Location | Uncertain / US Cloud | Norway (GDPR/EEA) |
| Storage | Standard SSD / HDD | Enterprise NVMe |
| Console Access | Standard VNC | Secure Out-of-Band VNC |
Conclusion: Trust Nothing, Encrypt Everything
Zero Trust is a journey, not a switch. Start by moving your critical data to a jurisdiction that respects privacy. Then, overlay your network with WireGuard and harden your access control with SSH certificates. The days of trusting an IP address simply because it is "local" are over.
If you need a foundation that aligns with high-performance security requirements—where KVM isolation and NVMe storage are standard, not paid upgrades—we are ready for you.
Secure your infrastructure today. Deploy a KVM-based, Zero-Trust ready instance on CoolVDS in Oslo.