Files

T

Micha dda6021116 docs: record tailscale acl plan and watcher activation

2026-06-05 23:27:40 +02:00

15 KiB

Raw Blame History

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; Tailscale-Inventar am 2026-06-05 real gemessen. Letzte Pruefung: 2026-06-05 (Tailscale-Inventar), 2026-06-01 (Router/Ports)

Zweck

Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennung. Es ergaenzt das Architektur-Zielbild in HOMELAB_ARCHITECTURE_MASTER_V2.md um konkrete Hardware- und Betriebswerte.

Internet und Router

Feld	Wert
Anschluss / Provider	DSL, Telekom
Bandbreite (FRITZ!Box-UI)	ca. 87,3 Mbit/s Download, ca. 36 Mbit/s Upload
Router-Modell	FRITZ!Box 7590
Firmware	FRITZ!OS 8.25 (`154.08.25` per TR-064 am 2026-06-01)
Router-IP	192.168.178.1
DHCP-Server	FRITZ!Box (Standardannahme, Override durch Operator nicht dokumentiert)
Lokales Subnetz	192.168.178.0/24
IPv6 aktiv	Windows-Client hat Provider-IPv6; Host hat keine globale Provider-IPv6, nur Tailscale-ULA
DynDNS / DDNS	Cloudflare via `ddns-updater` (kein FRITZ!Box-DynDNS in Nutzung)
Heimnetz-Geraete (FRITZ!Box-UI)	35 aktive Geraete
LAN-Ports belegt	LAN 1-4 verbunden
Telefonie / DECT	aktiv
USB an FRITZ!Box	nicht verbunden
Ausfallschutz (FRITZ!Box)	nicht eingerichtet (Mobilfunk-Stick-Failover nicht aktiv)

Beobachtungen

Telekom-DSL ist Single-WAN; ohne Ausfallschutz ist Internet-Ausfall = kein DDNS-Update, keine ACME-Erneuerung, keine externen Push-Quellen.
Upload 36 Mbit/s ist die effektive Obergrenze fuer Off-site-Backup-Geschwindigkeit nach Hetzner und fuer Plex-Remote-Streaming.
FRITZ!OS ist am 2026-06-01 per TR-064 auf 154.08.25 beobachtet; FRITZ!Box-Konfig-Backup Einstellungen_FRITZ.Box_7590_154.08.25_01.06.26_1318.export wurde extern/off-system in Vaultwarden abgelegt.
Internet -> Freigaben -> FRITZ!Box-Dienste ist am 2026-06-01 geprueft: Internetzugriff auf die FRITZ!Box per HTTPS ist aus, FTP/FTPS-Zugriff auf Speichermedien ist aus.

DNS

Komponente	Rolle	Adresse	Bemerkung
AdGuard Home	LAN DNS / Filter	Host `192.168.178.58`, Docker `172.23.0.3`	DNS auf Port 53; Admin soll nur via Tailscale-IP `100.80.98.33:8082` erreichbar sein
Unbound	Rekursiver Resolver	Docker `dns_net`	Upstream fuer AdGuard
Cloudflare	Authoritative DNS	extern	DNS-Challenge fuer TLS
Router	DHCP DNS-Verteilung	TBD	Muss auf AdGuard zeigen, falls so betrieben

Tailscale

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

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):

tailscale status
tailscale status --json | jq '{exitNode: .Self.ExitNodeOption, primaryRoutes: .Self.PrimaryRoutes, allowedIPs: .Self.AllowedIPs}'
tailscale ip -4
tailscale ip -6

ACL-Policy — Entwurf und Rollout-Plan (Stand 2026-06-05, NICHT angewendet)

Die Tailnet-ACL wird in der Tailscale-Admin-Konsole unter Access controls verwaltet (kein Wert/Secret gehoert ins Repo). Aktueller Live-Stand ist Default-Allow (src: ["*"] -> dst: ["*:*"]), d. h. jedes Tailnet-Geraet darf alles inklusive der LAN-Subnet-Route.

Abgestimmte Richtung (Operator-Entscheidungen 2026-06-05):

Ziel ist eine restriktivere, Tag-basierte ACL.
Single-User-Realitaet: aktuell gehoeren alle Nodes demselben User michaelkaleschke@. Eine Differenzierung Operator/Familie ist nur ueber Tags moeglich. Tagging aendert Ownership/Key-Expiry und erfordert je Geraet Re-Auth — deshalb bewusst ein eigener, spaeterer Schritt.
Heute bewusst nur Sichtung + Entwurf, kein Tagging, keine Anwendung.
Familiengeraete brauchen Tailnet-Zugriff auf bestimmte Dienste (welche genau, ist noch zu konkretisieren) — tag:family bekommt gezielte dst-Regeln.
iphone-14 ist ein Operator-Geraet und faellt unter tag:operator.

Geraete -> Tag (fuer den spaeteren Tagging-Schritt):

Tag	Geraete
`tag:server`	`kallilabcore` (Host, Subnet-Router)
`tag:operator`	`baerchen-1`, `iphone-14`
`tag:family`	kuenftige Familiengeraete

Entwurf (Vorschlag, noch nicht in der Konsole gespeichert):

{
  "tagOwners": {
    "tag:server":   ["autogroup:admin"],
    "tag:operator": ["autogroup:admin"],
    "tag:family":   ["autogroup:admin"]
  },
  "autoApprovers": {
    "routes": { "192.168.178.0/24": ["tag:server"] }
  },
  "acls": [
    { "action": "accept", "src": ["tag:operator"], "dst": ["*:*"] },
    { "action": "accept", "src": ["tag:server"],   "dst": ["tag:operator:*"] },
    { "action": "accept", "src": ["tag:family"],   "dst": ["100.80.98.33:443"] }
  ],
  "ssh": [
    { "action": "accept", "src": ["tag:operator"], "dst": ["tag:server"],
      "users": ["root", "autogroup:nonroot"] }
  ]
}

