From b20edd6b623d73ebc0bb2bda12fd757511020111 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Fri, 11 Sep 2026 13:53:41 +0200 Subject: [PATCH] =?UTF-8?q?TP43=20reopened:=20interne=20BF-Namen=20=C3=BCb?= =?UTF-8?q?er=20WG=20am=20dw=20=E2=80=94=20Entscheidung=20DHCP-Multi=20[.3?= =?UTF-8?q?6/.37/public]?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Auslöser: portainer.bf.emsenhuber.net vom dw-Standort (WG-Tunnel up) nicht auflösbar — dw-FritzBox kennt die interne Zone bf.emsenhuber.net nicht. - Gitea #32 reopened (status:todo, thema:firewall-dns), Prosa aus dem Archiv zurück nach teilprojekte.md (Archiv = ♻️-Zeiger). - fm-Einwand live entkräftet (dig @.36): bf-Namen → 10.40.0.0/16 (über WG erreichbar), fm-Namen → Cloudflare-Anycast, nie 10.101.x. - Entscheidung: FritzBox verteilt per DHCP die DNS-Liste .36/.37/9.9.9.9; .37-Redundanz bleibt, FB entlastet. NXDOMAIN-Failover-Haken + zwei On-site-Verifikationen dokumentiert. Umsetzung = eigene On-site-Session. Co-Authored-By: Claude Opus 4.8 --- docs/teilprojekte-archiv.md | 31 ++++-------------- docs/teilprojekte.md | 63 +++++++++++++++++++++++++++++++++++++ 2 files changed, 69 insertions(+), 25 deletions(-) diff --git a/docs/teilprojekte-archiv.md b/docs/teilprojekte-archiv.md index a4dd6c8..1197318 100644 --- a/docs/teilprojekte-archiv.md +++ b/docs/teilprojekte-archiv.md @@ -66,7 +66,7 @@ teuerste Eigenschaft der Datei zerstört, um ihr billigstes Problem zu lösen. B | [TP34](#tp34) | Caddyfile via Nautobot/GC (generische Reverse-Proxy-Schnittstelle) | ❌ VERWORFEN (2026-09-08) — Caddyfile bleibt manuell | | [TP44](#tp44) | Cloudflare-Estate als Dokumentations-SSoT in Nautobot | ✅ DURCH (2026-09-10) | | [TP41](#tp41) | CF-Access-Reparatur + Zero-Trust-Konsolidierung | ✅ ABGESCHLOSSEN (2026-09-10) — Gelis WARP via Android eingerichtet, letzter Blocker weg | -| [TP43](#tp43) | dw-Standort-DNS-Uplink (site-spezifische Overrides) | ❌ VERWORFEN (2026-09-11) — 420 ist public CF-Worker, kein Split-Horizon nötig; Zugang via WARP+CF Access | +| [TP43](#tp43) | dw-Standort-DNS-Uplink (site-spezifische Overrides) | ♻️ REOPENED (2026-09-11) — Volltext zurück in teilprojekte.md; interne BF-Namen über WG am dw offen | | [TP42](#tp42) | Namens-Vereinheitlichung: ein interner Suffix bf.emsenhuber.net | ✅ DURCH (2026-09-02) — `.bf.lan` raus, `.16` abgebaut, Compliance 140/140 | Dazu am Ende: **[TP25 (Langfassung)](#tp25-lang)** — die Messchronik und die Funde A–E im Volltext. @@ -1906,31 +1906,12 @@ der Egress ohnehin Cloudflare (nicht diese IP) → der IP-Include wäre dann üb **Gitea-Least-Privilege** = eigener künftiger TP (jedes Projekt repo-scoped Login, Admin nur Claude/Christoph). - Bezug **TP11** (Monitoring): eine Plattenfüllstand-Warnung hätte das Wochen früher gezeigt. -### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ ❌ **VERWORFEN (2026-09-11)** — Prämisse (BF-internes 420) gegenstandslos: `420.teilzeitladen.xyz` = public CF-Worker hinter CF Access (löst auf CF-Anycast, NS=Cloudflare), kein BF-Origin ⇒ kein Split-Horizon/Override nötig. Auslöser via TP41-**WARP** gelöst (Geli 2026-09-10 via Android). Keine BF-Altlasten aufzuräumen (kein 420-Caddy-vhost, kein macmini:8890-Container; `terpene-db`/LXC400 = blaueblüten, bleibt). Prosa unten = Historie. +### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ ♻️ **REOPENED 2026-09-11 → Volltext zurück in [`teilprojekte.md`](teilprojekte.md) (Abschnitt TP43)** -**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. +Kurz zwischen 2026-09-11 verworfen und am selben Tag reopened: die 420-Prämisse war gegenstandslos +(public CF-Worker, via WARP/TP41 gelöst), aber die **interne** BF-Namensauflösung über WG am dw blieb +dabei offen (`portainer.bf.emsenhuber.net` am dw nicht erreichbar). Korrigierter Scope + verworfene +420-Historie stehen jetzt aktiv in `teilprojekte.md`. Gitea-Issue #32 = `status:todo` · `thema:firewall-dns`. ### TP42 — Namens-Vereinheitlichung: ein interner Suffix bf.emsenhuber.net ▸ ✅ **DURCH (2026-09-02)** — ein interner Suffix `bf.emsenhuber.net`, `.bf.lan` raus, `.16` (adguard_bf1) abgebaut, Compliance 140/140. Offen nur der an **TP37** gekoppelte Nautobot-Doku-Teil. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 7a01586..b93c531 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -2725,3 +2725,66 @@ TP22 · TP-R · **TP3.2** (08-17) · **TP5** (08-18) · **TP7.1** (08-18) · **T 7. **Foundation (2026-07-14):** **TP15** (MikroTik-Switching / Omada-WLAN, 2× CRS326 bestellt) ∥ **TP20 (Platform-Postgres, single-site replication-ready)** → **TP21 (Nautobot Golden Config)** ∥ **TP20.1 (Vaultwarden→PG + 2-Site-HA)**. TP20 hängt an **TP18 ①** (Garage-Bucket für pgBackRest). + + +### TP43 — dw-Standort: interne BF-DNS-Namen über WG auflösbar machen ▸ 🔜 **REOPENED 2026-09-11, Richtung entschieden (DHCP-Multi `[.36/.37/public]`); Umsetzung on-site offen** (verworfene 420-Historie am Ende dieses Abschnitts) + +**Live-Auslöser (2026-09-11):** Christoph am dw-Standort, WG-Tunnel zu BF up, kann `portainer.bf.emsenhuber.net` +nicht erreichen. Direkte IP `https://10.40.20.126:9443` geht ⇒ **reines DNS-, kein Routing-Problem.** Der +dw-Client nutzt die FritzBox (`10.95.10.1`) als Resolver; die kennt die interne Zone `bf.emsenhuber.net` +(Split-Horizon `.36/.37 → 10.40.20.40` Caddy) nicht. + +**Korrektur gegenüber dem verworfenen Scope:** Der ursprüngliche Fall (`420.teilzeitladen.xyz`) ist ein +**öffentlicher** CF-Worker und war nie das Problem — der ist via TP41/WARP + CF Access gelöst. Das echte, +offene Problem sind **interne** BF-Namen (`*.bf.emsenhuber.net`) über den WG-Tunnel. + +**Live verifiziert (2026-09-11, `dig @10.40.20.36` über den Tunnel):** `portainer.bf.emsenhuber.net +→ 10.40.20.40` (Caddy), `macmini.bf.emsenhuber.net → 10.40.20.167` — alle internen bf-Namen landen +in `10.40.0.0/16`, über WG erreichbar. `ds-fm`/`gateway-fm.emsenhuber.net → 188.114.96.10/.97.10` += **Cloudflare-Anycast** (public), **nie `10.101.0.x`**. ⇒ **Der fm-Einwand (10.101.x intern ohne +Pfad von dw) trifft für `.36/.37` nicht zu** — fm läuft über den public `fm.emsenhuber.net`-Tunnel, +nicht über interne Records. (WG-Topologie TP10: dw-Peer AllowedIPs BF-seitig = `10.40.0.0/16`, dw +routet **nicht** nach `10.101.0.0/24`.) + +**Constraint am dw:** die 24/7-Geräte `10.95.10.246/.247` sind **Cudy-APs (kein DNS-Host)**, und die +FritzBox kann **kein Per-Zone-Forwarding** (nur einen globalen Upstream). Ohne Zusatz-Dauerläufer ist +ein echter conditional forwarder (dnsmasq `server=/bf.emsenhuber.net/.36`) deshalb nicht drin. + +**Entscheidung (Christoph, 2026-09-11): DHCP-Multi.** Die dw-FritzBox verteilt **per DHCP** die +DNS-Serverliste **`10.40.20.36, 10.40.20.37, 9.9.9.9`** an die Clients (FB-eigener Resolver damit +umgangen). Gewählt gegenüber „FB-Upstream `.36` primär/public sekundär", weil die **`.37`-Redundanz +bleibt** (3 Server statt FB-2-Slot-Grenze) und die **FB entlastet** ist. +- **BF-up:** Client fragt `.36` zuerst → interne `bf.*` (Split-Horizon → `.40`) **und** public; der + public-Eintrag wird nie konsultiert. +- **BF-down:** `.36`/`.37` timeouten → Client fällt auf `9.9.9.9` → public lebt, `bf.*` = NXDOMAIN + (erwartet). + +🔴 **Fundamentaler DNS-Haken (gilt für jede Server-Liste, nicht fixbar):** Failover zwischen +Nameservern greift nur bei **Timeout/SERVFAIL, nicht bei NXDOMAIN**. Wird der public Server für +`bf.*` zuerst gefragt, liefert er ein sauberes NXDOMAIN und der Client fragt `.36` nicht mehr → +funktioniert nur, solange `.36`/`.37` **strikt zuerst** drankommen. Daraus die **zwei +On-site-Verifikationen** (Christoph, am dw): (1) die dw-FRITZ!OS liefert per DHCP wirklich die +Fremd-Liste aus (nicht die FB selbst); (2) die realen dw-Clients fragen **strikt in Reihenfolge** +(kein `options rotate`/Parallel-Query) — mehrfach `nslookup portainer.bf.emsenhuber.net` muss +**stabil** `10.40.20.40` liefern, nie sporadisch NXDOMAIN. Leakt ein Client-OS dennoch nach public: +für **dieses Gerät** per-Device-Rückfall — `/etc/hosts`-Zeile `10.40.20.40 ` oder WARP mit +`fallback_domains bf.emsenhuber.net → [.36,.37]` (TP41-Präzedenz). + +**Sofort-Workaround (läuft unabhängig):** `https://10.40.20.126:9443` direkt bzw. +`/etc/hosts`-Zeile `10.40.20.40 portainer.bf.emsenhuber.net`. + +**Abhängigkeiten:** WG-Route dw→`10.40.0.0/16` (steht). Grenzt an TP42 (interner Namensraum +`bf.emsenhuber.net`) und TP10 (Multi-Site-VPN). **Umsetzung = eigene On-site-Session** (FritzBox-DHCP +ist Christophs manueller Schritt, kein Tool-Zugriff). + +--- + +**Historie — verworfener 420-Scope (angelegt 2026-09-01, verworfen 2026-09-11):** + +**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."* — Diese Prämisse fiel weg: `420.teilzeitladen.xyz` ist ein +public CF-Worker hinter CF Access (löst auf CF-Anycast), kein BF-Origin ⇒ dafür braucht es kein +Split-Horizon; Zugang via TP41-**WARP** gelöst (Geli 2026-09-10 via Android). Der Override-Bedarf für +**interne** Namen blieb dabei übersehen — deshalb reopened, s.o.