Record FRITZBox WAN cleanup (80/tcp out, VONETS UPnP off)

Operator umgesetzt 2026-05-28: - 80/tcp aus FRITZBox-UI entfernt; Mobilfunk-validiert: http liefert Timeout, https weiter erreichbar. - 222/tcp bleibt bewusst nicht eingerichtet (Tailscale-only- Linie). MASTER Sektion 10 entsprechend praezisiert. - UPnP-Selbstfreigabe-Recht fuer PC-192-168-178-71 deaktiviert. Identifiziert als VONETS-WiFi-Bridge (vermutlich SolarEdge- Wechselrichter). SolarEdge-Cloud-Sync ist outbound und braucht keine UPnP. Aktiver WAN-Endstand: ausschliesslich 443/tcp -> 192.168.178.58. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-28 15:32:10 +02:00
parent 3c71a66c55
commit 19604e0114
5 changed files with 44 additions and 12 deletions
@@ -395,7 +395,7 @@ Für den laufenden Betrieb gilt stattdessen:
 | `Komodo` | Docker-Socket Zugriff | Stack-Deployments benötigen Socket |
 | `glance-docker-socket-proxy` | Docker-Socket read-only | Glance benoetigt Containerstatus; Zugriff wird ueber einen internen Socket-Proxy auf lesende Docker-API-Endpunkte begrenzt und nicht ins `frontend_net` gelegt |
 | `Komodo` | keine pauschale zentrale Middleware | Webhooks (`/listener`), API und Periphery-WebSocket (`/ws/periphery`) sollen nicht durch vorgeschaltete ForwardAuth gebrochen werden |
-| `gitea` | SSH-Port 222 direkt gebunden | Git-SSH-Zugang; kein HTTP-Proxy für SSH möglich |
+| `gitea` | SSH-Port 222 direkt gebunden (LAN/Tailscale) | Git-SSH-Zugang; kein HTTP-Proxy für SSH möglich. Bewusst **nicht** in FRITZ!Box-WAN freigegeben (Operator-Entscheidung 2026-05-28): Tailscale ist Operator-Pfad, GitHub-Mirror deckt DR-Bootstrap ab, SSH-Brute-Force-Vektor extern vermeiden. |
 | `ddns-updater` | bleibt in `frontend_net` statt `backend_net` | braucht Cloudflare-API-Zugang; `backend_net` ist `internal: true` |
 | `mail-archiver` | `frontend_net` + `backend_net` | braucht Internetzugang für IMAP-Abruf (GMX, Gmail) und DB-Zugang |
 | `traefik/dynamic/*` | manueller Host-Sync trotz GitOps | File-Provider bleibt bewusst fuer `middlewares.yml`, `tls.yml` und `dashboards.yml`; Komodo deployed diese Dateien nicht automatisch |
@@ -76,7 +76,7 @@ Kontext bewusst gesichert, bevor weitere Live-Aenderungen passieren:
 | erledigt | USV-Test oder USV-Entscheidung | Operator-Entscheidung 2026-05-26: aktuell keine USV-Anschaffung; Power-Loss-Risiko wird bewusst akzeptiert und dokumentiert |
 | erledigt (Baseline) | H:/ als zusaetzliches lokales Backupziel bewerten | Als zweite Nearline-Kopie und Freeze-Sicherung sinnvoll; kein Offsite-Ersatz, kein CIFS-Hard-Mount am Unraid; Pull-Modell vom Windows-PC ist der getestete Weg (siehe `docs/CAPACITY_AND_LIFECYCLE.md`) |
 | erledigt (Pull live, Scheduled Task offen) | H:/ Groesse und Pull-Schedule festschreiben | Groesse erfasst: 8.0T NTFS, 3.91T belegt, 4.10T frei, `Healthy`. Erster echter Pull 2026-05-27 20:45 erfolgreich: 19 Borg-Dumps + 10 Gitea-Bundle-Files unter `H:\kallilab-nearline-backups`. `unraid-flash-config.*` bewusst ausserhalb Scope (`/XF`-Exclude, Restore aus Hetzner-Borg). Permission-Fixes in `pre-backup-dumps.sh` (alle Dumps 0644 ausser Flash-Config), `gitea-bundle-mirror.sh` (Bundles 0644), `export-prometheus-textfile.sh` (Metric-File 0644) und `pull-critical-backups.ps1` (Report-Bug + ExcludeFiles). Windows Scheduled Task taeglich 05:30 bleibt offen (Operator-Bestaetigung). |
