100 lines
10 KiB
Markdown
100 lines
10 KiB
Markdown
# 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](GNAI-006-SEC_VPN.md), [Rollenmodell](GNAI-004-SEC_Access-Control.md), [Windows](GNAI-006-SEC_VPN_Clients_Windows11.md), [Linux](GNAI-006-SEC_VPN_Clients_Linux.md)
|
|
|
|
## Ä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:
|
|
|
|
```text
|
|
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
|
|
|
|
1. Vor Änderung konsistentes Backup und aktuelle Regeln sichern; Arbeiten über LAN/Proxmox-Konsole durchführen.
|
|
2. Bestehende Peers, ihre VPN-IP, Gerät und Rolle erfassen. Der alte Name „FullAdmin“ unterscheidet Familie und Server Admin nicht. Unzugeordnete Peers deaktivieren.
|
|
3. 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.
|
|
4. Die zugeordneten Peers nacheinander bearbeiten und ausdrückliche **Firewall Allowed IPs** setzen. Die Fallback-Wirkung leerer Felder nicht als Rollenpolitik verwenden.
|
|
5. 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.
|
|
6. 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](https://wg-easy.github.io/wg-easy/latest/guides/admin/)
|
|
|
|
## 4. Neuen Geräteclient anlegen und Profil verteilen
|
|
|
|
1. 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.
|
|
2. 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.
|
|
3. Den Eintrag bis zur abgeschlossenen Konfiguration deaktiviert halten. Falls die GUI das Anlegen nur aktiviert ermöglicht, direkt deaktivieren und noch kein Profil verteilen.
|
|
4. Zugewiesene IPv4-Adresse im VPN-Netz prüfen: Server `.1`, Endgeräte eindeutige freie Adressen. Adressen bestehender Peers nicht versehentlich wiederverwenden.
|
|
5. 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.
|
|
6. 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.
|
|
7. 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.
|
|
8. Änderungen speichern. Über die Download-Funktion das aktualisierte `.conf` exportieren. Für die vorgesehenen Windows-/Linux-Verfahren wird die Datei verwendet.
|
|
9. 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.
|
|
10. 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.
|
|
11. 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](https://wg-easy.github.io/wg-easy/latest/guides/clients/) 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.
|