backup: windows image baseline for baerchen

docs/NETWORK_INVENTORY.md

@@ -1,7 +1,7 @@
 # Network Inventory - KalliLab CORE
 
-Status: Host-Audit erfasst; Router-Baseline und Portfreigaben-UI bereinigt; FRITZ!Box-Remote-Dienste aus; IPv6-Exposure technisch und per UI entschaerft.
-Letzte Pruefung: 2026-06-01
+Status: Host-Audit erfasst; Router-Baseline und Portfreigaben-UI bereinigt; FRITZ!Box-Remote-Dienste aus; IPv6-Exposure technisch und per UI entschaerft; Tailscale-Inventar am 2026-06-05 real gemessen.
+Letzte Pruefung: 2026-06-05 (Tailscale-Inventar), 2026-06-01 (Router/Ports)
 
 ## Zweck
 
@@ -44,23 +44,70 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun
 
 ## Tailscale
 
-| Feld | Wert |
+Gemessen am 2026-06-05 per read-only SSH auf den Host (`tailscale status`,
+`tailscale status --json`, `tailscale ip -4/-6`).
+
+| Feld | Wert / Status |
 |---|---|
 | Node-Name | Kallilabcore |
-| Tailscale IPv4 | 100.80.98.33 |
-| Tailscale IPv6 | TBD |
-| Exit Node | TBD |
-| Subnet Router | TBD |
-| ACL-Policy extern dokumentiert | TBD |
+| Tailnet / MagicDNS | `taild9fcf2.ts.net`; DNSName `kallilabcore.taild9fcf2.ts.net` |
+| Tailscale IPv4 | `100.80.98.33` |
+| Tailscale IPv6 | `fd7a:115c:a1e0::2c01:62b2` (gemessen 2026-06-05) |
+| Exit Node | **Nein.** `Self.ExitNodeOption: false` und `Self.ExitNode: false` — Host bietet keinen Exit Node an und nutzt keinen. Entspricht dem Ziel (Operator-Zugang ist eingehend, nicht als Internet-Ausgang). |
+| Subnet Router | **Ja, aktiv.** Host advertised und ist Primary fuer `192.168.178.0/24` (`Self.PrimaryRoutes: ["192.168.178.0/24"]`, ebenfalls in `AllowedIPs`). Das LAN ist also fuer das gesamte Tailnet ueber diesen Subnet-Router erreichbar — bewusst gemessener Ist-Zustand, **kein** "keine Route" wie zuvor vermutet. |
+| ACL-Policy extern dokumentiert | **Operator-Entscheidung offen** — siehe eigener Block unten; durch den aktiven Subnet-Router ist die ACL-Frage sicherheitsrelevanter als zuvor angenommen. |
 
-Pruefkommando:
+### Tailnet-Geraete (Snapshot 2026-06-05)
+
+| Tailscale-IP | Node | OS | Status |
+|---|---|---|---|
+| `100.80.98.33` | kallilabcore | linux | aktiv (Host, Subnet-Router) |
+| `100.78.133.37` | baerchen-1 | windows | aktiv (aktuelle Operator-Workstation, direct) |
+| `100.105.203.21` | baerchen | windows | offline, zuletzt vor ~1 Tag gesehen (Alt-Node) |
+| `100.73.83.55` | iphone-14 | iOS | bekannt |
+| `100.112.0.90` | kallilab-core | linux | gelistet, kein aktiver Verkehr — **moeglicher Alt-/Dubletten-Node**, separat pruefen |
+
+> Hygiene-Hinweis (kein Secret): Es existieren zwei linux-Nodes mit aehnlichem
+> Namen (`kallilabcore` und `kallilab-core`) sowie zwei `baerchen`-Nodes
+> (`baerchen-1` aktiv, `baerchen` offline). Bei Gelegenheit in der
+> Tailscale-Admin-Konsole pruefen, ob die inaktiven Eintraege stillgelegt werden
+> koennen. Das ist Aufraeumarbeit, kein akutes Risiko.
+
+### Subnet-Router-Konsequenz
+
+Weil `Kallilabcore` das LAN `192.168.178.0/24` als Subnet-Route anbietet, kann
+**jedes** Tailnet-Geraet mit Zugriff auf diese Route potenziell LAN-Dienste auf
+`192.168.178.0/24` erreichen — auch die Admin-Ports, die im LAN bewusst nur auf
+die Tailscale-IP gebunden sind, sind ueber die Subnet-Route adressierbar. Genau
+deshalb ist die ACL-Policy (unten) der eigentliche Schutzmechanismus und nicht
+nur der LAN-Bind.
+
+Pruefkommando (auf dem Unraid-Host, read-only):
 
 ```bash
 tailscale status
+tailscale status --json | jq '{exitNode: .Self.ExitNodeOption, primaryRoutes: .Self.PrimaryRoutes, allowedIPs: .Self.AllowedIPs}'
 tailscale ip -4
 tailscale ip -6
 ```
 
