Course Module 01: Threat Model and Product Selection

This is the first module of the RouteHarden Network Engineering Course. Before you provision a single VPS or generate a single WireGuard key, you need to be honest about what you're actually defending against. Most "VPN failures" in production are not technical — they're a mismatch between the threat the user imagined and the threat the product was built for.

By the end of this module you will be able to:

• Name the three or four threats your stack actually defends against
• Reject any product or guide whose threat model does not include your case
• Decide whether a commercial VPN, a self-hosted WireGuard server, or a multi-hop overlay matches the threats you listed
• Draft a one-page written threat statement you can re-read before every architecture decision

The threat model fork

Network privacy is not a single problem. It is at least four problems with different solutions:

1. Hostile public WiFi. Coffee shops, airports, hotels. The threat is on-path observers on the local segment. The right tool is any properly configured tunnel — even a commercial VPN — terminating somewhere outside the local network.

2. ISP-level DPI and logging. Your residential or cellular ISP can see SNI, can perform statistical traffic classification, and may be subject to retention requirements. The right tool is an encrypted tunnel that also avoids being trivially classified as a tunnel.

3. Opaque commercial VPN providers. You traded one observer (your ISP) for another (your VPN provider). The right tool is a tunnel you operate yourself, terminating on infrastructure you control.

4. Supply-chain compromise and platform risk. Your VPN client app, your VPS provider, your DNS resolver, or your update channel are all potential failure points. The right tool is a stack that lets you verify each link.

Almost every real deployment is some combination of two or three of these. Be explicit about which.

Reading list (free background)

These free posts give you the conceptual background. Read them in order before moving to module 02.

• Threat models for network anonymity — the canonical breakdown of what different threat models imply
• Operational anonymity for engineers — process and discipline, not tooling
• Network OPSEC checklist — concrete daily-driver checks

The product-class decision

Once your threat model is written, the product-class decision is straightforward:

• If only threat 1 applies → a commercial VPN with a clean privacy policy is enough; you do not need this course.
• If threats 1 + 2 apply → a self-hosted WireGuard server on a clean VPS is the baseline. Modules 02-03.
• If threats 1 + 2 + 3 apply → self-hosted plus a transport that resists statistical classification. Modules 02-04.
• If threats 1 + 2 + 3 + 4 apply → self-hosted, classification-resistant, with multi-region egress and verified supply chain. The full course.

Module 01 deliverable

Before you move on, write a one-page document with:

1. The three or four threats your stack defends against, ranked by severity
2. The threats your stack does not defend against (explicit out-of-scope)
3. The maximum acceptable cost in latency, bandwidth, and dollars per month
4. The maximum acceptable cost in operational complexity (hours per month)

That document is your filter for every subsequent module. If a tutorial elsewhere on the internet pulls you in a direction inconsistent with your threats, you ignore it.

Next module

Module 02 covers VPS provider evaluation — logging policies, network quality, and the trade-offs between low-cost CN2 routes, mainstream cloud providers, and bare-metal options.

Module 01 is free. Modules 02-07, plus video walkthroughs, downloadable configs, and free updates as tooling evolves, are part of the RouteHarden Network Engineering Course — one-time $79, lifetime access, 30-day refund.