Recherche „Zugriff von außen“ (Stand 28.10.2026)¶
Arbeitsstand der Recherche
Dieser Bericht ist eine Belegsammlung aus der D1-Session (27./28.10.2026). Er enthält Einschätzungen, die später anders entschieden wurden. Verbindlich ist das D1-Design.
Kennzeichnung: [B] belegt (Quelle mit Datum), [E] Einschätzung. Nur Recherche, keine Änderungen.
Ausgangslage aus der eigenen Doku [B, homelab-documentation/docs/architecture/network.md]: Die Heim-IP ist per Cloudflare-DDNS (ddns./udm.robinwerner.net, unproxied) als A-Record veröffentlicht, TeamSpeak läuft über UDM-Forwards 9987/udp + 30033/tcp. Daraus folgt: kein CG-NAT, öffentliche IPv4 vorhanden. Ob der 443-Forward aktiv ist, ist laut Doku unverifiziert. IPv6 am Anschluss ist dort nicht dokumentiert.
Kurzfazit und empfohlene Gesamt-Topologie [E]¶
- Eine öffentliche Tür: der Hetzner-VPS. Traefik auf dem VPS als reiner TCP-Router mit
HostSNI+tls.passthrough+ PROXY-Protocol v2 über einen WireGuard-/Tailnet-Tunnel zum NUC-Traefik. TLS endet zu Hause, die Heim-IP verschwindet aus dem DNS, die UDM-Forwards (443, TeamSpeak) fallen weg. - Home Assistant ohne VPN, aber mit mTLS: Der NUC-Traefik verlangt für
ha.ein Client-Zertifikat (clientAuth: RequireAndVerifyClientCert). Die iOS-Companion-App kann das seit 2026.3. Seit App-Version 2026.8 ist die Funktion nicht mehr experimentell. Dahinter läuft der normale HA-Login (lokale Konten + TOTP, oderhass-oidc-auth). Rückfallebene: Nabu Casa für 75 €/Jahr, falls die Standort-Webhooks mit mTLS im Hintergrund nicht zuverlässig ankommen. - Immich:
immich-public-proxy(IPP) öffentlich für geteilte Alben. Immich selbst bleibt hinter mTLS (die iOS-App kann das seit v2.6.0) oder hinter VPN. - Jellyfin: Die iOS-Clients können kein mTLS. Also entweder öffentlich mit CrowdSec + Geo-Block DE + fail2ban + sofortigen Updates, oder nur über VPN. Vorher klären, ob Lars Jellyfin unterwegs überhaupt nutzt („Läuft ≠ genutzt“).
- TeamSpeak zieht direkt auf den VPS (UDP 9987, TCP 30033). Bis Ende 2027 TS3 → TS6 entscheiden (siehe unten).
- VPN (Headscale oder NetBird) nur noch für Admin. Ein Wechsel zu NetBird ist eine eigene, getrennte Entscheidung und keine Voraussetzung.
- Phasen: (a) mTLS für HA mit einem iPhone 2 Wochen testen, Standortverlauf in der App prüfen (Companion → Troubleshooting → Location history). (b) Danach Immich/IPP. (c) Jellyfin erst nach der Nutzungsfrage. (d) Talos/Cilium 2027 ändert an der Topologie nichts: Der VPS leitet dann auf die Cilium-LB-IP statt auf den NUC.
Ausfallverhalten: Ist der VPS weg, ist der Fernzugriff weg; das LAN bleibt über Split-DNS unberührt. Notweg: VPN, Nabu Casa (falls abonniert) oder vorübergehend ein UDM-Forward. Ein VPS-Ausfall ist derselbe Single Point of Failure wie heute bei Headscale.
A. Home Assistant ohne VPN sicher exponieren¶
A.0 Wie Standort-Updates technisch laufen¶
| Punkt | Befund | Quelle |
|---|---|---|
| Transport | Die App schickt alles an einen Webhook /api/webhook/<id>. Der braucht kein Access-Token, „the webhook ID is the credential“. Reihenfolge: Cloudhook-URL → Remote-UI-URL (Nabu Casa) → eigene URL |
[B] HA Contributor Docs „Send data“ (abgerufen 28.10.2026) |
| Verschlüsselung | Die iOS-App verschlüsselt Sensor-/Standort-Payloads zusätzlich mit libsodium (Secret aus der Registrierung). Android tut das nicht | [B] Companion Docs „How the app handles your data“ |
| HA-Doku zu VPN | „When using the Home Assistant Companion app … without this connection [VPN], your sensors will not update in Home Assistant.“ | [B] home-assistant.io/docs/configuration/remote |
| Unterwegs nicht erreichbar | Persistente Webhooks laufen über eine iOS-Background-URLSession mit timeoutIntervalForResource = 2 h. iOS wiederholt den Versand also bis zu 2 Stunden, danach ist das Update verloren |
[B] WebhookManager.swift, Branch main (abgerufen 28.10.2026) |
| Ersetzen statt Stapeln | Ein neues Update desselben Typs bricht ein noch hängendes älteres ab (evaluateCancellable / shouldReplace). HA bekommt nach dem Wiederverbinden die letzte Position, keinen Verlauf |
[B] Code; [E] Folge für Location |
| Zonen-Events | ios.zone_entered wurde 2024 per sendEphemeral geschickt, also ohne Hintergrund-Retry. Ist HA in dem Moment nicht erreichbar, geht das Event verloren. Der Zonenzustand kommt später mit dem nächsten update_location |
[B] Log in iOS-Issue #2796 (27.05.2024); [E] dass das heute noch so ist |
| Auth-Gates vor HA brechen Tracking | Cloudflare-Access-OTP vor HA blockierte die Standort-Updates, die UI lief weiter | [B] home-assistant/iOS#2796 (Aug 2024 / Jan 2025) |
| Nabu-Casa-Änderung | „Local-only“-Nutzer (Abo aktiv, Remote Access aus) bekommen keine Cloudhooks mehr. Das ist so gewollt | [B] home-assistant/iOS#4618, bgoncal 19.05.2026 |
Folge [E]: Damit das Tracking funktioniert, muss /api/webhook/* von unterwegs ohne interaktiven Login erreichbar sein. Forward-Auth/OTP davor ist ausgeschlossen (deckt sich mit der früheren Entscheidung). Es bleiben: offen + HA-Auth, mTLS (Gerät authentisiert sich ohne Interaktion), Nabu Casa oder VPN.
A.1 Optionen im Vergleich¶
| Option | iOS-App + Hintergrund-Standort | Sicherheit | Aufwand | Stand/Quelle |
|---|---|---|---|---|
(a) Öffentlich, HA-Login + TOTP + ip_ban_enabled |
funktioniert voll | HA-Core direkt im Internet. Advisories 2026 sind überwiegend LAN-/Frontend-Themen; dazu kommt eine unauthentifizierte Path-Traversal im Onboarding-Fenster (<2026.6.0). Webhook-ID ist das einzige Geheimnis | gering | [B] HA Securing-Checkliste; HTTP-Integration (IP-Bans laufen nicht ab); GHSA-5hxg-r395-fqxx (21.07.2026) |
(b) hass-oidc-auth |
App-Login per Device-Code (Code in Safari eingeben), danach normaler Token-Betrieb. Webhooks unberührt | Ändert nur den Login, nicht die Angriffsfläche. HA bleibt exponiert, und der IdP muss für den Login auch von außen erreichbar sein | mittel | [B] v1.0.x „stable“ (21.04.2026); v1.1.0 trusted_networks (14.05.2026); v1.1.1 Fix „alternative method“ in der Mobile-App (08.06.2026); v1.2.0/1.2.1 (19.08.2026): Fix Open Redirect GHSA-gg9c-6c2r-6x28 + Device-Code-Hänger. FAQ: keine Session-/Backchannel-Logout-Unterstützung |
| (c) mTLS / Client-Zertifikat | iOS: ja. Experimentell ab 2026.3 (PR #4362, gemergt 24.02.2026), laut frenck nicht mehr experimentell ab App 2026.8 (09.10.2026). Abgedeckt: WebView, Token-Austausch, WebSocket, Webhook-Hintergrund-Uploads. Grenzen: Apple Watch nein, Local Push „may not work“, Siri/Shortcuts eingeschränkt. Intermediate-CA-Ketten erst seit Fix April 2026 | stärkste Variante ohne VPN: ohne Zertifikat kommt niemand an HA heran, auch nicht an den Webhook | mittel (eigene CA, .p12 je Gerät, Traefik-TLS-Option) | [B] GitHub-Discussion #1078 (Antwort 09.10.2026); docs/mTLS.md im iOS-Repo (Datei trägt noch das Label „experimental“); iOS#4477 (April 2026). [E] Hintergrund-Versand mit Zertifikat vor dem Rollout testen: im Feb. 2026 hieß es noch „background operations hit and miss“ |
| (d) Nabu Casa / „Home Assistant Link“ | funktioniert voll, offiziell unterstützt (Cloudhooks + Remote-UI) | E2E-TLS über SniTun (SNI-Routing, privater Schlüssel nur lokal, CT-Logs prüfbar). Blockiert Remote Access für bekannt unsichere HA-Versionen. Heim-IP verborgen | sehr gering | [B] Preis EU 7,50 €/Monat oder 75 €/Jahr inkl. MwSt (nabucasa Pricing; bestätigt Aug./Sep. 2026). Umbenennung in „Home Assistant Link“ angekündigt 02.10.2026, Umstellung im Dezember, Preis unverändert (tink.nl 03.10.2026). Security-Aspekte: Nabu-Casa-Support |
| (e) VPN-on-Demand | funktioniert, solange der Tunnel steht | sehr gut (nichts öffentlich) | gering bis mittel, aber Akzeptanzproblem | [B] Tailscale VPN On Demand ab iOS 1.48 (Doku validiert 05.01.2026). Nur eine VPN-App mit On-Demand gleichzeitig. Akku: „known issue (#3363)“ (Doku 20.03.2026), neue Drain-Berichte unter iOS 26 (Issue #20136, Juni/Juli 2026). NetBird iOS On-Demand seit 20.03.2026 (ios-client PR #70); offener Bug #6041: Endlosschleife nach Session-Ablauf (30.04.–21.06.2026), Fix-PR #85 |
Was HA empfiehlt [B]: Die Remote- und Securing-Doku nennt Home Assistant Cloud „the easiest and safest option for most people“. VPN ist die zweite Option, mit dem Hinweis, dass Sensoren ohne Tunnel nicht aktualisieren.
Einschätzung für Robin + Lars [E]: Robins eigene Messung (iPhone seit Wochen nicht im Tailnet) zeigt: VPN-on-Demand wird im Alltag nicht durchgehalten, und der Akkuverbrauch ist ein belegtes Dauerthema. Für das Tracking zählen nur zwei Wege ohne Nutzerdisziplin: mTLS (selbst betrieben) oder Nabu Casa (fertig, kostet Geld, unterstützt das HA-Projekt). (a) ist machbar, aber die schwächste Variante. (b) löst ein Login-Problem, kein Expositionsproblem, lässt sich aber mit (c) kombinieren.
B. Immich: Freigaben öffentlich, der Rest privat¶
| Punkt | Befund | Quelle |
|---|---|---|
| IPP-Stand | v4.1.2 (23.10.2026), Node-Bump wegen CVE-2026-111497. v4.1.0 (19.10.) mit Namensfeld bei Gast-Uploads; v4.0.0 (07.10.) mit optionalem Upload-Container + Container-Härtung; v3.0.0 (30.06.2026) kompatibel mit Immich 3.x. Lizenz AGPL-3.0 | [B] GitHub-Releases alangrainger/immich-public-proxy |
| IPP-Sicherheitsmodell | Kein API-Key, zustandslos, read-only. Fragt Immich per LAN nur nach dem Inhalt eines Share-Keys; alles Unerwartete → 404. Respektiert Passwort, Ablauf, Download-Erlaubnis und Metadaten-Schalter des Links. Begründung: Immichs eigene Share-Seite braucht /api/, das müsste dann öffentlich sein. „The ideal setup is Immich secured behind mTLS or a VPN, with public access only to IPP.“ |
[B] docs.ipp.nz Introduction / How to use |
| Einrichtung | In Immich „External domain“ auf die IPP-URL setzen, dann erzeugt Immich die passenden Links. IPP lauscht auf :3000 hinter dem Reverse Proxy, PUBLIC_BASE_URL setzen |
[B] docs.ipp.nz Installation / Reverse proxy |
| Warum Immich nicht direkt raus | Advisories 2026: kritisches XSS mit Account-Übernahme in main-Builds (GHSA-8244, 01.06.2026, kein Release betroffen); Shared-Link-Authz-Bypass (GHSA-hvq7, ≤2.1.0, Fix 3.0.0, 06.07.2026); Share-Link mit fremden Assets (GHSA-g4w3, ≤3.1.0, Fix 3.2.0, 19.10.2026); authentifiziertes SVG→ImageMagick-RCE (GHSA-q89f, 28.09.2026); Share-Passwort im GET-Query (<2.6.0) |
[B] immich-app Security Advisories |
| App-Zugang für Robin/Lars | Mobile-App nutzt seit v2.6.0 (19.03.2026) native HTTP-Clients auf iOS/Android mit mTLS, Custom-Headers, Basic-Auth, auch für Hintergrund-Tasks und Video. Achtung: iOS-Issue #27362 (P12-Import auf iOS 16 kaputt, März 2026); im Okt. 2026 fragt jemand, ob mTLS auf iOS wirklich geht | [B] Immich-Blog v2.6.0; PR #25802; Issue #27362; Kommentar in PR #10860 (23.10.2026) |
| OAuth | Mobile-Redirect app.immich:///oauth-callback; alternativ /api/oauth/mobile-redirect als https-Override |
[B] Immich-Doku OAuth (Stand 27.07.2026) |
| Rate-Limits | Immich hat keine eingebaute Login-Drosselung. Üblich ist fail2ban/CrowdSec am Proxy auf 401 POST /api/auth/login |
[B] Immich-Discussions #3243, #23802 (11.11.2025); [E] dass es nichts Eingebautes gibt: keine Doku-Fundstelle dafür |
| Upload-Größe | Proxy muss große Bodies erlauben, Request-Buffering aus | [B] Immich Reverse-Proxy-Doku |
Alternativen [E]: Pangolin-Share-Links oder NetBird-Reverse-Proxy mit PIN/Passwort vor einer IPP-ähnlichen Instanz. Für Dritte ohne Konto ist IPP aber die sauberste Lösung, weil Immich dabei gar nicht öffentlich wird.
C. Jellyfin öffentlich¶
| Punkt | Befund | Quelle |
|---|---|---|
| Aktuelle Version | Jellyfin 12.0 (07./08.09.2026; neues Versionsschema), „contains security fixes“ | [B] jellyfin.org-Blog 07.09.2026; GitHub-Release v12.0 |
| Unauth. Datei-Lesen | CVE-2026-35033 / GHSA-jh22: ffmpeg-Argument-Injection über /Videos/{id}/stream, Endpunkt ohne [Authorize], CVSS-B 9.3. Fix 10.11.7 (14.04.2026). Braucht eine Item-GUID |
[B] NVD / GHSA (14.04.2026) |
| Unauth. vor dem Setup | GHSA-6828: Path-Traversal in VirtualFolders, anonym möglich, solange der Setup-Wizard nicht abgeschlossen ist. Kritisch 9.1, Fix 12.0 (22.09.2026) | [B] GHSA-6828 |
| Weitere 2026 | Subtitle-Upload → RCE (CVE-2026-35031, ≤10.11.6, braucht Upload-Recht); mehrere Path-Traversal/IDOR (Sep. 2026) | [B] Jellyfin Security Advisories |
| Grundproblem | Issue #5415 „Video streams completely unauthenticated“ steht weiter in der Sammelliste. CVE-2025-32012: IP-Spoofing über X-Forwarded-For; seit 10.10.7 muss „Known Proxies“ gesetzt sein | [B] jellyfin#5415; GHSA-qcmf (13.04.2025) |
| Client-Zertifikate | Swiftfin: nein (Maintainer lehnt ab, 2023; neue Nachfrage 23.02.2026). jellyfin-ios: not planned (Sep. 2024). mTLS als Schutzschicht scheidet für iOS-Apps aus | [B] Swiftfin#736, jellyfin-ios#531 |
| Härtung (offiziell) | fail2ban-Jail auf „Authentication request … denied“ (Log-Level Info); Known Proxies; api_key nicht im Proxy-Log |
[B] Jellyfin-Doku Reverse Proxy / fail2ban |
| Geo-Block | UDM CyberSecure „Region Blocking“ gilt global vor den eigenen Regeln. Ausnahmen gehen nur über Zone-Based-Firewall mit Regionsauswahl | [B] Ubiquiti Community (Jan. 2026) |
| CrowdSec auf UDM | Community-Bouncer wolffcatskyy/crowdsec-unifi-bouncer (v2.5.4, 24.09.2026; UDM Pro ≈ 50.000 ipset-Einträge). Nicht von Ubiquiti oder CrowdSec |
[B] GitHub |
Einschätzung [E]: Mit 2 Nutzern und ohne mTLS-fähigen Client ist Jellyfin der Dienst mit dem schlechtesten Verhältnis von Nutzen zu Risiko. Wenn öffentlich, dann: nur über den VPS-Eingang, CrowdSec-Bouncer am VPS-Traefik oder an der UDM, Geo-Allowlist DE (+ Urlaubsländer bei Bedarf), Known Proxies, Updates zeitnah. Sonst nur über VPN. Erst klären, ob Lars Jellyfin außer Haus nutzt.
D. Topologie des Eingangs¶
D.1 Varianten¶
| Variante | Pro | Contra | Reife/Quelle |
|---|---|---|---|
D1: VPS-Traefik, TCP HostSNI + Passthrough + PROXY v2 über WireGuard/Tailnet → NUC-Traefik |
Heim-IP verborgen; TLS und mTLS enden zu Hause; echte Client-IP über PROXY v2 (CrowdSec/fail2ban zu Hause funktionieren); kein Fremdanbieter; Hetzner EU 20 TB Traffic inklusive | VPS = Single Point of Failure; Upload-Bandbreite zu Hause bleibt der Engpass; HTTP-Middleware am VPS wirkungslos (nur IP-Filter auf L4) | [B] Muster: sinkingpoints (16.02.2025), Traefik-Doku TCP-TLS passthrough; Traefik-Issue #12055 (Regression in 3.5.2 bei proxyProtocol, Konfigurationsmigration); Hetzner-Traffic-Doku |
| D2: Direkt 443 an der UDM + CrowdSec/Geo + DDNS | kein Umweg, volle Bandbreite, keine Abhängigkeit vom VPS | Heim-IP öffentlich; Scanner und DDoS treffen den Heimanschluss; Region Blocking ist grob | [B] UniFi Region Blocking (Jan. 2026); CrowdSec-UniFi-Bouncer |
| D3: Pangolin (fosrl) auf dem VPS + Newt zu Hause | fertige UI, Auth vor Ressourcen, Share-Links, seit 1.25 mTLS als Auth-Methode für öffentliche Ressourcen, CrowdSec-Integration | HTTPS-Ressourcen terminieren TLS auf dem VPS. Passthrough nur als Raw-TCP-Ressource ohne Pangolin-Auth (Port-basiert, nicht SNI); ein weiterer Traefik + Badger-Plugin (v1.8.0 laut Release-Notes kaputt) | [B] Pangolin 1.25.3 (23.10.2026); Raw-TCP-Doku; Blog thomaswildetech (18.08.2025) |
| D4: NetBird-Reverse-Proxy | eigene Domains, HTTP mit SSO/PIN/Passwort, L4-TLS-Modus mit SNI-Passthrough, TCP/UDP, CrowdSec, IP-/Länder-Filter | laut Doku Beta (27.10.2026); self-hosted nur mit Traefik; setzt Wechsel zu NetBird voraus | [B] NetBird-Doku Reverse Proxy (27.10.2026); v0.65.0 (13.02.2026) |
| D5: Tailscale Funnel | null Konfiguration | mit Headscale nicht verfügbar; nur *.ts.net, Ports 443/8443/10000, nicht konfigurierbare Bandbreitenlimits |
[B] Headscale-Features-Doku; Tailscale-Funnel-Doku |
| frp / rathole | schlanke Tunnel | eigener Betrieb, keine Auth-Schicht | [E] nicht vertieft, da D1 dasselbe mit dem vorhandenen Traefik leistet |
D.2 Weitere Punkte¶
- CG-NAT/IPv6: Kein CG-NAT (öffentliche IPv4 per DDNS). Die Tunnelrichtung ist trotzdem egal: der NUC baut den Tunnel nach außen auf. IPv6: [E] vor dem Schließen der Forwards prüfen, ob die UDM per IPv6 Dienste freigibt.
- Latenz/Bandbreite: WireGuard-Overhead im LAN-Benchmark: +0,27 ms (Kernel, NetBird) vs. +1,56 ms (userspace, Tailscale) (Blog arthurbrugiere 14.08.2026). Zu Hetzner FSN/NBG kommen nur wenige ms hinzu [E]. Den Engpass setzt der Heimanschluss, nicht der VPS [E]: Jellyfin-Remote-Streams belasten den Heim-Upload, Immich-Video-Uploads vom iPhone dagegen den Heim-Download (meist unkritisch). Durch den VPS-Umweg fällt der Traffic doppelt beim VPS an; das ist bei 20 TB inklusive unkritisch.
- Hetzner-Preise: Preisanpassung zum 15.06.2026 nur für Neubestellungen/Rescales (CX33 neu 8,49 €), bestehende Server unverändert. Den VPS nicht rescalen, sonst greift der neue Preis [B Hetzner-Doku].
- Ausfall: D1/D3/D4: VPS weg = extern alles weg. D2: Heimanschluss weg = ohnehin alles weg. Kombination [E]: TS und IPP auf dem VPS sind unabhängig vom HA-Pfad; für HA bleibt Nabu Casa als Notweg denkbar.
E. NetBird vs. Tailscale vs. Headscale (Stand Okt. 2026)¶
| Merkmal | NetBird (self-hosted) | Tailscale SaaS | Headscale + Tailscale-Clients |
|---|---|---|---|
| Version | v0.81.5 (26.10.2026), v0.82.0-rc.1 (26.10., MySQL entfernt) [B] | Client 1.104.4 (27.10.2026), Tailworm-Fixes [B] | 0.29.6 (24.10.2026), 0.30 in Arbeit (REST/OpenAPI statt gRPC, OAuth-Clients) [B] |
| Subnetze/Routen | „Networks“ + Routing-Peers, HA ohne CLI-Advertise [B] | Subnet-Router, App-Connectors [B] | Subnet-Router, Exit-Nodes, Via [B] |
| Exit-Nodes | ja [B Vergleichsseite NetBird] | ja | ja |
| ACL/Policies | Gruppen + Policies im Dashboard, „Control Center“-Graph [B] | HuJSON/Grants, Tests [B] | ACL/Grants/Tests; OIDC-Gruppen nicht in ACLs [B] |
| SSO/IdP | eingebauter IdP (Dex)/lokale Nutzer (seit v0.62), oder externer OIDC [B] | Fremd-IdPs | OIDC-Registrierung [B] |
| Posture Checks | vorhanden; Cloud erst im Business-Plan. Laut Plans-Doku sind self-hosted nur IdP-Provisioning, Device Approvals, MDM/EDR, Traffic-Event-Logs und Streaming lizenzpflichtig [B] | Premium/Enterprise für Teile | nein [E] |
| iOS On-Demand | seit 20.03.2026, Bug #6041 offen [B] | seit 1.48 [B] | über Tailscale-Client [E] |
| Akku iOS | keine belastbaren Daten [E] | „known issue #3363“ [B] | wie Tailscale [E] |
| DNS | private Zonen (A/AAAA/CNAME) pro Gruppe [B] | MagicDNS | MagicDNS + Extra Records [B] |
| Öffentliche Exposition | Reverse Proxy (v0.65, Beta), netbird expose (v0.66, 24.02.2026) [B] |
Funnel (Limits s. D5) | kein Funnel [B] |
| Komponenten | ein Container netbird-server (Management+Signal+Relay+STUN) + Dashboard + Traefik, Config config.yaml [B] |
– | ein Binary + optional DERP |
| Ressourcen | min. 1 CPU / 2 GB; TCP 80/443, UDP 3478 direkt [B Quickstart 14.10.2026] | – | gering [E] |
| Lizenz | Client BSD-3; management/ signal/ relay/ combined/ + Dashboard AGPL-3.0 seit v0.53 (05.08.2025); Self-Hosting/Heimgebrauch ausdrücklich unberührt [B] |
Client BSD-3, Control-Plane proprietär | BSD-3 [E] |
| Cloud-Free | 5 Nutzer, 100 Maschinen, Routes, ACL, DNS, SSO/MFA [B Pricing] | Personal: 6 Nutzer, unbegrenzt User-Geräte, 50 Tagged [B Vergleich 07.08.2026] | – |
| Security Okt. 2026 | SSH-Session-Härtung in 0.81.5 nach Tailworm [B] | Tailworm: 4 Bulletins TS-2026-014…017 [B] | Tailworm Klasse 3: unauthentifizierte Ressourcenerschöpfung am Control-Server (geprüft 0.29.5). Der 0.29.6-Changelog erwähnt keinen Fix [B]; [E] Fix-Status offen |
Auf 2 vCPU / 4 GB neben Traefik/Authelia/lldap [E]: passt. Konflikt: Die NetBird-Quickstart-Skripte bringen einen eigenen Traefik mit. In den bestehenden Traefik einbinden (gRPC/h2c-Routen laut Doku „External Reverse Proxy“). UDP 3478 muss direkt offen sein.
Migration von Headscale [B Erfahrungsberichte]: Clients neu installieren, Regeln im Dashboard neu bauen, rund ein Wochenende (arthurbrugiere 14.08.2026; iter8lab 30.03.2026: 12 Peers, Parallelbetrieb, danach Headscale-VMs gelöscht). XDA (18.07. und 16.08.2026): NetBird für privat + Pangolin für öffentlich. Lemmy (27.03.2026): positiv nach Headscale. Kein automatischer Migrationspfad [E].
Einschätzung [E]: NetBird ist 2026 eine echte Alternative. Pluspunkte: offizielle, vollständig offene Control-Plane, Web-UI, Lazy Connections, eingebauter Reverse-Proxy. Für Robins Problem (Geräte selten im VPN) löst NetBird aber nichts. Ein Wechsel lohnt sich nur, wenn der NetBird-Reverse-Proxy D1 ersetzen soll (dann aber Beta), oder wegen Headscale-Lücken (Tailworm-Klasse 3, OIDC-Gruppen, kein Funnel). Wenn Identity nach Hause zieht, darf der VPN-Login nicht vom Heim-IdP abhängen. Bei NetBird geht das mit dem eingebauten IdP auf dem VPS, bei Headscale mit Pre-Auth-Keys oder einem IdP auf dem VPS.
F. „Best Practice“ für Familien-Homelabs 2026¶
Mehrere unabhängige Quellen zeigen dasselbe Muster [B]: Admin privat (VPN/Mesh), nur gezielt ausgewählte, familientaugliche Dienste öffentlich hinter Reverse Proxy mit App-Auth/MFA, Logs und Patch-Disziplin. Nie Router/NAS/Hypervisor/Backup-Konsolen öffentlich.
- Cygan Labs „Self-Hosting Remote Access“ (30.04.2026): Muster nach Zielgruppe (nur ich → VPN; wenige Vertraute → identitätsgeschützte Route; alle → Reverse Proxy; Admin immer privat).
- TechGeeks (16.06., 22.06., 13.07.2026): „Family-facing media or photo portal: maybe public through proxy, with strong auth and app hardening“, Admin nur VPN.
- joween.dev (26.07.2026): Mesh-VPN für eigene Geräte, öffentlich nur einzelne Web-Apps.
- kombify (28.04.2026): DNS, TLS, Tunnel und Policies als ein Edge-System behandeln.
- XDA (16.08.2026): NetBird privat + Pangolin für Jellyfin/Immich/Nextcloud/Vaultwarden öffentlich.
- HA-Doku: Cloud als „easiest and safest“; VPN mit Sensor-Einschränkung.
[E] Robins Fall passt genau: Admin über VPN, öffentlich nur HA (mit mTLS), IPP, TS und eventuell Jellyfin, alles über eine Tür.
TeamSpeak 3 (Nebenbefund)¶
- TS3-Server 3.13.8 (27.05.2026) behebt CVE-2026-4390/-4391/-4392 (DoS, teils unauthentifiziert). Docker-Image
teamspeaksystems/teamspeak3-server:3.13.8[B TeamSpeak-Community 27.05.2026]. - TS3 Phased Sunset mit Ziel 31.12.2027 laut TeamSpeak-AGB [B Sekundärquelle licenseware, abgerufen 14.10.2026; Primärtext nicht selbst gelesen].
- TS6-Server weiter Beta (6.0.0-beta13.1, 22.09.2026): 32-Slot-Beta-Lizenz, alle 2 Monate erneuert, kein Migrationspfad TS3 → TS6, TS3-Lizenzen nicht kompatibel [B GitHub/Support 03.10.2026].
- Umzug auf den VPS [E]: unkritisch (wenig CPU/RAM), Heim-IP wird frei; die TeamSpeak-Daten (SQLite) mitnehmen.
Drei überraschende Befunde¶
- Die HA-iOS-App kann mTLS, nicht mehr experimentell seit App 2026.8 (frenck, 09.10.2026). Damit ist HA ohne VPN und trotzdem gut abgeschirmt erstmals realistisch, inklusive Hintergrund-Webhooks (vorher testen).
- Tailworm (24.10.2026) traf neben Tailscale SSH auch Headscale 0.29.5: unauthentifizierte Ressourcenerschöpfung am Control-Server, also genau das, was auf Robins VPS öffentlich hängt. Tailscale hat am 27.10. gepatcht (1.104.4), im 0.29.6-Changelog steht dazu nichts.
- TeamSpeak 3 läuft bis Ende 2027 aus, und der TS6-Server ist noch Beta ohne Migrationspfad. Ein Umzug auf den VPS sollte die TS6-Frage gleich mit einplanen.
Weitere bemerkenswerte Punkte: Die iOS-App puffert Standort-Webhooks nur bis 2 h und ersetzt ältere durch neuere. Jellyfin hatte 2026 einen unauthentifizierten Datei-Lese-Bug über den Stream-Endpunkt (CVSS 9.3), und die Jellyfin-iOS-Clients lehnen mTLS ab. Nabu-Casa-Abos ohne Remote Access bekommen seit Mai 2026 keine Cloudhooks mehr.
Offene Prüfpunkte vor der Entscheidung [E]¶
- Ist der UDM-Forward 443 aktiv? Gibt es IPv6-Freigaben? (Gegenprobe von außen, siehe network.md)
- Nutzt Lars HA/Jellyfin/Immich unterwegs tatsächlich, und wie oft?
- mTLS-Test: HA-App 2026.8+ mit .p12 (volle Kette), 2 Wochen Standortverlauf, Widgets und Benachrichtigungen prüfen.
- Immich-iOS-mTLS auf aktueller iOS-Version testen (Issue #27362).
- Headscale-Fix-Status für Tailworm Klasse 3 im Repo prüfen. Bis dahin Headscale-Endpunkt nicht weiter öffnen als nötig.