---
id: 2024-11-02-what-is-a-vpn-a-beginner-guide
slug: what-is-a-vpn-a-beginner-guide
title: "What is a VPN?: a beginner guide"
excerpt: "How VPNs work: encapsulation, cryptography, WireGuard, OpenVPN and IPsec, setup on your devices, fine-tuning, leak tests and systematic troubleshooting."
date: "2024-11-02T16:00:25+01:00"
updated: "2026-09-09T12:00:00+02:00"
author:
  name: "Sebastian Palencsár"
  handle: "spalencsar"
category: ["network"]
tags: ["vpn", "datenschutz", "netzwerk", "security", "privatsphaere", "wireguard"]
reading_time: 28
toc: true
---

A **VPN (Virtual Private Network)** is an invisible, tap-resistant tunnel through the public internet. Picture sending important documents to a colleague from home — but the only path is an unsecured, crowded marketplace. Anyone walking past could see what you carry, who you send it to and where you come from. A VPN is a locked private tunnel under that marketplace: nobody outside can look in, tamper with your data or establish your real identity.

In a connected world, VPNs matter in private life and in professional IT. They protect passwords on open hotel Wi-Fi, connect home-office seats securely to the company network and stop internet providers and ad networks from building a complete movement profile of your browsing.

What you work through, in plain technical terms:

* How a VPN encrypts and carries data at network level
* How modern protocols such as **WireGuard, OpenVPN and IPsec** differ
* What VPN servers and VPN clients actually do
* How you install and tune a VPN on Windows, macOS, Linux and smartphones
* Which client settings (kill switch, auto-connect, split tunneling) fit which purpose
* How you check connection quality, stop data leaks and fix typical problems yourself

These basics sit in [Networking](/en/category/network){.badge-link-text} and are the theoretical foundation for a practical build such as the [WireGuard VPN server guide](/en/server-environments/set-up-a-wireguard-vpn-server-on-ubuntu){.badge-link-text}.

<blockquote class="infobox infobox--info">
💡 **Core job of a VPN:** It encrypts your entire internet traffic at network level and replaces your real source IP address with the IP address of the VPN server.
</blockquote>

## Basics: what is a VPN?

### How it works, simply

Without a VPN, your packets travel straight through your internet provider (ISP) and countless intermediate hops (routers, peering points). On modern HTTPS sites the actual content (for example passwords in forms) is encrypted. Metadata is a different story.

**What a local observer can still see without a VPN:**

* the **destination IP**
* **duration** and **volume** of the transfer
* **DNS names**, unless you use encrypted DNS (DoH/DoT)
* the **TLS hostname (SNI)**, unless Encrypted Client Hello (ECH) is in use on browser, site and DNS path

ECH plus encrypted DNS can hide the hostname from the ISP. They still see which IP you talk to, and when. A VPN goes further: DNS, SNI and destination IPs of the sites you visit all sit **inside** the tunnel. The ISP only sees an encrypted stream to the VPN server.

```markdown
┌─────────────────────────────────────────────────────────────┐
│            Connection: without VPN vs. with VPN             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   WITHOUT VPN (direct / unprotected):                       │
│   [Your device] ──────▶ [Internet / ISP] ─────▶ [Web]       │
│                  (path metadata visible)                    │
│                                                             │
│   WITH VPN (encrypted tunnel):                              │
│   [Your device] ══════▶ [VPN server] ─────────▶ [Web]       │
│       (secure tunnel)              (target sees only        │
│                                     the server IP)          │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

**What happens with an active VPN, step by step?**

1. **Encryption on the device:** Before a packet leaves your network card, the VPN client intercepts it and encrypts it fully (payload + original IP header).
2. **Encapsulation and transport:** The encrypted packet is wrapped in a new outer IP packet (*header-in-header*) and sent as an apparently random stream (usually UDP) to the VPN server.
3. **Decryption at the gateway:** The VPN server receives the packet, verifies the cryptographic signature, decrypts the original data and forwards the packet with its own source IP to the destination (NAT / masquerading).
4. **Protected return path:** The target site’s reply arrives at the VPN server, is encrypted again for your client and travels back through the tunnel.

### The header-in-header principle (packet encapsulation)

To see why a VPN works independently of the transport path, look at [layer 3 (network layer) of the OSI model](/en/network/the-osi-model-a-detailed-introduction-to-the-7-layers){.badge-link-text}.

A VPN uses **encapsulation (tunneling)**. The original IP packet is wrapped completely and gets a new outer envelope:

```markdown
┌─────────────────────────────────────────────────────────────┐
│           Packet encapsulation: header-in-header            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   1. Original IP packet (cleartext before sending):         │
│   ┌─────────────────────┬───────────────────────────────┐   │
│   │ Original IP header  │ Payload (HTTP/DNS/data)       │   │
│   │ (your source IP)    │                               │   │
│   └─────────────────────┴───────────────────────────────┘   │
│                                                             │
│   2. Encapsulated VPN packet (encrypted in the tunnel):     │
│   ┌───────────────┬─────────────────────────────────────┐   │
│   │ New header    │ Encrypted payload                   │   │
│   │ (VPN server   │ ┌─────────────────┬───────────────┐ │   │
│   │  as dest.)    │ │ Orig. IP header │ Payload       │ │   │
│   │               │ └─────────────────┴───────────────┘ │   │
│   └───────────────┴─────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

