Standard Operating Procedure

Dokumenten-ID: GNAI-006-SEC-SOP-01
Titel: Clients in der wg-easy-GUI einrichten und verwalten
Status: Betriebsverfahren dokumentiert; Rollen-Firewall noch nicht umgesetzt oder abgenommen
Referenzen: Gateway-Architektur, Rollenmodell, Windows, Linux

Änderungsverlauf

Datum	Version	Autor	Änderung
2026-09-15	1.0	spektr	Eigenständige SOP für Rollenzuordnung, Profilausgabe, Änderung, Widerruf und Abnahme angelegt.
2026-09-18	1.1	spektr	Offenen Umsetzungsstand der Rollen-Firewall, Gateway-INPUT-Regeln und negative Rollentests präzisiert.

1. Zweck und Voraussetzungen

Administratoren erstellen, ändern, verteilen und widerrufen WireGuard-Profile. Nutzer erhalten ausschließlich ihr eigenes Geräteprofil und benötigen keinen Zugriff auf wg-easy. GUI-Zugang ist für Familie und Server Admins vorgesehen, LLM Admins erhalten keinen Zugang.

Benötigt werden ein Administratorlogin, Zugriff auf http://10.0.0.15:51821 aus einem erlaubten Netz und ein aktuelles Serverinventar. Der dokumentierte Endpoint ist vpn.ghostnet.selfhost.eu; vor Profilausgabe seine DNS-Auflösung mit der aktuellen WAN-IP vergleichen. HTTPS ist geplant, noch nicht eingerichtet. Ein eigener Peer pro Gerät ermöglicht gezielten Widerruf.

Vor Rollenvergabe müssen Per-Client Firewall und Gateway-INPUT-Regeln nach der Architektur eingerichtet und geprüft werden. Der derzeitige Serverzustand bietet noch keine nachgewiesene Rollenisolierung. Diese SOP dokumentiert die Umstellung und den anschließenden Regelbetrieb; sie erklärt bestehende Peers nicht rückwirkend für sicher.

2. Rollenwerte festlegen

Rolle	Allowed IPs im Profil	Firewall Allowed IPs auf dem Server	DNS
Familie	`10.0.0.0/24`	`10.0.0.0/24`	`10.0.0.1`
Server Admin	freigegebene Server jeweils `/32`	dieselben Serveradressen ausdrücklich eintragen	zunächst leer / System-DNS
LLM Admin	`10.0.0.90/32`	`10.0.0.90/32`	leer / System-DNS

Für Server Admins enthält das Quelleninventar derzeit Proxmox .2 sowie .4, .10, .11, .12, .15, .17, .23, .47 und KI-Server .90. Vor Vergabe in Proxmox mit der tatsächlichen Belegung abgleichen. Beispiel nach bestätigtem Inventarabgleich:

10.0.0.2/32, 10.0.0.4/32, 10.0.0.10/32, 10.0.0.11/32, 10.0.0.12/32, 10.0.0.15/32, 10.0.0.17/32, 10.0.0.23/32, 10.0.0.47/32, 10.0.0.90/32

Das ist eine Inventarliste, keine behauptete vollständige LXC-Erfassung. Neue Server einzeln ergänzen. Der geplante statische Bereich bis .99 wird nicht automatisch freigegeben. Die Fritzbox .1 ist keine implizite Server-Admin-Freigabe. DNS über die Fritzbox für diese Rolle benötigt eine separate Entscheidung und Freigabe, gegebenenfalls gezielt TCP/UDP 53.

Zugriff auf 10.8.0.1 oder andere VPN-Peers ist in diesen Basislisten nicht enthalten. Bei Bedarf gesondert beschließen und sowohl Routing als auch Firewall ergänzen. Familie hat mit 10.0.0.0/24 Zugriff auf Heimnetz-Clients, nicht automatisch auf sämtliche anderen VPN-Peers.

3. Einmalige Umstellung auf Per-Client Firewall

