Merge TP41-Follow-up: Abschluss (Google/GitHub ✅, FB abgesagt, Geli CF-seitig fertig)

Follow-up nach dem TP41-Kernmerge (20671ae): App-Launcher D1, Geli-Enrollment
verifiziert (zt-humans), IdP-Anleitungen, TP43-Anlage, TP41-Doku-Abschluss.

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

docs/handoff-20260901-tp41-followup.md

@@ -0,0 +1,109 @@
+# Handoff 2026-09-01 — TP41 Follow-up: IdP-Feinschliff, App-Launcher, Geli-Zugänge, dw-DNS
+
+> Kleine Folgesession nach TP41 (T4/T3/T2 durch). Sammelt die Rest-Punkte rund um **Logins für Geli**,
+> die **App-Launcher-Seite** und den **dw-Split-Horizon** für Terpenfinder. Mehrere Punkte sind
+> **User-Konsolen-Aufgaben** (Google/Meta), dafür je eine Kurzanleitung.
+
+## Status je Punkt (Stand dieser Session)
+| # | Punkt | Stand |
+|---|---|---|
+| 1 | GitHub-Login | ✅ funktioniert (User bestätigt) |
+| 2 | Google „Zugriff blockiert: nur innerhalb der Organisation" | ✅ **gefixt** — User hat Consent-Screen auf *External* gestellt; Google-Login läuft (bestätigt 2026-09-01). Anleitung §A war der Weg. |
+| 3 | Meta/Facebook einbinden | ❌ **für TP41 abgesagt** (User-Entscheid 2026-09-01) — optional, kein Bedarf. Keine App, kein CF-IdP angelegt. Geli via OTP+Google voll gedeckt. §B nur noch als Anleitung, falls später gewünscht. |
+| 4 | Geli-Zugänge hinterlegen | ✅ `pillepalle670@gmail.com` in `zt-humans`. **FB-Konto-Mail = `angelikahy@outlook.de`** (schon drin → Facebook automatisch abgedeckt, sobald Meta läuft). Instagram = kein CF-IdP. |
+| 5 | App-Launcher überarbeiten | ✅ **D1 umgesetzt** — 3 Bookmark-Kacheln (Vaultwarden/Home Assistant/Terpenfinder), Bundle-/Wildcard-/Terpene-self_hosted-Kacheln aus dem Launcher genommen (Policies **unverändert** geprüft), Launcher gestylt (Titel „BF-Zugänge", Begrüßung, Buttons). |
+| 6 | `420.teilzeitladen.xyz` an dw | ✅ **Entscheidung:** Geli sofort per **WARP**; das dw-Site-DNS-Uplink-Thema → **TP43** (angelegt). |
+
+---
+
+## §A — Google-Login-Fix (User, Google Cloud Console)
+Fehler „cloudflare kann nur innerhalb der Organisation verwendet werden" = der **OAuth-Consent-Screen**
+des Google-Projekts steht auf **User Type = Internal** (nur Workspace-Org-Konten). Gelis Gmail ist extern
+→ blockiert. Fix (der CF-Google-IdP `c757…` bleibt unverändert, nur die Consent-Einstellung ändert sich):
+1. <https://console.cloud.google.com> → richtiges Projekt (das, aus dem die Google-OAuth-Client-ID stammt).
+2. **APIs & Services → OAuth consent screen** (neu: „Google Auth Platform → Audience").
+3. **User Type / Audience von *Internal* auf *External*** stellen.
+4. **Veröffentlichen:** Publishing status → **„In production"** (dann kann jedes Google-Konto rein).
+   Alternativ in „Testing" bleiben und **Gelis Gmail als Test user** eintragen.
+5. Danach Login-Test mit Gelis Google-Konto. (Bei „External/unverified" kommt ggf. ein
+   „unbestätigte App"-Hinweis — für den kleinen Kreis unkritisch, oder App verifizieren lassen.)
+
+## §B — Meta/Facebook als Login (User legt App an, dann CF-IdP durch mich)
+Es gibt **noch keine** Facebook-App (Creds leer). Schritte:
+1. <https://developers.facebook.com> → **My Apps → Create App** → Use case **„Authenticate and request
+   data from users with Facebook Login"** (Consumer).
+2. Produkt **Facebook Login** hinzufügen.
+3. **Facebook Login → Settings → Valid OAuth Redirect URIs** =
+   `https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback`
+4. **App settings → Basic:** **App ID** + **App Secret** → an mich (in `~/.secrets`, **nicht** in den Chat),
+   ich trage sie in `mcp/cloudflare/.env` (`FACEBOOK_APP_ID/SECRET`) ein und lege den CF-Facebook-IdP an.
+5. **App Mode → Live** (sonst dürfen nur App-Rollen/Tester rein); Geli ggf. als Tester eintragen.
+6. ⚠️ CF matcht die Policy über die **E-Mail**, die Facebook zurückgibt — diese E-Mail muss in
+   `zt-humans` stehen (s. §C).
+
+## §C — Geli: Zugangsmethoden (Matrix)
+CF Access matcht Personen über die **E-Mail** der Identität (nicht über Usernamen). Stand:
+| Methode | Gelis Angabe | CF-Status | To-Do |
+|---|---|---|---|
+| OTP (E-Mail-Code) | `angelikahy@outlook.de` | ✅ in `zt-humans` | — |
+| OTP + Google | `pillepalle670@gmail.com` | ✅ **heute ergänzt** | Google-Fix §A nötig, damit Google-Login geht |
+| Facebook | User `35Lika.Ange` | ⏳ | Facebook-App (§B); dann die **E-Mail** ihres FB-Kontos in `zt-humans` — welche ist das? (vermutlich eine der beiden obigen) |
+| Instagram | `angelikahy` | ❌ **CF Access hat keinen Instagram-IdP** | Nicht möglich als Direkt-Login → Geli nutzt Facebook/Google/OTP |
+
+→ Sobald Gelis FB-Konto-E-Mail bekannt ist und sie eine der schon hinterlegten Adressen ist, ist Facebook
+automatisch abgedeckt. Sonst diese E-Mail zusätzlich in `zt-humans` aufnehmen.
+
+## §D — App-Launcher `emsenhuber.cloudflareaccess.com` überarbeiten
+**Ist-Analyse (live):** Der Launcher (App `6df5c431`, `landing_page_design={}` = ungestylt) zeigt Kacheln
+aus den Access-Apps mit `app_launcher_visible=true`:
+- `1dbc45ca` **„hass, vw, gitea"** (self_hosted, Domain `vw.emsenhuber.net`) → **eine** Kachel, verlinkt nur vw.
+- `16aaec78` **`*.emsenhuber.net`** (Wildcard) → Kachel ohne sinnvolles Ziel.
+- `e6a7991f` **Terpenfinder v3** (`420.teilzeitladen.xyz`) → eigene Kachel ✅.
+Deshalb „stimmt nicht mehr": vw/hass/gitea teilen sich eine Kachel, die Wildcard-Kachel stört.
+
+**Ziel:** je ein sauberer Button für **Vaultwarden, Home Assistant, Terpenfinder** + freundlichere Seite.
+**Zwei Wege (Entscheidung offen):**
+- **D1 — CF-nativ (empfohlen, „diese Seite"):** je ein **Bookmark-App** (type `bookmark`) für vw/hass/
+  terpenfinder mit Name + Logo (eigene Kachel/Link), die Wildcard-Kachel aus dem Launcher nehmen,
+  `landing_page_design` setzen (Titel z.B. „BF-Zugänge", Begrüßung, Farbe, Logo). Reversibel, in Minuten.
+  Grenze: CF-Styling = Titel/Text/Farbe/Logo + uniforme Kacheln.
+- **D2 — Custom-Landing-Page:** eigene HTML-Seite (Caddy, hinter Access) mit voller Gestaltung/großen
+  Buttons. Mehr Design, mehr Aufwand (eigener vhost + Access-Regel).
+
+## §E — dw: `420.teilzeitladen.xyz` lokal auflösen (FritzBox `10.95.10.1`)
+**Ehrliche FritzBox-Antwort:** Eine FritzBox kann **keinen** freien „Hostname → beliebige IP"-Override im
+GUI (nur *DNS-Rebind-Schutz-Ausnahmen* = Whitelist gegen Rebind-Blockade, **ohne** IP-Zuweisung). Ein
+sauberer Split-Horizon für genau diesen Namen braucht daher einen **kleinen lokalen Resolver** am dw
+(dnsmasq/AdGuard/Pi-hole auf einem Dauerläufer): `address=/420.teilzeitladen.xyz/<BF-Caddy-über-WG>` +
+Rest weiterleiten; diesen Resolver als DNS der FritzBox bzw. der Clients setzen.
+⚠️ **Vor Umsetzung verifizieren** (nicht aus dem Kopf): FritzOS-Version am dw + ob ein Dauerläufer da ist.
+**BF-seitige Prereqs (fehlen noch):**
+1. **Caddy-vhost** `420.teilzeitladen.xyz` → macmini-Worker (`10.40.20.167:8890`) **mit Cert**
+   (DNS-01, `…4148` hat jetzt teilzeitladen.xyz-DNS).
+2. **WG-Route** dw → `10.40.20.40` (Caddy) muss stehen.
+3. **Split-Horizon** für `420.teilzeitladen.xyz` (heute liefern auch `.36/.37` **public** für diesen Namen).
+Cross-Projekt (teilzeitladen.xyz). Alternative aus Ur-Handoff: Gelis Gerät in **WARP** (Session statt Login,
+CGNAT unkritisch) + Access-Policy auf die WARP-Identität — spart den ganzen dw-DNS-Umbau.
+
+## Entscheidungen (2026-09-01, getroffen)
+1. **App-Launcher:** ✅ **D1** (CF-nativ) — umgesetzt (s. §D / Punkt 5).
+2. **Gelis Facebook-Mail:** ✅ `angelikahy@outlook.de` — schon in `zt-humans`, Facebook damit abgedeckt.
+3. **dw-Ansatz:** ✅ Geli per **WARP** (sofort); Site-DNS-Uplink als **TP43** ausgelagert.
+
+## Verbleibende offene To-Dos (User)
+- ~~**§A Google-Consent-Screen** auf *External*~~ ✅ **erledigt** — Google-Login läuft (2026-09-01).
+- ~~**§B Facebook-App anlegen**~~ ❌ **abgesagt für TP41** (User-Entscheid 2026-09-01) — optional; §B
+  bleibt als Anleitung stehen, falls später doch gewünscht.
+- ~~**d47435-Revoke**~~ ✅ erledigt · ~~**T3-WARP-Client-Verify**~~ ✅ ok (User, 2026-09-01).
+- **Geli in WARP:** ✅ **CF-seitig nichts zu tun** — Enrollment läuft über App „Warp Login App"
+  (`6c32fe23…`) → `bf-users` → Gruppe `zt-humans`, die Gelis Mails **schon enthält**; sie darf bereits
+  enrollen. Terpenfinder-`geli`-Policy lässt sie per E-Mail durch. **Rest = Handgriff auf Gelis Gerät:**
+  WARP installieren, Team `emsenhuber`, Login OTP `angelikahy@outlook.de` oder Google `pillepalle670@gmail.com`.
+  *Permission-Frage:* CF-seitig keine nötig; `/access/seats` per MCP nicht nutzbar (`10405`, Endpoint will
+  User-Token statt Account-Token — kein Scope-Fix, für Enroll irrelevant).
+- **T5 (TP41)** ✅ GitHub- **und** Google-Login laufen (bestätigt).
+- **TP43** (dw-Site-DNS) bei Gelegenheit.
+
+> **TP41-Auth-Kern damit abgeschlossen (2026-09-01):** T2/T3/T4/T5 ✅, FB abgesagt, d47435-Revoke ✅,
+> WARP-Verify ✅, Geli CF-seitig fertig. **Nichts mehr auf Claude-/CF-Seite offen** — verbleibt nur
+> Gelis WARP-Client auf ihrem Gerät.

docs/teilprojekte.md

@@ -31,19 +31,27 @@ Mgmt (VLAN99, Ist 2026-08-16): core `.99.1` · branch `.99.2` · ap1 `.99.11` ·
 **Compliance am 2026-08-31 nach vollem Refresh (Backup→Intended→Compliance) gelesen: 128/135.**
 *(Die Fassung vom 2026-08-16 stand bis zum 18. hier und war an vier Stellen überholt. Wer diesen Block
 liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
-- ⏳ **TP41 CF-Access-Reparatur (2026-09-01, Kern live + T4 durch):** Session 720h,
+- ⏳ **TP41 CF-Access-Reparatur (2026-09-01, Auth-Kern abgeschlossen):** Session 720h,
   login_method-Loch zu (`bf-users` email-only), `zt-`-Gruppen, vw voll Bypass + `vw/admin` per WAF
   geblockt (Mobilfunk-verifiziert), API-Token auf vollständiges `…4148` konsolidiert. **T4 ✅**
   (ein Access-Service-Token `zt-svc`, Terpene-Worker per wrangler auf zt-svc umgestellt, Alt-Tokens
   gelöscht). **T3 ✅** (WARP Default-Profil fallback_domains `emsenhuber.net → .36/.37`). **T2 ✅**
   (WAF-Regel gelöscht, Caddy-Origin-404 für `/admin` via CF-Header; Edge=404, lokal=200).
-  **Token-Altlast geklärt:** `b00722`=live Caddy-DNS-Token, `d47435`=stale Kopie → **User revoket d47435**.
-  **Offen nur noch User:** **T5 = GitHub/Google-Callback** (der OTP-Fix), d47435-Revoke, T3-WARP-Client-Verify.
-  Handoff: [`docs/handoff-20260901-tp41.md`](handoff-20260901-tp41.md).
+  **T5 ✅** (GitHub- **und** Google-Login laufen, User-bestätigt 2026-09-01; Google via Consent-Fix §A).
+  **Facebook/Meta für TP41 abgesagt** (optional, kein CF-IdP angelegt) — Geli über OTP
+  `angelikahy@outlook.de` + Google `pillepalle670@gmail.com` voll gedeckt.
+  **Token-Altlast geklärt:** `b00722`=live Caddy-DNS-Token, `d47435`=stale Kopie → **✅ d47435 revoked**,
+  **✅ T3-WARP-Client-Verify** (User). **Geli CF-seitig fertig** (Enrollment via `zt-humans` + `geli`-Policy,
+  2026-09-01 live geprüft) → verbleibt nur ein **Device-Handgriff bei Geli** (WARP-Client, Team `emsenhuber`).
+  **Claude-/CF-Seite damit vollständig.** Handoff: [`docs/handoff-20260901-tp41.md`](handoff-20260901-tp41.md) · [Follow-up](handoff-20260901-tp41-followup.md).
 - 🔜 **TP42 Namens-Vereinheitlichung (2026-09-01, angelegt):** internes `.bf.lan` (Core-DNS, DHCP-Search-
   Domain) und die `.bf.emsenhuber.net`-Aliase (Caddyfile) auf **einen** Namensraum `emsenhuber.net`
   ziehen; stale `.16/.17`-Rewrites abbauen; Sollzustand in Nautobot. Handoff:
   [`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md).
+- 🔜 **TP43 dw-Standort-DNS-Uplink (2026-09-01, angelegt):** dem dw-Standort einen eigenen Resolver/
+  DNS-Uplink mit **site-spezifischen Overrides** geben (erster Fall `420.teilzeitladen.xyz` → BF-Caddy
+  über WG), **inkl. Verhalten bei WG-Disconnect** (Override auf BF-interne IP fällt sonst aus). FritzBox
+  standard kann keinen Per-Host-Override. Geli-Sofortlösung = **WARP** (nicht Teil von TP43). Cross-Projekt.
 - ✅ **TP16.3 ABGESCHLOSSEN (2026-09-01):** Flip **und** Abbau durch. Öffentlich laufen nur noch
   `bf-public` (12 Connectoren) und `fm` — die drei Alttunnel `bf-mm`/`bf-nas`/`bf-pve` **und** der
   projektfremde `terpene-db` sind gelöscht, **7 cloudflared-Container** entfernt (inkl.
@@ -488,8 +496,9 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP37 | 🔜 | Nautobot als Netzwerkdoku: Hosts/Container/Dienste + CF-Connectoren (Okay 08-30) | — |
 > | TP38 | 🔜 | OOB-Mgmt: untagged-VLAN99-Port je Switch | — |
 > | TP40 | 🔜 | HA-Recorder-Retention: 41 GB `states` beschneiden (Okay 09-01) | — |
-> | TP41 | ⏳ | CF-Access-Reparatur: **T4/T3/T2 ✅**; Token-Altlast geklärt; offen nur noch User-Aufgaben (T5 IdP-Callbacks = OTP-Fix, d47435-Revoke, T3-WARP-Client-Verify) | — |
+> | TP41 | ⏳ | CF-Access-Reparatur: **T2/T3/T4/T5 ✅** (GitHub+Google-Login live); **Facebook abgesagt**; d47435-Revoke ✅, T3-Verify ✅; **Geli CF-seitig fertig** (zt-humans+geli-Policy) → offen nur noch WARP-Client auf Gelis Gerät | — |
 > | TP42 | 🔜 | Namens-Vereinheitlichung bf.lan→emsenhuber.net: `.bf.lan`/`.bf.emsenhuber.net` aus allen Geräten raus, in Nautobot festhalten | — |
+> | TP43 | 🔜 | dw-Standort-DNS-Uplink: eigener Resolver mit site-Overrides (`420.teilzeitladen.xyz`→BF-Caddy/WG), WG-Disconnect bedacht; Geli sofort per WARP | — |
 > | — | — | **35 archivierte TPs** in `teilprojekte-archiv.md` (inkl. TP39 ✅ 2026-09-01) | — |
 
 ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt
@@ -2877,7 +2886,7 @@ Der HA-Recorder schreibt **unbegrenzt** — es ist keine `purge_keep_days`-Grenz
 - 🔴 **Kein eigenmächtiger Datenlöschvorgang** — `purge` wirft echte Historie weg; die
   Aufbewahrungsdauer ist eine Nutzerentscheidung. Diese Session hat **nur** vergrössert und gemessen.
 
-### TP41 — CF-Access-Reparatur + Zero-Trust-Konsolidierung ▸ ⏳ **ANGELEGT 2026-09-01, Kern live**
+### TP41 — CF-Access-Reparatur + Zero-Trust-Konsolidierung ▸ ⏳ **Auth-Kern abgeschlossen 2026-09-01 (FB abgesagt)**
 
 **Auslöser:** CF-Access zwang Christoph **und Geli** täglich zum OTP-Login (soll: 30 Tage); GitHub/Google
 „funktionieren nicht". Root-Causes: Team-Domain-Rename `bf4`→`emsenhuber` (Provider-Callback veraltet),
@@ -2903,13 +2912,35 @@ Kopie (kein Consumer) → **User revoket `d47435`**; `credentials.env`-Kopie auf
 **✅ T2 DURCH (2026-09-01):** WAF-Regel `f26744eb` gelöscht; Caddy `vw`-Block `respond @cf_admin 404` bei
 Header `CF-Connecting-IP` (LXC130). Verify: Edge `/admin`=404, lokal/WARP `/admin`=200. ✅
 
-**🔜 Offen:** **T5 (USER)** GitHub-OAuth `Ov23li2h96hAkGRPJXYV` + Google-Client Callback =
-`https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback` (**der eigentliche OTP-Fix**,
-Fehler „redirect_uri is not associated" bestätigt) · **d47435-Revoke** (User) · **T3-Client-Verify** (User) ·
-**T6** optional Rate-Limit · 🔴 `TERPENE_ANDROID_KEYSTORE_PW`-Rotation erwägen (Transkript-Leak).
+**✅ T5 DURCH (2026-09-01, User-bestätigt):** GitHub-Login läuft; Google-Login läuft nach dem
+Consent-Screen-Fix (§A des Follow-up-Handoffs: User Type *Internal*→*External*/veröffentlicht).
+Callback für beide `https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback`.
+**❌ Facebook/Meta für TP41 abgesagt (2026-09-01, User-Entscheid):** optional, kein Bedarf — Geli ist
+über OTP `angelikahy@outlook.de` + Google `pillepalle670@gmail.com` voll gedeckt. **Keine Facebook-App,
+kein CF-Facebook-IdP angelegt → nichts aufzuräumen.** Instagram hat ohnehin keinen CF-IdP.
+**✅ App-Launcher (D1):** je eine Bookmark-Kachel vw/hass/terpenfinder, Wildcard-Kachel raus, Launcher
+gestylt (Follow-up-Handoff §D, Policies unverändert).
 
-**🆕 dw/Geli an Auth vorbei (CGNAT):** Split-Horizon in dw-FritzBox `420.teilzeitladen.xyz` → BF-Caddy
-über WG; Caddy serviert die Terpene-App mit Cert (DNS-01, Token hat teilzeitladen.xyz-DNS). Cross-Projekt.
+**✅ Geli in WARP — CF-seitig nichts zu tun (2026-09-01 live geprüft):** Device-Enrollment läuft über
+die App **„Warp Login App"** (`6c32fe23…`, type `warp`) → Policy `bf-users` → Gruppe **`zt-humans`**, die
+Gelis beide Mails **schon enthält** → sie **darf bereits enrollen** (deshalb war „Device enrollment
+permissions" nicht als fehlendes Setting zu finden). Terpenfinder-`geli`-Policy lässt sie per E-Mail durch.
+⇒ verbleibt **nur ein Handgriff auf Gelis Gerät** (WARP installieren, Team `emsenhuber`, Login OTP
+`angelikahy@outlook.de` / Google `pillepalle670@gmail.com`) — nicht aus der Ferne machbar.
+🔑 **Permission-Frage beantwortet:** CF-seitig **keine** nötig. Für generelle WARP/Enrollment/User-Verwaltung
+per Account-Token: *Access: Apps and Policies → Edit* + *Access: Organizations, IdPs, and Groups → Edit*
+(User erteilt 2026-09-01). **Seat-Verwaltung (`/access/seats`) bleibt per MCP gesperrt** — `10405 Method
+not allowed for this authentication scheme` (Endpoint will User-Token, nicht Account-Token; kein Scope-Fix,
+für Enroll irrelevant).
+
+**🔜 Offen — nur noch außerhalb CF:** **Gelis WARP-Client** auf ihrem Gerät (s.o.) · **T6** optional
+Rate-Limit · 🔴 `TERPENE_ANDROID_KEYSTORE_PW`-Rotation erwägen (TP30 Posten #7, Transkript-Leak).
+**d47435-Revoke ✅ · T3-WARP-Client-Verify ✅** (User, 2026-09-01).
+
+**🔻 Optionaler Security-Cleanup (eigener Punkt, nicht in dieser Runde):** die `geli`-Terpenfinder-Policy
+hat **OR-Semantik** und enthält den breiten CGNAT-Bereich `94.154.138.0/24` als IP-Include → jeder aus
+dieser geteilten Range käme **ohne Login** rein. Über WARP ist der Egress ohnehin Cloudflare (nicht diese
+IP) → der IP-Include wäre dann überflüssig und entfernbar.
 
 **Abgrenzung:** hass/gitea bleiben (diese Runde) öffentlich; Terpenfinder-Human-Policies nicht angefasst;
 **Gitea-Least-Privilege** = eigener künftiger TP (jedes Projekt repo-scoped Login, Admin nur Claude/Christoph).
@@ -2944,6 +2975,32 @@ Problem"). **Abh.:** TP37 (Nautobot-Datenmodell) für Punkt 4; sonst nichts Offe
 **Status:** 🔜 angelegt 2026-09-01, Ausarbeitung eigene Session. Handoff:
 [`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md).
 
+### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ 🔜 ANGELEGT 2026-09-01 (User-Okay erteilt)
+
+**Auslöser (2026-09-01, TP41-Follow-up):** Geli soll `420.teilzeitladen.xyz` am dw-Standort erreichen.
+Split-Horizon am dw scheitert an der **FritzBox** (`10.95.10.1`): kein Per-Host-A-Override im Standard
+(nur DNS-Rebind-Ausnahmen ohne IP). Christoph: *„keine Chance im FritzBox-Standard? … lieber ein TP als
+uns verfranzen. Geli kommt rein, das zählt."*
+
+**Ziel:** dem dw-Standort einen **eigenen Resolver/DNS-Uplink** geben, der **site-spezifische Overrides**
+hält (erster Fall `420.teilzeitladen.xyz` → BF-Caddy über WG), als DNS der FritzBox/Clients gesetzt.
+
+**Kernfrage (explizit):** Verhalten bei **WG-Disconnect.** Ein Override auf eine BF-interne IP
+(`10.40.20.40`) fällt aus, wenn der Tunnel unten ist. Für einen Login-gegateten Dienst gibt es kein
+„kein Login **und** funktioniert bei WG-down" — Optionen: (a) Override nur bei WG-up (Failover-Resolver),
+(b) öffentlicher Pfad (CF, mit Login) als Fallback. Zu entwerfen.
+
+**Sofortlösung (nicht Teil von TP43):** Geli per **WARP** (Session statt täglichem Login, CGNAT egal,
+degradiert sauber: WG-up = nahtlos, WG-down = öffentliche URL + Login).
+
+**BF-seitige Prereqs:** Caddy-vhost `420.teilzeitladen.xyz` → macmini-Worker (`10.40.20.167:8890`) mit
+Cert (DNS-01, `…4148` hat teilzeitladen.xyz-DNS) · WG-Route dw→`10.40.20.40` · Split-Horizon für
+`420.teilzeitladen.xyz` (heute liefern auch `.36/.37` public). **Vorher verifizieren:** FritzOS-Version +
+Dauerläufer am dw. Cross-Projekt (teilzeitladen.xyz). Handoff:
+[`docs/handoff-20260901-tp41-followup.md`](handoff-20260901-tp41-followup.md).
+
+**Status:** 🔜 angelegt 2026-09-01, eigene Session.
+
 ### TP37 — Nautobot als durchgehende Netzwerkdoku: Hosts/Container/Dienste, erster Anwendungsfall CF-Connectoren ▸ 🔜 ANGELEGT 2026-08-30 (User-Okay erteilt)
 > **Christophs Formulierung (2026-08-30):** *„können wir das setup mit den cf-connectoren dann auch in
 > nautobot abbilden. quasi eine durchgehende netzwerkdoku stück für stück. muss eh fast sein, da du auf