To every router between you and the VPN server this packet looks like a simple connection between your IP and the server IP. Which destination you aim at on the inside stays mathematically unreadable to outsiders.

### The four core components of a VPN

Every VPN setup is built from four main parts that work together for security:

| Component | Role and technical job |
|---|---|
| **1. Endpoint (host)** | Computer, smartphone, tablet or router — this is where packets and application requests originate. |
| **2. VPN client** | The software or kernel module that provides a virtual network adapter (`wg0`, `tun0`), manages keys and intercepts traffic. |
| **3. VPN tunnel** | The encrypted transport channel over the public internet on [TCP or UDP](/en/network/tcp-ip-structure-and-how-the-protocol-family-works){.badge-link-text}. |
| **4. VPN server (gateway)** | The far endpoint that authenticates users, decrypts packets and forwards them to the internet or the company LAN. |

## VPN technology and cryptography in detail

A VPN combines modern mathematics to guarantee three fundamental security goals: **confidentiality** (nobody can read along), **integrity** (nobody can change data unnoticed) and **authenticity** (both sides have proved their identity).

```markdown
┌─────────────────────────────────────────────────────────────┐
│           Crypto process: handshake and tunneling           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   Client (laptop/phone)                 VPN gateway/server  │
│   ┌──────────────────────┐             ┌─────────────────┐  │
│   │ Priv./public keypair │             │ Server key pair │  │
│   └──────────┬───────────┘             └────────┬────────┘  │
│              │                                  │           │
│              │ 1. Asymmetric key exchange       │           │
│              │    (Diffie-Hellman / Curve25519) │           │
│              │  ◀────────────────────────────▶  │           │
│              │                                  │           │
│              │ 2. Shared session key            │           │
│              │    (session key / ephemeral)     │           │
│              ▼                                  ▼           │
│   ═══════════════════════════════════════════════════════   │
│     Symmetrically encrypted data stream (AES / ChaCha)      │
│   ═══════════════════════════════════════════════════════   │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

### 1. Asymmetric handshake (key exchange)

At the start of a connection, client and server do not know each other yet. Through asymmetric cryptography (**elliptic-curve cryptography / Curve25519** or **RSA / Diffie-Hellman**) both sides exchange public keys and compute a shared secret session key (*shared secret*) without ever sending that secret over the network.

### 2. Symmetric tunnel encryption (payload)

Asymmetric encryption is expensive, so the actual data stream is encrypted with fast **symmetric ciphers**:

* **ChaCha20-Poly1305:** modern stream cipher with built-in authentication (AEAD). Extremely fast on all CPUs (especially phones without hardware AES). Standard in WireGuard.
* **AES-256-GCM:** industry-proven block cipher with 256-bit key length. Very fast on desktop and server CPUs with dedicated hardware instructions (AES-NI). Standard in OpenVPN and IPsec.

### 3. Perfect Forward Secrecy (PFS)

Modern VPNs generate new, short-lived session keys (*ephemeral keys*) for every session. Even if an attacker later steals the server’s long-term private key, they **cannot decrypt previously recorded tunnel data after the fact**.

<blockquote class="infobox infobox--info">
💡 **Post-quantum protection:** WireGuard can mix a symmetric **pre-shared key (PSK)** into the handshake. That helps against later quantum attacks on recorded traffic only if the PSK itself was not delivered over a quantum-breakable channel. Production setups add a post-quantum KEM (typically ML-KEM) and inject the result into WireGuard’s PSK slot — for example Rosenpass, or a provider’s hybrid handshake. A static `PresharedKey` from `wg genpsk` is still worth using. It is not a complete post-quantum handshake on its own, because WireGuard’s X25519 exchange stays quantum-vulnerable without that extra layer.
</blockquote>

### Division of work: server vs client

In operation, server and client split the work precisely:

| VPN server tasks | VPN client tasks |
|---|---|
| User authentication and access checks | Encryption before the packet leaves the device |
| Assignment of internal tunnel IPs (DHCP pools) | Building and watching the tunnel |
| NAT routing / masquerading to the internet or LAN | DNS redirection to the VPN resolver |
| Decryption of incoming client packets | Automatic reconnect on network change |
| Firewall filtering and peer isolation | Emergency block on drop (kill switch) |

## The most important VPN protocols compared

Not every VPN protocol is equally secure or fast. The protocol choice largely determines speed, battery use on mobiles and latency. WireGuard is the default for new setups. OpenVPN remains the fallback when UDP is blocked or you need TLS-style configuration. IKEv2/IPsec stays strong on mobiles because of native OS support. Commercial stacks such as **NordLynx** (WireGuard-based) or **Lightway** follow the same idea — a small, modern data channel — with provider-specific extras.

| Protocol | Type and architecture | Security | Speed | Stability and roaming | Recommendation |
|---|---|---|---|---|---|
| **WireGuard** | Native Linux kernel driver | 🟢 State of the art (*ChaCha20*) | 🚀 Very high | 🟢 Excellent (instant connect) | **First choice** for modern servers and clients |
| **OpenVPN** | Userspace daemon (SSL/TLS), optional kernel DCO | 🟢 Very high (*AES-256*) | 🟢 High with DCO | 🟢 Very good (TCP/UDP choice) | Proven standard for complex nets and TCP 443 |
| **IKEv2 / IPsec** | Kernel- and hardware-accelerated | 🟢 Very high (*AES-GCM*) | 🟢 Very high | 🟢 Excellent on mobile handover | Popular for native mobile integrations |
| **SSTP** | Microsoft-proprietary (TCP 443) | 🟡 Good (AES) | 🟡 Moderate | 🟡 Moderate (TCP meltdown) | Windows special case behind restrictions |
| **PPTP / L2TP** | Legacy protocols | 🔴 Insecure / broken | 🔴 Moderate | 🔴 Moderate | ⚠️ **Obsolete:** do not use |

### Protocol profiles in detail

<span class="nb-accent">1. WireGuard (the modern generation)</span>

WireGuard was designed from scratch:

* **Advantages:** With under 4,000 lines of source (the OpenVPN daemon is on the order of 70,000, plus a TLS stack) WireGuard is extremely slim, straightforward to audit and has a small attack surface. It runs as a Linux kernel module, so context switches between kernel and userspace drop away. Connections come up immediately (*instant connect*), and IP changes (for example from home Wi-Fi to 5G) survive without a full new handshake. Mesh overlays such as Tailscale build on the same protocol for device-to-device nets rather than a classic full-tunnel privacy VPN.
* **Drawback:** UDP only. On extremely restrictive hotel or company nets that block UDP, WireGuard needs extra obfuscation tunnels (for example Shadowsocks or wstunnel).

<span class="nb-accent">2. OpenVPN (the flexible enterprise classic)</span>

OpenVPN has been the reliable open-source workhorse for more than 20 years:

* **Advantages:** Almost endlessly configurable. It supports UDP (for speed) and **TCP on port 443**, so it can look like ordinary HTTPS and get through strict company firewalls. On current Linux, **Data Channel Offload (DCO)** moves the encrypted payload into the kernel. With DCO, throughput sits close to WireGuard. The current 2.7 series is the line to run; 2.6 is old-stable with security fixes only.
* **Drawback:** The TLS handshake is still slower than WireGuard’s one-round-trip Noise handshake. Without DCO, CPU and battery cost stay higher because of the userspace `tun`/`tap` path.

<span class="nb-accent">3. IKEv2 / IPsec (the roaming specialist)</span>

IKEv2 (Internet Key Exchange v2) plus IPsec is the standard solution for mobiles:

* **Advantages:** Native in Apple iOS, macOS, Windows and Android (no third-party app required). The built-in *MOBIKE* protocol switches quickly between Wi-Fi and mobile data. Some stacks can add a hybrid ML-KEM exchange in IKEv2 for post-quantum key agreement, independent of WireGuard.
* **Drawback:** Very complex server configuration and demanding certificate management.

## The three main kinds of VPN

In IT practice you distinguish three basic VPN architectures:

### 1. Remote-access VPN (client-to-gateway / road warrior)

Individual endpoints (home-office staff, laptops on the road, smartphones) connect over the internet to a central company or home server:

* **Use:** home office, secure remote maintenance, protection on foreign Wi-Fi.
* **How it works:** the user starts a VPN app or uses the operating-system profile.
* **Routing:** access to internal servers (`192.168.1.0/24`) or full internet routing (*full tunnel*).

### 2. Site-to-site VPN (linking sites)

Two permanent gateways (for example routers or Linux servers) connect two geographically separate company sites or a home lab to a cloud infrastructure:

* **Use:** branch linking (for example office A ↔ office B or a cloud VPC).
* **How it works:** the gateways keep the tunnel up permanently. Individual endpoints on the LAN need no VPN software of their own.
* **Routing:** transparent routing between the local [private IP subnets](/en/network/public-vs-private-ip-addresses-the-main-differences){.badge-link-text} without NAT.

### 3. Client-based consumer VPNs (privacy and streaming)

Services for end users that send all outbound internet traffic through worldwide server farms:

* **Use:** bypassing geoblocking (streaming), protection on public hotspots, hiding your location from tracking networks.
* **Limits:** a consumer VPN does not make you magically “100% anonymous” — browser fingerprinting, cookies and logged-in accounts still identify you.

## Where you use VPNs in daily life and at work

### 1. Private use and privacy

* **Streaming and entertainment:** access to media libraries and sports without regional limits (geoblocking).
* **Online shopping and dynamic pricing:** protection against price tracking — many flight and hotel sites adjust prices based on location, provider and device type.
* **Gaming:** protection against targeted DDoS on your home IP and access to regional servers when ISP peering is poor.

### 2. Business use and home office

* **Secure access to company data:** encrypted access to CRM systems, file servers, code repositories and internal databases from the road.
* **Cross-site collaboration:** uniform security and access controls for distributed teams without opening ports to the public internet.

### 3. Public Wi-Fi security

On open hotspots (cafés, trains, hotels, airports) attackers on the same net can capture unencrypted data (man-in-the-middle, evil-twin access points). A VPN encrypts the connection from the network card and protects passwords, email and banking.

<blockquote class="infobox infobox--warn">
⚠️ **Hotspot note:** Always turn the VPN on **before** you join a foreign Wi-Fi, or enable automatic protection for unknown networks in your VPN app.
</blockquote>

## Advantages and drawbacks at a glance

### Security aspects and the trust question

| Positive aspects | What you must watch |
|---|---|
| 🔒 Strong encryption protects on open Wi-Fi | The VPN operator sees your traffic (check no-logs policy and audits) |
| 🛡️ Real IP address is hidden from websites | You need to trust the provider — free services often sell user data |
| 🌍 Protection against tracking by your own ISP | A VPN does not protect against phishing, malware or browser cookies |

### Cost models compared

* **Free VPNs:** sound tempting, but are often a data trap. They fund themselves through ads, data collection or reselling your bandwidth. Bandwidth and server choice are usually tightly limited.
* **Premium VPNs (about 3–10 €/month):** professional infrastructure with worldwide high-speed servers, RAM-only operating systems (no disk logs), independent security audits and 24/7 support.
* **Your own VPN server (self-hosted):** full data control on a cheap cloud server (from about 3–5 €/month) with for example [WireGuard on Ubuntu](/en/server-environments/set-up-a-wireguard-vpn-server-on-ubuntu){.badge-link-text}. Ideal for admins and privacy-conscious users.

## Practical use: step by step

### 1. Choosing provider and setup

When you pick a commercial provider, watch these core criteria:

* **No-logs policy:** proven by independent audits from known labs (for example Cure53, PwC).
* **Modern protocols:** full WireGuard support; OpenVPN with TCP 443 as fallback.
* **RAM-only servers:** servers run without disk persistence; on reboot all temporary data in RAM is gone.
* **Payment methods:** support for anonymous payment (cash, cryptocurrencies such as Monero).

### 2. Installing software on your devices

Installation differs by operating system:

* **Windows:** download the official installer (`.exe`). During setup confirm the virtual TUN/TAP or Wintun adapter and the exception in Windows Defender Firewall.
* **macOS:** install the app from the Mac App Store or the website. After first start open *System Settings → Privacy & Security* and allow the system extension (*Network Extension*).
* **Linux:** install packages via the native package manager (for example `sudo apt install wireguard resolvconf`) or use the NetworkManager GUI client.
* **Smartphones (iOS / Android):** load the official app from the App Store or Google Play Store. Confirm the system prompt to add a VPN configuration.

### 3. The connection sequence in detail

When you tap **Connect** in the app, the software runs four phases:

| Phase | Technical process in the background | Typical status |
|---|---|:---:|
| **1. Start** | Check of the physical network, DNS reachability and local firewall rules | 🔄 *Initialising* |
| **2. Authentication** | Check of user tokens, certificates or keys at the gateway | ⚡ *Authenticating* |
| **3. Tunnel handshake** | Asymmetric key exchange, parameter negotiation and tunnel IP assignment | 🔒 *Building tunnel* |
| **4. Routing activation** | Virtual adapter takes default routing (`0.0.0.0/0`) — stream is encrypted | ✅ *Connected (secure)* |

### 4. Checking connection quality and leaks

After the first connection always run these four basic checks:

1. **IP check:** open `whatismyipaddress.com` — the IP shown must match the chosen VPN server, not your real location.
2. **DNS leak test:** open `dnsleaktest.com` and start the *Extended Test*. Only DNS servers of the VPN provider may appear, none of your home ISP.
3. **WebRTC leak test:** check on `ipleak.net` whether your browser leaks your real IP via WebRTC.
4. **Speed test:** measure bandwidth on `speedtest.net` and compare it with your baseline without VPN.

## VPN fine-tuning and optimisation

### 1. Configuring a kill switch

A kill switch stops unencrypted data leaking when the tunnel drops unexpectedly:

* **System-wide kill switch:** blocks all outbound traffic at OS level as soon as the tunnel is down (recommended for maximum security).
* **App-based kill switch:** closes only selected applications (for example browser, torrent clients) on loss of connection.
* **Local LAN access:** if needed, allow access to the local home network (printer, NAS) while the internet stays blocked.

### 2. Auto-connect and trusted networks

* **Auto-start:** starts the VPN client with the operating system.
* **Wi-Fi protection:** connects the VPN automatically as soon as you join an unknown or open Wi-Fi. On trusted home Wi-Fi the VPN can pause if you want.

### 3. Setting up split tunneling

Split tunneling splits your traffic:

* **App-based:** send only security-relevant programs (browser, mail, banking) through the VPN, while graphics- and bandwidth-heavy games use the home line directly.
* **Domain-based:** define exceptions for sites (for example local banks or streaming services) that block VPN connections.

### 4. Server choice and latency

* **Distance:** for normal browsing pick a server in your own country or at most about 500 km away.
* **Server load:** prefer servers under 60 % load to avoid bottlenecks.
* **Latency (ping):** for snappy browsing and gaming the ping to the server should stay under 30–50 ms.

## Common problems and troubleshooting

### Problem 1: no internet / captive portals

* **Symptom:** the browser shows “No internet connection” even though Wi-Fi is connected.
* **Cause on hotel and train Wi-Fi:** you must accept a splash page (*captive portal*) before browsing. An active VPN kill switch blocks access to that local login page.
* **Fix:**
  1. Disconnect or pause the VPN.
  2. In the browser open `http://neverssl.com` (a plain HTTP page that forces the redirect to the captive portal). If that fails, try `http://captive.apple.com`.
  3. Accept the terms in the portal and unlock access.
  4. Once the internet works, turn the VPN back on.