Vor Änderung konsistentes Backup und aktuelle Regeln sichern; Arbeiten über LAN/Proxmox-Konsole durchführen.
Bestehende Peers, ihre VPN-IP, Gerät und Rolle erfassen. Der alte Name „FullAdmin“ unterscheidet Familie und Server Admin nicht. Unzugeordnete Peers deaktivieren.
In Admin Panel → Interface Per-Client Firewall einschalten und speichern. Sichtbarkeit und Funktion im installierten v15.4.0 prüfen. Falls das Feld fehlt oder eine Fehlermeldung erscheint, nicht auf clientseitiges Routing als Ersatz ausweichen.
Die zugeordneten Peers nacheinander bearbeiten und ausdrückliche Firewall Allowed IPs setzen. Die Fallback-Wirkung leerer Felder nicht als Rollenpolitik verwenden.
Gateway-INPUT-Zugriff für Familie und Server Admin anhand der bestätigten VPN-IP-Zuordnung ergänzen. wg-easy-Port 51821 und SSH-Port 22 für LLM Admin prüfen und sperren; GUI-Einstellungen allein beweisen diese INPUT-Beschränkung nicht.
Serverregeln und Hooks prüfen. Positive und negative Tests aus Abschnitt 7 ausführen. Erst danach Peers für die neue Rollenpolitik freigeben.

Die offizielle Dokumentation kennzeichnet Per-Client Firewall als experimentell; sie benötigt eine funktionierende iptables-Umgebung. Admin Panel

4. Neuen Geräteclient anlegen und Profil verteilen

In wg-easy anmelden und über die Funktion zum Hinzufügen eines Clients einen neuen Eintrag erstellen. Die konkrete Schaltflächenbeschriftung kann je nach Sprache abweichen.
Einen eindeutigen Gerätenamen setzen und Besitzer, Rolle, Datum und Zweck im Peer-Verzeichnis erfassen. Kurze technische Profilnamen verwenden, beispielsweise gnai-laptop; Linux-Interface-Namen sind auf 15 Zeichen begrenzt.
Den Eintrag bis zur abgeschlossenen Konfiguration deaktiviert halten. Falls die GUI das Anlegen nur aktiviert ermöglicht, direkt deaktivieren und noch kein Profil verteilen.
Zugewiesene IPv4-Adresse im VPN-Netz prüfen: Server .1, Endgeräte eindeutige freie Adressen. Adressen bestehender Peers nicht versehentlich wiederverwenden.
Client-Details öffnen. Allowed IPs, Firewall Allowed IPs und DNS gemäß Rolle setzen. Server Allowed IPs bei einem einfachen Endgerät auf dessen eigene VPN-IP /32 belassen.
Endpoint kontrollieren: vpn.ghostnet.selfhost.eu, UDP-Port 51820, DNS-Abgleich mit aktueller WAN-IP. MTU zunächst beim geprüften Default belassen. Keepalive ist im Altbestand 0; bei Bedarf für Geräte hinter NAT gezielt 25 Sekunden konfigurieren und testen.
Client-Hooks leer lassen, damit das Profil auch in Windows und NetworkManager importierbar bleibt. Server-Hooks für NAT nicht mit diesen Client-Hooks verwechseln.
Änderungen speichern. Über die Download-Funktion das aktualisierte .conf exportieren. Für die vorgesehenen Windows-/Linux-Verfahren wird die Datei verwendet.
Lokal prüfen: eigene Address, richtiger Endpoint, rollenabhängige AllowedIPs/DNS, kein unbeabsichtigtes 0.0.0.0/0 oder ::/0. PrivateKey und PresharedKey dabei nicht in Dokumente oder Nachrichten kopieren.
Profil über einen geschützten, für den Empfänger bestimmten Kanal verteilen. Das Profil ist ein Zugangsschlüssel. Keine öffentlichen Links, gemeinsamen Ordner oder offenen E-Mail-/Chat-Verteiler verwenden.
Peer kontrolliert aktivieren und mit dem Nutzer die Client-SOP und rollenabhängigen Abnahmen durchführen. Danach Status und Datum eintragen; ungeschützte Downloadkopien entfernen.