-| erledigt (Abweichung dokumentiert) | FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen | UI am 2026-05-27 geprueft: aktiv sind `80/tcp` und `443/tcp` auf `192.168.178.58`; `222/tcp` fehlt; zusaetzlich UPnP-Selbstfreigabe durch `PC-192-168-178-71`. Korrektur ist ein separater produktiver Router-Schritt nach Operator-Freigabe; Vorbereitung in `docs/FRITZBOX_PORT_CORRECTION_PLAN.md` |
+| erledigt 2026-05-28 | FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen | Bereinigt: `80/tcp` entfernt (Mobilfunk-validiert: HTTP timeout, HTTPS weiter erreichbar). `222/tcp` bleibt bewusst nicht eingerichtet (Tailscale-only-Linie). UPnP-Selbstfreigabe-Recht fuer `PC-192-168-178-71` (VONETS-Bridge, vermutlich SolarEdge-Wechselrichter) deaktiviert. Aktiver Endstand: ausschliesslich `443/tcp -> 192.168.178.58`. Details in `docs/FRITZBOX_PORT_CORRECTION_PLAN.md`. |
 ## Sprint 5 - Auth und Frontdoor, bewusst zuletzt
@@ -1,8 +1,18 @@
 # FRITZ!Box Portfreigaben - Korrektur-Vorbereitung
-Status: **Vorbereitung (Doku-only)**, 2026-05-27. Keine Router-Aenderung.
+Status: **umgesetzt 2026-05-28**, Doku bleibt als Historie und Begruendungs-Anker.
 Audit-Bezug: `docs/AUDIT_2026-05-25_TODO.md` Sprint 4 ("FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen") und `docs/NETWORK_INVENTORY.md`.
 ## Umsetzungs-Befund 2026-05-28
 | Punkt | Entscheidung | Validierung |
 |---|---|---|
 | 1. `80/tcp` entfernen | **umgesetzt** | Mobilfunk-Test: `http://vault.kaleschke.info` Timeout, `https://...` weiter erreichbar. Lokal via LAN: HTTP->HTTPS-Redirect funktioniert weiter durch Traefik. |
 | 2. `222/tcp` ergaenzen | **bewusst NICHT umgesetzt** | Tailscale bleibt Operator-Pfad; GitHub-Mirror deckt DR-Bootstrap ab; SSH-Brute-Force-Vektor vermieden. Repo-Soll in `NETWORK_INVENTORY.md` und `MASTER_V2.md` Sektion 10 entsprechend angepasst. |
 | 3. UPnP-Selbstfreigabe `PC-192-168-178-71` | **umgesetzt** | "Selbstständige Portfreigaben fuer dieses Geraet erlauben" deaktiviert. Identifiziert als VONETS-WiFi-Bridge (Hostname `VONETS.COM`, MAC `00:17:13:2F:61:96`) — vermutlich Bridge zum SolarEdge-Wechselrichter. SolarEdge-Cloud-Sync ist outbound und benoetigt keine UPnP. |
 Aktiver Endstand: ausschliesslich `443/tcp -> 192.168.178.58:443` (Traefik HTTPS) ist von WAN aus erreichbar.
 ## Aktueller FRITZ!Box-Befund (2026-05-27)
 Aus dem Operator-Live-Check der FRITZ!Box-UI:
@@ -87,8 +97,8 @@ Empfehlung in zwei Stufen:
 | Status | Punkt | Naechster Schritt |
 |---|---|---|
-| offen (Operator-Go) | `80/tcp` entfernen | FRITZ!Box-UI, danach `docs/NETWORK_INVENTORY.md` aktualisieren |
+| erledigt 2026-05-28 | `80/tcp` entfernen | umgesetzt, Mobilfunk-validiert |
-| offen (Operator-Go) | `222/tcp` Entscheidung | Operator klaert: extern noetig oder Tailscale-only |
+| erledigt 2026-05-28 (bewusst nicht) | `222/tcp` Entscheidung | bleibt Tailscale-only; Repo-Soll entsprechend angepasst |
-| offen (Operator-Go) | UPnP-Freigabe `PC-192-168-178-71` | FRITZ!Box-UI Geraete-Detail pruefen |
+| erledigt 2026-05-28 | UPnP-Freigabe `PC-192-168-178-71` | UPnP-Selbstfreigabe-Recht fuer VONETS-Bridge deaktiviert |
 | offen | FRITZ!OS 8.21 Update | Service-Fenster, separat geplant |
 | offen | IPv6-Exposure pruefen | bei naechstem WAN-Touch mit erfassen |