+### ACL-Policy (Operator-Entscheidung offen)
+
+Die Tailnet-ACL ist aktuell nicht im Repo gespiegelt. Sie wird in der
+Tailscale-Admin-Konsole unter `Access controls` verwaltet (kein Wert/Secret
+gehoert ins Repo). Offene Entscheidung:
+
+- Default-Allow belassen (jedes Tailnet-Geraet darf alles, inkl. der
+  LAN-Subnet-Route), **oder**
+- restriktivere, Tag-basierte ACL einfuehren: nur Operator-Geraete duerfen die
+  Subnet-Route `192.168.178.0/24` und die Admin-Ports nutzen, Familien-/Mobil-
+  geraete nur die explizit benoetigten Dienste.
+
+Empfehlung (zur Entscheidung, nicht umgesetzt): Da der Subnet-Router das ganze
+LAN ins Tailnet bringt, ist eine restriktive ACL der wirksamste Hebel. Naechster
+Schritt waere, die aktuelle Policy read-only aus der Admin-Konsole zu sichten
+und dann eine Tag-Struktur (`tag:operator`, `tag:family`) zu entwerfen.
+
 ## Portfreigaben und Exposure
 
 ### FRITZ!Box (WAN -> Host)
@@ -154,7 +201,7 @@ docker network inspect backend_net | jq '.[0].Internal'
 | FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | **erledigt 2026-06-01** | 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-Selbstfreigaben sind aus. Aktiver Soll-Stand: ausschliesslich `443/tcp -> 192.168.178.58`. |
 | FRITZ!Box-Dienste aus dem Internet | **erledigt 2026-06-01** | `Internet -> Freigaben -> FRITZ!Box-Dienste`: HTTPS-Zugriff auf die FRITZ!Box aus dem Internet aus; FTP/FTPS auf Speichermedien aus. |
 | FRITZ!OS Update und Konfig-Backup | **erledigt 2026-06-01** | TR-064 meldet `154.08.25`; Konfig-Export liegt extern/off-system in Vaultwarden, Kennwort und Datei bleiben ausserhalb des Repos. |
-| 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 |
+| Gast-/IoT-Zugriff auf Admin-Ports | **Entscheidungspunkt: kein Gast-/IoT-Netz aktivieren, solange nicht gebraucht** | Aktuell entschaerft, weil Gast-WLAN inaktiv ist und kein IoT-VLAN existiert. Risiko entsteht erst bei Aktivierung. Harte Vorbedingung fuer eine spaetere Aktivierung: **vor** dem Einschalten von Gast-WLAN/IoT muessen `192.168.178.58:8082` (AdGuard-Admin, ohnehin Tailscale-gebunden), `192.168.178.58:8181` (InfluxDB, bereits `127.0.0.1`-bound) und alle weiteren LAN-Admin-Ports per FRITZ!Box-Netzwerkfilter/Kindersicherung gegen das Gastsegment gesperrt sein. Bis dahin bewusst kein Gastnetz. |
 | IPv6 Exposure | technisch und per UI entschaerft | Public DNS liefert keine AAAA-Records fuer `*.kaleschke.info`; Host hat keine globale Provider-IPv6. TR-064 meldet IPv6-Firewall aktiv und Pinholes grundsaetzlich erlaubt; FRITZ!Box-UI zeigt keine aktiven IPv6-Freigaben, keine Admin-/SSH-Freigaben. |
-| WAN-Ausfallschutz | bewusst nicht eingerichtet | Mobilfunk-Stick-Failover an FRITZ!Box ist nicht aktiv; Internet-Ausfall = ACME/DDNS pausieren, lokale Apps laufen weiter |
+| WAN-Ausfallschutz | **geparkt: spaeter evaluieren** (Operator-Entscheidung 2026-06-05) | Mobilfunk-Stick-Failover an FRITZ!Box bleibt vorerst inaktiv. Folgen sind bewusst akzeptiert: Internet-Ausfall = ACME/DDNS pausieren, lokale Apps laufen weiter. Review-Trigger: haeufigere oder laengere DSL-Ausfaelle, oder wenn externer Remote-Zugang (statt nur lokalem Betrieb) geschaeftskritisch wird. Erst dann Mobilfunk-Failover technisch bewerten. |
 | Home Assistant InfluxDB Bind | validiert 2026-05-31 | `docker-proxy` bindet `127.0.0.1:8181`; keine LAN-Exposure. Wenn Home Assistant nicht lokal auf dem Host schreibt, braucht das eine bewusste Bind-Aenderung. |