WireGuard Site-to-Site-VPN zwischen Büro und Cloud: die komplette Konfiguration

Ein Site-to-Site-WireGuard-Tunnel besteht aus zwei Peers, je rund zwanzig Zeilen Konfiguration und eingeschaltetem IP-Forwarding. Jede Seite listet ihr eigenes Subnetz und das ferne Subnetz in AllowedIPs, die NAT-Seite hält mit PersistentKeepalive ein Mapping offen, und der Verkehr zwischen den Netzen läuft über UDP auf einem einzigen Port. Alles läuft ohne Controller, ohne Zertifizierungsstelle und ohne Client-Daemons.

Ich nutze diese Form, um ein kleines Büro-Netz mit einer Cloud-VPS zu verbinden: Fileserver und Drucker bleiben im Büro, die Anwendung und ihre Datenbanken laufen in der Cloud, und der interne Verkehr beider Seiten berührt das öffentliche Internet nicht.

Wie unterscheidet sich Site-to-Site von einem Client-VPN?#

Ein Road-Warrior-Setup hat viele Clients an einem Server, die meisten oder der gesamte Verkehr läuft in den Tunnel. Site-to-Site dreht die Form um: genau zwei Peers, jeder spricht für ein ganzes Subnetz. Der spannende Teil: AllowedIPs macht doppelte Arbeit.

• Es ist die Crypto-Key-Routing-Tabelle: Pakete mit einer Quelladresse außerhalb der AllowedIPs des Peers werden sofort verworfen.
• wg-quick installiert zusätzlich eine Systemroute für jeden AllowedIPs-Eintrag und entscheidet damit, welche Pakete überhaupt in den Tunnel gehen.

Ein Tippfehler in AllowedIPs erzeugt deshalb keine Fehlermeldung. Er erzeugt ein stilles schwarzes Loch, das man mit ping und wg show debuggt wie alle vor dir.

Die vollständigen Konfigurationen#

Büro-Seite, hinter einem NAT-Router, Subnetz 192.168.187.0/24:

# /etc/wireguard/wg0.conf  (office, 192.168.187.0/24)
[Interface]
Address    = 10.7.0.2/24
PrivateKey = <office private key>
 
[Peer]
PublicKey           = <cloud public key>
Endpoint            = vpn.example.com:51820
AllowedIPs          = 10.7.0.0/24, 10.20.0.0/24
PersistentKeepalive = 25

Cloud-Seite, eine VPS mit dem Anwendungs-Subnetz 10.20.0.0/24:

# /etc/wireguard/wg0.conf  (cloud VPS, app subnet 10.20.0.0/24)
[Interface]
Address    = 10.7.0.1/24
ListenPort = 51820
PrivateKey = <cloud private key>
 
[Peer]
PublicKey  = <office public key>
AllowedIPs = 10.7.0.2/32, 192.168.187.0/24

Die Schlüsselpaare entstehen mit wg genkey und wg pubkey; der private Key verlässt die Maschine nie, auf der er erzeugt wurde. Danach braucht beide Seiten Paket-Forwarding:

sysctl -w net.ipv4.ip_forward=1        # persist in /etc/sysctl.d/
ufw route allow in on wg0 out on wg0   # or the nftables forward chain equivalent

MTU: das zuerst fixen, bevor irgendetwas anderes debuggt wird#

WireGuard fügt rund 60 Bytes Overhead über IPv4 hinzu (80 über IPv6), deshalb setzt wg-quick die Interface-MTU standardmäßig auf 1420. Auf deutschem DSL, wo PPPoE die Frames auf 1492 Bytes drückt, erscheint der klassische Satz an Symptomen: kleine Pings gehen, große Transfers stocken, TLS-Handshakes bleiben mittendrin hängen. Auf der Büro-Seite 1412 setzen und testen mit:

ping -M do -s 1372 10.7.0.1

Wenn 1372 Bytes mit gesetztem Do-not-Fragment-Flag durchkommen, stimmt die MTU-Kette. Wenn nicht, Interface-MTU in Zehnerschritten senken und erneut testen. Aus dem Verhalten von Anwendungen raten kostet einen Nachmittag; dieser Test kostet zehn Sekunden.

Verifizieren und die ersten drei Fehlerfälle#

wg show beantwortet die meisten Fragen: Der letzte Handshake sollte bei laufendem Verkehr unter zwei Minuten alt sein, und die Transfer-Zähler sollten steigen.

1. Gar kein Handshake: Eine Seite erreicht den UDP-Port 51820 der anderen nicht. Zuerst die VPS-Firewall prüfen (ufw allow 51820/udp), dann etwaige Packet-Filter des Providers.
2. Handshake klappt, Verkehr nicht: fast immer asymmetrische AllowedIPs. Ein Peer verwirft Pakete, deren Quelladresse nicht in seinem Eintrag steht: Beide Subnetze müssen auf beiden Seiten in den richtigen Rollen stehen.
3. Ein Subnetz geht, das andere nicht: Forwarding fehlt auf dem Peer, der zwischen den Interfaces routen soll, oder der Forward-Chain der Firewall hat keine Regel.

tcpdump entscheidet den Rest: tcpdump -ni udp port 51820 zeigt die verschlüsselten Hüllen im Transit. Sieht man Klartext-Anwendungverkehr in diesem Capture, hat etwas um den Tunnel herum geroutet. Das ist ein anderes und dringenderes Gespräch.

Wann ich WireGuard wähle statt der Alternativen#

IPsec interoperiert überall; OpenVPN überlebt feindliche Netze und seltsame Proxies. Für eine feste Büro-zu-Cloud-Strecke bleibe ich bei WireGuard: Die Konfiguration passt auf einen Bildschirm und wird wie Code reviewt, Key-Rotation ist ein Dateitausch plus Reload, und die Kernel-Implementierung bringt ordentlichen Durchsatz auf bescheidener Hardware. Der offizielle Quickstart und die wg-quick-Manpage decken die restliche Oberfläche ab. Es gibt nicht viel restliche Oberfläche, das ist der Punkt.