@@ -17,6 +17,15 @@ Dieses Dokument ist nur noch ein historischer Verlauf. Der aktuelle operative Ab
 ## Historische Meilensteine
 ### 2026-05-28 - FRITZ!Box-Portfreigaben bereinigt
 - WAN-Soll auf eine einzige Freigabe reduziert: `443/tcp -> 192.168.178.58:443` (Traefik HTTPS).
 - `80/tcp` aus FRITZ!Box-UI entfernt. Validierung: Mobilfunk-Test ergibt Timeout auf `http://vault.kaleschke.info`, `https://vault.kaleschke.info` weiter erreichbar; lokal greift Traefik-Redirect 80->443 nach wie vor. Cloudflare-DNS-Challenge braucht kein Port 80.
 - `222/tcp` bleibt bewusst nicht eingerichtet. Begruendung: Tailscale ist Operator-Pfad, GitHub-Push-Mirror `michaelkaleschke-spec/homelab-infra` deckt Repo-Bootstrap-Pfad ab, Gitea-Bundles unter `/mnt/user/backups/git-bundles/gitea` decken Offline-Restore ab. `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 10 entsprechend mit "Tailscale-only, bewusst nicht WAN-freigegeben" praezisiert.
 - UPnP-Selbstfreigabe-Recht fuer `PC-192-168-178-71` (Hostname `VONETS.COM`, MAC `00:17:13:2F:61:96`) deaktiviert. Identifiziert als VONETS-WiFi-Bridge, vermutlich Bridge-Anbindung zum SolarEdge-Wechselrichter. SolarEdge-Cloud-Sync ist outbound und benoetigt keine UPnP. Aktuell waren 0 Selbstfreigaben aktiv; die Aenderung ist praeventiv gegen kuenftige Anforderungen.
 - `docs/NETWORK_INVENTORY.md`, `docs/FRITZBOX_PORT_CORRECTION_PLAN.md` und `docs/AUDIT_2026-05-25_TODO.md` Sprint 4 entsprechend nachgezogen.
 - Bewusst NICHT angefasst: FRITZ!OS 8.21 Update (Service-Fenster), IPv6-Exposure (separater Folgeschritt), WAN-Ausfallschutz (bewusst aus).
 ### 2026-05-27 - Monitoring-Alerts live, Gitea-Bundle-Cron live, H:/-Pull live
 Drei Audit-TODOs gleichzeitig auf "erledigt" gezogen; alle Aenderungen mit Host-Smoke verifiziert.
@@ -64,14 +64,27 @@ tailscale ip -6
 ### FRITZ!Box (WAN -> Host)
-Die FRITZ!Box-UI meldete initial "Portfreigabe aktiv, 2 Portfreigaben eingerichtet". Die zwei aktiven Freigaben muessen mit den im Repo dokumentierten Public-Ports konsistent sein:
+Aktiver Soll-Stand nach Operator-Bereinigung 2026-05-28:
-| Erwartete Freigabe | Ziel | Zweck | Konsistenz-Check |
+| Aktive Freigabe | Ziel | Zweck | Bemerkung |
 |---|---|---|---|
-| 443/tcp -> 192.168.178.58:443 | Traefik HTTPS | Public Apps via Traefik | Soll exakt diesen Eintrag in FRITZ!Box-UI haben |
+| `443/tcp` -> `192.168.178.58:443` | Traefik HTTPS | einziger Public-HTTPS-Einstieg, Wildcard-Cert via Cloudflare-DNS-Challenge | bleibt |
 | 222/tcp -> 192.168.178.58:222 | Gitea SSH | Git Push/Pull via SSH | Soll exakt diesen Eintrag in FRITZ!Box-UI haben |
-**Wichtig:** Port 80/tcp ist im Cloudflare-DNS-Challenge-Modell **nicht** erforderlich; eine 80er-Freigabe waere ein unnoetiger Angriffsvektor. Wenn die FRITZ!Box-UI mehr oder andere Eintraege zeigt als die zwei oben, muss das im naechsten Operator-Review abgeglichen werden (siehe "Offene Entscheidungen").
+Bewusst **nicht** freigegeben:
 | Port | Begruendung |
 |---|---|
 | `80/tcp` | Cloudflare-DNS-Challenge ersetzt HTTP-01; Traefik macht HTTP->HTTPS-Redirect nur LAN-seitig; WAN-`80` waere zusaetzliche Angriffsflaeche ohne Funktionsnutzen. **2026-05-28 in FRITZ!Box-UI entfernt**, Validierung: Mobilfunk-Test ergibt Timeout auf `http://vault.kaleschke.info`, `https://...` weiter erreichbar. |
 | `222/tcp` (Gitea SSH) | bewusst Tailscale-only: Operator-Pfad ist Tailscale, GitHub-Mirror deckt DR-Bootstrap ab, Gitea-Bundles sind off-host. Externe SSH-Brute-Force-Vektoren vermeiden. |
 ### UPnP / Selbstständige Portfreigaben
 | Geraet | UPnP-Selbstfreigabe-Recht | Begruendung |
 |---|---|---|
 | `Kallilabcore` (192.168.178.58) | nicht erlaubt | Repo-managed; alle benoetigten Public-Ports sind explizite Freigaben |
 | `PC-192-168-178-71` / VONETS-Adapter (192.168.178.71, MAC 00:17:13:2F:61:96) | **2026-05-28 deaktiviert** | wahrscheinlich VONETS-WiFi-Bridge fuer SolarEdge-Wechselrichter; SolarEdge-Cloud-Sync ist ausschliesslich outbound, eingehende Ports sind nicht erforderlich |
 Sollten neue Geraete UPnP-Selbstfreigaben anfordern, wird das in `docs/MIGRATION_LOG.md` und hier als bewusste Ausnahme dokumentiert oder pro Geraet wieder deaktiviert.
 Aktueller UI-Befund vom 2026-05-27 (`Internet -> Freigaben -> Kallilabcore`):
