Add: DNS über Pi-Hole LXC. Härtung von CT-105 Wireguard.

2026-10-05 17:45:38 +02:00
parent 0758813e63
commit b40f726d22
26 changed files with 1014 additions and 158 deletions
@@ -1,6 +1,6 @@
 # Ghostnet.AI – Dokumentationsindex und Projektstand

-**Stand:** 2026-09-22
+**Stand:** 2026-10-05

 **Status:** Plattformgrundlage vorhanden; Sicherheitsabschluss und LLM-Serving offen

@@ -16,45 +16,52 @@ jeweiligen Fachdokumenten. Die priorisierte weitere Umsetzung beschreibt der
 | Dokument | Verbindlicher Inhalt |
 | --- | --- |
 | [GNAI-001](GNAI-001-PLAN_Project-Roadmap.md) | priorisierte nächste Schritte, Entscheidungstore und Abnahmekriterien |
+| [GNAI-013](GNAI-013-PLAN_Security-Closure-and-Repository-Restructure.md) | aktive Checkliste für Sicherheitsabschluss, Repository-Struktur und Übergang zum LLM-Stack |

 ### Plattform und Sicherheit

 | Dokument | Verbindlicher Inhalt |
 | --- | --- |
 | [Bereichsindex](platform/README.md) | Einstieg in Host-, Zugriffs-, Reverse-Proxy- und VPN-Dokumentation |
-| [Ghostnet.AI-Host](platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md) | GNAI-002 Hardware und Debian-Basis des KI-Servers `10.0.0.90` |
-| [Ghostnet.AI-Zugänge](platform/ghostnet-ai/GNAI-003-INFRA_Users.md) | GNAI-003 Benutzer, Hostnetz, Resolver und SSH des KI-Servers |
+| [LLM-Server](platform/llm-server/README.md) | Geräteindex für Host, AI-Serving und Encoding auf `10.0.0.90` |
+| [Ghostnet.AI-Host](platform/llm-server/host/GNAI-002-INFRA_BaseSystem.md) | GNAI-002 Hardware und Debian-Basis des KI-Servers `10.0.0.90` |
+| [Ghostnet.AI-Zugänge](platform/llm-server/host/GNAI-003-INFRA_Users.md) | GNAI-003 Benutzer, Hostnetz, Resolver und SSH des KI-Servers |
 | [GNAI-005](platform/GNAI-005-SEC_Access-Control.md) | Rollen- und Zugriffsziel |
