Privaten VPS-Cluster mit einem WireGuard-Mesh aufbauen

Kurz gesagt: Um mehrere VPS zu einem privaten Cluster zu machen, geben Sie jedem VPS-Node ein WireGuard-Interface mit einer Adresse aus einem gemeinsamen privaten Subnetz, tragen jeden anderen Node als `[Peer]` mit seinem öffentlichen `Endpoint` und einem `/32` in `AllowedIPs` ein, erlauben UDP 51820 nur von Ihren eigenen Nodes und binden Datenbanken und interne Dienste an die `wg0`-Adresse statt an die öffentliche IP. Bis etwa zehn Nodes lässt sich das gut von Hand oder mit einer Vorlage pflegen; darüber hinaus nutzen Sie Tools, die die Konfigurationen erzeugen und verteilen.

Diese Anleitung setzt voraus, dass Sie die Grundlagen aus der Anleitung zu WireGuard-VPN kennen und SSH auf jedem Node wie in der Anleitung zur SSH-Härtung gehärtet haben; um Nodes ohne Agent Forwarding über einen Bastion-Host zu erreichen, siehe die Anleitung zu StrictModes und Agent Forwarding.

Adressplan für die VPN-Nodes

Wählen Sie einen privaten Bereich, der mit nichts anderem kollidiert, das Sie nutzen (Heim-LAN, Docker, Pod-Bereiche von Kubernetes). Ein `/24` reicht für einen kleinen Cluster und hält die Adressen lesbar. Weisen Sie jedem Node eine feste Adresse zu und halten Sie den Plan in der Versionsverwaltung, denn jede Konfiguration wird daraus abgeleitet.

Peer-Konfiguration auf jedem VPS-Node

In einem Full Mesh spricht jeder Node direkt mit jedem anderen, also hat jede Konfiguration ein `[Interface]` und N-1 `[Peer]`-Abschnitte. Vier Nodes bedeuten insgesamt sechs Tunnel, zehn Nodes 45. Jeder Node hat eine öffentliche IP, daher ist `PersistentKeepalive` meist nicht nötig; Details stehen in der Anleitung zu Keepalive und PresharedKey.

1. 01.Führen Sie auf jedem Node `apt install wireguard` aus, dann `umask 077; wg genkey | tee /etc/wireguard/wg0.key | wg pubkey > /etc/wireguard/wg0.pub`.
2. 02.Sammeln Sie alle öffentlichen Schlüssel und den Adressplan an einem Ort.
3. 03.Erzeugen Sie optional einen `wg genpsk`-Schlüssel pro Node-Paar als Absicherung gegen Quantenangriffe.
4. 04.Schreiben Sie auf jedem Node `/etc/wireguard/wg0.conf` wie unten gezeigt.
5. 05.Führen Sie `systemctl enable --now wg-quick@wg0` aus und prüfen Sie mit `wg show`, ob mit jedem Peer ein aktueller Handshake besteht.

# /etc/wireguard/wg0.conf on node1
[Interface]
Address = 10.88.0.1/24
ListenPort = 51820
PrivateKey = <node1 private key>

[Peer]
# node2
PublicKey = <node2 public key>
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.88.0.2/32

[Peer]
# node3
PublicKey = <node3 public key>
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.88.0.3/32

[Peer]
# node4
PublicKey = <node4 public key>
Endpoint = 203.0.113.14:51820
AllowedIPs = 10.88.0.4/32

Wie AllowedIPs in einem Mesh funktioniert

`AllowedIPs` erfüllt zwei Aufgaben zugleich. Ausgehend ist es eine Routing-Tabelle: Pakete für `10.88.0.3` gehen an den Peer, der `10.88.0.3/32` aufführt. Eingehend ist es eine Zugriffsliste: Ein Paket von diesem Peer wird nur akzeptiert, wenn seine Quelladresse innerhalb der `AllowedIPs` dieses Peers liegt. Deshalb bekommt jeder Peer genau sein eigenes `/32`, nicht das ganze `/24`.

