$ pwd
[$ ] use-case: vpn
// NAME
vpn — vpn & personal privacy server hosting.
// SYNOPSIS
xmrhost-cli playbook describe --workload=vpn
xmrhost-cli provision --workload=vpn --region=<is|ro>// TL;DR
$ head -n1 README
// self-hosted wireguard / openvpn endpoint — your trust boundary is the vps, not a third-party provider.
// DESCRIPTION
$ man playbook(vpn)
// self-hosted endpoint = trust boundary you control
Commercial VPN services move the trust boundary; they don't shrink it. The traffic that exits a third-party VPN exits past their packet filter, their NetFlow sampling, and whatever logging-policy footnote they revise without notice. A self-hosted WireGuard or OpenVPN endpoint moves the boundary to the VPS — the host sees that an SSH tunnel exists; it does not see WireGuard payload, key material, or the upstream destinations the user reaches.
WireGuard is the right default for almost every threat model: ChaCha20-Poly1305 + Curve25519, single static binary, kernel-side on Linux, ~70k lines of code total against OpenVPN's ~600k. RFC 9298 defines the modern UDP-tunneling shape; the WireGuard whitepaper (Donenfeld 2017) is the protocol reference. OpenVPN remains the right answer for environments aggressively filtering UDP signatures (e.g. corporate captive portals doing protocol fingerprinting) — TCP-mode plus an obfs proxy gets through what WireGuard can't.
Hardware-wise the workload is trivial: vps-1 (1c/1GB) carries one user comfortably; vps-2 handles a household; lokinet-1 doubles as a Lokinet exit if the trust model favors a routed overlay over a direct tunnel. The harder questions — DNS-leak protection, MTU, killswitch behavior — are client-side and well-documented in the WireGuard reference clients. We do not run host-level VPN-aware monitoring and do not capture traffic on customer instances.
// see also
- WireGuard Whitepaper — Donenfeld, NDSS 2017
- RFC 9298 — Proxying UDP in HTTP (IETF, 2022)
- RFC 4301 — Security Architecture for the Internet Protocol
- WireGuard Quick Start (wireguard.com/quickstart)
// RECOMMENDED NODES
$ xmrhost-cli list --workload=vpn
// 5 plans flagged for this workload. all xmr-billed.
// RECOMMENDED REGIONS
$ xmrhost-cli regions list --workload=vpn
-
is — iceland : Lög um persónuvernd nr. 90/2018 (GDPR transposition) + IMMI source-protection codification. Police access to subscriber data requires a domestic court order in nearly every civil case.
-
ro — romania : GDPR directly applicable (Regulation 2016/679); EU lawful-intercept stays within the EU information-sharing perimeter, outside the SIGINT clubs. Lower-cost compute for households.
// THREAT MODEL + AUP BOUNDARY
$ xmrhost-cli scope --workload=vpn
// the hosting layer is one component of the threat model. what we cover, and what we explicitly don't:
// scope: in
- WireGuard / OpenVPN endpoint with kernel-side WireGuard on the Linux base image
- Stable IPv4 with IP swap on request (free 1×/quarter on vps-1 through vps-4)
- No host-level VPN-aware monitoring; no traffic capture on customer instances
- Jurisdictional posture (Iceland or Romania) for the egress IP itself
// scope: out
- Client-side DNS-leak protection, killswitch, MTU tuning — RFC 4301 section 5.2 is your friend
- Browser fingerprinting / canvas fingerprinting / TLS-fingerprint mitigation
- Any OPSEC failure on the user's endpoint (compromised browser, leaky app, mobile carrier)
- Multi-user VPN abuse handling — once you give friends access, you are the abuse contact
// AUP boundary
VPN operators are responsible for ensuring their personal use complies with the law of the jurisdiction they exit from and the jurisdiction they connect from. We do not encourage or facilitate evasion of lawful sanctions or court orders.
// SEE ALSO
// playbook — full workload list, node — full catalog, location — region posture, why-monero — billing rationale.