Ein VPS, viele Homeserver: Die saubere WireGuard‑Architektur für stabile Zero‑Trust‑Netzwerke

Viele Admins stehen irgendwann vor der gleichen Frage:
Wie kann ein einzelner VPS mehrere Homeserver sicher und stabil über WireGuard anbinden?

Die gute Nachricht:
Das ist nicht nur möglich, sondern sogar elegant lösbar — wenn man ein paar grundlegende Architekturprinzipien beachtet.
Dieser Beitrag fasst die wichtigsten Erkenntnisse zusammen, damit kein Wildwuchs entsteht und das Setup langfristig stabil bleibt.

1. Ein VPS braucht nur ein einziges WireGuard‑Interface

Der wichtigste Grundsatz lautet:

👉 Ein VPS = ein WireGuard‑Interface (wg0)

Warum?

• ein Interface = ein Routing‑Kontext
• ein Interface = ein NAT‑Kontext
• ein Interface = ein Satz Firewall‑Regeln
• ein Interface = keine Konflikte mit Docker oder iptables

Sobald mehrere WG‑Interfaces parallel laufen, steigt die Komplexität exponentiell.
Ein Interface dagegen bleibt übersichtlich, stabil und reproduzierbar.

2. Alle Homeserver hängen an diesem einen Interface

WireGuard ist Peer‑basiert, nicht Interface‑basiert.
Das bedeutet:

• Der VPS ist der Hub
• Jeder Homeserver ist ein Peer
• Alle Peers verbinden sich mit demselben VPS‑Interface

Das ist die klassische Hub‑and‑Spoke‑Topologie, die sich in der Praxis bewährt.

3. Ein gemeinsames WireGuard‑Subnetz für alle

Ein häufiger Irrtum ist, jedem Homeserver ein eigenes Subnetz zu geben.
Das ist unnötig und führt zu Komplexität.

Die saubere Lösung:

👉 Ein gemeinsames WG‑Subnetz, z. B. 10.10.0.0/24

Und dann:

• VPS: 10.10.0.1
• Homeserver 1: 10.10.0.2
• Homeserver 2: 10.10.0.3
• Homeserver 3: 10.10.0.4

Jeder Homeserver bekommt eine eindeutige IP — mehr braucht es nicht.

4. AllowedIPs: klein, eindeutig, konfliktfrei

Der Schlüssel zu stabilen Routen:

👉 AllowedIPs pro Homeserver nur /32

Beispiel:

• AllowedIPs = 10.10.0.2/32
• AllowedIPs = 10.10.0.3/32
• AllowedIPs = 10.10.0.4/32

Damit gibt es:

• keine Überschneidungen
• keine Routing‑Konflikte
• keine versehentlichen Default‑Routen

Das ist die minimalistische, aber perfekte Lösung.

5. Jeder Homeserver hat sein eigenes Schlüsselpaar

Das ist wichtig für Sicherheit und Übersichtlichkeit:

• Jeder Homeserver generiert ein eigenes Private/Public‑Key‑Paar
• Der VPS trägt jeden Public Key als eigenen Peer ein
• Alle Homeserver verwenden denselben VPS‑Public‑Key

Das ist kein Problem — das ist genau so vorgesehen.
Der VPS unterscheidet die Homeserver über deren Public Keys, nicht über Ports oder Subnetze.

6. NAT und Firewall bleiben übersichtlich

Weil es nur ein WG‑Interface gibt:

• NAT wird nur einmal definiert
• Firewall‑Regeln bleiben klar
• Docker‑NAT kollidiert nicht
• Routing bleibt deterministisch

Das verhindert Wildwuchs und sorgt für langfristige Stabilität.

7. Die wichtigsten Regeln auf einen Blick

✔ Ein WG‑Interface auf dem VPS

✔ Ein gemeinsames WG‑Subnetz

✔ Eine eindeutige IP pro Homeserver

✔ AllowedIPs nur /32

✔ Ein VPS‑Public‑Key für alle Homeserver

✔ Ein eigenes Schlüsselpaar pro Homeserver

✔ NAT nur einmal

✔ Keine parallelen WG‑Interfaces auf dem VPS

Wenn man diese Regeln einhält, kann ein VPS problemlos:

• 2 Homeserver
• 5 Homeserver
• 20 Homeserver

…stabil und sauber bedienen.

Fazit

Ein VPS kann ohne Weiteres mehrere Homeserver über WireGuard anbinden — und zwar sicher, performant und ohne Chaos.
Der Schlüssel liegt nicht in komplizierten Setups, sondern in einer klaren, reduzierten Architektur:

Ein Interface, ein Subnetz, klare Peers, eindeutige IPs.

Wer diese Prinzipien beachtet, baut ein Zero‑Trust‑Netzwerk, das nicht nur funktioniert, sondern auch langfristig wartbar bleibt.