WireGuard-Inventar

Einleitung

In Lesson 0001 war WireGuard nur die Linie VPS ↔ lab-gateway. Heute lernst du, wo Peers und Tunnel-IPs im Repo stehen, und warum die UI noch live steuert. Primärquelle: docs/wireguard.md.

Rollen im Netz

• Hub: öffentlicher Endpunkt (net/wireguard/network.nix: Endpoint, Hub-Pubkey, Tunnel-Netz).
• Client: Laptop/VM mit einer Tunnel-IP (role = "client").
• Site: lab-gateway (role = "site") reicht das Lab-LAN weiter (extraAllowedIPs = [ "192.168.200.0/24" ]).

WireGuard spricht von Peers, nicht von Server/Client. AllowedIPs entscheidet, welche Adressen zu welchem Peer gehören (Routing hinaus, Filter hinein). Überblick: WireGuard Quick Start, Ubuntu: Allowed IPs.

Zwei Wahrheiten bis zum Cutover

• Live: noch wireguard-ui auf dem VPS (mutable wg0.conf + Peer-DB).
• Git: Inventar unter wireguard/ (IPAM + Peer-Dateien) als Vorbereitung für MR-basiertes Self-Service. labEdge.vpnHub.enable bleibt aus, bis die UI abgelöst wird.

Merksatz: Heute liest du Peers in Git, um sie zu planen und zu reviewen. Live-Änderungen an der Schnittstelle laufen noch über die UI.

Ordner → Aufgabe

Analog zu Lab-IPAM (net/lab/hosts/): Adressen und Inventar deklarativ, Secrets (private Keys) nicht in Git. Beide Bereiche teilen sich dieselben pure-Nix-Helfer aus net/ipam.nix (u. a. readDirNix, nextFreeId).

Lesen am Repo

1. net/wireguard/network.nix: Hub-IPv4 172.30.0.1, Endpoint, MTU
2. net/wireguard/peers/lab-gateway.nix: role = "site", extraAllowedIPs
3. Ein Client-Peer (z. B. spreisner-tuxedo.nix): nur Tunnel-IPs, leeres extraAllowedIPs

Üben

Primärquelle

docs/wireguard.md, docs/wireguard-ui-mode.md. Extern: wireguard.com/quickstart.

Kompakt: Referenz: WireGuard-IPAM.