AI-Profile-Router/docs/WIREGUARD_HOME_PEER.md

WireGuard über die Fritzbox

Gewählter Betriebsmodus

Athena verwendet die Fritzbox-Konfiguration für einen einzelnen WireGuard-Client. Die unveränderte Exportdatei wird als root-only Secret nach

/etc/mike-ai/wireguard/fritz-athena.conf

kopiert (chmod 600). Sie gehört weder ins Git-Repository noch in Backups ohne Verschlüsselung. Eine LAN-zu-LAN-Konfiguration ist für diesen Host nicht nötig.

Der Tunnel endet im Container mike-ai-wireguard-gateway. Nur dieser Container erhält NET_ADMIN und /dev/net/tun. Open WebUI und Router veröffentlichen keine Ports auf der physischen Hostadresse. Der Gateway stellt OpenWebUI, Router und die Werkzeugdienste auf der von der Fritzbox zugeteilten VPN-Adresse bereit. Die vollständige Liste steht in VPN_SERVICE_PORTS.md.

Split der Verantwortlichkeiten

• Debian, Paketverwaltung und SSH benutzen die normale Standortverbindung.
• Die Docker-Netze frontend und tools-egress werden per Quellrouting zum WireGuard-Gateway geschickt.
• Interner Docker-Verkehr bleibt lokal und durchquert den Tunnel nicht.
• Der Fritzbox-Export darf 0.0.0.0/0 und ::/0 enthalten. Das ändert nicht die Default-Route des Debian-Hosts, sondern nur die des Gateway-Namespace.
• Fällt WireGuard aus, bleibt die Quellroute auf den dann unerreichbaren Gateway zeigen: Anwendungscontainer fallen geschlossen aus.

Kontrolle ohne Geheimnisse auszugeben

docker inspect -f '{{.State.Health.Status}}' mike-ai-wireguard-gateway
docker exec mike-ai-wireguard-gateway wg show wg0 latest-handshakes
systemctl status mike-ai-container-vpn-guard

Der Healthcheck verlangt einen Handshake, der jünger als drei Minuten ist. Open WebUI liegt unter http://<VPN-IP>:8080, der Router unter http://<VPN-IP>:8081/v1; die MCPs liegen auf 8201 bis 8208. An der physischen Standortadresse dürfen diese Anwendungsports nicht antworten.

Getestetes Verhalten am 22. August 2026

• Fritzbox-Handshake und Datenverkehr in beide Richtungen: erfolgreich
• Open WebUI, Router und direkte MCP-Endpunkte über die VPN-Adresse: erreichbar
• dieselben Ports über die physische Hostadresse: geschlossen
• VPN-Gateway gestoppt: ausgehender Open-WebUI-Test blockiert (fail-closed)
• Gateway erneut gestartet: automatischer aktueller Handshake
• vollständiger Hostneustart: SSH, Guard, Gateway, Open WebUI und Router kamen automatisch gesund zurück; VPN-Ports erreichbar, Standortports geschlossen

Die Exportdatei muss Bestandteil des verschlüsselten Disaster-Recovery-Satzes sein. Ohne sie kann ein neuer Host den Heimtunnel nicht rekonstruieren.