infrastructure/README.md

Ghostnet.AI Infrastruktur

Dokumentation für die Infrastruktur eines privaten Homelabs mit öffentlich erreichbaren Webdiensten, einem WireGuard-Zugang und einem dedizierten KI-Server. Dieses Repository hält Architekturentscheidungen, den belegten Betriebsstand und Verfahren für Einrichtung, Betrieb und Sicherheitsabnahme fest.

Projektstand: 19.09.2026. Die Dokumentationsrevisionen sind zusammengeführt. Mehrere Sicherheitsmaßnahmen und technische Abnahmen stehen noch aus. Der KI-Server ist derzeit ein frisch eingerichtetes Basissystem; sein LLM-Anwendungsstack soll in einem späteren Sprint mit Ansible installiert werden.

Überblick

flowchart LR
    Internet --> Router[Fritzbox]
    Router -->|HTTP/HTTPS| NPM[Nginx Proxy Manager]
    Router -->|WireGuard| VPN[wg-easy]
    NPM --> Apps[Webdienste in eigenen LXCs]
    VPN --> LAN[Heimnetz]
    LAN --> PVE[Proxmox und Service-LXCs]
    LAN --> AI[KI-Server]
    NPM -.-> AI

Der Reverse Proxy und das VPN-Gateway laufen in getrennten Proxmox-LXCs. Weitere Webdienste befinden sich in eigenen LXCs. Der physische KI-Server ist für lokale Inferenz und darauf aufbauende Anwendungen vorgesehen. Die gestrichelte Verbindung zum KI-Server beschreibt einen geplanten Veröffentlichungsweg für LLM-Anwendungen; die Dienste sind dort noch nicht installiert.

Die drei vorgesehenen VPN-Netzwerkrollen sind Familie (gesamtes Heimnetz), Server Admin (bestätigte Server und Service-LXCs) und LLM Admin (nur KI-Server). Ihre serverseitige Durchsetzung ist noch nicht abgenommen. Anwendungsanmeldung, SSH-Schlüssel und API-Schlüssel bleiben zusätzliche, eigenständige Zugangskontrollen.

Aktueller Stand

Bereich	Belegter Stand	Nächster Nachweis oder Schritt
KI-Server	Debian-Basissystem und getrennte SSH-Konten; lesender Teilabgleich am 18.09.2026	LLM-Anwendungsstack später mit Ansible einrichten und abnehmen
VPN	wg-easy v15.4.0 auf CT 105 aktiv; ein externer Laptop-Teiltest liegt vor	Rollenrechte serverseitig umsetzen und mit erlaubten sowie gesperrten Zielen testen
Reverse Proxy	NPM auf CT 103 dokumentiert; Fail2Ban laut Betreiber fest gepinnt und wieder in Betrieb	Effektive Jails, Sperren und Wiederanlauf prüfen
Identität	Keycloak/OIDC laut Betreiber produktiv für Vaultwarden	Öffentlich erreichbare Keycloak-Administration sperren und den OIDC-Login erneut prüfen

Der Dokumentationsindex enthält die datierten Quellen, offenen Angaben und Abnahmegrenzen. Er ist die maßgebliche Übersicht für den aktuellen Projektstand. Eine Zielbeschreibung in diesem README oder den Architekturdokumenten ist kein Nachweis für eine bereits wirksame Konfiguration.

Dokumentation lesen

Einstieg	Inhalt
Dokumentationsindex und Projektstand	Dokumentenübersicht, bestätigte Entscheidungen und offene Befunde
Zielarchitektur	Komponenten, Datenwege und geplante Sicherheitszonen
Zugriffsmodell	Rollen, Zugriffsmatrix und Authentifizierung
Basissystem und Benutzer, Netz und SSH	KI-Server-Basis und zugehörige Prüfungen
Reverse Proxy und Fail2Ban	Konfiguration, Keycloak-Korrektur und ausstehende Abnahme
WireGuard-Gateway	Gateway-Aufbau, Ist-Stand und Rollen-Firewall
Client-Verwaltung	Profile ausgeben, ändern, widerrufen und Rollen prüfen
Windows 11 und Linux	Einrichtung und Nutzung auf Endgeräten
WireGuard-Implementation-Log	Historie, Tests und Korrekturen früherer Befunde

Arbeiten mit dem Repository

Dieses Repository enthält derzeit Dokumentation und noch keine Ansible-Rollen oder ausführbare Bereitstellung des KI-Anwendungsstacks. Vor einer Infrastrukturänderung den Ist-Stand am betroffenen Host prüfen, die passende Fachanleitung lesen und die dort genannten Abnahmeschritte dokumentieren. Der KI-Server soll bis zum geplanten Ansible-Sprint abgesehen von den eingerichteten Benutzerzugängen ein Basissystem bleiben.

WireGuard-Profile enthalten private Schlüssel. Sie gehören nicht in Git, Ausgaben oder freigegebene Dokumente. Das lokale Verzeichnis docs/GNAI-006-profiles/ schließt Profil-Dateien über eine eigene .gitignore aus; es ist kein Verteiler- oder Backup-Ort für Zugangsdaten.

Änderungen am Projektstand sollten zuerst im zuständigen Fachdokument mit Datum und Beleg erfasst werden. Anschließend den Index und diese README aktualisieren, wenn sich eine übergreifende Aussage geändert hat.