Add FRITZBox correction plan and offsite options

Two operator decision documents, doc-only, no live action:

- docs/FRITZBOX_PORT_CORRECTION_PLAN.md prepares the three open
  router items: remove 80/tcp (no HTTP-01 in use), do not add
  222/tcp while Tailscale remains the operator path, deactivate
  the UPnP self-exposure from PC-192-168-178-71. Every step waits
  for operator go.

- docs/OFFSITE_BACKUP_OPTIONS.md compares rsync.net, BorgBase EU2
  and rotating cold disk for a second offsite target. Recommends
  rsync.net or cold disk; BorgBase EU2 is explicitly not
  recommended because it does not separate the provider risk.
  No provider booked, no costs triggered.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs/FRITZBOX_PORT_CORRECTION_PLAN.md

@@ -0,0 +1,94 @@
+# FRITZ!Box Portfreigaben - Korrektur-Vorbereitung
+
+Status: **Vorbereitung (Doku-only)**, 2026-05-27. Keine Router-Aenderung.
+Audit-Bezug: `docs/AUDIT_2026-05-25_TODO.md` Sprint 4 ("FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen") und `docs/NETWORK_INVENTORY.md`.
+
+## Aktueller FRITZ!Box-Befund (2026-05-27)
+
+Aus dem Operator-Live-Check der FRITZ!Box-UI:
+
+- aktiv: `80/tcp` -> `192.168.178.58`
+- aktiv: `443/tcp` -> `192.168.178.58`
+- fehlt: `222/tcp` -> `192.168.178.58` (Gitea-SSH)
+- zusaetzlich gemeldet: eine Portfreigabe durch das Geraet `PC-192-168-178-71` (Selbst-Freigabe per UPnP)
+
+## Soll-Stand laut Repo
+
+`docs/NETWORK_INVENTORY.md` definiert genau zwei aktive Portfreigaben:
+
+| Erwartete Freigabe | Ziel | Begruendung |
+|---|---|---|
+| `443/tcp` -> `192.168.178.58:443` | Traefik HTTPS | einziger Public-HTTPS-Einstieg, Wildcard-Zert ueber Cloudflare-DNS-Challenge |
+| `222/tcp` -> `192.168.178.58:222` | Gitea SSH | Git-SSH-Push/Pull; dokumentierte Ausnahme |
+
+Port `80/tcp` ist im Cloudflare-DNS-Challenge-Modell **nicht** notwendig.
+
+## Drei Korrektur-Punkte
+
+### 1. `80/tcp` entfernen
+
+Begruendung:
+
+- ACME laeuft als Cloudflare-DNS-Challenge (`traefik/docker-compose.yml`), nicht als HTTP-01.
+- Traefik leitet intern jeden HTTP-Request auf `https://` weiter; ein WAN-`80`-Listener bietet keinen Mehrwert, oeffnet aber einen zusaetzlichen Angriffsvektor (Header-/Method-Scanning, Open-Redirect-Versuche bevor TLS terminiert).
+- Innerhalb des LAN funktioniert die Browser-Auto-HTTPS-Umleitung weiter ueber AdGuard-DNS.
+
+Empfehlung: WAN-Eintrag `80/tcp` in FRITZ!Box-UI **entfernen** nach Operator-Go.
+
+Validierung nach Aenderung:
+
+```bash
+# WAN-seitiger Test, idealerweise von einem Geraet im Mobilfunknetz oder Tailscale-Exit-Node
+curl -sI http://kaleschke.info/   # erwartet: Connection refused / Timeout
+curl -sI https://vault.kaleschke.info/   # erwartet: HTTP/2 200 oder Authelia-Redirect
+```
+
+### 2. `222/tcp` ergaenzen (nur wenn externes Git-SSH wirklich gewuenscht)
+
+Frage an Operator: Wird `git@git.kaleschke.info -p 222` von extern gebraucht? Hinweise:
+
+| Pro `222/tcp` extern | Contra `222/tcp` extern |
+|---|---|
+| Push/Pull vom unterwegs-Laptop ohne Tailscale | Tailscale ist schon der Operator-Pfad, deckt das voll ab |
+| GitHub-Mirror-Bootstrap funktioniert dann auch ohne Tailscale | GitHub-Push-Mirror laeuft automatisch von Gitea aus, braucht kein WAN-SSH |
+| Externe Webhooks gegen Git push (nicht in Nutzung) | weniger Angriffsflaeche fuer SSH-Brute-Force |
+
+Empfehlung: `222/tcp` **nicht** ergaenzen, solange Tailscale stabil verfuegbar ist. Stattdessen `docs/NETWORK_INVENTORY.md` und `HOMELAB_ARCHITECTURE_MASTER_V2.md` darauf abgleichen, dass Gitea-SSH bewusst LAN/Tailscale-only ist.
+
+Wenn Operator entscheidet, `222/tcp` doch extern zu oeffnen: zusaetzlich SSH-Login auf Key-only setzen, Brute-Force-Limits in Gitea pruefen, `docs/NETWORK_INVENTORY.md` "Erwartete Freigabe"-Tabelle aktualisieren.
+
+### 3. UPnP-Selbstfreigabe von `PC-192-168-178-71` deaktivieren
+
+Begruendung:
+
+- Geraete-initiierte Portfreigaben (UPnP) sind ausserhalb der Repo-Sollkonfiguration.
+- Welcher Port von welchem Programm geoeffnet wurde, ist aus der FRITZ!Box-UI heraus nicht versionierbar.
+- Wenn der Port gebraucht wird, gehoert er als bewusste Operator-Freigabe in `docs/NETWORK_INVENTORY.md`.
+
+Empfehlung in zwei Stufen:
+
+1. FRITZ!Box-UI: in den Geraete-Details fuer `PC-192-168-178-71` die aktuelle Selbstfreigabe-Liste pruefen und mit dem Operator besprechen.
+2. Wenn der Port nicht gebraucht wird: Selbstfreigabe deaktivieren. Optional: UPnP global pro Geraet abschalten ("Selbststaendige Portfreigaben fuer dieses Geraet erlauben" abwaehlen).
+
+## Schutzregeln
+
+- Keine Router-Aenderung ohne ausdrueckliches Operator-Go.
+- Nach jeder Aenderung: `docs/NETWORK_INVENTORY.md` Abschnitt "FRITZ!Box (WAN -> Host)" gegen den neuen UI-Stand abgleichen.
+- Aenderung in `docs/MIGRATION_LOG.md` als kurzer Eintrag dokumentieren (was/warum/Validierung).
+- Bei `80/tcp`-Entfernung kurz prufen, ob irgendein externer Dienst noch HTTP-01 nutzen wollte (sollte nicht der Fall sein).
+
+## Nicht Teil dieser Vorbereitung
+
+- FRITZ!OS-Update 8.21 -> aktuell. Das ist eigenes Service-Fenster und braucht WAN/Tailscale-Aufbau-Beobachtung.
+- IPv6-Exposure. Wenn Telekom IPv6 zustellt und Apps via Cloudflare-AAAA erreichbar sind, kann WAN-Filter pro Port noetig werden. Separater Doku-Punkt in `docs/NETWORK_INVENTORY.md` Offene Entscheidungen.
+- Mobilfunk-Failover-Stick. Bewusst nicht eingerichtet.
+
+## Offene Punkte
+
+| Status | Punkt | Naechster Schritt |
+|---|---|---|
+| offen (Operator-Go) | `80/tcp` entfernen | FRITZ!Box-UI, danach `docs/NETWORK_INVENTORY.md` aktualisieren |
+| offen (Operator-Go) | `222/tcp` Entscheidung | Operator klaert: extern noetig oder Tailscale-only |
+| offen (Operator-Go) | UPnP-Freigabe `PC-192-168-178-71` | FRITZ!Box-UI Geraete-Detail pruefen |
+| offen | FRITZ!OS 8.21 Update | Service-Fenster, separat geplant |
+| offen | IPv6-Exposure pruefen | bei naechstem WAN-Touch mit erfassen |