@@ -137,7 +150,7 @@ docker network inspect backend_net | jq '.[0].Internal'
 | Thema | Status | Naechster Schritt |
 |---|---|---|
 | AdGuard Admin nur via Tailscale | live validiert 2026-05-26 | Compose bindet Admin-Port auf `100.80.98.33:8082`; DNS auf Port 53 funktioniert, LAN-Zugriff auf `192.168.178.58:8082` schlaegt fehl |
-| FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | erledigt, Abweichung gefunden | UI zeigt am 2026-05-27 `80/tcp` + `443/tcp` auf `192.168.178.58`; `222/tcp` fehlt. Naechster Operator-Schritt: nach Freigabe `80/tcp` entfernen und nur bei Bedarf `222/tcp` anlegen |
+| FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | **erledigt 2026-05-28** | Bereinigt: `80/tcp` entfernt (Cloudflare-DNS-Challenge ersetzt HTTP-01; Mobilfunk-Test bestaetigt Timeout auf `http://`, `https://` weiter ok). `222/tcp` bleibt bewusst nicht eingerichtet (Tailscale-only-Linie). UPnP-Selbstfreigabe-Recht fuer VONETS-Bridge (SolarEdge) deaktiviert. Aktiver Soll-Stand: ausschliesslich `443/tcp -> 192.168.178.58`. |
 | FRITZ!OS 8.21 Update | gemeldet | Operator-Aufgabe; vor Update kurzes Service-Fenster planen, weil Reboot WAN/Tailscale-Aufbau unterbricht |
 | Gast-/IoT-Zugriff auf Admin-Ports | aktuell entschaerft | Gast-WLAN ist inaktiv; bei Aktivierung muessen `192.168.178.58:8082`, `192.168.178.58:8181` und ggf. weitere LAN-Ports per FRITZ!Box-Kindersicherung/Netzwerk-Filter abgesichert werden |
 | IPv6 Exposure | offen | Router und Traefik/Cloudflare pruefen; Telekom-DSL liefert in der Regel IPv6, FRITZ!Box-Standard-Verhalten klaeren |