129 lines
4.8 KiB
Markdown
129 lines
4.8 KiB
Markdown
# VPN – Basics
|
||
|
||
What a VPN does, full tunnel vs split tunnel, and the key concepts behind WireGuard.
|
||
|
||
For generic networking concepts, see:
|
||
|
||
- [Network / Basics](../Basics.md)
|
||
|
||
For my concrete WireGuard setup on the home server, see:
|
||
|
||
- [Home-Server / WireGuard implementation](../../Home-Server/Implementations/VPN/WireGuard.md)
|
||
|
||
---
|
||
|
||
## 1. What Is a VPN?
|
||
|
||
A **VPN** (Virtual Private Network) creates an **encrypted tunnel** between two network endpoints. Any traffic sent through it is:
|
||
|
||
- **Encrypted** — cannot be read by anyone in between.
|
||
- **Encapsulated** — wrapped inside VPN packets so the underlying network only sees opaque data.
|
||
|
||
From the application's perspective, the other end of the tunnel behaves as if it were directly reachable on the local network.
|
||
|
||
Common use cases:
|
||
|
||
- Accessing services on a home network remotely.
|
||
- Encrypting traffic on untrusted networks (public Wi-Fi).
|
||
- Linking two separate networks together (site-to-site VPN).
|
||
|
||
---
|
||
|
||
## 2. Full Tunnel vs Split Tunnel
|
||
|
||
### 2.1 Full Tunnel
|
||
|
||
All traffic from the client goes through the VPN — including regular internet browsing. The VPN server becomes the client's internet gateway.
|
||
|
||
```
|
||
All traffic → VPN server → internet
|
||
```
|
||
|
||
Use case: strong privacy, hiding traffic from the local ISP. Slower because everything is routed via the server.
|
||
|
||
### 2.2 Split Tunnel
|
||
|
||
Only traffic to specific IP ranges goes through the VPN. Everything else uses the client's normal connection directly.
|
||
|
||
```
|
||
192.168.1.0/24 → VPN server → home network
|
||
10.10.10.0/24 → VPN server → VPN peers
|
||
Everything else → direct internet (no VPN)
|
||
```
|
||
|
||
Use case: accessing home services remotely while keeping normal internet performance. This is the typical choice for a home server VPN.
|
||
|
||
In WireGuard, this is controlled by the `AllowedIPs` field on the client — see section 3.3.
|
||
|
||
---
|
||
|
||
## 3. WireGuard Concepts
|
||
|
||
WireGuard is a modern VPN protocol built into the Linux kernel. It is simpler, faster, and uses more modern cryptography than OpenVPN or IPsec.
|
||
|
||
### 3.1 Interface and Peers
|
||
|
||
WireGuard creates a virtual network interface (for example `wg0`). You then define **peers** — the other endpoints allowed to communicate through it.
|
||
|
||
There is no hard "server vs client" distinction in the protocol. In practice, one machine (the home server) has a stable public address and acts as the hub. But cryptographically, every participant is just a peer.
|
||
|
||
### 3.2 Public/Private Key Pairs
|
||
|
||
Each WireGuard peer has a **key pair**:
|
||
|
||
- **Private key** — stays on the peer, never shared with anyone.
|
||
- **Public key** — shared with all peers that need to communicate with this one.
|
||
|
||
Authentication is purely cryptographic: no passwords, no certificates, no CA. Holding the private key matching a registered public key is sufficient.
|
||
|
||
```bash
|
||
# Generate a key pair
|
||
wg genkey | tee privatekey | wg pubkey > publickey
|
||
```
|
||
|
||
### 3.3 AllowedIPs
|
||
|
||
`AllowedIPs` is the most important WireGuard concept. It does two things simultaneously:
|
||
|
||
1. **Outbound routing** — tells the interface which destination IPs should be sent through this peer.
|
||
2. **Inbound access control** — only packets with a source IP inside `AllowedIPs` are accepted from this peer.
|
||
|
||
Example on the **server** side (describing a client peer):
|
||
|
||
```ini
|
||
[Peer]
|
||
PublicKey = <client-public-key>
|
||
AllowedIPs = 10.10.10.2/32 # only this specific client VPN IP is valid
|
||
```
|
||
|
||
Example on the **client** side (describing the server peer):
|
||
|
||
```ini
|
||
[Peer]
|
||
PublicKey = <server-public-key>
|
||
Endpoint = <server-public-ip>:51820
|
||
AllowedIPs = 10.10.10.0/24, 192.168.1.0/24 # split tunnel — only these ranges go through the VPN
|
||
```
|
||
|
||
Setting `AllowedIPs = 0.0.0.0/0` on the client is a full tunnel — all traffic goes through the server.
|
||
|
||
### 3.4 Endpoint
|
||
|
||
The `Endpoint` field specifies the real IP address and UDP port used to reach a peer. Only the server needs a stable, publicly reachable endpoint. Roaming clients can omit it — their endpoint is learned dynamically from the first packet they send.
|
||
|
||
WireGuard uses **UDP** (port 51820 by convention). This port must be open in the server's firewall.
|
||
|
||
### 3.5 PersistentKeepalive
|
||
|
||
Because WireGuard uses UDP, NAT routers may drop the session mapping if no packet is sent for a while. Setting `PersistentKeepalive = 25` on a client makes it send a small keepalive packet every 25 seconds to maintain the NAT entry.
|
||
|
||
---
|
||
|
||
## 4. WireGuard vs Other Protocols
|
||
|
||
| Protocol | Complexity | Performance | Notes |
|
||
|---------------|------------|-------------|-----------------------------------------------------|
|
||
| **WireGuard** | Low | Very high | In-kernel on Linux, ~4 000 lines of code, modern crypto |
|
||
| **OpenVPN** | Medium | Medium | Mature, widely supported, certificate-based |
|
||
| **IPsec** | High | High | Enterprise standard, very complex to configure |
|