The Coffee Shop Hazard
Let’s be real. If you are remote administating servers via the free Wi-Fi at a hotel in Stockholm or a café in Grünerløkka, you are practically begging for a packet sniffer to capture your credentials. Even with SSH, exposing your management ports to the open internet is a rookie mistake. I've seen `auth.log` files grow by gigabytes in hours just from brute-force bots the moment port 22 touches a public IP.
The solution isn't just a firewall; it's a tunnel. Specifically, OpenVPN. Unlike the nightmare that is IPsec configuration on Linux, OpenVPN offers a robust, SSL/TLS-based userspace solution that actually works through NATs and restrictive firewalls.
Today, we aren't just installing packages. We are building a secure gateway on a CoolVDS instance hosted right here in Oslo. Why Oslo? Because latency to the NIX (Norwegian Internet Exchange) matters when you're typing over a tunnel, and Datatilsynet (The Norwegian Data Protection Authority) actually respects your privacy, unlike certain jurisdictions across the Atlantic.
The Iron Hardware Reality
Encryption costs CPU cycles. Back in the day, we ran VPNs on dedicated hardware, but virtualization has matured. However, not all virtualization is equal. Many VPS providers oversell their CPU cores using container-based virtualization like Virtuozzo, where the kernel is shared. If your neighbor decides to compile a kernel, your VPN throughput tanks.
This is why CoolVDS uses Xen and KVM. You get dedicated resources. For AES-256 encryption, you need the guarantee that your CPU cycles are actually yours. We also back our storage with high-performance 15k RPM SAS RAID arrays (and increasingly, those new Enterprise SSDs), so logging verbosity doesn't choke your I/O.
Step 1: The Foundation (Ubuntu 10.04 Lucid Lynx)
We are using the fresh Ubuntu 10.04 LTS release for this. It’s stable and supported.
sudo apt-get update
sudo apt-get install openvpn openvpn-blacklistPro Tip: The openvpn-blacklist package is crucial. Remember the Debian OpenSSL vulnerability from 2008? This ensures we check against known weak keys. Never assume your random number generator is truly random.Step 2: PKI and Key Generation
We aren't using pre-shared keys; that's for amateurs. We are building a proper Public Key Infrastructure (PKI) using easy-rsa. Copy the scripts to a safe location to avoid updates overwriting your changes.
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
vi varsEdit the vars file. Don't leave the defaults. Set your KEY_COUNTRY to "NO" (Norway), and increase the key size. By default, it says 1024. Change it to 2048. Paranoia is a virtue.
export KEY_SIZE=2048Now, build the CA and the server certificate:
source ./vars
./clean-all
./build-ca
./build-key-server serverGenerate the Diffie-Hellman parameters. This will take time. Go grab a coffee. On a standard shared host, this takes forever. On a CoolVDS instance, the dedicated CPU crunching makes this tolerable.
./build-dhStep 3: Server Configuration
Create /etc/openvpn/server.conf. We are going to use UDP for speed (TCP over TCP leads to meltdown due to retransmission timers fighting each other).
port 1194
proto udp
dev tun
ca easy-rsa/keys/ca.crt
cert easy-rsa/keys/server.crt
key easy-rsa/keys/server.key
dh easy-rsa/keys/dh2048.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3Step 4: IP Forwarding and IPTables
A VPN that doesn't route traffic is just a fancy ping machine. Enable forwarding in sysctl.conf:
net.ipv4.ip_forward=1Apply it with sysctl -p. Now, the magic sauce: NAT. We need traffic coming from the VPN subnet (10.8.0.0/24) to masquerade as the server's public IP.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADESave your rules. If you reboot and get locked out, don't blame me. Use `iptables-save`.
Why This Setup Matters in Norway
Data sovereignty is becoming a massive issue. With the Personopplysningsloven (Personal Data Act) enforcing strict standards, you cannot afford to have client data routed through unverified nodes. By hosting your VPN endpoint on a CoolVDS server in Oslo, you ensure that your encrypted tunnel terminates within Norwegian jurisdiction.
Furthermore, latency kills productivity. If you are working from Tromsø or Bergen, routing your VPN through a cheap server in Germany adds unnecessary milliseconds. Our direct peering at NIX keeps your ping low, making SSH sessions feel local.
Final Check
Start the service:
/etc/init.d/openvpn startCheck the logs. If you see `Initialization Sequence Completed`, you are live. Distribute the client keys securely (SCP them, don't email them!).
Don't let your data traverse the public internet naked. Security is not an add-on; it's a baseline. If you need a stable, high-performance host to run this on, deploy a CoolVDS instance today. We don't oversell, and we don't compromise on uptime.