# 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

```text
/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 Host-Ports; der Gateway stellt ausschließlich Port 8080 und 8081 auf der
von der Fritzbox zugeteilten VPN-Adresse bereit.

## 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

```bash
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`. An der physischen Standortadresse dürfen beide Ports
nicht antworten.

## Getestetes Verhalten am 22. August 2026

- Fritzbox-Handshake und Datenverkehr in beide Richtungen: erfolgreich
- Open WebUI und Router über die VPN-Adresse: HTTP 200
- 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.