### Problem 2: massive speed drop

* **Symptom:** download rate drops by more than 50 %.
* **Fix steps:**
  1. **Change server:** pick a geographically closer server with lower load.
  2. **Change protocol:** switch from OpenVPN TCP to **WireGuard** or OpenVPN UDP. On Linux, enable OpenVPN DCO if the client and kernel support it, before you give up on OpenVPN.
  3. **Adjust MTU:** on packet fragmentation in DS-Lite or mobile nets, reduce the MTU in the adapter settings from 1420 to `1360` bytes.

### Problem 3: streaming services block access

* **Symptom:** a message such as “You appear to be using an unblocker or proxy”.
* **Fix steps:**
  1. In the app pick a dedicated, streaming-optimised server.
  2. Clear the browser cache and delete cookies for the streaming service.
  3. Disable location services (GPS) in the browser or on the phone.

### Problem 4: systematic 4-step diagnosis plan

If a connection fails, work methodically:

```markdown
┌─────────────────────────────────────────────────────────────┐
│                  Systematic diagnosis plan                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   1. Baseline check:                                        │
│      Does the internet work without VPN?                    │
│      [Yes] ──▶ continue to step 2                           │
│      [No]  ──▶ check local router / Wi-Fi                   │
│                                                             │
│   2. Software and driver check:                             │
│      Quit the VPN app, wait 30 s, start again               │
│      Check the virtual adapter in the device manager        │
│                                                             │
│   3. Server and protocol change:                            │
│      Pick another server location                           │
│      Switch UDP to TCP, or to WireGuard                     │
│                                                             │
│   4. Firewall and antivirus exceptions:                     │
│      Check security software temporarily / add exceptions   │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

## Command Reference (Cheatsheet)

The following reference collects the essential checks and commands around VPN use on Linux:

| Category | Command or check | Purpose |
| :--- | :--- | :--- |
| **Install** | `sudo apt install wireguard resolvconf` | Installs WireGuard tools and DNS helper on Debian/Ubuntu |
| **Status** | `sudo wg show` | Shows interfaces, peers, handshake and transfer |
| **Status** | `ip addr show` | Lists `wg0` / `tun0` and tunnel addresses |
| **Status** | `ip route show` | Confirms default route through the tunnel |
| **Keys** | `wg genkey \| tee private.key \| wg pubkey` | Creates a WireGuard key pair |
| **PSK** | `wg genpsk` | Creates a symmetric pre-shared key for a peer |
| **Service** | `sudo systemctl enable --now wg-quick@wg0` | Starts the tunnel and enables it on boot |
| **Forwarding** | `cat /proc/sys/net/ipv4/ip_forward` | Checks whether the self-hosted gateway forwards |
| **Leaks** | `curl ifconfig.me` | Shows the public IP the internet sees |
| **Leaks** | `dnsleaktest.com` (extended test) | Checks whether DNS leaves the tunnel |
| **Leaks** | `ipleak.net` | Checks WebRTC IP leaks in the browser |
| **Portal** | `http://neverssl.com` | Forces a captive-portal redirect over plain HTTP |
| **Speed** | `speedtest.net` or `speedtest-cli` | Compares bandwidth with and without VPN |