-| [Proxmox-LXC-SSH](platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md) | GNAI-011 gemeinsame SSH-Sicherheitsarchitektur der LXCs; Hypervisor ausgenommen |
-| [CT 103 / GNAI-006](platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md) | NPM, Fail2Ban und Keycloak-Adminpfad |
-| [CT 105 / GNAI-007](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall |
-| [VPN-Client-Verwaltung](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md) | Ausgabe, Änderung und Widerruf von Geräteprofilen |
-| [Windows 11](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Windows11.md) / [Linux](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Linux.md) | Client-SOPs |
-| [VPN-Implementation-Log](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Implementation-Log.md) | historische Umsetzung und datierte Evidenz |
+| [Proxmox-Server](platform/proxmox-server/README.md) | Geräteindex für den Hypervisor-Kontext und seine LXCs |
+| [Proxmox-LXC-SSH](platform/proxmox-server/GNAI-011-SEC_LXC-SSH-Architecture.md) | GNAI-011 gemeinsame SSH-Sicherheitsarchitektur der LXCs; Hypervisor ausgenommen |
+| [GNAI-012](platform/proxmox-server/lxc/ct-100-dns/GNAI-012-PLAN_Pi-hole-DNS-Handoff.md) | implementierter Pi-hole-LXC, FRITZ!Box-DNS, Split-DNS, Abnahme und Rückfallstand |
+| [CT 103 / GNAI-006](platform/proxmox-server/lxc/ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md) | NPM, Fail2Ban und Keycloak-Adminpfad |
+| [CT 105 / GNAI-007](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall |
+| [VPN-Client-Verwaltung](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Client-Management.md) | Ausgabe, Änderung und Widerruf von Geräteprofilen |
+| [Windows 11](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Clients_Windows11.md) / [Linux](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Clients_Linux.md) | Client-SOPs |
+| [VPN-Implementation-Log](platform/proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Implementation-Log.md) | historische Umsetzung und datierte Evidenz |

 ### KI und Deployment

 | Dokument | Verbindlicher Inhalt |
 | --- | --- |
-| [Bereichsindex](ai/README.md) | Einstieg in die KI-Dokumentation |
-| [GNAI-004](ai/GNAI-004-INFRA_Architecture.md) | Zielarchitektur und Vertrauensgrenzen |
-| [GNAI-008](ai/GNAI-008-PLAN_Ansible-Deployment.md) | detaillierter Ansible-/Gitea-Planungsstand und Implementierungshistorie |
-| [GNAI-009](ai/GNAI-009-PLAN_Llama-Model-Evaluation.md) | reproduzierbarer Modellvergleich |
-| [GNAI-010](ai/GNAI-010-TECH_Llama-Serving.md) | technische Sollkonfiguration des Testing-Servings |
+| [Bereichsindex](platform/llm-server/ai/README.md) | Einstieg in die KI-Dokumentation |
+| [GNAI-004](platform/llm-server/ai/GNAI-004-INFRA_Architecture.md) | Zielarchitektur und Vertrauensgrenzen |
+| [GNAI-008](platform/llm-server/ai/GNAI-008-PLAN_Ansible-Deployment.md) | detaillierter Ansible-/Gitea-Planungsstand und Implementierungshistorie |
+| [GNAI-009](platform/llm-server/ai/GNAI-009-PLAN_Llama-Model-Evaluation.md) | reproduzierbarer Modellvergleich |
+| [GNAI-010](platform/llm-server/ai/GNAI-010-TECH_Llama-Serving.md) | technische Sollkonfiguration des Testing-Servings |
 | [Ansible-Control-Projekt](../ansible/README.md) | ausführbare Playbooks, Rollen und belegter technischer Stand |

 ### Video-Encoding

 | Dokument | Verbindlicher Inhalt |
 | --- | --- |
-| [GNENC-000](video-encoding/GNENC-000-DOC_Index.md) | Bereichsstatus und offene Festlegungen |
-| [GNENC-001](video-encoding/GNENC-001-PLAN_Architecture.md) | vorläufige Architektur des CPU-Encoding-Workloads |
+| [GNENC-000](platform/llm-server/encoding/GNENC-000-DOC_Index.md) | Bereichsstatus und offene Festlegungen |
+| [GNENC-001](platform/llm-server/encoding/GNENC-001-PLAN_Architecture.md) | vorläufige Architektur des CPU-Encoding-Workloads |

 Die Dokumente wurden am 21.09.2026 neu geordnet: Die Roadmap belegt
 `GNAI-001`; die zuvor bestehenden Dokumente `GNAI-001` bis `GNAI-009` wurden
 unter Beibehaltung ihrer Reihenfolge zu `GNAI-002` bis `GNAI-010`.
 Am 22.09.2026 wurden KI-Host und Proxmox-LXCs in getrennte Unterverzeichnisse
 überführt; GNAI-011 beschreibt die gemeinsame SSH-Architektur der LXCs.
+Am 05.10.2026 wurde die Dokumentation geräteorientiert neu geordnet:
+`platform/proxmox-server/` bildet den Proxmox-Kontext und seine LXCs ab,
+`platform/llm-server/` den physischen KI-Server mit AI und Encoding.

 ## 2. Belegter Stand

@@ -65,7 +72,8 @@ Am 22.09.2026 wurden KI-Host und Proxmox-LXCs in getrennte Unterverzeichnisse
 | LLM-Serving | zwei unveränderlich definierte Modellkandidaten und technische Sollkonfiguration | Modelle, Quadlets, dauerhaftes Podman-Netz und Health Checks |
 | Deployment | lokales Ansible-Control-Projekt und idempotente Hostrollen | statische CI, Runner, geschützte Freigaben, Production-Inventar und automatisierter Rollback |
 | VPN | wg-easy v15.4.0 und Regelwerke am 22.09.2026 live geprüft; Schlüsseldateien auf `0600` gehärtet | serverseitige Rollenrechte, negative Tests, IPv6-/Restart-/Restore-Abnahme |
-| Reverse Proxy | CT-103-Lesekonto, persönlicher Schlüsselzugang mit passwortgeschütztem sudo sowie SSH- und LAN/WireGuard-Netzbaseline einschließlich Reboot abgenommen; Root-/Passwortzugriff abgelehnt; NPM 2.15.1 und Fail2Ban aktiv; sensible NPM-Dateirechte gehärtet | wirksame Jails/Bans und deren Wiederanlauf; Keycloak-Adminpfad weiterhin offen |
+| DNS / Pi-hole | CT 100 unter `10.0.0.14` mit digest-gepinntem Pi-hole 2026.09.0 als Podman-Quadlet; SSH/nftables, UDP/TCP-DNS, Split-DNS, Blocking/Allowlist, FRITZ!Box-Cutover, LXC-Reboot und Stop-Mode-Backup am 01.10.2026 abgenommen | vollständige App-/OIDC-Regression, praktischer FRITZ!Box-Rollback, mobile DuckDuckGo-/IPv6-Strategie, WireGuard-Profile und hostunabhängiger Restore-Test |
+| Reverse Proxy | CT-103-Lesekonto, persönlicher Schlüsselzugang mit passwortgeschütztem sudo sowie SSH- und LAN/WireGuard-Netzbaseline einschließlich Reboot abgenommen; lokales Stop-Mode-Backup technisch geprüft; NPM 2.15.1 und Fail2Ban aktiv; sensible NPM-Dateirechte gehärtet | wirksame Jails/Bans und deren Wiederanlauf; internen Keycloak-Adminweg bestätigen und öffentlichen Adminpfad sperren; hostunabhängige Backupkopie/Restore-Test |
 | Encoding | Konto, Pfade und eigener rootless Store | Workload, Zeitsteuerung, Ressourcenlimits und Lasttest |

 Ein Zielbild, eine Betreiberangabe oder ein erfolgreicher Teiltest gilt nicht als
@@ -8,7 +8,7 @@

 **Status:** Arbeitsgrundlage; Entscheidungstore vor externer Veröffentlichung offen

-**Referenzen:** [Projektstand](GNAI-000-DOC_Index.md), [Zielarchitektur](ai/GNAI-004-INFRA_Architecture.md), [Ansible-Plan](ai/GNAI-008-PLAN_Ansible-Deployment.md), [Modellbewertung](ai/GNAI-009-PLAN_Llama-Model-Evaluation.md), [`llama.cpp`-Sollkonfiguration](ai/GNAI-010-TECH_Llama-Serving.md)
+**Referenzen:** [Projektstand](GNAI-000-DOC_Index.md), [Zielarchitektur](platform/llm-server/ai/GNAI-004-INFRA_Architecture.md), [Ansible-Plan](platform/llm-server/ai/GNAI-008-PLAN_Ansible-Deployment.md), [Modellbewertung](platform/llm-server/ai/GNAI-009-PLAN_Llama-Model-Evaluation.md), [`llama.cpp`-Sollkonfiguration](platform/llm-server/ai/GNAI-010-TECH_Llama-Serving.md)

 ## 1. Ziel und Planungsprinzip

@@ -66,12 +66,20 @@ fehlende VPN-Rollenisolierung sind live bestätigt. Die Schlüsseldateien des
 WireGuard-Gateways wurden auf `0600` gehärtet. Auf CT 103 sind persönlicher und
 lesender Schlüsselzugang, passwortgeschütztes sudo, SSH-Härtung,
 LAN/WireGuard-Netzbaseline und der Wiederanlauf nach einem kontrollierten
-Neustart abgenommen. Für die nächsten wirksamen Änderungen fehlen weiterhin
-(1) ein aktueller Rückfallstand vor der Keycloak-Änderung sowie (2) die
-verbindliche Rolle der beiden vorhandenen VPN-Peers. Die technische Reihenfolge
-ist deshalb: Backup sichern, öffentlichen `/admin`-Pfad sperren und
-regressionsprüfen, Peers zuordnen und Gateway-Regeln umsetzen, anschließend die
-noch offenen Fail2Ban-Funktionstests abschließen.
+Neustart abgenommen. Ein konsistentes, lokal auf Proxmox gespeichertes
+Stop-Mode-Backup wurde am 24.09.2026 erstellt, technisch geprüft und der
+Dienstwiederanlauf abgenommen; hostunabhängige Kopie und Restore-Test bleiben
+offen. Der DNS-Vorläufer GNAI-012 wurde am 01.10.2026 umgesetzt: CT 100 unter
+`10.0.0.14` stellt Pi-hole und `auth-admin.ghostnet.selfhost.eu -> 10.0.0.10`
+bereit; FRITZ!Box-Cutover, LAN-Testclient, Restart/Reboot und lokales
+Stop-Mode-Backup sind abgenommen. Mobile DuckDuckGo-/IPv6-Umgehung,
+WireGuard-DNS pro Rolle, vollständige App-/OIDC-Regression und praktischer
+FRITZ!Box-Rollback bleiben ausdrücklich offen. Für die nächsten wirksamen
+Änderungen fehlt weiterhin die verbindliche Rolle der beiden vorhandenen
+VPN-Peers. Die technische Reihenfolge ist nun: internen NPM-Host und Keycloak
+`hostname-admin` einrichten und testen, öffentlichen `/admin`-Pfad sperren und
+regressionsprüfen, danach Peers zuordnen und Gateway-Regeln umsetzen sowie die
+offenen Fail2Ban-Funktionstests abschließen.

 **Fertig, wenn:** Die vier priorisierten Sicherheitsbefunde im zentralen Index
 als bestanden oder mit ausdrücklich akzeptiertem Restrisiko dokumentiert sind.
@@ -0,0 +1,192 @@
+# Sicherheitsabschluss und Repository-Neustrukturierung
+
+**Dokumenten-ID:** GNAI-013-PLAN  
+**Stand:** 2026-10-05  
+**Status:** Aktiver Arbeitsplan
+
+## 1. Ziel
+
+Dieser Plan führt die noch offenen Zugriffs- und Sicherheitsarbeiten bis zum
+Start des internen LLM-Vertical-Slice. Er ist zugleich die laufende Checkliste:
+Erledigte Punkte werden erst nach einem technischen Nachweis abgehakt.
+
+## 2. Zielstruktur der Dokumentation
+
+```text
+docs/
+├── GNAI-000-DOC_Index.md
+├── GNAI-001-PLAN_Project-Roadmap.md
+├── GNAI-013-PLAN_Security-Closure-and-Repository-Restructure.md
+└── platform/
+    ├── GNAI-005-SEC_Access-Control.md
+    ├── proxmox-server/
+    │   ├── GNAI-011-SEC_LXC-SSH-Architecture.md
+    │   └── lxc/
+    │       ├── ct-100-dns/GNAI-012-PLAN_Pi-hole-DNS-Handoff.md
+    │       ├── ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md
+    │       └── ct-105-wireguard/GNAI-007-SEC_*.md
+    └── llm-server/
+        ├── host/GNAI-002-INFRA_BaseSystem.md
+        ├── host/GNAI-003-INFRA_Users.md
+        ├── ai/GNAI-004-INFRA_Architecture.md
+        ├── ai/GNAI-008-PLAN_Ansible-Deployment.md
+        ├── ai/GNAI-009-PLAN_Llama-Model-Evaluation.md
+        ├── ai/GNAI-010-TECH_Llama-Serving.md
+        └── encoding/GNENC-*.md
+```
+
+## 3. Arbeitscheckliste
+
+### A. Dokumentation und lokale Geheimnisse
+
+- [x] Projekt- und Live-Zustand von DNS, Reverse Proxy und WireGuard lesend
+  inventarisiert.
+- [x] Dokumentation in die geräteorientierte Zielstruktur verschieben.
+- [x] Alle relativen lokalen Markdown-Links nach der Verschiebung validieren.
+- [x] Zentrale Indizes und Architekturübersicht an die neue Struktur anpassen.
+- [x] WireGuard-Profile aus dem Repository-Baum in einen privaten lokalen
+  Konfigurationspfad verschieben; Verzeichnis `0700`, Dateien `0600`.
+- [x] Sicherstellen, dass keine WireGuard-PrivateKeys oder PresharedKeys in
+  versionierten Dateien oder der Git-Historie liegen.
+- [x] Bereits offengelegte Altpeers über wg-easy rotieren oder widerrufen.
+
+### B. WireGuard-Arbeitsplatz und Gateway
+
+- [x] NetworkManager-Unterstützung auf dem CachyOS-Arbeitsplatz prüfen;
+  `wireguard-tools` ist für die verwendete native NetworkManager-Methode nicht
+  erforderlich und bleibt bewusst uninstalliert.
+- [x] Laptop-Profil geschützt in NetworkManager importieren und Autoconnect
+  zunächst deaktiviert lassen.
+- [x] Verbindung aus einem fremden Netz positiv testen: Handshake, erlaubtes
+  Ziel, Split-Tunnel und DNS.
+- [x] Alten Laptopzugang zunächst Server Admin zuordnen und anschließend durch
+  den neuen Peer `ghost-laptop` mit nativer nftables-Durchsetzung ersetzen.
+- [x] Testpeer `Android-LLMAdmin` widerrufen und aus wg-easy entfernen.
+- [x] Vor Gateway-Änderungen ein aktuelles konsistentes Backup von CT 105
+  erstellen.
+- [x] Native nftables-Zielpolicy und Gateway-INPUT-Rechte umsetzen; parallele
+  wg-easy-`iptables-legacy`-Hooks und Laufzeitregeln entfernen und einen
+  wg-easy-Neustart ohne Wiederkehr der Regeln prüfen.
+- [x] Positive und negative Rollentests mit absichtlich erweitertem
+  Client-Routing durchführen.
+- [x] CT 105 härten: SSH-Forwarding abschalten, Patchverfahren festlegen,
+  defekte `wtmpdb-rotate.timer`-Referenz bereinigen und Wiederanlauf testen.
+
+### C. Interner Keycloak-Adminzugang
+
+- [ ] Aktuellen Keycloak-Stand und wirksame Hostname-/Proxy-Konfiguration
+  sichern und inventarisieren.
+- [ ] Internen NPM-vHost für `auth-admin.ghostnet.selfhost.eu` mit gültigem TLS
+  und ohne öffentliche Freigabe einrichten.
+- [ ] Keycloak `hostname-admin` passend zur installierten Version setzen.
+- [ ] Internen Adminlogin über LAN und berechtigte VPN-Rolle positiv testen.
+- [ ] Öffentliche `/admin`-GUI und Admin-API über HTTP und HTTPS sperren.
+- [ ] Externe Negativtests sowie Vaultwarden-/OIDC-Regression durchführen.
+
+### D. Reverse Proxy, Fail2Ban und Recovery
+
+- [ ] Fail2Ban-Konfiguration, aktive Jails und Imagezustand prüfen.
+- [ ] Kontrollierten Ban/Unban für HTTP und HTTPS nachweisen.
+- [ ] Dienst- und LXC-Wiederanlauf einschließlich Jails und Regeln testen.
+- [ ] Praktischen FRITZ!Box-DNS-Rollback auf einem Testclient durchführen.
+- [ ] Hostunabhängige Backupkopien und mindestens einen Restore-Test planen
+  beziehungsweise abnehmen.
+
+### E. Übergang zum LLM-Stack
+
+- [ ] KI-Server kontrolliert einschalten und Resolver auf den beschlossenen
+  Pi-hole-Pfad abstimmen.
+- [ ] Lokale Ansible-`.venv` wegen des veralteten Repository-Pfads neu
+  erstellen und alle Syntaxprüfungen regulär ausführen.
+- [ ] Lesenden Preflight sowie Host-/ROCm-Verifikation wiederholen.
+- [ ] Internes, nicht öffentliches `llama.cpp`-Testing-Vertical-Slice nach
+  GNAI-010 implementieren und bei 64k abnehmen.
+
+## 4. Arbeitsnachweise
+
+### 05.10.2026 – Struktur, Geheimnisse und lokaler VPN-Client
+
+- Dokumente geräteorientiert verschoben; lokaler Linkvalidator meldet
+  `broken_local_links=0`, alte Pfadverweise wurden nicht mehr gefunden.
+- Profile liegen in `~/.config/ghostnet/wireguard/`; beide Dateinamen sind als
+  Linux-Interface-Namen gültig. Elternverzeichnisse sind `0700`, Dateien `0600`.
+- Aktueller Arbeitsbaum und vollständige Git-Historie enthalten keine
+  WireGuard-Schlüsselzuweisung im Format eines Base64-Schlüssels. Zwei Treffer
+  in einer alten Anleitung sind keine Schlüsselwerte, sondern erklärender
+  Beispieltext beziehungsweise Satzzeichen.
+- NetworkManager 1.58.1 hat `gnai-laptop` nativ importiert. Autoconnect ist aus,
+  die Verbindung ist auf `ghost` beschränkt und wieder inaktiv; im Heimnetz ist
+  keine WireGuard-Route verblieben.
+- `wireguard-tools` ist nicht installiert und für die gewählte native
+  NetworkManager-Methode nicht erforderlich. Es wird nur bei späterem Bedarf
+  an `wg`, `wg-quick` oder entsprechender CLI-Diagnose ergänzt.
+- Betreiberentscheidung: Laptop = Server Admin; der reine Android-Testpeer wird
+  widerrufen.
+- Vor dem Peer-Widerruf wurde ein stop-konsistentes, rootgeschütztes
+  wg-easy-Anwendungsbackup erstellt; Archiv- und Datenbankintegrität sowie der
+  Dienstwiederanlauf wurden bestätigt. Ein vollständiges Proxmox-LXC-Backup ist
+  dadurch nicht ersetzt.
+- Das lokale Android-Profil ist entfernt. Die endgültige serverseitige Löschung
+  erfolgte über eine authentifizierte wg-easy-Administratorsitzung. Danach
+  enthielten Datenbank und aktives `wg0` jeweils genau den verbleibenden
+  Laptop-Peer; SQLite-Integritätsprüfung und Dienststatus waren fehlerfrei.
+- Der Altpeer routet noch das gesamte LAN und verwendet `10.0.0.1` als DNS. Der
+  neue Peer `gnai-ghost-laptop` mit `10.8.0.3` ersetzt ihn mit neuen Schlüsseln;
+  seine explizite Client-Routenliste und der Profilimport stehen noch aus. Für
+  Server Admin wurden einzelne dokumentierte Server-`/32` einschließlich
+  Pi-hole `10.0.0.14` beschlossen; Pi-hole ist zugleich der DNS-Server für
+  Split-DNS. Die wg-easy-Per-Client-Firewall bleibt bewusst aus.
+- Native nftables-Sets und natives MASQUERADE sind mit den alten und neuen
+  Laptop-Peer-IPs aktiv. Syntaxprüfung, gesicherter Rollout, neue
+  SSH-Verbindung, Dienste, `wg0`, Netavark-Erhalt und Persistenzdatei wurden
+  geprüft. Die wg-easy-Legacy-Hooks und ihre vier Laufzeitregeln wurden nach
+  gesondertem Backup entfernt; nach kontrolliertem wg-easy-Neustart blieben
+  Legacy-Regelzahl null, native Policy, NAT, Netavark, zwei Peers und GUI aktiv.
+- Das neue Profil `ghost-laptop.conf` wurde mit `.3/32`, Pi-hole-DNS und den elf
+  Serverzielen validiert, geschützt nach `~/.config/ghostnet/wireguard/`
+  verschoben und in NetworkManager manuell/inaktiv für `ghost` importiert. Der
+  alte lokale Eintrag und die alte Profildatei sind entfernt.
+- Fremdnetzabnahme über Smartphone-Hotspot `10.62.63.0/24`: aktueller
+  Handshake und Transfer, Pi-hole-/Split-DNS, Proxmox, Keycloak, NPM, Pi-hole,
+  wg-easy und Gateway-SSH bestanden. Die öffentliche IPv4 blieb vor, während
+  und nach Aktivierung gleich. Mit absichtlich um `10.0.0.1/32` erweitertem
+  Testprofil blieb Proxmox erreichbar, während die aktive FRITZ!Box per ICMP
+  und HTTP gesperrt war; nftables-Zähler belegten vier erlaubte neue
+  Verbindungen und drei Drops. Testverbindung und temporäres Profil wurden
+  anschließend entfernt.
+- Nach bestandener Abnahme wurde `Laptop-FullAdmin` `.2` über wg-easy gelöscht.
+  Datenbank und `wg0` enthalten nur noch `ghost-laptop` `.3`; `.2` wurde auch
+  aus der persistenten nftables-Rollenmenge entfernt. DNS, Proxmox und wg-easy
+  funktionierten danach weiter, Legacy-Regelzahl blieb null und das VPN wurde
+  kontrolliert getrennt.
+- Der Betreiber erstellte anschließend ein vollständiges Proxmox-Backup von
+  CT 105 im Modus `Stop`. Der dadurch ausgelöste Wiederanlauf um 17:19 Uhr
+  wurde live abgenommen: SSH, nftables und wg-easy waren aktiv, die persistente
+  nftables-Datei bestand die Syntaxprüfung, Rollen- und Zielsets sowie natives
+  NAT waren vorhanden, `iptables-legacy` enthielt keine wg-easy-Regeln, genau
+  ein WireGuard-Peer war aktiv, SQLite meldete `integrity_check=ok` und die
+  lokale wg-easy-GUI antwortete mit HTTP 302.
+- Die SSH-Baseline von CT 105 deaktiviert nun TCP-, Agent-, StreamLocal-,
+  X11- und Tunnel-Forwarding. Ein Remote-Forwarding-Negativtest wurde vom
+  Server abgelehnt. Der verwaiste `wtmpdb-rotate.timer`-Symlink wurde entfernt
+  und ein kontrollierter LXC-Neustart um 17:38 Uhr bestätigte die Persistenz
+  der SSH-, Firewall- und wg-easy-Konfiguration ohne fehlgeschlagene Units.
+  Systemupdates erfolgen künftig kontrolliert manuell nach Simulation und mit
+  dokumentiertem Health-Check; unbeaufsichtigte Upgrades bleiben deaktiviert.
+
+## 5. Aktuell bestätigte Blocker
+
+- Der öffentliche Keycloak-Adminpfad ist noch erreichbar.
+- Die native WireGuard-Rollenpolicy ist aktiv und die Legacy-Regeln sind
+  bereinigt; Fremdnetz-, Positiv-, Negativ- und Wiederanlauftests sind
+  abgeschlossen.
+- Fail2Ban läuft, seine aktuelle funktionale Ban-Wirkung ist aber nicht
+  abgenommen.
+- Der KI-Server ist bewusst ausgeschaltet und wird für die Punkte A bis D
+  nicht benötigt.
+
+## 6. Pflege
+
+Nach jedem Arbeitsschritt werden hier Status und Nachweis aktualisiert. Ein
+Punkt gilt nicht allein aufgrund einer gespeicherten Konfiguration als
+erledigt, sondern erst nach dem zugehörigen Positiv- oder Negativtest.
@@ -3,7 +3,7 @@
 **Dokumenten-ID:** GNAI-005-SEC  
 **Titel:** Homelab / LLM-Infrastruktur – Sicherheits-, Authentifizierungs- und Zugriffskonzept  
 **Status:** Verbindliches Zielmodell; technische Durchsetzung teilweise offen  
-**Vorgänger / Referenzen:** [Architektur](../ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md), [Gateway](proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md), [GUI-SOP](proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md), [Reverse Proxy](proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md)
+**Vorgänger / Referenzen:** [Architektur](llm-server/ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](proxmox-server/GNAI-011-SEC_LXC-SSH-Architecture.md), [Gateway](proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN.md), [GUI-SOP](proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN_Client-Management.md), [Reverse Proxy](proxmox-server/lxc/ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md)

 ---

@@ -43,7 +43,7 @@ Familienmitglieder (Betreiber und Bruder) dürfen das gesamte Heimnetz `10.0.0.0

 ### 2.2 Server Admin

-Server Admins dürfen Proxmox `10.0.0.2`, aktuelle Service-LXCs und KI-Server `10.0.0.90` erreichen. NPM und wg-easy zählen zu den Service-LXCs. Allgemeine Heimnetz-PCs/Clients gehören nicht zu dieser Freigabe. Serverseitig eine Liste bestätigter Hosts pflegen; der statische Adressbereich bis `.99` ist keine pauschale Zugriffsfreigabe.
+Server Admins dürfen Proxmox `10.0.0.2`, aktuelle Service-LXCs und KI-Server `10.0.0.90` erreichen. Pi-hole, NPM und wg-easy zählen zu den Service-LXCs. Allgemeine Heimnetz-PCs/Clients gehören nicht zu dieser Freigabe. Serverseitig eine Liste bestätigter Hosts pflegen; der statische Adressbereich bis `.99` ist keine pauschale Zugriffsfreigabe. Für internes Split-DNS verwenden Server-Admin-Profile Pi-hole `10.0.0.14`.

 ### 2.3 LLM Admin

@@ -94,7 +94,7 @@ Ein normaler LLM User erhält **keinen WireGuard-Peer**, sofern für einen konkr
 | OpenWebUI / weitere Webanwendungen | nach Anwendungsrechten | nach Anwendungsrechten | nach Anwendungsrechten | Soll: HTTPS und geeignete Anmeldung |
 | llama.cpp / Datenbanken | nur nach Backend-/Dienstpolicy | nur nach Backend-/Dienstpolicy | nur KI-Server-bezogen nach Bedarf | nicht direkt öffentlich |

-Das ist die Sollmatrix. Per-Client Firewall ist aktuell deaktiviert; Keycloak-Admin-Exposure ist durch einen externen Betreiber-Test bestätigt. Keine Sollfreigabe wird damit als bereits sicher implementiert behauptet.
+Das ist die Sollmatrix. Die wg-easy-Per-Client-Firewall bleibt deaktiviert; eine native nftables-Rollenpolicy ist aktiv, aber noch nicht vollständig bereinigt oder abgenommen. Keycloak-Admin-Exposure ist durch einen externen Betreiber-Test bestätigt. Keine Sollfreigabe wird damit als bereits sicher implementiert behauptet.

 ---

@@ -170,9 +170,9 @@ zusätzliche per-Workstation- oder per-Peer-SSH-Allowlist.

 ## 5. Netzwerk-Autorisierung

-Familie erhält ausdrücklich Heimnetz-Vollzugriff. Server Admins und LLM Admins erhalten nur die beschlossenen Zielhosts. Die **serverseitigen Firewall Allowed IPs** in wg-easy sollen diese Rechte durchsetzen, während clientseitige Allowed IPs nur Routing festlegen. Ein Benutzer darf die Serverbeschränkung nicht durch Änderungen an seinem lokalen Profil umgehen können. Für Gateway-eigene Dienste wird die INPUT-Chain separat geprüft und anhand zugeordneter VPN-Quellen begrenzt.
+Familie erhält ausdrücklich Heimnetz-Vollzugriff. Server Admins und LLM Admins erhalten nur die beschlossenen Zielhosts. Native nftables-Sets auf CT 105 setzen diese Rechte anhand von Peer-IP und Zielhost durch, während clientseitige Allowed IPs nur Routing festlegen. Ein Benutzer darf die Serverbeschränkung nicht durch Änderungen an seinem lokalen Profil umgehen können. Für Gateway-eigene Dienste wird die INPUT-Chain separat anhand zugeordneter VPN-Quellen begrenzt.

-Aktuell fehlt die Per-Client-Durchsetzung. Negative Tests müssen mit absichtlich erweitertem Client-Routing und aktivem Zielservice stattfinden. Normale LLM-Anwendungsnutzer erhalten keinen Managementpeer. Geräteprofile werden durch Administratoren erstellt und geschützt verteilt. Die GUI ist für Familie und Server Admins vorgesehen.
+Die native Rollenpolicy wurde am 05.10.2026 zunächst für den alten und neuen Server-Admin-Laptop-Peer geladen. Die parallelen wg-easy-`iptables-legacy`-Hooks und Laufzeitregeln wurden entfernt und blieben nach einem kontrollierten wg-easy-Neustart fort. Positive und negative Abnahme stehen noch aus. Negative Tests müssen mit absichtlich erweitertem Client-Routing und aktivem Zielservice stattfinden. Normale LLM-Anwendungsnutzer erhalten keinen Managementpeer. Geräteprofile werden durch Administratoren erstellt und geschützt verteilt. Die GUI ist für Familie und Server Admins vorgesehen.

 MASQUERADE wird mangels Rückroute verwendet; es verbirgt gegenüber LAN-Diensten die ursprüngliche Peer-IP. Zielkontrolle muss daher am VPN-Gateway vor NAT erfolgen. Lokale LAN-Quellen lassen sich nicht allein durch die VPN-Rolle gruppengenau zuordnen; hierfür sind zusätzliche Regeln/Identitäten nötig.

@@ -222,7 +222,7 @@ Nicht vorgesehen ist ein pauschales Blocking aller HTTP-Fehlercodes.

 Insbesondere soll ein allgemeiner `404` nicht automatisch als Angriff gewertet werden.

-Die vorhandenen NPM-Jails sind in [GNAI-006](proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md) dokumentiert. Ihre Funktion nach dem Image-Pin sowie Neustart und Wiederanlauf müssen noch abgenommen werden.
+Die vorhandenen NPM-Jails sind in [GNAI-006](proxmox-server/lxc/ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md) dokumentiert. Ihre Funktion nach dem Image-Pin sowie Neustart und Wiederanlauf müssen noch abgenommen werden.

 ---

@@ -311,4 +311,4 @@ Das Sicherheitsmodell basiert damit nicht auf einem einzelnen „Security-Progra

 ## 11. Umsetzungsnachweise

-Dieses Dokument definiert die Zugriffsziele. Der [Dokumentationsindex](../GNAI-000-DOC_Index.md) bündelt den aktuellen Projektstand. Konkrete Gateway-Regeln und Rollentests stehen in [GNAI-007](proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md), der Keycloak-Adminpfad und Fail2Ban in [GNAI-006](proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md). Offene Zielrechte gelten bis zu ihrer technischen Abnahme nicht als durchgesetzt.
+Dieses Dokument definiert die Zugriffsziele. Der [Dokumentationsindex](../GNAI-000-DOC_Index.md) bündelt den aktuellen Projektstand. Konkrete Gateway-Regeln und Rollentests stehen in [GNAI-007](proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN.md), der Keycloak-Adminpfad und Fail2Ban in [GNAI-006](proxmox-server/lxc/ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md). Offene Zielrechte gelten bis zu ihrer technischen Abnahme nicht als durchgesetzt.
@@ -1,20 +1,16 @@
-# Plattform- und Hostdokumentation
+# Plattform- und Gerätedokumentation

-Dieser Bereich trennt den physischen KI-Host von den auf Proxmox betriebenen
-LXCs. Übergreifende Rollen und Zugriffsziele bleiben auf dieser Ebene;
-host- beziehungsweise LXC-spezifische Betriebsdokumente liegen in eigenen
-Unterverzeichnissen. Die SSH-Konfiguration des Proxmox-Hypervisors selbst ist
-nicht Teil der LXC-Dokumentation.
+Dieser Bereich bildet die beiden physischen Geräte der Infrastruktur ab: den
+Proxmox-Server mit seinen LXCs und den separaten LLM-Server mit AI-Serving und
+CPU-Encoding. Übergreifende Rollen und Zugriffsziele bleiben auf dieser Ebene.
+Die SSH-Konfiguration des Proxmox-Hypervisors selbst ist weiterhin nicht Teil
+der LXC-Dokumentation.

 | Dokument | Inhalt |
 | --- | --- |
-| [Ghostnet.AI-Host](ghostnet-ai/GNAI-002-INFRA_BaseSystem.md) | GNAI-002 Hardware und Debian-Basisinstallation des KI-Servers `10.0.0.90` |
-| [Ghostnet.AI-Zugänge](ghostnet-ai/GNAI-003-INFRA_Users.md) | GNAI-003 Hostbenutzer, Netzwerk, Resolver und SSH des KI-Servers |
+| [LLM-Server](llm-server/README.md) | physischer Server `10.0.0.90`, Hostbasis, AI-Serving und Encoding |
+| [Proxmox-Server](proxmox-server/README.md) | Proxmox-Kontext und LXC-Dienste einschließlich DNS, Reverse Proxy und WireGuard |
 | [GNAI-005](GNAI-005-SEC_Access-Control.md) | Rollen- und Zugriffsziel für die Infrastruktur |
-| [Proxmox-LXCs](proxmox-lxc/README.md) | gemeinsamer Einstieg für CTs auf Proxmox `10.0.0.2` |
-| [GNAI-011](proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md) | gemeinsame SSH-Sicherheitsarchitektur der LXCs |
-| [CT 103 / GNAI-006](proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md) | Reverse Proxy, Keycloak-Adminpfad und Fail2Ban |
-| [CT 105 / GNAI-007](proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall |

 Der übergreifende Projektstand steht im
 [zentralen Dokumentationsindex](../GNAI-000-DOC_Index.md).
@@ -0,0 +1,17 @@
+# LLM-Server `ghostnet-ki`
+
+Dieser Gerätebereich dokumentiert den physischen Server `10.0.0.90`. Er
+gruppiert die gemeinsame Hostbasis, den eigentlichen LLM-Stack und den davon
+fachlich getrennten CPU-Encoding-Workload. Alle drei Bereiche teilen Hardware,
+Betriebssystem und Ansible-Control-Projekt.
+
+| Bereich | Inhalt |
+| --- | --- |
+| [Host](host/GNAI-002-INFRA_BaseSystem.md) | Hardware, Debian-Basis und GPU-Ausgangslage |
+| [Zugänge](host/GNAI-003-INFRA_Users.md) | Benutzer, Netzwerk, Resolver und SSH |
+| [AI](ai/README.md) | Architektur, Ansible-Deployment, Modellbewertung und `llama.cpp`-Serving |
+| [Encoding](encoding/GNENC-000-DOC_Index.md) | CPU-Encoding-Architektur und offener Implementierungsstand |
+
+Übergreifende Rollen stehen im
+[Zugriffskonzept](../GNAI-005-SEC_Access-Control.md), der Gesamtstand im
+[zentralen Dokumentationsindex](../../GNAI-000-DOC_Index.md).
@@ -3,7 +3,7 @@
 **Dokumenten-ID:** GNAI-004-INFRA  
 **Titel:** Homelab / LLM-Infrastruktur – Zielarchitektur  
 **Status:** Zielarchitektur; bestätigter Teilstand und offene Umsetzung separat ausgewiesen  
-**Vorgänger / Referenzen:** [Basisinstallation](../platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md), [Benutzer/SSH](../platform/ghostnet-ai/GNAI-003-INFRA_Users.md), [Zugriffskonzept](../platform/GNAI-005-SEC_Access-Control.md), [Reverse Proxy](../platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md), [WireGuard](../platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md)
+**Vorgänger / Referenzen:** [Basisinstallation](../host/GNAI-002-INFRA_BaseSystem.md), [Benutzer/SSH](../host/GNAI-003-INFRA_Users.md), [Zugriffskonzept](../../GNAI-005-SEC_Access-Control.md), [Reverse Proxy](../../proxmox-server/lxc/ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md), [WireGuard](../../proxmox-server/lxc/ct-105-wireguard/GNAI-007-SEC_VPN.md)

 ---

@@ -64,6 +64,7 @@ Der Proxmox-Server bildet die Virtualisierungs- und Isolationsschicht.
 | Komponente | Adresse | Rolle |
 | --- | --- | --- |
 | Proxmox VE | `10.0.0.2` | Virtualisierungs-/Managementhost |
+| DNS LXC | `10.0.0.14` | Pi-hole, lokaler Resolver und Split-DNS |
 | Reverse Proxy LXC | `10.0.0.10` | einziger öffentlicher HTTP(S)-Entry-Point |
 | WireGuard LXC | `10.0.0.15` | VPN-/Managementzugang |
 | LLM Server | `10.0.0.90`, Hostname `ghostnet-ki` | KI-Inferenz und LLM-Dienste |
@@ -72,12 +73,17 @@ Die Service-LXCs (z. B. Nextcloud, Gitea, Vaultwarden, Keycloak etc.) verbleiben

 ### Adressplanung und aktuelles Serviceinventar

-Heimnetz `10.0.0.0/24`, Fritzbox/Gateway/DNS `.1`. Statische Server-/LXC-Adressen sind bis `.99` vorgesehen; DHCP vergibt `.100–.200` an Clients. Die `.90` ist dem physischen KI-Server vorbehalten. Das ist eine Belegungsordnung innerhalb desselben Netzes, keine VLAN-/Firewall-Isolation.
+Heimnetz `10.0.0.0/24`, Fritzbox/Gateway `.1`, lokaler DNS `.14`. Statische
+Server-/LXC-Adressen sind bis `.99` vorgesehen; DHCP vergibt `.100–.200` an
+Clients und verteilt Pi-hole als IPv4-DNS. Die `.90` ist dem physischen
+KI-Server vorbehalten. Das ist eine Belegungsordnung innerhalb desselben
+Netzes, keine VLAN-/Firewall-Isolation.

 | Host / Service | Quellenstand | Status der Angabe |
 | --- | --- | --- |
 | Proxmox | `10.0.0.2` | Betreiber bestätigt |
 | Keycloak | `10.0.0.4:8080` | Betreiber bestätigt NPM-Backend |
+| Pi-hole | `10.0.0.14:53` | am 01.10.2026 in CT 100 abgenommen |
 | NPM / wg-easy | `10.0.0.10` / `10.0.0.15` | Betreiber bestätigt |
 | Jellyfin | `10.0.0.11:8096` | GNAI-006-Inventar, vor Freigabe abgleichen |
 | Nextcloud | `10.0.0.12:8080` | GNAI-006-Inventar, vor Freigabe abgleichen |
@@ -361,4 +367,4 @@ Die Architektur gilt als korrekt umgesetzt, wenn mindestens folgende Eigenschaft

 ## 14. Umsetzungsstand

-Die Architektur-Abnahmekriterien in Abschnitt 13 sind Sollkriterien und keine bestätigte Abnahme. Der aktuelle Projektstand und die priorisierten Befunde stehen im [Dokumentationsindex](../GNAI-000-DOC_Index.md); technische Nachweise und offene Prüfungen werden in GNAI-006 und GNAI-007 geführt. Backendisolation und lokale Netzwerksegmentierung sind ebenfalls noch nachzuweisen.
+Die Architektur-Abnahmekriterien in Abschnitt 13 sind Sollkriterien und keine bestätigte Abnahme. Der aktuelle Projektstand und die priorisierten Befunde stehen im [Dokumentationsindex](../../../GNAI-000-DOC_Index.md); technische Nachweise und offene Prüfungen werden in GNAI-006 und GNAI-007 geführt. Backendisolation und lokale Netzwerksegmentierung sind ebenfalls noch nachzuweisen.
@@ -4,7 +4,7 @@
 **Titel:** Ansible-Deployment für den KI-Server – Planungsstand  
 **Stand:** 2026-09-21
 **Status:** Nicht finaler Arbeitsentwurf zur Persistierung des aktuellen Planungsstands  
-**Referenzen:** [Projektstand](../GNAI-000-DOC_Index.md), [Zielarchitektur](GNAI-004-INFRA_Architecture.md), [Modellbewertung](GNAI-009-PLAN_Llama-Model-Evaluation.md), [llama.cpp-Sollkonfiguration](GNAI-010-TECH_Llama-Serving.md), [Zugriffskonzept](../platform/GNAI-005-SEC_Access-Control.md)
+**Referenzen:** [Projektstand](../../../GNAI-000-DOC_Index.md), [Zielarchitektur](GNAI-004-INFRA_Architecture.md), [Modellbewertung](GNAI-009-PLAN_Llama-Model-Evaluation.md), [llama.cpp-Sollkonfiguration](GNAI-010-TECH_Llama-Serving.md), [Zugriffskonzept](../../GNAI-005-SEC_Access-Control.md)

 > **Abgrenzung:** Dieses Dokument hält die Ergebnisse der am 19.09.2026
 > begonnenen und bis zum 21.09.2026 fortgeschriebenen Planungssession fest. Es ist
@@ -85,7 +85,7 @@ dokumentierten Zugangs-, Verzeichnis- und Runtime-Zustände begrenzt.
 Ein fachlich vom LLM-Stack getrennter CPU-Encoding-Workload wird auf demselben
 Host vorgesehen. Sein Ansible-Sollzustand bleibt wegen des gemeinsamen Hosts im
 Infrastructure-Repository; Architektur und spätere Nutzer-SOPs werden unter
-[`docs/video-encoding/`](../video-encoding/GNENC-000-DOC_Index.md) getrennt geführt.
+[`docs/platform/llm-server/encoding/`](../encoding/GNENC-000-DOC_Index.md) getrennt geführt.

 ---

@@ -292,7 +292,7 @@ und muss über CPU-, Speicher- und I/O-Grenzen die Reaktionsfähigkeit der
 KI-Dienste schützen. Die Betreiberfestlegung „CPU-basiert“ und die geplante
 Parallelität sind noch durch einen repräsentativen gemeinsamen Lasttest zu
 bestätigen. Zeitfenster und Grenzwerte werden ausschließlich im getrennten
-[Encoding-Plan](../video-encoding/GNENC-001-PLAN_Architecture.md) spezifiziert.
+[Encoding-Plan](../encoding/GNENC-001-PLAN_Architecture.md) spezifiziert.

 Große schreibgeschützte Modelldateien können später aus einem gemeinsamen,
 nur lesbar eingebundenen Modellspeicher bereitgestellt werden. Datenbanken,
@@ -617,7 +617,7 @@ erfolgreichen Einrichtung.
 Der frühere Phasenplan vermischte bereits erledigte Grundlagen mit offener
 Arbeit und stellte die Gitea-Integration pauschal vor den ersten
 Anwendungsnachweis. Er wird durch den statusbasierten
-[High-Level-Implementierungsplan](../GNAI-001-PLAN_Project-Roadmap.md) ersetzt.
+[High-Level-Implementierungsplan](../../../GNAI-001-PLAN_Project-Roadmap.md) ersetzt.

 Für diesen Ansible-Teilplan gelten daraus drei Leitplanken:

@@ -4,7 +4,7 @@
 **Titel:** `llama.cpp`-Serving mit ROCm und rootless Podman  
 **Stand:** 2026-09-21  
 **Status:** Technische Sollkonfiguration für Testing; noch nicht implementiert  
-**Referenzen:** [Modellbewertung](GNAI-009-PLAN_Llama-Model-Evaluation.md), [Ansible-Deployment](GNAI-008-PLAN_Ansible-Deployment.md), [Zielarchitektur](GNAI-004-INFRA_Architecture.md), [Ansible-Anleitung](../../ansible/README.md)
+**Referenzen:** [Modellbewertung](GNAI-009-PLAN_Llama-Model-Evaluation.md), [Ansible-Deployment](GNAI-008-PLAN_Ansible-Deployment.md), [Zielarchitektur](GNAI-004-INFRA_Architecture.md), [Ansible-Anleitung](../../../../ansible/README.md)

 > Dieses Dokument beschreibt den vorgesehenen technischen Sollzustand. Es ist
 > keine Betriebs-SOP und kein Nachweis, dass Modell, Quadlet oder Inferenz
@@ -1,18 +1,19 @@
 # KI-Dokumentation

 Dieser Bereich enthält die fachliche Zielarchitektur und Deployment-Planung für
-den KI-Stack. Gemeinsame Host-, Netzwerk- und Sicherheitsgrundlagen liegen in
-der [Plattformdokumentation](../platform/README.md). Der CPU-basierte
+den KI-Stack auf dem LLM-Server. Gemeinsame Hostgrundlagen liegen im
+[Geräteindex](../README.md), übergreifende Netzwerk- und Sicherheitsgrundlagen
+in der [Plattformdokumentation](../../README.md). Der CPU-basierte
 Video-Encoding-Workload besitzt einen
-[eigenen Dokumentationsbereich](../video-encoding/GNENC-000-DOC_Index.md).
+[eigenen Dokumentationsbereich](../encoding/GNENC-000-DOC_Index.md).

 | Dokument | Inhalt |
 | --- | --- |
-| [GNAI-001](../GNAI-001-PLAN_Project-Roadmap.md) | priorisierter High-Level-Implementierungsplan mit Entscheidungstoren und Abnahmekriterien |
+| [GNAI-001](../../../GNAI-001-PLAN_Project-Roadmap.md) | priorisierter High-Level-Implementierungsplan mit Entscheidungstoren und Abnahmekriterien |
 | [GNAI-004](GNAI-004-INFRA_Architecture.md) | Zielarchitektur, Komponenten und Datenwege des KI-Stacks |
 | [GNAI-008](GNAI-008-PLAN_Ansible-Deployment.md) | nicht finaler Arbeitsentwurf für Ansible- und Gitea-Deployment |
 | [GNAI-009](GNAI-009-PLAN_Llama-Model-Evaluation.md) | nicht finaler A/B-Plan für Swift, Unsloth, Reasoning-, Kontext- und MTP-Abnahme |
 | [GNAI-010](GNAI-010-TECH_Llama-Serving.md) | technische Sollkonfiguration für zwei geprüfte Modellprofile auf rootless `llama.cpp` mit ROCm |

 Der übergreifende Projektstand steht im
-[zentralen Dokumentationsindex](../GNAI-000-DOC_Index.md).
+[zentralen Dokumentationsindex](../../../GNAI-000-DOC_Index.md).
@@ -1,7 +1,7 @@
 # Video-Encoding – Dokumentationsindex und Projektstand

 **Dokumenten-ID:** GNENC-000-DOC
-**Stand:** 2026-09-20
+**Stand:** 2026-10-05
 **Status:** Nicht finaler Arbeitsstand; Encoding-Workload noch nicht installiert

 ## Dokumente
@@ -14,8 +14,8 @@

 - Das gemeinsame Infrastructure-Repository bleibt die einzige Quelle für den
  Ansible-Sollzustand des physischen Servers.
- Encoding-Dokumentation verwendet den getrennten Bereich `docs/video-encoding/`
-  und die Dokumentenkennung `GNENC`.
+- Encoding-Dokumentation verwendet innerhalb des LLM-Server-Gerätebereichs
+  `docs/platform/llm-server/encoding/` und die Dokumentenkennung `GNENC`.
 - Encoding ist nach Betreiberfestlegung CPU-basiert und darf parallel zur
  jeweils aktiven KI-Umgebung laufen.
 - Encoding soll ausschließlich außerhalb der Stoßzeiten, zunächst nachts,
@@ -2,7 +2,7 @@

 **Dokumenten-ID:** GNENC-001-PLAN
 **Titel:** CPU-basiertes Video-Encoding auf dem KI-Server
-**Stand:** 2026-09-20
+**Stand:** 2026-10-05
 **Status:** Nicht finaler Arbeitsentwurf zur Persistierung der Planungsentscheidung

 ## 1. Zweck und Abgrenzung
@@ -22,7 +22,7 @@ unabhängig konkurrierende Sollzustände auf denselben Host anwenden.
 | Thema | Entscheidung | Nachweisgrenze |
 | --- | --- | --- |
 | Repository | Host- und Deployment-Ansible bleibt im bestehenden Infrastructure-Repository | angenommen |
-| Dokumentation | Encoding erhält `docs/video-encoding/` und die Kennung `GNENC` | umgesetzt |
+| Dokumentation | Encoding liegt unter `docs/platform/llm-server/encoding/` und verwendet die Kennung `GNENC` | umgesetzt |
 | Ausführungsidentität | eigenes gesperrtes Konto `gn-encoding`, UID/GID 982 | eingerichtet und mit rootless Podman geprüft |
 | Containertrennung | eigener rootless Podman-Store und eigener rootverwalteter Quadlet-Pfad | eingerichtet; noch keine Workload definiert |
 | Rechenressource | Encoding ist nach Betreiberfestlegung rein CPU-basiert und erhält keinen GPU-Zugriff | Planungsentscheidung; reale Last noch nicht gemessen |
@@ -1,11 +0,0 @@
-# Proxmox-LXCs
-
-Dieser Bereich dokumentiert ausschließlich die auf Ghostnet Proxmox
-`10.0.0.2` betriebenen LXCs. Er beschreibt nicht die SSH-Konfiguration des
-Hypervisors selbst.
-
-| Dokument / Bereich | Inhalt |
-| --- | --- |
-| [GNAI-011](GNAI-011-SEC_LXC-SSH-Architecture.md) | gemeinsame SSH-Sicherheitsarchitektur und Rolloutverfahren der LXCs |
-| [CT 103](ct-103/GNAI-006-SEC_Reverse-Proxy.md) | Reverse Proxy, Keycloak-Adminpfad und Fail2Ban |
-| [CT 105](ct-105/GNAI-007-SEC_VPN.md) | WireGuard-Gateway, Rollen-Firewall und Clientverfahren |
@@ -4,7 +4,7 @@
 **Titel:** Gemeinsame SSH-Sicherheitsarchitektur der LXCs auf Ghostnet Proxmox  
 **Status:** Legacy-Root-Bestand und Zielbild definiert; CT-103-SSH-Rollout einschließlich Neustart abgenommen
 **Geltungsbereich:** LXCs auf Proxmox `10.0.0.2`; nicht der Proxmox-Host selbst  
-**Referenzen:** [KI-Host-SSH](../ghostnet-ai/GNAI-003-INFRA_Users.md), [Zugriffskonzept](../GNAI-005-SEC_Access-Control.md), [CT 103](ct-103/GNAI-006-SEC_Reverse-Proxy.md), [CT 105](ct-105/GNAI-007-SEC_VPN.md)
+**Referenzen:** [KI-Host-SSH](../llm-server/host/GNAI-003-INFRA_Users.md), [Zugriffskonzept](../GNAI-005-SEC_Access-Control.md), [CT 103](lxc/ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md), [CT 105](lxc/ct-105-wireguard/GNAI-007-SEC_VPN.md)

 ## Änderungsverlauf

@@ -39,7 +39,7 @@ Verfahren.
 | CT 103 `10.0.0.10` | Reverse Proxy, NPM und Fail2Ban; öffentliches HTTP(S)-Ingress | `ghost` als persönlicher Administrator und `ghost-agent` als unprivilegiertes Lesekonto; Root- und Passwort-SSH deaktiviert; Proxmox-Konsole bleibt Recovery-Weg |
 | CT 105 `10.0.0.15` | WireGuard-Gateway und wg-easy | verifizierte Ausnahme: `admin` UID 1000, Key-Login und sudo/`NOPASSWD`; vollständige Baseline noch abnehmen |
 | weitere Legacy-LXCs | unterschiedliche Plattformdienste | laut Betreiber nur `root`; erst nach Inventaraufnahme einzeln migrieren, keine ungeprüfte Massenänderung |
-| KI-Host `10.0.0.90` | physischer KI-Server | eigene Dokumentation unter `platform/ghostnet-ai/` |
+| KI-Host `10.0.0.90` | physischer KI-Server | eigene Dokumentation unter `platform/llm-server/` |
 | Proxmox `10.0.0.2` | Hypervisor und Recovery-Konsole | ausdrücklich außerhalb dieses Dokuments |

 Öffentliche Anwendungsports eines LXC begründen keine öffentliche
@@ -132,7 +132,8 @@ LoginGraceTime 30
 Abweichungen benötigen einen dokumentierten Anwendungsfall. Insbesondere
 Port-, Agent- oder X11-Forwarding wird nicht nur aus Bequemlichkeit aktiviert.
 Änderungen werden mit `sshd -t` geprüft. Vor der Aktivierung ist zu prüfen, ob
-`ssh.socket` aktiv ist. Auf CT 103 schlug `systemctl reload ssh.service` fehl,
+`ssh.socket` aktiv ist. Auf CT 103 und CT 105 schlug
+`systemctl reload ssh.service` fehl,
 weil der per Socket-Aktivierung gestartete Daemon beim SIGHUP Port 22 erneut
 binden wollte. `ssh.socket` startete den Dienst beim nächsten Zugriff wieder
 korrekt. Dort künftig nach erfolgreichem Syntaxcheck und bei offener
@@ -0,0 +1,12 @@
+# Proxmox-Server und LXCs
+
+Dieser Gerätebereich dokumentiert den Proxmox-Kontext unter `10.0.0.2` und die
+darauf betriebenen LXCs. Er beschreibt derzeit nicht die SSH-Konfiguration des
+Hypervisors selbst.
+
+| Dokument / Bereich | Inhalt |
+| --- | --- |
+| [GNAI-011](GNAI-011-SEC_LXC-SSH-Architecture.md) | gemeinsame SSH-Sicherheitsarchitektur und Rolloutverfahren der LXCs |
+| [GNAI-012 / CT 100](lxc/ct-100-dns/GNAI-012-PLAN_Pi-hole-DNS-Handoff.md) | `10.0.0.14`: Pi-hole-Quadlet, FRITZ!Box-DNS, Split-DNS, Abnahme und Rollback |
+| [GNAI-006 / CT 103](lxc/ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md) | `10.0.0.10`: Reverse Proxy, Keycloak-Adminpfad und Fail2Ban |
+| [GNAI-007 / CT 105](lxc/ct-105-wireguard/GNAI-007-SEC_VPN.md) | `10.0.0.15`: WireGuard-Gateway, Rollen-Firewall und Clientverfahren |
@@ -0,0 +1,439 @@
+# Pi-hole und internes Split-DNS – Übergabeauftrag
+
+**Dokumenten-ID:** GNAI-012-PLAN  
+**Titel:** Pi-hole-LXC, FRITZ!Box-DNS und Split-DNS für interne Dienste  
+**Status:** Implementiert und im LAN produktiv; klar ausgewiesene Folgepunkte für WireGuard, mobile DNS-Umgehung und NPM/Keycloak  
+**Stand:** 01.10.2026  
+**Referenzen:** [Projekt-Roadmap](../../../../GNAI-001-PLAN_Project-Roadmap.md), [Zugriffskonzept](../../../GNAI-005-SEC_Access-Control.md), [LXC-SSH-Architektur](../../GNAI-011-SEC_LXC-SSH-Architecture.md), [Reverse Proxy](../ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md), [WireGuard](../ct-105-wireguard/GNAI-007-SEC_VPN.md)
+
+## 1. Auftrag und Umsetzungsergebnis
+
+> GNAI-012 wurde am 01.10.2026 als abgegrenztes Infrastrukturvorhaben
+> umgesetzt. Grundlage war der folgende Auftrag: Lies zuerst
+> `AGENTS.md`, `.codex/LOCAL_MEMORY.md`, den zentralen Dokumentationsindex und
+> alle oben referenzierten Fachdokumente. Prüfe den Live-Zustand, bevor du
+> Änderungen vornimmst. Richte einen dedizierten, unprivilegierten
+> Pi-hole-LXC ein, härte ihn nach GNAI-011, teste DNS und Blocking zunächst
+> ohne Netz-Cutover und verteile ihn erst nach bestandener Abnahme über die
+> FRITZ!Box an das LAN. Implementiere den lokalen DNS-Eintrag
+> `auth-admin.ghostnet.selfhost.eu -> 10.0.0.10`. Verändere in diesem Auftrag
+> weder NPM/CT 103 noch Keycloak/`10.0.0.4` und sperre den öffentlichen
+> `/admin`-Pfad noch nicht. Dokumentiere Versionen, Konfiguration, Tests,
+> Backup und Rollback ohne Passwörter, Schlüssel oder vollständige
+> WireGuard-Profile. Beende den Auftrag mit dem Übergabebericht aus Abschnitt
+> 10, damit die ursprüngliche Sitzung die Keycloak-/NPM-Arbeit fortsetzen kann.
+
+Die Umsetzung wich nach Betreiberentscheidung in einem wesentlichen Punkt vom
+ursprünglichen Soll ab: Pi-hole läuft nicht nativ im LXC, sondern als
+digest-gepinnter rootful Podman-Container unter einer Quadlet-Unit. Das folgt
+dem Muster der anderen modernen Ghostnet-LXCs. Der dafür notwendige
+unprivilegierte LXC besitzt `nesting=1,keyctl=1`. Diese Abweichung wurde durch
+Host-Netzwerkbetrieb, minimale Containerrechte, lokalen Paketfilter und
+Reboot-/Backup-Tests abgenommen.
+
+## 2. Anlass und bestätigter Ausgangszustand
+
+Die laufende Sicherheitsarbeit soll den öffentlich erreichbaren
+Keycloak-Adminpfad von den öffentlichen OIDC-Endpunkten trennen. Dafür ist ein
+interner Name vorgesehen:
+
+```text
+auth-admin.ghostnet.selfhost.eu -> 10.0.0.10
+```
+
+`10.0.0.10` ist CT 103 mit Nginx Proxy Manager. Keycloak selbst läuft hinter
+NPM auf `10.0.0.4:8080`. Der lokale DNS-Eintrag soll später einen getrennten
+internen NPM-Host ermöglichen; er zeigt deshalb **nicht** direkt auf
+`10.0.0.4`.
+
+Bestätigter Netzstand:
+
+| Komponente | Adresse / Stand |
+| --- | --- |
+| FRITZ!Box, Gateway und bisheriger DNS | `10.0.0.1` |
+| Proxmox | `10.0.0.2` |
+| Keycloak-Backend | `10.0.0.4:8080` |
+| CT 103 / NPM | `10.0.0.10` |
+| CT 105 / WireGuard | `10.0.0.15`, VPN-Netz `10.8.0.0/24`, LAN-seitig MASQUERADE |
+| KI-Server | `10.0.0.90` |
+| Heimnetz | `10.0.0.0/24` |
+| geplanter statischer Bereich | `.2` bis `.99` |
+| bisheriger DHCP-Clientbereich | `.100` bis `.200` |
+| CT 100 / Pi-hole | `10.0.0.14`, Hostname `dns`; seit 01.10.2026 produktiver lokaler DNS |
+
+Am 24.09.2026 wurde bestätigt:
+
+- `auth.ghostnet.selfhost.eu` löst im LAN öffentlich auf und erreicht NPM über
+  Hairpin-NAT; NPM sah dabei die öffentliche WAN-Adresse als Clientquelle.
+- Ein gezielter interner Aufruf desselben Hostnamens gegen `10.0.0.10` war mit
+  gültigem TLS erfolgreich und erschien bei NPM mit der echten LAN-Adresse.
+- Der direkte Keycloak-Aufruf `10.0.0.4:8080/admin` leitet auf den öffentlichen
+  Auth-Host zurück. DNS allein ersetzt daher nicht die spätere
+  Keycloak-`hostname-admin`-/NPM-Konfiguration.
+- CT 103 besitzt einen am selben Tag technisch geprüften Stop-Mode-vzdump und
+  ist nach Neustart vollständig wieder angelaufen. Details stehen in GNAI-006.
+
+## 3. Verbindlicher Umfang
+
+### 3.1 In diesem Auftrag
+
+- freien CT-Identifier und die freie statische Adresse bestätigen;
+- dedizierten, unprivilegierten Debian-LXC für Pi-hole erstellen;
+- LXC-Basis, Updates, lokalen Paketfilter und SSH gemäß GNAI-011 härten;
+- Pi-hole als digest-gepinntes offizielles Image über rootful Podman und
+  Quadlet betreiben und die konkreten Versionen festhalten;
+- FRITZ!Box als DHCP-Server beibehalten; Pi-hole-DHCP nicht aktivieren;
+- geeigneten Upstream-DNS ohne Resolver-Schleife konfigurieren;
+- Blocking mit einer kleinen, nachvollziehbaren Ausgangsliste testen;
+- lokalen DNS-Eintrag
+  `auth-admin.ghostnet.selfhost.eu -> 10.0.0.10` einrichten;
+- DNS über UDP und TCP, Weboberfläche, Updates und Neustart abnehmen;
+- IPv4- und IPv6-DNS-Pfade prüfen und DNS-Bypass dokumentieren;
+- Pi-hole erst nach Vorabtests als lokalen DNS-Server über die FRITZ!Box
+  verteilen;
+- mindestens einen LAN-Client nach neuer DHCP-Lease regressionsprüfen;
+- WireGuard-Erreichbarkeit des DNS-Dienstes prüfen oder als exakt begründeten
+  Folgepunkt ausweisen;
+- konsistenten Proxmox-Rückfallstand und Rückstellverfahren dokumentieren.
+
+### 3.2 Ausdrücklich nicht in diesem Auftrag
+
+- keine Änderung an NPM, CT 103 oder dessen Proxy-Host 7;
+- keine Änderung an Keycloak, `hostname` oder `hostname-admin`;
+- den öffentlichen Pfad `auth.ghostnet.selfhost.eu/admin` noch nicht sperren;
+- keine VPN-Rollenarchitektur oder Per-Client-Firewall neu entwerfen;
+- Pi-hole nicht als DHCP-Server aktivieren;
+- keine erzwungene netzweite Sperre externer DNS-/DoH-Ziele;
+- keine großen Community-Blocklisten ohne begründete Auswahl einführen;
+- keine geheimen Werte, Passwörter, privaten Schlüssel oder vollständigen
+  VPN-Profile in Git, Laufprotokolle oder dieses Dokument schreiben.
+
+## 4. Zielarchitektur und Entscheidungen
+
+```text
+LAN-/WireGuard-Client
+        |
+        | DNS TCP/UDP 53
+        v
+Pi-hole-LXC CT 100 / 10.0.0.14
+        |-- lokaler Record: auth-admin.ghostnet.selfhost.eu -> 10.0.0.10
+        |-- Blocklisten / Cache
+        `-- Upstream-DNS für alle übrigen Namen
+
+FRITZ!Box 10.0.0.1
+        `-- DHCP bleibt aktiv und verteilt Pi-hole als lokalen DNS
+```
+
+Verbindliche Entscheidungen:
+
+1. Es wird **ein** Pi-hole-LXC verwendet; kein zusätzlicher reiner DNS-LXC.
+2. Pi-hole wird als rootful Podman-Quadlet in einem dedizierten,
+   unprivilegierten LXC betrieben, nicht auf CT 103, CT 105 oder dem KI-Host.
+   Das Image ist über Version und Digest festgeschrieben; Podman-Socket und
+   automatisches Image-Update bleiben deaktiviert.
+3. `.local` wird nicht als Unicast-DNS-Zone verwendet, weil diese Endung für
+   mDNS reserviert ist. Der projektspezifische Split-DNS-Eintrag nutzt die
+   bereits verwendete öffentliche Domain.
+4. Die FRITZ!Box bleibt DHCP-Server. Pi-hole wird über die Einstellung
+   **Lokaler DNS-Server** an Clients verteilt, nicht ungeprüft als WAN-Upstream
+   der FRITZ!Box eingetragen.
+5. Pi-hole darf nicht die FRITZ!Box als Upstream verwenden, wenn umgekehrt die
+   FRITZ!Box Pi-hole als WAN-Upstream nutzt; diese Schleife ist zu verhindern.
+6. Ein öffentlicher Ersatzresolver darf Clients nicht als scheinbar sichere
+   zweite DHCP-DNS-Adresse angeboten werden, weil Clients ihn unabhängig
+   nutzen und damit Blocking sowie Split-DNS umgehen können.
+7. Das erste Ziel ist ein kontrollierter Einzelresolver. Das verbleibende
+   Single-Point-of-Failure-Risiko wird dokumentiert; ein zweiter Pi-hole ist
+   eine spätere Verfügbarkeitsentscheidung.
+8. DNS-Erreichbarkeit ist keine Anwendungsautorisierung. NPM und Keycloak
+   erzwingen den internen Adminzugang erst im anschließenden Hauptvorhaben.
+
+## 5. Mindestressourcen und Sicherheitsbaseline
+
+Realisierter Stand nach Live-Inventur:
+
+| Parameter | Vorschlag |
+| --- | --- |
+| Hostname | `dns` |
+| IPv4 | `10.0.0.14/24`, Gateway `10.0.0.1` |
+| LXC-ID | `100` |
+| Betriebssystem | Debian 13.7 aus `debian-13-standard_13.1-2_amd64.tar.zst` |
+| Privilegierung | unprivilegierter LXC |
+| CPU / RAM / Swap | 1 vCPU / 1024 MiB / 512 MiB |
+| RootFS / Storage | 8 GiB auf `local-lvm` |
+| Start | `onboot=1`, sinnvolle Startreihenfolge nach Netzwerk |
+| Features | `nesting=1,keyctl=1` für den gewählten Podman-Betrieb |
+
+Lokaler Paketfilter:
+
+- INPUT standardmäßig `drop`;
+- established/related, Loopback und benötigtes ICMP zulassen;
+- TCP/UDP 53 nur aus `10.0.0.0/24`; damit ist auch der von CT 105 maskierte
+  WireGuard-Verkehr mit Quelle `10.0.0.15` umfasst;
+- Pi-hole-Weboberfläche nur aus LAN/WireGuard;
+- SSH gemäß Betreiberentscheidung aus LAN/WireGuard, nicht öffentlich;
+- keine Portweiterleitung an der FRITZ!Box für DNS oder Pi-hole-Webzugang;
+- OUTPUT zunächst zulassen und benötigte Upstream-/Updatepfade dokumentieren.
+
+SSH-Konten nach GNAI-011:
+
+- persönliches Konto `ghost` mit eigenem passphrasegeschütztem Ed25519-Key und
+  passwortgeschütztem sudo;
+- `ghost-agent` mit eigenem Schlüssel, gesperrtem Passwort, ohne Zusatzgruppen
+  und ohne sudo;
+- Root-, Passwort- und Keyboard-Interactive-SSH deaktivieren;
+- individuelle Schlüssel pro LXC, keine Wiederverwendung von CT 103, CT 105
+  oder KI-Host;
+- Hostschlüssel vor dem ersten vertrauenswürdigen Login über die
+  Proxmox-Konsole bestätigen;
+- Proxmox-Konsole bis nach Positiv- und Negativtests offen halten;
+- Neustart und erneute Anmeldung beider vorgesehenen Konten abnehmen.
+
+## 6. Umsetzungsphasen
+
+### Phase A – Live-Inventur und Freigabe
+
+Mindestens erfassen:
+
+```bash
+pct list
+qm list
+pveam list local
+ip -4 neigh show dev vmbr0
+```
+
+Zusätzlich wurde vor der Erstellung geprüft, dass `10.0.0.14` nicht anderweitig
+verwendet oder reserviert war. Ein fehlender Ping allein hätte keine freie
+Adresse bewiesen. CT-ID, Adresse, Template, Storage und Ressourcen wurden mit
+dem Betreiber festgelegt.
+
+Vorhandene Proxmox-Firewall-, Backup- und Startreihenfolgen erfassen. Keine
+Massenänderung an anderen LXCs vornehmen.
+
+### Phase B – LXC und Betriebssystem
+
+1. Unprivilegierten LXC mit statischer Adresse und `onboot=1` erstellen.
+2. Hostname, Adresse, Gateway, Resolver und Zeitsynchronisation prüfen.
+3. Basispakete aktualisieren und automatisches Sicherheitsupdateverfahren
+   festlegen.
+4. nftables-Baseline anwenden und persistent testen.
+5. Persönlichen und lesenden SSH-Zugang nach Abschnitt 5 einrichten.
+6. Root-/Passwort-SSH erst nach erfolgreicher zweiter Sitzung abschalten.
+7. Ausgangszustand und alle Abweichungen dokumentieren.
+
+### Phase C – Pi-hole ohne Netz-Cutover
+
+1. Aktuelle Pi-hole-Container-Version ausschließlich aus offiziellen Quellen
+   bestätigen.
+2. Offizielles Image über Version und Multi-Arch-Digest pinnen und als
+   rootful Quadlet unter `/etc/containers/systemd/pihole.container` betreiben.
+   Die persistente Konfiguration liegt unter `/opt/pihole/etc-pihole`; das
+   Webpasswort wird ausschließlich als Podman-Secret eingebunden.
+3. Statische LXC-Adresse als Pi-hole-Adresse konfigurieren.
+4. Pi-hole-DHCP ausgeschaltet lassen.
+5. Upstream-Resolver bewusst festlegen. Wenn die FRITZ!Box als Upstream dient,
+   darf deren WAN-DNS nicht gleichzeitig zurück auf Pi-hole zeigen.
+6. Zunächst nur die offizielle Standard-/Ausgangsliste verwenden. Zusätzliche
+   Listen benötigen einen Zweck, eine Quelle und einen False-Positive-Test.
+7. Webpasswort interaktiv setzen; niemals in Dokumentation oder Befehlsausgabe
+   übernehmen.
+8. Logging und Aufbewahrung so konfigurieren, dass Diagnose möglich bleibt,
+   ohne unnötig lange personenbezogene DNS-Verläufe zu speichern. Entscheidung
+   dokumentieren.
+
+### Phase D – Split-DNS
+
+Den lokalen A-Record über die Pi-hole-Oberfläche oder die zur installierten
+Version passende offizielle Konfigurationsschnittstelle einrichten:
+
+```text
+auth-admin.ghostnet.selfhost.eu  A  10.0.0.10
+```
+
+Vor dem FRITZ!Box-Cutover direkt gegen Pi-hole testen:
+
+```bash
+dig @10.0.0.14 auth-admin.ghostnet.selfhost.eu A +short
+dig @10.0.0.14 auth-admin.ghostnet.selfhost.eu A +tcp +short
+dig @10.0.0.14 auth.ghostnet.selfhost.eu A +short
+dig @10.0.0.14 example.com A +short
+```
+
+Erwartung:
+
+- der Adminname liefert ausschließlich `10.0.0.10`;
+- der öffentliche Auth-Name bleibt normale Upstream-Auflösung und wird nicht
+  versehentlich überschrieben;
+- externe Namen funktionieren über UDP und TCP;
+- NXDOMAIN, Cache und Blockantworten verhalten sich nachvollziehbar.
+
+### Phase E – Dienst- und Sicherheitstests vor Cutover
+
+- `pihole-FTL` aktiv und beim Boot aktiviert;
+- TCP und UDP 53 lauschen nur wie vorgesehen;
+- Weboberfläche aus LAN erreichbar und aus öffentlichen Netzen nicht
+  veröffentlicht;
+- eine nachweislich in der aktiven Liste enthaltene Testdomain wird blockiert;
+- bewusst erlaubte Projektdomains, OIDC, Vaultwarden, Nextcloud, Gitea und
+  Updatequellen lösen weiterhin auf;
+- lokale Recordänderung über Neustart hinweg persistent;
+- DNS-Anfragen aus einem nicht erlaubten Quellnetz werden verworfen;
+- LXC-Neustart, DNS-Wiederkehr und SSH-Wiederanmeldung erfolgreich;
+- keine fehlgeschlagenen systemd-Units und keine unkontrolliert wachsenden Logs.
+
+### Phase F – FRITZ!Box-Cutover
+
+Erst nach bestandenen Phasen A bis E:
+
+1. bisherigen FRITZ!Box-DNS-Zustand und Rückstellwert dokumentieren;
+2. unter
+   `Heimnetz > Netzwerk > Netzwerkeinstellungen > IP-Adressen >
+   IPv4-Konfiguration > Heimnetz` Pi-hole als **Lokalen DNS-Server** eintragen;
+3. nicht gleichzeitig unkoordiniert die WAN-DNS-Einstellung unter
+   `Internet > Zugangsdaten > DNS-Server` ändern;
+4. DHCP-Lease zunächst nur auf einem Testclient erneuern;
+5. am Client prüfen, dass ausschließlich der beabsichtigte Resolver genutzt
+   wird und `auth-admin...` auf `10.0.0.10` zeigt;
+6. normales Browsing, Softwareupdates und die bekannten Ghostnet-Dienste
+   regressionsprüfen;
+7. erst danach weitere Clients ihre Lease erneuern lassen.
+
+### Phase G – IPv6 und WireGuard
+
+IPv6 darf nicht stillschweigend an Pi-hole vorbeiführen. Vor Abschluss:
+
+- tatsächliche IPv6-Nutzung und von der FRITZ!Box angekündigte DNSv6-Server auf
+  mindestens Linux und einem weiteren relevanten Client erfassen;
+- entweder eine stabile Pi-hole-ULA nach der offiziellen FRITZ!Box-Anleitung
+  verteilen und testen oder IPv6-DNS-Blocking ausdrücklich als offenen Befund
+  dokumentieren;
+- keine link-lokale IPv6-Adresse als segmentübergreifenden WireGuard-DNS
+  verwenden;
+- für WireGuard prüfen, ob `10.0.0.14` in Client-Routen und Gateway-Regeln
+  erreichbar ist;
+- Änderungen an produktiven WireGuard-Profilen nur mit gesicherter
+  Rückfallkopie und gemäß GNAI-007 vornehmen;
+- wenn die Profilumstellung bewusst vertagt wird, muss die Übergabe exakt
+  nennen, welche Rollen/Profile noch keinen Pi-hole-DNS verwenden.
+
+## 7. Abnahmekriterien
+
+- [x] CT-ID, Adresse und Template sind live bestätigt und dokumentiert.
+- [x] Pi-hole läuft in einem dedizierten unprivilegierten LXC mit statischer IP.
+- [x] LXC-Paketfilter erlaubt DNS, Web und SSH nur aus LAN/WireGuard.
+- [x] Persönlicher und lesender SSH-Zugang entsprechen GNAI-011.
+- [x] Root-/Passwort-SSH sind deaktiviert und Negativtests bestanden.
+- [x] Pi-hole-Version, Installationsquelle, Upstream und Blocklisten sind erfasst.
+- [x] Pi-hole-DHCP ist deaktiviert; FRITZ!Box bleibt DHCP-Server.
+- [x] UDP- und TCP-DNS funktionieren direkt gegen Pi-hole.
+- [x] `auth-admin.ghostnet.selfhost.eu` liefert intern `10.0.0.10`.
+- [x] `auth.ghostnet.selfhost.eu` bleibt unverändert öffentlich auflösbar.
+- [x] Blocking und eine kontrollierte Freigabe wurden positiv getestet.
+- [x] LXC-Neustart sowie DNS-, Web- und SSH-Wiederanlauf sind bestanden.
+- [x] FRITZ!Box verteilt Pi-hole zunächst erfolgreich an einen Testclient.
+- [x] DHCP-Erneuerung und tatsächliche Resolverauswahl sind belegt.
+- [x] IPv6-DNS ist wirksam über Pi-hole geführt oder als offener Bypass klar
+      dokumentiert; ein stiller Mischzustand gilt nicht als bestanden.
+- [x] WireGuard-DNS-Erreichbarkeit ist bestanden oder mit betroffenen Profilen
+      als Folgearbeit ausgewiesen.
+- [ ] Öffentliche Ghostnet-Dienste und OIDC funktionieren unverändert.
+- [ ] Rückstellung auf den vorherigen FRITZ!Box-DNS wurde beschrieben und
+      mindestens auf einem Testclient nachvollzogen.
+- [x] Ein aktuelles Proxmox-Backup des fertigen DNS-LXC ist technisch geprüft.
+- [x] Keine Secrets oder privaten Schlüssel wurden dokumentiert oder committed.
+
+## 8. Rollback
+
+Bei DNS-Ausfall oder Fehlfilterung:
+
+1. In der FRITZ!Box den **Lokalen DNS-Server** von `10.0.0.14` auf den
+   wirksamen Ausgangswert `10.0.0.1` zurückstellen.
+2. Testclient vom Netz trennen/verbinden oder DHCP-Lease erneuern.
+3. Resolverauswahl und normale öffentliche Auflösung bestätigen.
+4. Pi-hole aus dem Clientpfad nehmen, aber für Diagnose eingeschaltet lassen,
+   sofern kein Sicherheitsproblem vorliegt.
+5. Fehlgeschlagene Änderung anhand Pi-hole-Query-Log, FTL-Log, nftables und
+   Upstreamtests untersuchen.
+6. Nur falls Konfiguration nicht sicher korrigierbar ist, den geprüften
+   Proxmox-Rückfallstand verwenden. Restore nie über den laufenden LXC hinweg
+   improvisieren; Ziel-ID, Storage und Netzwerk vorher kontrollieren.
+
+Die Rückstellung darf nicht davon abhängen, dass Pi-hole selbst noch DNS
+liefert. FRITZ!Box-Adresse, PVE-Konsole und IP-basierter Zugang müssen deshalb
+vorher dokumentiert und erreichbar bleiben.
+
+## 9. Dokumentationspflichten des Folgeagenten
+
+Der Folgeagent aktualisiert mindestens:
+
+- dieses Dokument mit tatsächlicher CT-ID, Adresse, Versionen, Datum und
+  Abnahmeergebnissen;
+- den [zentralen Index](../../../../GNAI-000-DOC_Index.md);
+- den [Proxmox-LXC-Index](../../README.md);
+- GNAI-007, falls WireGuard-DNS oder Profile verändert wurden;
+- `.codex/LOCAL_MEMORY.md` nur mit nicht geheimen, datierten Betriebsfakten.
+
+Neue Detaildokumente nur anlegen, wenn sie einen dauerhaften Betriebszweck
+haben. Keine langen Konsolenmitschnitte duplizieren; Ergebnisse und relevante
+Fehlerursachen zusammenfassen.
+
+## 10. Verbindlicher Übergabebericht zurück an die Hauptsitzung
+
+Nach Abschluss einen kompakten Bericht mit diesen Punkten liefern:
+
+| Punkt | erforderliche Angabe |
+| --- | --- |
+| LXC | CT-ID, Hostname, IPv4/IPv6, Template, Ressourcen, Storage |
+| Pi-hole | Version, Installationsart, Upstream, aktive Listen, DHCP-Status |
+| Sicherheit | Konten, SSH-Abnahme, Firewallports, Updateverfahren |
+| Split-DNS | Nachweis für `auth-admin... -> 10.0.0.10` über UDP und TCP |
+| FRITZ!Box | geänderte Felder, Ausgangswerte, Cutover-Zeitpunkt |
+| Clients | getestete Betriebssysteme, DHCP-/DNS-Auswahl, IPv6-Ergebnis |
+| WireGuard | getestete Rollen/Profile oder präzise verbleibende Arbeit |
+| Regression | öffentliche Ghostnet-Dienste und OIDC |
+| Backup | Archivpfad, Größe, Integritätstest, Prüfsumme; keine Secrets |
+| Rollback | praktisch geprüfter Client-Rückweg und verbleibende Risiken |
+
+### 10.1 Umsetzungs- und Übergabebericht vom 01.10.2026
+
+| Punkt | Ist-Stand und Nachweis |
+| --- | --- |
+| LXC | CT `100`, Hostname `dns`, unprivilegierter Debian-13-LXC, `10.0.0.14/24`, Gateway `10.0.0.1`, kein konfiguriertes IPv6; 1 vCPU, 1024 MiB RAM, 512 MiB Swap, 8 GiB `local-lvm`; Template `debian-13-standard_13.1-2_amd64.tar.zst` |
+| Pi-hole | Offizielles Image `ghcr.io/pi-hole/pihole:2026.09.0` mit Multi-Arch-Digest `sha256:5b9c8cf51de7d6d3f2240dbe72baf5f06e1fd39cb4d77a99fab4fa13e23bd1be`; Core `v6.4.3`, Web `v6.6`, FTL `v6.7.1`; rootful Podman `5.4.2`, Host-Netzwerk, Quadlet-Autostart; Upstream `9.9.9.9` und `149.112.112.112`; 74.761 Gravity-Domains; DHCP und NTP deaktiviert; Abfrageaufbewahrung 30 Tage |
+| Persistenz und Secret | `/opt/pihole/etc-pihole` persistent und durch `/opt/pihole` Modus `0700` geschützt; Webpasswort als Podman-Secret `pihole_web_password`, nicht in Unit oder Dokumentation; Weblogin nach Restart bestätigt |
+| Sicherheit | `ghost` mit eigenem passphrasegeschütztem Ed25519-Schlüssel und passwortgeschütztem sudo; `ghost-agent` ohne sudo und ohne Zusatzgruppen; Root-, Passwort- und Keyboard-Interactive-SSH sowie Forwarding deaktiviert; nftables INPUT-Drop erlaubt aus `10.0.0.0/24` TCP 22/53/80/443 und UDP 53; DHCP-/NTP-Ports lauschen nicht; `unattended-upgrades` aktiv; Podman-Socket und Auto-Update-Timer deaktiviert |
+| Split-DNS | `auth-admin.ghostnet.selfhost.eu` liefert über UDP und TCP ausschließlich `10.0.0.10`; öffentliche `auth.ghostnet.selfhost.eu`-Auflösung blieb erhalten. HTTPS gegen den neuen Adminnamen scheitert erwartungsgemäß noch, weil NPM/Keycloak in diesem Auftrag nicht verändert wurden. |
+| Blocking | `techques.com` aus der aktiven Gravity-Liste lieferte A `0.0.0.0`, AAAA `::` und über TCP EDE 15 `Blocked (gravity)`. Ein temporärer exakter Allowlist-Eintrag lieferte die reale IPv4; nach Entfernung und Client-Cache-Flush griff Blocking erneut. |
+| Diensttests | Quadlet-Unit nach Container-Restart, vollständigem LXC-Reboot und Stop-Mode-Backup automatisch `active`; DNS, Split-DNS, Blocking, HTTP/HTTPS, SSH und `systemctl --failed` anschließend erneut geprüft. Pi-hole lauscht auf TCP/UDP 53 und TCP 80/443; die von `podman ps` angezeigten Ports 67/123 sind nur Image-Metadaten und keine Listener. |
+| FRITZ!Box | Effektiver Ausgangsresolver `10.0.0.1`; danach ausschließlich IPv4 **Lokaler DNS-Server** `10.0.0.14` verteilt. WAN-DNS, DHCP-Server und IPv6-Einstellungen blieben unverändert; kein öffentlicher Zweitresolver eingetragen. |
+| LAN-Clients | Linux-Laptop bezog nach Lease-Erneuerung ausschließlich `10.0.0.14`; kein DNSv6-Server und keine globale IPv6-Route; normale Auflösung, Split-DNS und Blocking bestanden. Ein Android-Handy zeigte ebenfalls `10.0.0.14`; bei gleichzeitig aktiven DuckDuckGo-Schutz-/VPN-Mechanismen wurden lokale Namen in Firefox und Chrome jedoch nicht aufgelöst. Der Betreiber akzeptierte diesen clientseitigen Bypass; `10.0.0.14` war auf dem Handy direkt erreichbar. Direkt gegen Pi-hole liefert `pi.hole` A `10.0.0.14`, aber auch eine nicht segmentübergreifend nutzbare link-lokale AAAA-Adresse; dieser IPv6-Befund bleibt offen. |
+| WireGuard | Keine produktiven Profile oder CT-105-Regeln verändert. CT 105 maskiert VPN-Verkehr im LAN als `10.0.0.15`, was die DNS-LXC-Firewall grundsätzlich umfasst; ein tatsächlicher DNS-Test pro Peer/Rolle und die Umstellung vorhandener Profile auf `10.0.0.14` bleiben bis zur Rollenklärung aus GNAI-007 offen. |
+| Regression | Öffentliche DNS-Auflösung und `auth.ghostnet.selfhost.eu` blieben erreichbar; der Auth-Endpunkt lieferte weiterhin seinen erwarteten Redirect. Eine vollständige erneute Regression aller in Phase E genannten Ghostnet-Anwendungen/OIDC-Flows steht noch aus. |
+| Backup | `/var/lib/vz/dump/vzdump-lxc-100-2026_10_01-18_49_00.tar.zst`; Stop-Mode, 18 Sekunden; 1.360.465.920 unkomprimierte Bytes, 492.997.570 Byte Archivgröße; `zstd --test` bestanden; SHA-256 `8dca820d72df0a38060ce85370bc3fc7441a408c7c73534821aa5137d6f21b66`; Dienstwiederanlauf bestanden |
+| Rollback | FRITZ!Box **Lokaler DNS-Server** auf `10.0.0.1` zurückstellen und Client-Lease erneuern. Das Verfahren ist beschrieben, wurde nach erfolgreichem Cutover aber nicht praktisch zurück- und wieder vorgespult. Das Backup liegt nur auf demselben Proxmox-Host; unabhängige Kopie und praktischer Restore-Test fehlen. |
+
+Offene Abschlussarbeiten sind damit bewusst begrenzt auf die vollständige
+Anwendungs-/OIDC-Regression, einen praktisch durchgespielten FRITZ!Box-Rollback,
+die Entscheidung zum mobilen DuckDuckGo-DNS-Bypass, eine saubere IPv6-Strategie
+und den rollenbezogenen WireGuard-DNS-Test. Sie ändern nichts am bestandenen
+IPv4-LAN-Betrieb des Pi-hole.
+
+**Rückkehrpunkt für die Hauptsitzung:** Pi-hole und Split-DNS sind stabil;
+`auth-admin.ghostnet.selfhost.eu` löst im LAN auf `10.0.0.10`. WireGuard bleibt
+bis zum profilorientierten Test ein ausgewiesener Folgepunkt. Die Hauptsitzung
+kann nun den internen NPM-Proxy-Host und Keycloak `hostname-admin` einrichten,
+den internen Login testen und danach `auth.ghostnet.selfhost.eu/admin` für
+öffentliche Quellen sperren.
+
+## 11. Primärquellen
+
+- [Pi-hole – Voraussetzungen](https://docs.pi-hole.net/main/prerequisites/)
+- [Pi-hole – Installation](https://docs.pi-hole.net/main/basic-install/)
+- [Pi-hole – FRITZ!Box](https://docs.pi-hole.net/routers/fritzbox-de/)
+- [Pi-hole FTL – Konfiguration und lokale Host Records](https://docs.pi-hole.net/ftldns/configfile/)
+- [Pi-hole – Container-Konfiguration](https://docs.pi-hole.net/docker/configuration/)
+- [Podman – Quadlet](https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html)
+- [DuckDuckGo – App Tracking Protection und lokale VPN-Schnittstelle](https://duckduckgo.com/duckduckgo-help-pages/p-app-tracking-protection/is-app-tracking-protection-a-vpn)
+- [RFC 6762 – `.local` und Multicast DNS](https://www.rfc-editor.org/rfc/rfc6762)
+- [RFC 8375 – `home.arpa` für Heimnetze](https://www.rfc-editor.org/rfc/rfc8375)
+- [Keycloak – Hostname-Konfiguration](https://www.keycloak.org/server/hostname)
@@ -4,7 +4,7 @@
 **Titel:** Reverse Proxy und Fail2Ban – Konfiguration, Betrieb und Sicherheitsabnahme  
 **Status:** NPM 2.15.1 und Fail2Ban aktiv; SSH-Rollout und lokale Dateirechte gehärtet; Keycloak-Admin-Exposure offen

-**Vorgänger / Referenzen:** [Architektur](../../../ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](../GNAI-011-SEC_LXC-SSH-Architecture.md), [Zugriffskonzept](../../GNAI-005-SEC_Access-Control.md), [WireGuard](../ct-105/GNAI-007-SEC_VPN.md)  
+**Vorgänger / Referenzen:** [Architektur](../../../llm-server/ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](../../GNAI-011-SEC_LXC-SSH-Architecture.md), [Zugriffskonzept](../../../GNAI-005-SEC_Access-Control.md), [WireGuard](../ct-105-wireguard/GNAI-007-SEC_VPN.md)  

 ---

@@ -30,6 +30,7 @@
 | 2026-09-24 | 2.3 | Codex | Aktive nftables-INPUT-DROP-Policy, LAN-Begrenzung von SSH und Boot-Aktivierung bestätigt; temporäre Public-Key-Datei entfernt. |
 | 2026-09-24 | 2.4 | Codex | LAN- und WireGuard-Erreichbarkeit als bewusste einfache SSH-Netzbaseline bestätigt; engere Workstation-Allowlist verworfen. |
 | 2026-09-24 | 2.5 | Codex | Kontrollierten Neustart und Wiederanlauf von SSH, nftables, NPM, Fail2Ban und öffentlichen Proxy-Pfaden erfolgreich abgenommen. |
+| 2026-09-24 | 2.6 | Codex | Konsistentes Stop-Mode-vzdump erstellt, Archivintegrität und Prüfsumme geprüft sowie Dienstwiederanlauf regressionsgetestet. |

 ---

@@ -77,7 +78,7 @@ ED25519-Hostschlüssel und die global angebotenen Methoden
 diesem Repository noch in automatisierten Laufprotokollen verarbeitet.

 CT 103 ist der erste Rollout der gemeinsamen
-[LXC-SSH-Architektur](../GNAI-011-SEC_LXC-SSH-Architecture.md). `ghost-agent`
+[LXC-SSH-Architektur](../../GNAI-011-SEC_LXC-SSH-Architecture.md). `ghost-agent`
 ist mit eigenem Schlüssel, ohne Passwort, Zusatzgruppen oder sudo eingerichtet.
 Das Drop-in `99-security.conf` deaktiviert Root-, Passwort- und
 Keyboard-Interactive-Login, verlangt Public Key, erlaubt nur `ghost-agent` und
@@ -406,11 +407,27 @@ podman exec fail2ban fail2ban-client set npm-scanner unbanip "$BAN_IP"

 ## 10. Backup & Disaster Recovery

-Im bisherigen Quellenstand ist ein Proxmox-vzdump-Backup von CT 103 dokumentiert:
+Historischer Quellenstand:

 * **Backup-Datei:** `/var/lib/vz/dump/vzdump-lxc-103-2026_08_31-19_11_10.tar.zst`

-Vor strukturellen Änderungen an nftables, Proxy-Konfiguration oder Quadlets ein aktuelles konsistentes Proxmox-Backup erstellen. Ein Snapshot kann ergänzen, ersetzt aber kein unabhängiges Backup. Der genannte Archivpfad ist historischer Quellenstand, kein Nachweis eines aktuellen oder getesteten Backups.
+Aktueller Rückfallstand vom 24.09.2026:
+
+| Merkmal | Nachweis |
+| --- | --- |
+| Archiv | `/var/lib/vz/dump/vzdump-lxc-103-2026_09_24-17_40_06.tar.zst` |
+| Verfahren | `vzdump`, Modus `stop`, Zstandard-Kompression; vollständiges 8-GiB-RootFS, keine zusätzlichen Mountpoints |
+| Lauf | erfolgreich in 50 Sekunden; 3.859.916.800 unkomprimierte Bytes, 1.228.224.791 Byte Archivgröße |
+| Integrität | `zstd --test` erfolgreich |
+| SHA-256 | `0d11a0d7dc75a61e402011264a6dca6932551d60e6e89e907db2ac1d0854d43c` |
+| Wiederanlauf | CT `running`; neuer Bootzeitpunkt `17:40:56`; SSH, nftables, NPM und Fail2Ban aktiv; keine fehlgeschlagenen Units; öffentliche Proxy-Ziele erfolgreich geprüft |
+
+Dieses Archiv ist ein geprüfter lokaler Rückfallstand für die anstehende
+Proxyänderung. Es liegt auf demselben Proxmox-Host; eine hostunabhängige Kopie
+und ein praktischer Restore-Test sind damit nicht nachgewiesen. Vor späteren
+strukturellen Änderungen an nftables, Proxy-Konfiguration oder Quadlets erneut
+einen aktuellen konsistenten Rückfallstand erstellen. Ein Snapshot kann
+ergänzen, ersetzt aber kein unabhängiges Backup.

 ---

@@ -451,11 +468,12 @@ Der erneute externe Abgleich am 22.09.2026 ergab:

 Die Sperre von `/admin` kann unabhängig vom Anwendungsrealm erfolgen. Eine
 zusätzliche Sperre von `/realms/master/` bleibt bis zur Identifikation des
-tatsächlichen Vaultwarden-Issuers zurückgestellt. Vor der Änderung fehlt noch
-ein aktuelles Backup. Der bei der ersten Prüfung fehlende administrative Weg
-zu CT 103 wurde später durch die getrennten Konten `ghost` und `ghost-agent`
-hergestellt; Root besitzt weiterhin weder Passwort noch installierten
-SSH-Schlüssel.
+tatsächlichen Vaultwarden-Issuers zurückgestellt. Der aktuelle lokale
+Rückfallstand für CT 103 liegt inzwischen vor. Vor der Pfadsperre muss noch ein
+funktionierender interner Keycloak-Administrationsweg bestätigt werden. Der bei
+der ersten Prüfung fehlende administrative Weg zu CT 103 wurde durch die
+getrennten Konten `ghost` und `ghost-agent` hergestellt; Root besitzt weiterhin
+weder Passwort noch installierten SSH-Schlüssel.

 **TLS-Widerspruch:** Externer HTTPS-Login funktionierte, obwohl für diesen Proxy Host SSL als ausgeschaltet angegeben ist. Effektiven Listener, Zertifikat und vHost-Zuordnung prüfen, bevor eine vollständige HTTPS-Bereitstellung behauptet wird. Auf CT 103 etwa:

@@ -1,9 +1,9 @@
 # CT 105 – WireGuard-Gateway

 **Dokumenten-ID:** GNAI-007-SEC  
-**Status:** Live-Stand am 22.09.2026 verifiziert; Schlüsseldateien gehärtet; Rollen-Firewall und Abnahme offen
+**Status:** Native nftables-Rollenpolicy aktiv; Legacy-Hooks entfernt; Fremdnetz- und Rollenabnahme offen

-**Referenzen:** [Zielarchitektur](../../../ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](../GNAI-011-SEC_LXC-SSH-Architecture.md), [Zugriffskonzept](../../GNAI-005-SEC_Access-Control.md), [GUI-SOP](GNAI-007-SEC_VPN_Client-Management.md), [Implementation-Log](GNAI-007-SEC_VPN_Implementation-Log.md)
+**Referenzen:** [Zielarchitektur](../../../llm-server/ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](../../GNAI-011-SEC_LXC-SSH-Architecture.md), [Zugriffskonzept](../../../GNAI-005-SEC_Access-Control.md), [GUI-SOP](GNAI-007-SEC_VPN_Client-Management.md), [Implementation-Log](GNAI-007-SEC_VPN_Implementation-Log.md)


 ## Änderungsverlauf
@@ -14,6 +14,7 @@
 | 2026-09-15 | 2.0 | spektr | Rollen Familie/Server Admin/LLM Admin; bestätigtes LXC und Hooks; NAT-Abhängigkeit; v15-Bereinigung; getrennte SOPs und belastbarer Abnahmestatus |
 | 2026-09-18 | 2.1 | spektr | Lesenden Gateway-Abgleich, iptables-legacy-Befund und DNS-Abgleich ergänzt; Betriebshinweise entsprechend korrigiert. |
 | 2026-09-22 | 2.2 | Codex | Gateway, Container, Regelwerke, Peers, Listener und SSH-Baseline erneut live geprüft; Schlüsseldateien auf Modus 0600 gehärtet. |
+| 2026-10-05 | 2.3 | Codex | Server-Admin-Rolle auf native nftables-Sets und natives NAT umgestellt; parallele Legacy-Hook-Bereinigung und externe Abnahme bleiben offen. |

 ## 1. Zweck und dokumentierter Stand

@@ -21,7 +22,7 @@ Das Gateway ermöglicht administrativen und familiären Fernzugriff auf das Heim

 Das WireGuard-Gateway läuft bereits. Die nachfolgende Installation beschreibt seinen reproduzierbaren Aufbau; neue Sicherheitsmaßnahmen sind als **Soll** gekennzeichnet. Grundlage sind die Quellen, die Tests vom 12.09.2026, die vom Betreiber bereitgestellte Konfiguration und die lesenden Gateway-Abgleiche vom 18. und 22.09.2026. Am 22.09.2026 wurden ausschließlich die Dateirechte von `wg-easy.db` und dem historischen `wg0.json` auf `0600` reduziert; Client- und Rollentests wurden nicht durchgeführt.

-**Wesentliche offene Umsetzung:** Per-Client Firewall ist deaktiviert. Die bisherige breite Forward-Regel erzwingt keine Rollenisolierung. HTTPS für die wg-easy-GUI ist noch nicht eingerichtet. Der dokumentierte Endpoint `vpn.ghostnet.selfhost.eu` stimmte am 18.09.2026 mit der ausgehenden IPv4 des Gateways überein; die DynDNS-Aktualisierung nach einem Adresswechsel ist noch nicht nachgewiesen. Der aktuelle Live-Abgleich steht im Implementation-Log.
+**Wesentliche offene Umsetzung:** Die experimentelle wg-easy-Per-Client-Firewall bleibt deaktiviert. Seit 05.10.2026 begrenzen native nftables-Sets den Server-Admin-Laptop auf inventarisierte Zielhosts und erlauben Gateway-SSH/-GUI für seine VPN-IPs. Die alten wg-easy-`iptables-legacy`-Hooks und Laufzeitregeln sind entfernt; ein kontrollierter wg-easy-Neustart erzeugte sie nicht erneut. Positive und negative Rollen- sowie Fremdnetztests stehen noch aus. HTTPS für die wg-easy-GUI ist noch nicht eingerichtet. Der aktuelle Live-Abgleich steht im Implementation-Log.

 ## 2. Architektur und Adressplan

@@ -46,7 +47,7 @@ flowchart TD
    F -->|"TCP 80/443"| N["NPM · 10.0.0.10"]
    F -->|"UDP 51820"| V["wg-easy · 10.0.0.15"]
    N --> A["Öffentliche Anwendungen"]
-    V --> R["Peer-Firewall · Soll; NAT · Ist"]
+    V --> R["native nftables-Rollenpolicy und NAT"]
    R --> S["Proxmox, LXCs und KI-Server"]
    R -->|"nur Familie"| C["Heimnetz-PCs und Clients"]
 ```
@@ -63,9 +64,9 @@ Die Adressgruppierung im selben `/24` bildet keine Netzwerksegmentierung. Server

 Diese Vorgaben erlauben Netzwerkzugriff auf die genannten Hosts. Anwendungs-, SSH- und Betriebssystemrechte werden separat vergeben. Ein statischer Adressbereich ist kein ausreichender Nachweis, dass jede Adresse darin ein Server ist: Erweiterungen benötigen einen Inventareintrag und die passende Peer-Freigabe.

-**Soll:** In wg-easy die Per-Client Firewall aktivieren und für jeden Peer **Firewall Allowed IPs** ausdrücklich setzen. **Allowed IPs** im exportierten Profil steuert weiter das Split-Tunnel-Routing. **Server Allowed IPs** bezeichnet die Netze, die der Server zum Peer routet; für ein einzelnes Endgerät bleibt das dessen eigene VPN-IP `/32`. Diese drei Felder dürfen nicht miteinander verwechselt werden. [Client-Felder](https://wg-easy.github.io/wg-easy/latest/guides/clients/)
+**Umsetzung:** wg-easy verwaltet Schlüssel, Tunneladressen und Exportprofile. **Allowed IPs** im exportierten Profil steuert das Split-Tunnel-Routing. **Server Allowed IPs** bezeichnet zusätzliche Netze hinter dem Client; bei einem einzelnen Endgerät bleibt dieses Feld leer. Die verbindliche Zielkontrolle erfolgt unabhängig davon in nativen nftables-Sets anhand der zugewiesenen Peer-IP. [Client-Felder](https://wg-easy.github.io/wg-easy/latest/guides/clients/)

-Die Funktion ist laut offizieller Dokumentation experimentell. Abnahme muss absichtliche Erweiterungen der clientseitigen AllowedIPs auf gesperrte Ziele einschließen. Insbesondere muss der Zugriff auf **lokale Gateway-Dienste** geprüft werden, da dieser die INPUT- statt FORWARD-Chain durchläuft. [Per-Client Firewall](https://wg-easy.github.io/wg-easy/latest/guides/admin/)
+Die wg-easy-Per-Client-Firewall wird nicht verwendet, weil sie laut offizieller Dokumentation experimentell ist und `iptables`/`ip6tables` benötigt. CT 105 verwendet stattdessen ausschließlich native nftables-Policy als Sollzustand. Abnahme muss absichtliche Erweiterungen der clientseitigen AllowedIPs auf gesperrte Ziele einschließen. Gateway-Dienste werden in INPUT, weitergeleitete Serverziele in FORWARD behandelt. [Per-Client Firewall](https://wg-easy.github.io/wg-easy/latest/guides/admin/)

 ## 3. Installation im Proxmox-LXC

@@ -115,7 +116,7 @@ sudo install -m 600 /dev/null /opt/wg-easy/environment

 Der letzte Befehl ist ausschließlich für eine **Neuinstallation**: ein vorhandenes Environment-File nicht überschreiben. Dokumentiert ist Podman 5.4.2. Die durch Debian bereitgestellte Version mit `podman --version` festhalten und Quadlet-Unterstützung prüfen.

-Den Benutzer `admin` nur anlegen, wenn er noch nicht existiert. SSH-Key hinterlegen und Rechte testen. Für die SSH-Härtung gilt die gemeinsame [LXC-SSH-Architektur](../GNAI-011-SEC_LXC-SSH-Architecture.md); KI-Host-Konten und Netzwerte werden nicht übernommen. Im bestehenden WireGuard-LXC ist `admin ALL=(ALL) NOPASSWD: ALL` eingerichtet; das ist der bestätigte Ist-Stand und keine allgemeine Vorgabe für andere LXCs. Änderungen an SSH immer mit einer offenen zweiten Sitzung oder Proxmox-Konsole absichern.
+Den Benutzer `admin` nur anlegen, wenn er noch nicht existiert. SSH-Key hinterlegen und Rechte testen. Für die SSH-Härtung gilt die gemeinsame [LXC-SSH-Architektur](../../GNAI-011-SEC_LXC-SSH-Architecture.md); KI-Host-Konten und Netzwerte werden nicht übernommen. Im bestehenden WireGuard-LXC ist `admin ALL=(ALL) NOPASSWD: ALL` eingerichtet; das ist der bestätigte Ist-Stand und keine allgemeine Vorgabe für andere LXCs. Änderungen an SSH immer mit einer offenen zweiten Sitzung oder Proxmox-Konsole absichern.

 ### 3.3 IP-Forwarding

@@ -176,7 +177,7 @@ table inet filter {
 }
 ```

-**Diese Baseline ist keine fertige Rollen-Firewall.** Die breite FORWARD-Freigabe muss gemeinsam mit Per-Client Firewall getestet werden. Die INPUT-Regel erlaubt LAN-Quellen, aber noch keine neuen Verbindungen von VPN-Quellen `10.8.0.x` auf TCP 22/51821. Für Familie und Server Admins muss am Gateway eine ausdrückliche INPUT-Freigabe anhand ihrer zugewiesenen VPN-IP oder einer gepflegten Peer-IP-Menge hinzukommen. LLM Admins dürfen diese Ports auch nach einer lokalen Routingänderung nicht erreichen. Die Rollenzuordnung vorhandener Peers ist noch offen; daher wird keine angeblich fertige IP-Regel erfunden.
+Diese historische Baseline wurde am 05.10.2026 ersetzt. Die aktuelle Datei verwendet die Tabellen `inet ghostnet_filter` und `ip ghostnet_wg_nat`, ein Set `vpn_server_admins` für zugewiesene Peer-IPs sowie `server_admin_targets` für inventarisierte Ziele. INPUT erlaubt den Server-Admin-IPs TCP 22/51821; FORWARD erlaubt ihnen neue Verbindungen nur zu Zielhosts im Set. Rückverkehr läuft über Connection Tracking, natives MASQUERADE über `eth0`.

 `flush ruleset` löscht dynamisch angelegte nftables-/iptables-nft-Regeln. Der Live-Abgleich am 18.09.2026 zeigte jedoch wg-easy-Hooks in **iptables-legacy**; diese werden durch einen nftables-Flush nicht automatisch mit gelöscht. Beide Regelwerke und ihre gemeinsame Wirkung müssen nach Reload oder Neustart geprüft werden. Bei einer Neuinstallation zuerst die Baseline laden, danach wg-easy starten. Im laufenden Betrieb vor einem Reload Regelzustand sichern und Änderung über die Proxmox-Konsole ausführen. Dauerhafte Regeln und dynamische Regeln brauchen eine getestete Start-/Reload-Reihenfolge; diese Abnahme steht noch aus.

@@ -240,8 +241,8 @@ Nach Quadlet-Änderungen `daemon-reload` und `restart` ausführen. Autostart von
 4. Als Host `vpn.ghostnet.selfhost.eu` und als Port `51820` eintragen; vor Ausgabe neuer Profile DNS-Auflösung und aktuelle WAN-IP erneut vergleichen.
 5. Interface-Adressraum `10.8.0.0/24`, Gateway `10.8.0.1` und IPv4-Betrieb prüfen. In Admin Panel → Interface das LAN-Ausgangsgerät `eth0` prüfen.
 6. Neue Client-Defaults so wählen, dass neue Peers keine ungeprüften Vollzugriffsrechte erhalten. Für jede Freigabe gilt die separate GUI-SOP; ein Default ist keine Rollenzuordnung.
-7. DNS rollenabhängig setzen: Familie kann die Fritzbox `10.0.0.1` über das Heimnetz erreichen. Server Admins und LLM Admins verwenden zunächst System-DNS, sofern keine gesonderte DNS-Freigabe beschlossen wird. Historischer Laptop-DNS `10.0.0.1` ist kein pauschaler neuer Default.
-8. Per-Client Firewall für die neue Rollenpolitik aktivieren und abnehmen. Vor Aktivierung vorhandene Peers erfassen, Änderungen über LAN durchführen und unzugeordnete Peers während der Umstellung gesperrt halten.
+7. DNS rollenabhängig setzen: Familie und Server Admin verwenden Pi-hole `10.0.0.14`, damit der produktive lokale Resolver und Split-DNS auch im fremden Netz funktionieren. Pi-hole muss dafür zugleich in Allowed IPs und im nativen nftables-Zielset enthalten sein. LLM Admin verwendet zunächst System-DNS, solange keine interne Namensauflösung benötigt und freigegeben wird. Historischer Laptop-DNS `10.0.0.1` ist kein neuer Default.
+8. Die wg-easy-Per-Client-Firewall deaktiviert lassen. Neue Peer-IP und Rolle in den nativen nftables-Sets pflegen, Konfiguration mit `nft --check --file` prüfen und erst danach atomar laden und abnehmen.

 [Offizieller Setup-Ablauf](https://wg-easy.github.io/wg-easy/latest/guides/setup/)

@@ -295,6 +296,27 @@ MASQUERADE lässt LAN-Dienste VPN-Verkehr unter der Quelladresse `10.0.0.15` seh

 Vor Änderungen ein konsistentes Proxmox-Backup erstellen. Ein Snapshot allein ist kein unabhängiges Backup. Für ein Dateibackup wg-easy in einem Wartungsfenster stoppen, **das gesamte Datenverzeichnis** einschließlich etwaiger SQLite-WAL-Dateien sowie Quadlet, Environment, Firewall und sysctl sichern; anschließend Dienst wieder starten. Backups enthalten PrivateKeys und PresharedKeys und sind entsprechend zu schützen. Wiederherstellung einschließlich Rollenregeln, NAT, externem Handshake und gesperrten Zielen testen. Restore kann inzwischen widerrufene Peers wieder aktivieren; Widerrufsliste abgleichen.

+### 6.1 Kontrolliertes Patchverfahren für CT 105
+
+Paketupdates werden mindestens monatlich sowie vor sicherheitsrelevanten
+Änderungen kontrolliert geprüft und manuell installiert. Die aktiven
+`apt-daily`-Timer ersetzen dieses Verfahren nicht; ein
+`unattended-upgrade`-Programm und eine wirksame
+`APT::Periodic::Unattended-Upgrade`-Konfiguration sind nicht vorhanden.
+
+1. Wartungsfenster ankündigen und bei grundlegenden Paket-, SSH-, Firewall-
+   oder Container-Runtime-Änderungen ein aktuelles Stop-Backup sicherstellen.
+2. Paketlisten mit `sudo apt update` aktualisieren, angebotene Pakete
+   inventarisieren und die Transaktion mit `sudo apt-get -s upgrade`
+   simulieren. Entfernte oder zurückgehaltene Pakete vorab bewerten.
+3. Reguläre Aktualisierungen mit `sudo apt upgrade` installieren.
+   Release-Upgrades und `full-upgrade` sind eigene Wartungsvorgänge.
+4. `/var/run/reboot-required`, den Paketmanager-Exitstatus und relevante
+   Journale prüfen. Falls erforderlich, CT 105 kontrolliert neu starten.
+5. Danach SSH, nftables, wg-easy, `wg0`, Peerzahl, SQLite-Integrität,
+   Legacy-Regelfreiheit und GUI erneut prüfen. Fehler führen zum Abbruch und
+   gegebenenfalls zur Wiederherstellung aus dem letzten konsistenten Backup.
+
 ## 7. Abnahme und Evidenz

 | Prüfung | Ergebnis / Status |
@@ -303,12 +325,12 @@ Vor Änderungen ein konsistentes Proxmox-Backup erstellen. Ein Snapshot allein i
 | Laptop → `10.8.0.1` und Ping `10.0.0.2` | bestanden am 12.09.2026 |
 | Laptop-Internet bleibt direkt | IPv4-Test bestanden am 12.09.2026 |
 | Zugriff auf KI-Server | offen; im letzten Test ausgeschaltet |
-| Proxmox-GUI / SSH-Diensttests | offen; Ping ersetzt keinen Diensttest |
+| Proxmox-GUI / SSH-Diensttests | bestanden am 05.10.2026 |
 | Familie → Heimnetz-PC | offen, einschließlich Host-Firewall und Authentifizierung |
-| Server Admin → Server erlaubt, DHCP-Client gesperrt | offen, Per-Client Firewall noch aus |
+| Server Admin → Server erlaubt, nicht freigegebenes aktives Ziel gesperrt | bestanden am 05.10.2026 im Fremdnetz; Proxmox parallel erlaubt, FRITZ!Box `.1` nach absichtlicher Routenerweiterung gesperrt, nftables-Zähler geprüft |
 | LLM Admin → KI-Server erlaubt, Proxmox/NPM/Gateway-GUI gesperrt | offen, auch bei erweiterten lokalen AllowedIPs prüfen |
 | WAN → TCP 22/51821 und IPv6-Exposure | offen |
-| Reboot / Firewall-Reload / Restore | offen |
+| Reboot / Firewall-Reload / Restore | LXC-Neustart und persistente Firewall am 05.10.2026 bestanden; tatsächlicher Restore offen |

 Tests von einem fremden Netz ausführen, nicht nur aus dem Heimnetz. Für Isolation zuerst sicherstellen, dass das gesperrte Ziel von einem erlaubten Peer tatsächlich erreichbar ist. Handshake und VPN-Routen prüfen, dann bewusst clientseitiges Routing zu einem gesperrten Ziel ergänzen. Timeout allein ist ohne aktiven Zielservice und nachvollziehbare Firewallwirkung kein ausreichender Isolationsnachweis. Ergebnisse mit Datum, Quellnetz, Peer, Ziel, Port und Regelzählern dokumentieren; Secrets auslassen.

@@ -317,7 +339,7 @@ Tests von einem fremden Netz ausführen, nicht nur aus dem Heimnetz. Für Isolat
 | Punkt | erforderliche Klärung / Umsetzung |
 | --- | --- |
 | VPN-DynDNS | Am 18.09.2026 löste `vpn.ghostnet.selfhost.eu` zur ausgehenden Gateway-IPv4 `93.208.161.126` auf; `vpn.ghostnet.dyndns.eu` zeigte auf `83.169.40.234`. Profile nutzen den selfhost-Namen. Automatische Aktualisierung nach WAN-IP-Wechsel und tatsächliche Fritzbox-DynDNS-Einstellung noch prüfen. |
-| Vorhandene Peers | `Laptop-FullAdmin` (`10.8.0.2`) und `Android-LLMAdmin` (`10.8.0.3`) sind historisch. Laptop der neuen Familie-/Server-Admin-Rolle ausdrücklich zuordnen; Android bleibt außerhalb der neuen Client-SOPs. |
+| Vorhandene Peers | `ghost-laptop` (`10.8.0.3`) ist der einzige Peer und wird als Server Admin durch native nftables-Sets eingeschränkt. Die Altpeers `Android-LLMAdmin` und `Laptop-FullAdmin` wurden am 05.10.2026 vollständig gelöscht. |
 | Gateway-Management | INPUT-Regeln für zugeordnete Familie-/Server-Admin-Peers ergänzen; lokale Zugangsgruppen festlegen. |
-| Per-Client Firewall | aktivieren, erzeugte Regeln samt Hooks prüfen, negative Tests und Wiederanlauf abnehmen. |
+| Rollen-Firewall | Native nftables-Policy aktiv; Legacy-Hooks entfernt, negative Tests und Wiederanlauf bestanden. |
 | GUI-HTTPS | Hostname, Zertifikat und Namensauflösung entscheiden und implementieren. |
@@ -2,8 +2,8 @@

 **Dokumenten-ID:** GNAI-007-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-007-SEC_VPN.md), [Rollenmodell](../../GNAI-005-SEC_Access-Control.md), [Windows](GNAI-007-SEC_VPN_Clients_Windows11.md), [Linux](GNAI-007-SEC_VPN_Clients_Linux.md)
+**Status:** Native nftables-Rollenpolicy teilweise umgesetzt; Legacy-Hook-Bereinigung und Abnahme offen  
+**Referenzen:** [Gateway-Architektur](GNAI-007-SEC_VPN.md), [Rollenmodell](../../../GNAI-005-SEC_Access-Control.md), [Windows](GNAI-007-SEC_VPN_Clients_Windows11.md), [Linux](GNAI-007-SEC_VPN_Clients_Linux.md)

 ## Änderungsverlauf

@@ -18,44 +18,44 @@ Administratoren erstellen, ändern, verteilen und widerrufen WireGuard-Profile.

 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.
+Vor Rollenvergabe müssen native nftables-Zielsets und Gateway-INPUT-Regeln nach der Architektur eingerichtet und geprüft werden. Die Policy wurde am 05.10.2026 geladen, ist aber bis zur Entfernung paralleler Legacy-Hooks und zu den Rollen-Negativtests noch nicht abgenommen. Diese SOP 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 |
+| Rolle | Allowed IPs im Profil | native nftables-Zielmenge auf CT 105 | 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 |
+| Familie | `10.0.0.0/24` | `10.0.0.0/24` | `10.0.0.14` |
+| Server Admin | freigegebene Server jeweils `/32` | dieselben Serveradressen ausdrücklich eintragen | `10.0.0.14` |
 | 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:
+Für Server Admins enthält das Quelleninventar derzeit Proxmox `.2` sowie `.4`, `.10`, `.11`, `.12`, Pi-hole `.14`, `.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
+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.14/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.
+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. Pi-hole `.14` ist bewusst enthalten, damit interne Namen auch im fremden Netz aufgelöst werden.

 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
+## 3. Einmalige Umstellung auf native nftables-Rollenpolicy

 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.
+2. Bestehende Peers, ihre VPN-IP, Gerät und Rolle erfassen. Unzugeordnete Peers deaktivieren.
+3. Die wg-easy-Per-Client-Firewall deaktiviert lassen. Sie benötigt iptables; CT 105 verwendet native nftables-Regeln als alleinigen Sollpfad.
+4. Peer-IP in das passende Rollen-Set und erlaubte Zielhosts in das zugehörige Ziel-Set aufnehmen. Kein pauschales Server-Subnetz als Ersatz für das Inventar 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 sperren.
+6. Konfiguration mit `nft --check --file` prüfen, gesichert laden und Sets, INPUT, FORWARD, NAT sowie parallel vorhandene Legacy-Regeln kontrollieren. Positive und negative Tests aus Abschnitt 7 ausführen.

-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/)
+Die offizielle Dokumentation kennzeichnet die nicht verwendete wg-easy-Per-Client-Firewall als experimentell und iptables-basiert. [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.
+2. Einen eindeutigen Gerätenamen setzen und Besitzer, Rolle, Datum und Zweck im Peer-Verzeichnis erfassen. Kurze technische Profilnamen verwenden, beispielsweise `ghost-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.
+5. Client-Details öffnen. **Allowed IPs** und **DNS** gemäß Rolle setzen. **Firewall Allowed IPs** wird nicht verwendet. **Server Allowed IPs** beschreibt zusätzliche Netze, die hinter dem Client liegen und zum Client geroutet werden. Bei einem einfachen Endgerät ohne nachgelagertes Netz bleibt dieses Feld leer; wg-easy erzeugt die Route zur zugewiesenen Client-VPN-IP selbst.
 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.
@@ -96,4 +96,4 @@ Im Status prüfen: letzter Handshake und steigende Transferwerte unter erzeugtem

 ## 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.
+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. Am 05.10.2026 wurden die Altpeers `Laptop-FullAdmin` und `Android-LLMAdmin` gelöscht; `ghost-laptop` `.3` ist der einzige aktive Peer und als Server Admin durch native nftables-Sets abgenommen.
@@ -11,10 +11,11 @@
 | --- | --- | --- | --- |
 | 2026-09-09 | 1.0 | spektr | Erste Clientanleitung für Linux mit KDE Plasma erstellt. |
 | 2026-09-15 | 2.0 | spektr | Debian, Arch/CachyOS, Fedora und Kinoite getrennt beschrieben; NetworkManager und wg-quick, Geheimnisschutz, Fehlersuche und belegten Teiltest überarbeitet. |
+| 2026-10-05 | 2.1 | spektr | Sicheren lokalen Ablagepfad, kurze Profilnamen und das beim Import beobachtete Aktivierungsverhalten von NetworkManager ergänzt. |

 ## 1. Voraussetzungen und Begriffe

-Du benötigst ein eigenes `.conf`-Profil vom Administrator, sudo-Berechtigung für die Einrichtung und Internetzugang. Der Administrator nennt deine Rolle und ein erreichbares Testziel. Du benötigst keine wg-easy-Anmeldung.
+Du benötigst ein eigenes `.conf`-Profil vom Administrator und Internetzugang. Je nach NetworkManager-/PolicyKit-Konfiguration kann die Einrichtung ohne sudo erfolgen; die wg-quick-Methode benötigt sudo. Der Administrator nennt deine Rolle und ein erreichbares Testziel. Du benötigst keine wg-easy-Anmeldung.

 Das Profil enthält geheime Schlüssel: **PrivateKey und PresharedKey** dürfen nicht geteilt werden. PublicKeys sind öffentlich, die vollständige Datei ist dennoch geheim. Jeder Rechner verwendet einen eigenen Peer. Serverdienste verlangen weiterhin ihre eigene Anmeldung.

@@ -22,14 +23,18 @@ Bei Split-Tunneling gehen nur freigegebene Ziele durch WireGuard, normale Intern

 ## 2. Software bereitstellen

-| Distribution | Installation der WireGuard-Werkzeuge |
+Für Methode A genügt ein NetworkManager mit nativer WireGuard-Unterstützung;
+`wireguard-tools` muss dafür nicht zusätzlich installiert sein. Die folgenden
+Pakete sind für Methode B mit `wg`, `wg-quick` und dessen CLI-Diagnose nötig:
+
+| Distribution | optionale WireGuard-Werkzeuge für Methode B |
 | --- | --- |
 | Debian | `sudo apt update`, anschließend `sudo apt install wireguard-tools` |
 | Arch / CachyOS | `sudo pacman -S wireguard-tools` |
 | Fedora, klassisch | `sudo dnf install wireguard-tools` |
 | Fedora Kinoite | falls Werkzeuge fehlen: `sudo rpm-ostree install wireguard-tools`, anschließend in die neue Deployment-Version neu starten |

-Die offiziellen Distributionsbefehle stehen auf der [WireGuard-Installationsseite](https://www.wireguard.com/install/). Aktuelle Standardkernel dieser Distributionen unterstützen WireGuard; bei angepassten Kerneln muss der Administrator dies prüfen. DKMS nicht pauschal installieren.
+Die offiziellen Distributionsbefehle stehen auf der [WireGuard-Installationsseite](https://www.wireguard.com/install/). Aktuelle Standardkernel dieser Distributionen unterstützen WireGuard; bei angepassten Kerneln muss der Administrator dies prüfen. DKMS nicht pauschal installieren. Auf dem geprüften CachyOS-Arbeitsplatz funktionierte der native NetworkManager-Import ohne installiertes `wireguard-tools`.

 Für NetworkManager muss dessen Dienst vorhanden und aktiv sein; auf KDE wird die Netzwerkoberfläche durch `plasma-nm` bereitgestellt, nicht durch ein automatisch von wireguard-tools erzeugtes Tray-Icon. Desktop-Installationen bringen das häufig bereits mit:

@@ -42,26 +47,36 @@ Wenn NetworkManager fehlt, klärt der Administrator zunächst, welcher Dienst de

 ## 3. Profilname und Aufbewahrung

-Für diese Anleitung heißt die lokale Datei `gnai-laptop.conf`. Vom Administrator anders benannte Dateien gegebenenfalls im Dateimanager umbenennen. Der tatsächliche Name muss bei folgenden Befehlen passen. Linux-wg-quick verwendet den Dateinamen ohne `.conf` als Interface-Namen, **ohne `wg-`-Präfix**, maximal 15 Zeichen. [wg-quick-Implementierung](https://git.zx2c4.com/wireguard-tools/tree/src/wg-quick/linux.bash)
+Für diese Anleitung heißt die lokale Datei `ghost-laptop.conf`. Vom Administrator anders benannte Dateien gegebenenfalls im Dateimanager umbenennen. Der tatsächliche Name muss bei folgenden Befehlen passen. Linux-wg-quick verwendet den Dateinamen ohne `.conf` als Interface-Namen, **ohne `wg-`-Präfix**, maximal 15 Zeichen. Buchstaben, Ziffern sowie unter anderem Bindestrich und Unterstrich sind erlaubt; `ghost-laptop` hat 12 Zeichen und ist gültig. [wg-quick-Implementierung](https://git.zx2c4.com/wireguard-tools/tree/src/wg-quick/linux.bash)

 ```bash
-chmod 600 "$HOME/Downloads/gnai-laptop.conf"
+install -d -m 700 "$HOME/.config/ghostnet/wireguard"
+mv "$HOME/Downloads/ghost-laptop.conf" "$HOME/.config/ghostnet/wireguard/ghost-laptop.conf"
+chmod 600 "$HOME/.config/ghostnet/wireguard/ghost-laptop.conf"
 ```

+Der private Ablagepfad liegt außerhalb des Projekt-Repositories. Keine
+Ignore-Regel im Repository als Ersatz für eine sichere Ablage verwenden.
+
 ## 4. Methode A: NetworkManager und Desktop

 Für Desktop-Nutzer eignet sich die bestehende NetworkManager-Verwaltung. Unter KDE **Systemeinstellungen → Verbindungen** öffnen und die Funktion zum Importieren einer Verbindung verwenden, sofern deine Version WireGuard-Dateiimport anbietet. Wenn die Oberfläche diese Funktion nicht anbietet, ist der folgende Import eindeutig; danach erscheint die Verbindung in der Desktop-Netzwerkverwaltung:

 ```bash
-sudo nmcli connection import type wireguard file "$HOME/Downloads/gnai-laptop.conf"
+nmcli connection import type wireguard file "$HOME/.config/ghostnet/wireguard/ghost-laptop.conf"
 nmcli connection show
 ```

-Den beim Import gemeldeten Verbindungsnamen verwenden. Bei abweichendem Namen in folgenden Befehlen `gnai-laptop` ersetzen:
+Der Import kann die Verbindung unmittelbar aktivieren. Im Heimnetz mit demselben
+Adressbereich deshalb direkt wieder trennen. Wenn sie noch nicht aktiv war, ist
+die entsprechende Fehlermeldung beim ersten Befehl unkritisch. Den beim Import
+gemeldeten Verbindungsnamen verwenden; bei abweichendem Namen in folgenden
+Befehlen `ghost-laptop` ersetzen:

 ```bash
-sudo nmcli connection modify gnai-laptop connection.autoconnect no
-sudo nmcli connection up gnai-laptop
+nmcli connection down ghost-laptop
+nmcli connection modify ghost-laptop connection.autoconnect no connection.permissions "user:$USER"
+nmcli connection up ghost-laptop
 nmcli connection show --active
 ip -br addr
 ```
@@ -69,24 +84,24 @@ ip -br addr
 Zum Trennen:

 ```bash
-sudo nmcli connection down gnai-laptop
+nmcli connection down ghost-laptop
 ```

-Alternativ über die Desktop-Netzwerkverwaltung verbinden/trennen. Verbindung erst nach Absprache automatisch starten lassen; Autoconnect-Verhalten wird beim Import nicht vorausgesetzt. NetworkManager speichert das Profil in seiner eigenen Verwaltung; die Downloaddatei ist danach nur eine zusätzliche Geheimniskopie. [NetworkManager-CLI](https://networkmanager.dev/docs/api/latest/nmcli.html)
+Alternativ über die Desktop-Netzwerkverwaltung verbinden/trennen. Verbindung erst nach Absprache automatisch starten lassen; Autoconnect-Verhalten wird beim Import nicht vorausgesetzt. NetworkManager speichert das Profil zusätzlich in seiner eigenen geschützten Verwaltung. Die Datei unter `.config` bleibt ebenfalls ein Geheimnis und dient als kontrollierte lokale Ausgangskopie. Falls PolicyKit den Import verweigert, die Befehle gezielt mit `sudo` wiederholen. [NetworkManager-CLI](https://networkmanager.dev/docs/api/latest/nmcli.html)

 ## 5. Methode B: wg-quick, Terminal und systemd

-Diese Methode verwendet die Datei `/etc/wireguard/gnai-laptop.conf`. Nur verwenden, wenn Methode A für dieses Profil nicht aktiv ist:
+Diese Methode verwendet die Datei `/etc/wireguard/ghost-laptop.conf`. Nur verwenden, wenn Methode A für dieses Profil nicht aktiv ist:

 ```bash
 sudo install -d -m 700 /etc/wireguard
-sudo install -m 600 "$HOME/Downloads/gnai-laptop.conf" /etc/wireguard/gnai-laptop.conf
-sudo wg-quick up gnai-laptop
-sudo wg show gnai-laptop
-ip -br addr show gnai-laptop
+sudo install -m 600 "$HOME/.config/ghostnet/wireguard/ghost-laptop.conf" /etc/wireguard/ghost-laptop.conf
+sudo wg-quick up ghost-laptop
+sudo wg show ghost-laptop
+ip -br addr show ghost-laptop
 ```

-Erwartet: Interface `gnai-laptop`, eigene Adresse `10.8.0.x`, ein Handshake nach Verkehr zu einem freigegebenen Ziel. Nicht pauschal `wg0` abfragen; das ist der Interface-Name auf dem Server.
+Erwartet: Interface `ghost-laptop`, eigene Adresse `10.8.0.x`, ein Handshake nach Verkehr zu einem freigegebenen Ziel. Nicht pauschal `wg0` abfragen; das ist der Interface-Name auf dem Server.

 **DNS-Abhängigkeit:** Wenn das Profil `DNS = ...` enthält, ruft Linux-wg-quick `resolvconf` auf. Vorher prüfen:

@@ -99,26 +114,26 @@ Bei fehlendem Befehl nicht die DNS-Zeile ungeprüft entfernen. Der Administrator
 Zum Trennen:

 ```bash
-sudo wg-quick down gnai-laptop
+sudo wg-quick down ghost-laptop
 ```

 Optionaler Autostart, erst nach erfolgreicher Prüfung und Absprache:

 ```bash
-sudo systemctl enable wg-quick@gnai-laptop.service
+sudo systemctl enable wg-quick@ghost-laptop.service
 ```

 Dies richtet den Bootstart ein. Für systemd-Verwaltung nach einem manuellen `wg-quick down`:

 ```bash
-sudo systemctl start wg-quick@gnai-laptop.service
-sudo systemctl status wg-quick@gnai-laptop.service
+sudo systemctl start wg-quick@ghost-laptop.service
+sudo systemctl status wg-quick@ghost-laptop.service
 ```

 Autostart entfernen und systemd-verwaltete Verbindung stoppen:

 ```bash
-sudo systemctl disable --now wg-quick@gnai-laptop.service
+sudo systemctl disable --now wg-quick@ghost-laptop.service
 ```

 ## 6. Verbindung prüfen
@@ -13,6 +13,7 @@
 | 2026-09-16 | 2.1 | spektr | bestätigten Fail2Ban-Pin und wieder laufenden Container als Querverweis aufgenommen; weitergehende Abnahme nicht unterstellt |
 | 2026-09-18 | 2.2 | spektr | Lesenden SSH-Abgleich von CT 105 und Grenzen des Nachweises dokumentiert. |
 | 2026-09-22 | 2.3 | Codex | aktuellen Gateway-Zustand live inventarisiert und Berechtigungen der Schlüsseldateien gehärtet |
+| 2026-10-05 | 2.4 | Codex | Peerrotation, native nftables-Rollenpolicy, Fremdnetztests sowie Stop-Backup und Wiederanlauf dokumentiert |

 ## 1. Evidenz und zeitliche Einordnung

@@ -49,15 +50,17 @@ Der aktuelle Quadlet-Pin `15.4.0` ist durch den Betreiber bestätigt. v15 verwen

 | Altpeer | VPN-IP | v15-Client-ID laut Quellen | Einordnung |
 | --- | --- | --- | --- |
-| Laptop-FullAdmin | `10.8.0.2` | 1 | neue Rolle Familie oder Server Admin noch ausdrücklich zuordnen |
-| Android-LLMAdmin | `10.8.0.3` | 2 | Altbestand; Android außerhalb des neuen SOP-Umfangs, keine Praxisabnahme |
+| Laptop-FullAdmin | `10.8.0.2` | 1 | am 05.10.2026 als Server Admin festgelegt; technische Rollenregeln noch offen |
+| Android-LLMAdmin | `10.8.0.3` | 2 | reiner Testpeer; am 05.10.2026 zum Widerruf freigegeben |

 Profile wurden laut Log manuell aus der SQLite-Datenbank generiert und gegen
 die Serverkonfiguration geprüft. Das ist ein historischer Vorgang, kein
-künftiges SOP-Verfahren. Neue Profile werden über die GUI exportiert. Der Pfad
-`docs/platform/GNAI-007-profiles/` wird inzwischen vollständig durch die
-Repository-`.gitignore` ausgeschlossen; Profile bleiben unabhängig von
-Git-Ausschlüssen Geheimnisse.
+künftiges SOP-Verfahren. Neue Profile werden über die GUI exportiert. Die
+vorhandenen Profile wurden am 05.10.2026 aus dem Repository-Baum nach
+`~/.config/ghostnet/wireguard/` verschoben. Das Verzeichnis ist lokal `0700`,
+die Profildateien sind `0600`. Im Repository gibt es bewusst keine Ignore-Regel
+für einen Profilordner: Eine versehentliche erneute Ablage soll bei
+`git status` sichtbar werden. Profile bleiben unabhängig davon Geheimnisse.

 Der Laptop wurde von außerhalb des Heimnetzes über EasyCable mit damaliger Außen-IPv4 `80.187.120.60` getestet. Diese und die damalige Heimnetz-WAN-IP sind zeitgebundene Messwerte, keine DNS-Sollwerte.

@@ -110,7 +113,7 @@ Die Fritzbox-Portweiterleitungen sind TCP 80/443→NPM `.10` und UDP 51820→Wir
 | F7 | wg-Tool im LXC nicht gefunden | Serverstatus mit `sudo podman exec wg-easy wg show wg0` prüfen |
 | F8 | sysctl nicht gefunden | procps/PATH prüfen; Forwarding unter `/proc/sys/net/ipv4/ip_forward` lesbar |
 | F9 | wireguard-dkms in CachyOS nicht verfügbar | im getesteten Kernel WireGuard vorhanden; wireguard-tools genügte |
-| F10 | zu langer Profil-/Interface-Name | `Laptop-FullAdmin` hat 16 Zeichen; auf `laptop` umbenannt, ohne Präfix |
+| F10 | zu langer Profil-/Interface-Name | `Laptop-FullAdmin` hat 16 Zeichen; aktueller Peer und lokale Datei heißen `ghost-laptop` beziehungsweise `ghost-laptop.conf` |
 | F11 | öffentliche IP-Abfrage lieferte IPv6 | `curl -4` für einen gezielten IPv4-Vergleich |

 ## 7. Lesender Live-Abgleich am 18.09.2026
@@ -147,19 +150,151 @@ Repository protokolliert.
 | Backup | Nur das historische wg-easy-Backup vom 09.09.2026 wurde gefunden. Ein aktuelles konsistentes Proxmox-/Dateibackup vor Firewall- oder Peer-Änderungen ist nicht belegt. |
 | Dateirechte | `wg0.conf` war bereits `0600`. `wg-easy.db` und das historische `wg0.json` wurden von `0644` beziehungsweise `0640` auf `0600` reduziert. Danach waren Dienst und WireGuard-Interface weiterhin funktionsfähig. |

-## 9. Offene Umsetzung und Abnahme
+## 9. Lokale Profilablage und NetworkManager am 05.10.2026
+
+Die beiden vorhandenen Clientprofile wurden aus dem Repository-Baum nach
+`~/.config/ghostnet/wireguard/` verschoben und in `gnai-laptop.conf` sowie
+`gnai-android.conf` umbenannt. Beide Basisnamen liegen unter der Linux-Grenze
+von 15 Zeichen. Bindestrich und Unterstrich wären zulässig; die Länge von
+`Laptop-FullAdmin` war das eigentliche Namensproblem. Übergeordnetes Verzeichnis
+und Profilverzeichnis sind `0700`, beide Dateien `0600` und gehören `ghost`.
+
+Auf dem CachyOS-Arbeitsplatz ist NetworkManager 1.58.1 aktiv. Das Laptopprofil
+wurde nativ als `gnai-laptop` importiert, auf `connection.autoconnect=no` und
+`connection.permissions=user:ghost` gesetzt und nach der beim Import erfolgten
+Sofortaktivierung wieder getrennt. Danach existierten weder das Interface noch
+eine VPN-Route; das lokale `10.0.0.0/24` blieb direkt über Ethernet erreichbar.
+`wireguard-tools` ist nicht installiert und für die nachgewiesene native
+NetworkManager-Einrichtung nicht erforderlich. Es wird nur bei Bedarf an
+`wg show` oder der alternativen wg-quick-Methode ergänzt. Der Betreiber ordnete
+den Laptop am selben Tag der Rolle Server Admin zu und gab den reinen Testpeer
+`Android-LLMAdmin` zum Widerruf frei. Ein erneuter Test aus einem fremden Netz,
+die technische Rollendurchsetzung und deren Abnahme stehen aus.
+
+Vor dem Widerruf wurde wg-easy kurz gestoppt und ein konsistentes
+Anwendungsbackup unter
+`/var/backups/ghostnet/wg-easy/ct105-wg-easy-2026-10-05-pre-android-revoke.tar.gz`
+erstellt. Es enthält Datenverzeichnis, Environment, Quadlet, nftables- und
+sysctl-Konfiguration, gehört `root:root` und ist `0600`. gzip-Test und
+SQLite-`integrity_check` waren erfolgreich; SHA-256:
+`623fc71c17a43d1359a05c949e2ae42ae5bf21bc11c69b2417386ed0c4f0a37f`.
+wg-easy und `wg0` liefen anschließend mit zwei Peers wieder. Das lokale
+`gnai-android.conf` wurde endgültig entfernt. Die lokale API lehnte
+unangemeldete Session- und Clientzugriffe erwartungsgemäß mit HTTP 401 ab. Der
+Betreiber löschte `Android-LLMAdmin` anschließend über eine authentifizierte
+GUI-Sitzung. Die Verifikation zeigte genau einen Datenbank- und Laufzeit-Peer
+(`Laptop-FullAdmin`), `database_integrity=ok` und einen aktiven wg-easy-Dienst.
+
+Der neue Peer `gnai-ghost-laptop` wurde anschließend mit `10.8.0.3` angelegt;
+die sichtbare IPv6-Adresse ist bei wirksamem `DISABLE_IPV6=true` reserviert,
+aber `wg0` besitzt nur IPv4. Der globale Client-DNS ist nun Pi-hole
+`10.0.0.14`. Der Peername ist als Linux-Interface-Name zu lang, daher bleibt der
+lokale Dateiname `ghost-laptop.conf`.
+
+Die Server-Admin-Durchsetzung wurde auf native nftables-Tabellen umgestellt.
+`vpn_server_admins` enthält während der Migration `.2` und `.3`;
+`server_admin_targets` enthält die einzeln dokumentierten Server einschließlich
+Pi-hole `.14`. INPUT erlaubt diesen Peer-IPs TCP 22/51821, FORWARD nur neue
+Verbindungen zu den inventarisierten Zielen, und `ip ghostnet_wg_nat` übernimmt
+MASQUERADE für `10.8.0.0/24` über `eth0`. Die Konfiguration bestand
+`nft --check --file`, wurde mit zweiminütigem Rückfalltimer geladen und über
+eine neue SSH-Verbindung, aktive Dienste, `wg0`, Sets, NAT und erhaltene
+Netavark-Tabelle geprüft; danach wurde der Timer entfernt. Die vorherige Datei
+liegt rootgeschützt unter
+`/var/backups/ghostnet/firewall/nftables.conf.pre-native-roles-2026-10-05`.
+Beim ersten Laden waren die alten wg-easy-`iptables-legacy`-Hooks und
+Laufzeitregeln noch vorhanden; ihre anschließende Bereinigung ist im folgenden
+Absatz dokumentiert.
+
+Der Betreiber benannte den neuen Peer anschließend in `ghost-laptop` um und
+setzte dessen Allowed IPs auf die elf Server-`/32`. DNS `10.0.0.14` wird aus dem
+globalen Default geerbt; `Server Allowed IPs` ist leer. Alle globalen Hooks
+wurden geleert. Nach Sicherung des vollständigen Legacy-Regelsatzes unter
+`/var/backups/ghostnet/firewall/iptables-legacy-2026-10-05-pre-removal.rules`
+wurden exakt die frühere UDP-INPUT-, beide wg0-FORWARD- und die
+MASQUERADE-Regel entfernt. Vor und nach einem kontrollierten
+wg-easy-Dienstneustart betrug die Zahl der Legacy-Regeln null. Beide Peers,
+`wg0`, native nftables-Sets/NAT, Netavark und die GUI blieben aktiv.
+
+Das exportierte neue Profil wurde ohne Ausgabe seiner Schlüssel geprüft:
+`10.8.0.3/32`, Pi-hole-DNS, elf Serverziele und der dokumentierte Endpoint waren
+korrekt; IPv6 war nicht enthalten. Es liegt als `ghost-laptop.conf` mit `0600`
+unter `~/.config/ghostnet/wireguard/` und ist in NetworkManager als manuelle,
+inaktive, auf `ghost` beschränkte Verbindung importiert. Der alte lokale
+NetworkManager-Eintrag und das alte Profil wurden entfernt. Der serverseitige
+Altpeer `.2` blieb bis zur erfolgreichen Fremdnetzabnahme als Rückfall aktiv.
+
+Die Fremdnetzabnahme erfolgte über einen Smartphone-Hotspot im Netz
+`10.62.63.0/24`; Ethernet war getrennt. `ghost-laptop` erhielt ausschließlich
+die elf vorgesehenen `/32`-Routen. Pi-hole beantwortete interne und externe
+DNS-Anfragen, `auth-admin.ghostnet.selfhost.eu` lieferte `10.0.0.10`, und
+Proxmox, Keycloak, NPM, Pi-hole, wg-easy sowie Gateway-SSH waren erreichbar.
+Die öffentliche IPv4 blieb mit und ohne Tunnel gleich. Serverseitig wurden ein
+aktueller Handshake und steigende Transferwerte bestätigt.
+
+Für den Negativtest wurde nur in einer geschützten temporären Profilkopie
+`10.0.0.1/32` ergänzt. Bei gleichzeitig erfolgreichem Proxmox-Aufruf waren
+Ping und HTTP zur aktiven FRITZ!Box gesperrt; der Gateway-eigene HTTP-Aufruf auf
+`.1` lieferte dagegen 200. Nach Ergänzung persistenter nftables-Zähler zeigte
+die Wiederholung vier neue Accepts zur Serverzielmenge, drei Drops und vier
+NAT-Bindungen. Testverbindung und temporäre Geheimnisdatei wurden entfernt; das
+Produktivprofil blieb unverändert.
+
+Nach bestandener Abnahme löschte der Betreiber `Laptop-FullAdmin` über die
+authentifizierte wg-easy-GUI. Datenbank und `wg0` enthielten danach genau
+`ghost-laptop` `.3`; SQLite-Integritätsprüfung und Dienste waren fehlerfrei.
+Die persistente nftables-Datei wurde im Prüfmodus validiert und anschließend so
+geladen, dass `vpn_server_admins` nur noch `10.8.0.3` enthält. Split-DNS,
+Proxmox und wg-easy blieben erreichbar, die Legacy-Regelzahl blieb null und das
+Produktiv-VPN wurde kontrolliert getrennt. Damit ist die Schlüsselrotation des
+Laptopzugangs abgeschlossen.
+
+Anschließend erstellte der Betreiber ein vollständiges Proxmox-Backup von
+CT 105 im Modus `Stop`. Der Neustart des LXC und von wg-easy um 17:19 Uhr ist
+damit belegt. Nach dem Start waren SSH, nftables und wg-easy aktiv; es gab
+keine fehlgeschlagene Unit. Die persistente nftables-Datei bestand die
+Syntaxprüfung, `vpn_server_admins` enthielt ausschließlich `10.8.0.3`, alle elf
+Serverziele und das native MASQUERADE waren vorhanden und `iptables-legacy`
+enthielt nur leere Standardketten. Der Container lief mit genau einem
+WireGuard-Peer, SQLite meldete `integrity_check=ok` und die lokale GUI
+antwortete mit HTTP 302. Ein tatsächlicher Restore des Backups bleibt eine
+gesonderte Recovery-Abnahme.
+
+Für die SSH-Härtung wurde die bestehende `99-security.conf` rootgeschützt
+gesichert und um `DisableForwarding yes` sowie explizite Verbote für TCP-,
+Agent-, StreamLocal-, X11- und Tunnel-Forwarding ergänzt. `sshd -t` bestand,
+ein Remote-Forwarding-Versuch wurde abgelehnt und ein neuer Schlüssel-Login
+funktionierte. Der erste `reload` traf auf das bekannte
+Socket-Aktivierungsproblem: sshd konnte beim SIGHUP den von `ssh.socket`
+gehaltenen Port nicht erneut binden; die nächste Verbindung startete den
+Dienst korrekt. Künftig wird nach Syntaxprüfung `restart` statt `reload`
+verwendet.
+
+Der Symlink
+`/etc/systemd/system/timers.target.wants/wtmpdb-rotate.timer` zeigte auf
+eine nicht vorhandene Paket-Unit und wurde entfernt. Das Patchverfahren bleibt
+bewusst kontrolliert manuell: `apt-daily`-Timer sind aktiv, aber
+`unattended-upgrade` und eine wirksame automatische Installation fehlen.
+Simulation, Wartungsfenster, gegebenenfalls Stop-Backup und anschließender
+Health-Check sind in der Betriebsdokumentation festgelegt. Nach dem
+kontrollierten LXC-Neustart um 17:38 Uhr waren keine Units fehlgeschlagen,
+sämtliche Forwarding-Arten effektiv aus, Kerndienste und native Firewall aktiv,
+Legacy-Regeln leer, genau ein Peer vorhanden, SQLite intakt und die GUI
+erreichbar.
+
+## 10. Offene Umsetzung und Abnahme

 | ID | Arbeit | Status |
 | --- | --- | --- |
 | O1 | Fritzbox-Portforward | bestätigt; Laptop-WAN-Handshake als Teilnachweis vorhanden |
 | O2 | DynDNS-Aktualisierung nach WAN-IP-Wechsel und Fritzbox-Einstellung prüfen | aktueller selfhost-Endpoint am 18.09.2026 durch DNS-/WAN-Abgleich bestätigt; dyndns.eu zeigt auf andere Adresse |
-| O3 | Altpeers neuen Rollen zuordnen | offen |
-| O4 | Per-Client Firewall und Gateway-INPUT-Rollenrechte umsetzen | offen |
-| O5 | Rollenisolierung bei geänderten lokalen AllowedIPs testen | offen |
-| O6 | KI-Server, Proxmox-GUI und SSH testen | offen |
+| O3 | Altpeers neuen Rollen zuordnen | abgeschlossen: Android-Testpeer und alter Laptoppeer gelöscht; `ghost-laptop` `.3` ist einziger Server-Admin-Peer |
+| O4 | Native nftables-Ziel- und Gateway-INPUT-Rechte umsetzen | abgeschlossen: Policy und NAT aktiv, Legacy-Hooks bereinigt, Dienst- und LXC-Wiederanlauf sowie Rollentests bestanden |
+| O5 | Rollenisolierung bei geänderten lokalen AllowedIPs testen | bestanden am 05.10.2026: erlaubtes Ziel parallel erreichbar, aktive `.1` gesperrt, nftables-Zähler geprüft |
+| O6 | KI-Server, Proxmox-GUI und SSH testen | Proxmox-GUI und Gateway-SSH bestanden; KI-Server bewusst ausgeschaltet und noch offen |
 | O7 | WAN-/IPv6-Managementport-Isolation | offen |
-| O8 | Reboot, Firewall-Reload und Restore | offen |
+| O8 | Reboot, Firewall-Reload und Restore | Stop-Backup mit vollständigem LXC-Wiederanlauf und persistenter Firewall bestanden; Restore noch offen |
 | O9 | wg-easy-GUI-HTTPS und lokales Gruppenmodell | geplant; Werte noch festzulegen |
-| O10 | SSH-Forwarding, X11 und automatisches Updateverfahren entscheiden | offen; keine Änderung ohne bestätigten Betriebsbedarf und Wartungsmodell |
+| O10 | SSH-Forwarding, X11 und automatisches Updateverfahren entscheiden | abgeschlossen: alle SSH-Forwarding-Arten aus; kontrolliertes manuelles Patchverfahren mit Simulation, Wartungsfenster und Health-Check festgelegt |

-Andere Sicherheitsbefunde werden im [Dokumentationsindex](../../../GNAI-000-DOC_Index.md) geführt. Dieses Log hält nur WireGuard-Umsetzung und zugehörige Tests fest.
+Andere Sicherheitsbefunde werden im [Dokumentationsindex](../../../../GNAI-000-DOC_Index.md) geführt. Dieses Log hält nur WireGuard-Umsetzung und zugehörige Tests fest.