Das `/24` in der Zeile `Address` legt nur die Kernel-Route für das Subnetz auf `wg0` an; WireGuard wählt dann pro Ziel den richtigen Peer.

• ▹Zwei Peers dürfen auf demselben Interface nie überlappende `AllowedIPs`-Bereiche haben; der letzte gewinnt.
• ▹Routet ein Node zusätzlich ein privates Subnetz (zum Beispiel Docker auf node3), fügen Sie dieses Subnetz auf den anderen Nodes den `AllowedIPs` von node3 hinzu.
• ▹Tragen Sie `0.0.0.0/0` nicht bei einem Mesh-Peer ein, es sei denn, Sie wollen wirklich, dass sämtlicher Traffic über diesen Node hinausgeht.

Firewall: Nur Ihre Nodes erreichen den Tunnel

WireGuard antwortet nicht auf nicht authentifizierte Pakete, aber UDP 51820 auf bekannte Node-IPs zu beschränken, reduziert trotzdem das Grundrauschen. Öffnen Sie innerhalb des Tunnels nur die Ports, die jeder Dienst braucht. Dieses nftables-Beispiel für Debian 12/13 und Ubuntu 24.04 gehört nach `/etc/nftables.conf`; laden Sie es mit `nft -f /etc/nftables.conf` und aktivieren Sie `nftables.service`. Lassen Sie beim Testen eine SSH-Sitzung offen.

table inet filter {
  set mesh_peers {
    type ipv4_addr
    elements = { 203.0.113.11, 203.0.113.12, 203.0.113.13, 203.0.113.14 }
  }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    meta l4proto { icmp, ipv6-icmp } accept
    tcp dport 22 accept
    udp dport 51820 ip saddr @mesh_peers accept
    iifname "wg0" ip saddr 10.88.0.0/24 tcp dport { 5432, 6379, 9100 } accept
  }
}

Dienste an das wg-Interface binden

Eine Firewall ist eine Schicht; die zweite besteht darin, gar nicht erst auf der öffentlichen Adresse zu lauschen. Binden Sie interne Dienste an die `wg0`-Adresse des Nodes, damit ein Firewall-Fehler sie nicht freilegt. Da `wg0` existieren muss, bevor der Dienst bindet, ordnen Sie die Units mit einem systemd-Drop-in oder erlauben mit `net.ipv4.ip_nonlocal_bind = 1` das Binden an Adressen, die noch nicht aktiv sind.

# PostgreSQL on node3: postgresql.conf
listen_addresses = '10.88.0.3'
# pg_hba.conf
host  all  all  10.88.0.0/24  scram-sha-256

# Redis: /etc/redis/redis.conf
bind 10.88.0.3

# systemctl edit postgresql  (repeat for other services)
[Unit]
[email protected]
[email protected]

Note · Prüfen Sie das Ergebnis mit `ss -tlnp`: Interne Dienste sollten `10.88.0.x` zeigen, nie `0.0.0.0` oder die öffentliche IP.

Skalierung: Wann Sie auf Tools umsteigen sollten

Ein von Hand geschriebenes Mesh ist in Ordnung, solange die Zahl der Nodes klein ist und Änderungen selten sind. Jeder neue Node bedeutet, jede bestehende Konfiguration zu bearbeiten, der Aufwand wächst also quadratisch. Sobald das lästig wird, erzeugen Sie die Konfigurationen, statt sie zu schreiben.

Bei NoctisNode werden alle neuen VPS-Nodes in FI-1 (Finnland) bereitgestellt, jeder mit dedizierter IPv4 und ungedrosseltem 1-Gbps-Port, und die stündliche Abrechnung plus die Agent-API (mit Auto-Destroy-TTL) machen es günstig, Test-Nodes hinzuzufügen und wieder zu entfernen. Die Pläne beginnen bei Wisp; siehe VPS-Pläne.

FAQ