## Further Resources

For deeper reading and the matching hands-on build:

| Resource | Description | Type |
| :--- | :--- | :--- |
| [Set up a WireGuard VPN server on Ubuntu](/en/server-environments/set-up-a-wireguard-vpn-server-on-ubuntu){.badge-link-text} | Self-hosted WireGuard: keys, peers, firewall and clients | Article |
| [OSI model](/en/network/the-osi-model-a-detailed-introduction-to-the-7-layers){.badge-link-text} | Layer 3 context for encapsulation and routing | Article |
| [TCP/IP protocol family](/en/network/tcp-ip-structure-and-how-the-protocol-family-works){.badge-link-text} | UDP vs TCP as VPN transport | Article |
| [Public vs private IP addresses](/en/network/public-vs-private-ip-addresses-the-main-differences){.badge-link-text} | NAT, RFC 1918 and why the VPN IP replaces yours | Article |
| [WireGuard whitepaper](https://www.wireguard.com/papers/wireguard.pdf){.badge-link-text} | Protocol design, Noise IK and cryptography | Documentation |
| [Rosenpass](https://rosenpass.eu/){.badge-link-text} | Post-quantum key exchange feeding WireGuard’s PSK slot | Project |
| [LPIC-1 series](/en/category/lpic-1-serie){.badge-link-text} | Linux administration and networking course | Course |

## Conclusion

A VPN is a core tool for network security, privacy and digital self-determination. It protects your data against eavesdropping on foreign networks, stops complete tracking by internet providers and enables secure remote access to company and home networks.

Modern protocols such as **WireGuard** make that as simple, fast and battery-friendly as it has ever been. OpenVPN with kernel offload remains the right tool when you must look like HTTPS. A VPN is still not a cure-all: careful passwords, two-factor authentication and scepticism toward phishing stay mandatory.
