The Intermediary Layer

Most traffic on the internet flows directly: client → server. But a large fraction is mediated — deliberately routed through an intermediary that forwards, transforms, or protects it. Proxies, VPNs, and tunnels are all variations of one idea: put a trusted middlebox in the path and move data through it. What differs is who the middlebox stands for, what layer it works at, and what it protects.

The three questions to ask of any intermediary:

1. Whose side is it on? (client’s, server’s, or a neutral third path)
2. What layer does it inspect? (L4 transport vs L7 application)
3. Does it encrypt? (pass-through vs secure tunnel)

Proxies Revisited

From the DNS & Load Balancing topic you know the core distinction; here’s the full picture:

• Forward proxy — stands for the client. The server sees the proxy’s address, not the client’s. Corporate egress filtering, caching of popular content, content filtering, and privacy/anonymity all use this shape.
• Reverse proxy — stands for the server. The client sees the proxy’s address, not the backend’s. Load balancing, TLS termination, caching, rate limiting, and hiding topology all use this shape.

A SOCKS proxy is the transport-layer forward proxy: it tunnels raw TCP (or UDP) rather than understanding HTTP, so it can carry anything — ssh -D creates one on the fly, letting you route arbitrary traffic through a jump host. Its advantage is generality; its limitation is no application-aware features (no URL routing, no caching).

One more flavor worth naming: a transparent proxy intercepts traffic without the client configuring anything (common in captive portals and office networks) — which is why HTTPS/end-to-end encryption is the standing defense against silent interception.

What a VPN Actually Is

A VPN (Virtual Private Network) creates a secure tunnel between endpoints over an untrusted network, so two sites (or a remote worker and the office) behave as if connected by a private wire. Two defining properties:

• Encryption + authentication — the tunnel is confidential (eavesdroppers see ciphertext) and authenticated (only authorized peers can enter).
• Virtual topology — hosts inside the tunnel use private IPs (10.0.0.x) that the underlying internet never routes; the tunnel encapsulates one packet inside another.

The encapsulation is the key move: your packet gets wrapped in an outer packet addressed to the VPN server, and the VPN server decapsulates and delivers it. From the network’s point of view, it’s just a stream of encrypted traffic to one address.

Site-to-Site vs Remote Access

Tunneling Protocols Compared

WireGuard’s kernel design (~4k lines vs OpenVPN’s ~100k) has made it the default for modern tunnels — lower attack surface, better performance, and a handshake measured in milliseconds. IPsec remains the enterprise interop standard. The modern managed trend is ZTNA (Zero Trust Network Access, see Network Security Fundamentals), which replaces “network-wide tunnel” with per-identity, per-application access — often just TLS to a gateway instead of a full L3 VPN.

NAT and the Tunnel Problem

Network Address Translation (NAT) lets many private hosts share one public IP — but it breaks inbound connections and therefore breaks naive VPNs: the VPN server doesn’t know which internal host a packet belongs to, and a client behind NAT can’t receive inbound packets. Two classic solutions:

• NAT traversal — the client initiates an outbound connection first, keeping a mapping alive at the NAT, then tunnels within it (what most client VPNs do).
• Tunnels that ride TCP/UDP — OpenVPN over UDP/TCP and WireGuard’s UDP are NAT-friendly because they look like ordinary client traffic.

This is also why peer-to-peer systems (BitTorrent, WebRTC) need hole punching — both sides establish outbound mappings, then rendezvous to send through the resulting hole.

The Architecture Decision

Practice Trajectory

1. ssh -D 1080 user@jump-host then curl --socks5 localhost:1080 ifconfig.me — confirm the egress IP changed (forward proxy behavior).
2. Put an nginx reverse proxy in front of a local server; curl -i and confirm the Server header no longer leaks the backend.
3. Stand up WireGuard on two VPSes and ping across the tunnel by private IP; tcpdump the outer interface and confirm you see only UDP 51820.
4. ip tunnel / ip route inspection on a WireGuard interface — identify the virtual interface and its route table.
5. Explain to someone the difference between a SOCKS proxy and a VPN in two sentences (transport forwarding vs encrypted L3 tunnel).

When It’s the Right Tool