Die Unterscheidung von Routing, serverseitigen Zielrechten und Client-Hooks wird in der offiziellen Feldreferenz erläutert. Das Server-Firewallfeld ist kein Bestandteil des exportierten WireGuard-Profils.

5. Bestehenden Client ändern

Vor Änderung aktuelle Rolle und Freigaben erfassen. Bei Rollensenkung den Peer zunächst deaktivieren, Serverrechte einschränken und aktualisiertes Routingprofil verteilen; erst nach Prüfung wieder aktivieren. Änderungen an AllowedIPs, DNS, Endpoint, MTU oder Keepalive benötigen einen neuen Export und eine Aktualisierung auf dem Endgerät. Server-Firewalländerungen wirken serverseitig, werden aber ebenfalls getestet und dokumentiert.

Ein Serverneuzugang erweitert nur die Server-Admin-Profile, die diesen Host tatsächlich benötigen. Namen ändern widerruft keine Schlüssel. Änderungen an erzeugten wg0.conf-Dateien oder direkte SQLite-Manipulation gehören nicht zum Regelbetrieb.

6. Deaktivieren, löschen und Schlüssel ersetzen

Temporäre Sperre: Client über seinen Aktivierungsstatus deaktivieren. Prüfen, dass der Peer aus der aktiven Serverkonfiguration entfernt wurde und keine neue Verbindung mehr funktioniert. Reaktivieren nur nach Prüfung des Sperrgrunds.

Geräteverlust oder vermutete Schlüsseloffenlegung: Betroffenen Peer sofort deaktivieren bzw. löschen. Einen neuen Client mit neuen Schlüsseln erstellen, konfigurieren und verteilen. Ein neuer Dateiname oder erneuter Download desselben Peers ist keine Schlüsselrotation. Ein gesperrter oder gelöschter Peer wird nicht durch bloßes Entfernen der Datei auf dem Client widerrufen.

Dauerhaft entfernen: Besitzer informieren, Peer löschen, Inventar und Widerrufsliste aktualisieren, Clientprofil entfernen und alte Exporte vernichten. Keine vollständigen geheimen Profile zur Nachvollziehbarkeit archivieren. Nach Restore die Widerrufsliste anwenden.

7. Rollenprüfung und Betriebsabnahme

Test	Familie	Server Admin	LLM Admin
KI-Server-Dienst auf `.90`	erlaubt	erlaubt	erlaubt
Proxmox `10.0.0.2:8006`	erlaubt	erlaubt	gesperrt
wg-easy `10.0.0.15:51821`	erlaubt	erlaubt	gesperrt
NPM Admin `10.0.0.10:81`	erlaubt	erlaubt	gesperrt
aktiver Heimnetz-PC im DHCP-Bereich	erlaubt, soweit Hostdienst freigegeben	gesperrt	gesperrt
normales Internet	direkt	direkt	direkt

Für Sperrtests die clientseitigen AllowedIPs bewusst um ein verbotenes Ziel ergänzen oder ein kontrolliertes Testprofil mit breiterem Routing nutzen. Derselbe Zielservice muss von einem erlaubten Peer erreichbar sein. Auf dem Gateway Regeln und Zähler kontrollieren; nur fehlendes Routing oder ein ausgeschalteter Zielhost sind kein Firewallnachweis. Testprofil danach zurückbauen.

Im Status prüfen: letzter Handshake und steigende Transferwerte unter erzeugtem Verkehr. Ein eingeschalteter Client allein beweist keine Verbindung. Vor der Produktionsabnahme auch Dienstneustart, Firewall-Reload und LXC-/Host-Wiederanlauf prüfen.

8. Nachweis und Abschluss

Pro Peer Besitzer, Gerät, neue Rolle, VPN-IP, Freigaben, Aktivierungsstatus, Ausgabedatum und Abnahme erfassen. PrivateKeys, PresharedKeys, GUI-Passwörter und QR-Codes nicht aufnehmen. Neue Rollen sind erst nach erfolgreicher serverseitiger Durchsetzung freigegeben. Die vorhandenen Altpeers und ihre neuen Rollen sind noch mit dem Betreiber abzugleichen.

10 KiB Raw Blame History