sysopsandClaude Sonnet 5
3b3ffd8ebf
Implements the from-scratch multi-server WireGuard management fork per CLAUDE.md spec: sqlite schema (servers/peers/audit_log/users), Curve25519 key generation, per-interface config rendering + wg-quick/systemd control, nftables hook scaffolding, session+CSRF-protected REST API with QR code and config download endpoints, a minimal vanilla-JS web UI, legacy wg0.conf migration, and both a native installer and a Proxmox LXC provisioning script (with auto-detected latest Debian template). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
5.1 KiB
Du bist ein Senior Go-Entwickler mit Erfahrung in Netzwerk-Engineering, WireGuard, Linux, nftables und Webanwendungen.
Aufgabe: Erstelle einen Fork von "wireguard-ui" mit dem Namen:
wireguard-ui-multi
Ziel: Eine native Multi-Server-Verwaltungsoberfläche für WireGuard, die ohne Docker betrieben werden kann und mehrere unabhängige WireGuard-Server-Interfaces verwaltet.
Hintergrund: Die aktuelle wireguard-ui Version verwaltet hauptsächlich eine einzelne WireGuard-Instanz. Die neue Version soll mehrere getrennte WireGuard-Server gleichzeitig verwalten können.
Primäre Zielplattform:
- Linux
- Proxmox LXC Container
- Debian/Ubuntu
- OpenWrt-kompatible Umgebung (optional)
- Betrieb als natives Binary ohne Docker
Grundanforderungen:
- Multi WireGuard Server Support
Die Anwendung muss mehrere WireGuard-Server verwalten können:
Beispiele:
Server:
-
WGhome Interface: wg-home Listen Port: 51822 Tunnelnetz: 10.20.22.0/24
-
WGrz Interface: wg-rz Listen Port: 51866 Tunnelnetz: 10.20.66.0/24
-
WGwinter Interface: wg-winter Listen Port: 51824
Jeder Server muss besitzen:
- eigener Name
- eigenes WireGuard Interface
- eigener Port
- eigener Private Key
- eigene Address Range
- eigene DNS Einstellungen
- eigene MTU
- eigener Status
- eigene Peers
- Datenmodell erweitern
Aktuelles Modell: Application └── WireGuard Server └── Peers
Neues Modell:
Application
├── Server │ ├── Interface │ ├── Config │ ├── Settings │ └── Peers │ ├── Server │ └── Peers │ └── Server └── Peers
Datenbank erweitern:
Tabelle: servers
Felder:
- id
- name
- interface_name
- listen_port
- private_key
- public_key
- address_range
- dns
- mtu
- enabled
- created_at
- updated_at
Tabelle: peers
Felder:
- id
- server_id
- name
- public_key
- private_key
- preshared_key
- allowed_ips
- endpoint
- persistent_keepalive
- enabled
- WireGuard Verwaltung
Die Anwendung muss automatisch erzeugen:
/etc/wireguard/
Beispiel:
wg-home.conf wg-rz.conf wg-winter.conf
Jede Config muss valides WireGuard Format besitzen:
[Interface] PrivateKey= Address= ListenPort=
[Peer] PublicKey= AllowedIPs= PersistentKeepalive=
- Service Management
Die Anwendung muss WireGuard Interfaces starten und stoppen können:
Beispiele:
wg-quick up wg-home wg-quick down wg-home
Unterstützung für:
systemd: wg-quick@wg-home.service
Optional: OpenWrt: uci / netifd Integration vorbereiten
- Webinterface
Erweitere die UI:
Dashboard:
Liste aller WireGuard Server:
Name Interface Port Status
WGhome wg-home 51822 UP WGrz wg-rz 51866 UP Winter wg-winter 51824 DOWN
Jeder Server bekommt eigene Verwaltung:
- Peers anzeigen
- Peer hinzufügen
- Peer löschen
- QR-Code erzeugen
- Config herunterladen
- Server starten
- Server stoppen
- Server neu laden
- Peer Verwaltung
Pro Server:
Funktionen:
- neuen Client erstellen
- Schlüssel automatisch erzeugen
- QR-Code erzeugen
- Konfiguration exportieren
- Ablaufdatum optional
- Beschreibung
- Benutzername
- Backup / Restore
Implementieren:
Export:
- Datenbank
- WireGuard Configs
- Keys
- Einstellungen
Restore:
- komplette Wiederherstellung
- API
REST API erweitern:
Beispiele:
GET /api/servers
POST /api/servers
GET /api/server/{id}/peers
POST /api/server/{id}/peer
DELETE /api/server/{id}/peer/{peerid}
- Sicherheit
Implementieren:
- Passwortschutz
- Session Management
- CSRF Schutz
- keine Private Keys im Frontend anzeigen
- Audit Log für Änderungen
- Firewall Integration
Vorbereitung für:
nftables
Beispiel:
Server WGhome:
INPUT: UDP 51822 ACCEPT
FORWARD: wg-home → lan
Hooks:
/etc/wireguard-manager/hooks/
server-start server-stop peer-add peer-remove
- Deployment
Kein Docker.
Erstellen:
Binary:
wireguard-ui-multi
Installationsstruktur:
/usr/local/bin/wireguard-ui-multi
/etc/wireguard-ui-multi/
/var/lib/wireguard-ui-multi/
Systemd Service:
wireguard-ui-multi.service
- Codequalität
Anforderungen:
- Go aktuelle Version
- saubere Package-Struktur
- Unit Tests
- Logging
- Fehlerbehandlung
- Dokumentation
Projektstruktur:
cmd/ └── wireguard-ui-multi
internal/
├── server/ ├── wireguard/ ├── database/ ├── api/ ├── firewall/ └── ui/
- Migration
Erstelle eine Migration von einer bestehenden wireguard-ui Installation:
- bestehende wg0.conf erkennen
- als ersten Server importieren
- Peers übernehmen
- Dokumentation
Erstellen:
README.md
mit:
- Installation
- Konfiguration
- LXC Installation
- Proxmox Hinweise
- Backup
- Migration
Beginne mit:
- Analyse der bestehenden wireguard-ui Architektur
- Vorschlag für Datenbankmigration
- Umsetzung der Server-Abstraktion
- Implementierung der Multi-Interface-Verwaltung
- Anpassung der UI
- Tests
Das Ergebnis soll ein produktiv nutzbarer Fork "wireguard-ui-multi" werden.