SpeedVPN

Behind a simple
connection.

An early VPN service made available to customers, taking the project beyond a personal experiment. The notes below explore the engineering behind a dependable connection: encrypted transport, routing policy, gateway management, and recovery when the network changes.

The design notes below are a conceptual reconstruction, not verified documentation of the original implementation.

01 / Engineering notes

Four components. One connection.

Component names are coined for this design study; each represents a separate responsibility and interface.

01 / Tunnel & identity

speed-tunnel

The tunnel adapter owns peer configuration, local key access, and session establishment. In this reference design it wraps WireGuard, exposing connect, disconnect, and status operations to the client. It passes network policy changes to speed-route and reports handshake state to speed-watch.

02 / Routing & DNS

speed-route

The network policy manager applies IPv4 and IPv6 routes, resolver settings, and split-tunnel rules. It preserves a route to the gateway outside the tunnel, records the previous network configuration for rollback, and holds a blocking policy during reconnects when full-tunnel mode is selected.

03 / Gateway operations

speed-node

The gateway agent translates authorized peer configurations into tunnel and firewall settings on a Linux node. It reconciles desired and applied configuration, removes revoked peers, and reports node health separately from packet forwarding. Configuration revisions let the control service track which changes have actually reached each gateway.

04 / Failure recovery

speed-watch

The connection supervisor combines handshake state, DNS checks, and application reachability into one connection state machine. On a network change it coordinates speed-route and speed-tunnel, retries with bounded backoff, and marks the connection ready only after verification. Failure reasons remain distinct so a DNS outage does not look like an authentication error.

02 / Validation plan

What a reliable tunnel needs to pass.

These are proposed acceptance checks, rather than historical benchmark results.

Network transitions

Move between Wi-Fi and cellular; verify reconnection and the intended traffic policy during the transition.

Routing correctness

Exercise IPv4, IPv6, local subnets, and DNS; check for unintended paths outside the selected tunnel policy.

Failure handling

Interrupt the gateway, resolver, and control service independently; distinguish their failure states.

Performance

Measure throughput, latency, packet loss, and CPU usage against a direct-connection baseline under stated test conditions.