Die tag:family-dst 100.80.98.33:443 ist ein Platzhalter und wird durch die real benoetigten Familien-Dienste ersetzt, sobald diese feststehen.

Lockout-sichere Reihenfolge (wenn die Umsetzung freigegeben wird):

tagOwners + autoApprovers + neue ACL-Regeln speichern, Allow-all-Regel zunaechst behalten.
Geraete taggen (baerchen-1, iphone-14 -> operator; kallilabcore -> server) und je Geraet die Verbindung verifizieren.
Subnet-Route bleibt approved (jetzt via autoApprovers/tag:server).
Erst zuletzt die Allow-all-Regel entfernen -> restriktiv schalten.
Sofort Smoke-Tests fahren (siehe unten).

Smoke-Tests nach Anwendung:

baerchen-1 erreicht Host: ping 100.80.98.33, ssh kallilabcore hostname (read-only).
baerchen-1 erreicht LAN ueber Route: z. B. AdGuard-Admin http://100.80.98.33:8082, curl -kI https://192.168.178.58.
Falls testbar: ein nicht-Operator-Geraet erreicht Route/Admin-Ports nicht mehr.
Host-Gegencheck: tailscale status zeigt alle Soll-Peers weiter verbunden.

Noch offene Eingaben vor Finalisierung:

Aktueller ACL-JSON aus der Admin-Konsole (read-only gesichtet, nur Struktur dokumentiert).
Konkrete Liste der Dienste/Ports, die Familiengeraete ueber Tailscale brauchen.

Portfreigaben und Exposure

FRITZ!Box (WAN -> Host)

Aktiver Soll-Stand nach Operator-Bereinigung und UI-Gegencheck 2026-06-01:

Aktive Freigabe	Ziel	Zweck	Bemerkung
`443/tcp` -> `192.168.178.58:443`	Traefik HTTPS	einziger Public-HTTPS-Einstieg, Wildcard-Cert via Cloudflare-DNS-Challenge	bleibt

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-06-01 erneut geprueft und 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 hier als bewusste Ausnahme dokumentiert oder pro Geraet wieder deaktiviert.

Historischer UI-Befund vor Bereinigung vom 2026-05-27 (Internet -> Freigaben -> Kallilabcore):

Beobachtung	Bewertung
`HTTP-Server`, TCP, extern `80/tcp` auf `192.168.178.58`	war Abweichung; 2026-05-28 entfernt
`HTTPS-Server`, TCP, extern `443/tcp` auf `192.168.178.58`	entspricht Repo-Soll
Keine `222/tcp`-Freigabe sichtbar	entspricht seit 2026-05-28 dem Soll: Gitea-SSH bleibt Tailscale-only
Kallilabcore: keine selbststaendige Portfreigabe, kein IPv4-/IPv6-Exposed-Host sichtbar	entspricht Sicherheitsziel
`PC-192-168-178-71`: selbststaendige Portfreigabe erlaubt, `0 aktiv`	2026-06-01 deaktiviert; danach nur noch `Kallilabcore` in der Portfreigabenliste sichtbar

Host (lokal beobachtbar)

Port	Ziel	Zweck	Bewertung
80/tcp	Traefik	HTTP->HTTPS / ACME	nur LAN, keine WAN-Freigabe noetig
443/tcp	Traefik	HTTPS	WAN-Freigabe in FRITZ!Box erwartet
222/tcp	Gitea SSH	Git SSH	nur LAN/Tailscale; keine WAN-Freigabe
53/tcp+udp	AdGuard	DNS	LAN-only, dokumentierte Ausnahme
8082/tcp	AdGuard Admin	Admin UI	Bind nur `100.80.98.33:8082` (Tailscale), nicht im LAN exponiert
8181/tcp	InfluxDB 3 Core	Home Assistant / Ecowitt Writer	2026-05-31 effektiv nur `127.0.0.1:8181`, nicht LAN-exponiert

Pruefkommando:

ss -ltnp | sort -k4
docker ps --format "{{.Names}}: {{.Ports}}" | sort

Netztrennung

Netz	Status	Bemerkung
LAN	192.168.178.0/24	Hauptnetz, Host `192.168.178.58`, FRITZ!Box meldet 35 aktive Geraete
WLAN 2,4 / 5 GHz	aktiv, SSID `Fritzi`	Standard-WLAN, im LAN-Adressbereich, kein eigener Adressraum
Gast-WLAN	inaktiv (FRITZ!Box-UI)	Solange inaktiv: kein Gast-Pfad zu LAN-Diensten; AdGuard-Admin-Trennung primaer ueber Tailscale-Bind statt Netzsegmentierung
IoT-Netz	nicht existent	Keine VLAN-Trennung dokumentiert
Tailscale	aktiv	Operator-Zugang, Host-IP `100.80.98.33`
VLANs	nicht in Nutzung	FRITZ!Box 7590 kann VLAN-Tagging an einzelnen LAN-Ports; aktuell nicht konfiguriert

Docker-Netze

Authoritativ ist HOMELAB_ARCHITECTURE_MASTER_V2.md. Dieses Inventar haelt nur den Laufzeit-Snapshot fest.

Docker-Netz	Zweck	Erwartung
frontend_net	Traefik/Web	external bridge
backend_net	DB/Cache intern	internal bridge
dns_net	AdGuard/Unbound	bridge
monitoring_net	Observability	compose-intern
app-interne Netze	Stack-isoliert	nur wenn technisch noetig