admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

TP43 — dw-Standort: interne BF-DNS-Namen über WG auflösbar machen #32

New Issue
Closed
opened 2026-09-07 11:26:44 +02:00 by admin · 5 comments
admin commented 2026-09-07 11:26:44 +02:00
Owner
Copy Link

Steuerungs-SSoT: Index/Status hier in Gitea; Prosa/Detail im Repo unter docs/teilprojekte.md (Abschnitt TP43).

Reopened 2026-09-11 — korrigierter Scope. Der ursprüngliche Auslöser (öffentliches 420.teilzeitladen.xyz) ist über TP41/WARP gelöst. Offen: interne BF-Namen (*.bf.emsenhuber.net, Split-Horizon .36/.37 → 10.40.20.40 Caddy) sind vom dw über den WG-Tunnel nicht auflösbar — die dw-FritzBox (10.95.10.1) kennt die interne Zone nicht. Live an portainer.bf.emsenhuber.net aufgefallen (Tunnel up; direkte IP 10.40.20.126:9443 geht → reines DNS-Problem).

Entscheidung 2026-09-11 — FB-Upstream + Rebind-Ausnahme. (DHCP-Multi verworfen: dw-FB kann per DHCP nur EINE DNS-IP ausliefern.) Clients bekommen 10.95.10.1 (FB); die FB forwardet an Bevorzugt 10.40.20.36, Alternativ 10.40.20.37 (beide BF, Voll-Resolver). Sauber, weil .36 intern+public löst → alles zuerst an .36, public nur als Unreachable-Fallback (kein NXDOMAIN-Leak).

🔴 Zwingend: DNS-Rebind-Schutz-Ausnahme bf.emsenhuber.net — sonst filtert die FB die Privat-IP-Antworten (10.40.x) als Rebind-Angriff weg.

BF-down-Fallback: FRITZ!OS-Setting „öffentliche NS bei Unreachbarkeit der primären" aktivieren, falls vorhanden (dann .36+.37 behalten). Fehlt es → Alternativ-Slot auf public 9.9.9.9 (kostet .37, dann strikt-primär verifizieren).

Constraint: dw-24/7-Geräte .246/.247 = Cudy-APs (kein DNS-Host); FritzBox kann kein Per-Zone-Forwarding und nur 1 DHCP-DNS-IP → echter conditional forwarder bräuchte Zusatz-Dauerläufer (abgelehnt).

On-site-Verify: (1) Rebind-Ausnahme greift (nslookup portainer.bf.emsenhuber.net → stabil 10.40.20.40); (2) BF-down-Fallback vorhanden/gesetzt; (3) falls BF+public gemischt: strikt primär.

  • Status: 🔜 (status:todo) · thema: firewall-dns · Umsetzung = eigene On-site-Session (FritzBox, Christophs manueller Schritt)
  • Abschluss: —
Steuerungs-SSoT: Index/Status hier in Gitea; **Prosa/Detail** im Repo unter `docs/teilprojekte.md` (Abschnitt `TP43`). **Reopened 2026-09-11 — korrigierter Scope.** Der ursprüngliche Auslöser (öffentliches `420.teilzeitladen.xyz`) ist über TP41/WARP gelöst. Offen: **interne** BF-Namen (`*.bf.emsenhuber.net`, Split-Horizon `.36/.37 → 10.40.20.40` Caddy) sind vom dw über den WG-Tunnel nicht auflösbar — die dw-FritzBox (`10.95.10.1`) kennt die interne Zone nicht. Live an `portainer.bf.emsenhuber.net` aufgefallen (Tunnel up; direkte IP `10.40.20.126:9443` geht → reines DNS-Problem). **Entscheidung 2026-09-11 — FB-Upstream + Rebind-Ausnahme.** (DHCP-Multi verworfen: dw-FB kann per DHCP nur EINE DNS-IP ausliefern.) Clients bekommen `10.95.10.1` (FB); die FB forwardet an **Bevorzugt `10.40.20.36`, Alternativ `10.40.20.37`** (beide BF, Voll-Resolver). Sauber, weil `.36` intern+public löst → alles zuerst an `.36`, public nur als Unreachable-Fallback (kein NXDOMAIN-Leak). 🔴 **Zwingend: DNS-Rebind-Schutz-Ausnahme `bf.emsenhuber.net`** — sonst filtert die FB die Privat-IP-Antworten (`10.40.x`) als Rebind-Angriff weg. **BF-down-Fallback:** FRITZ!OS-Setting „öffentliche NS bei Unreachbarkeit der primären" aktivieren, falls vorhanden (dann `.36`+`.37` behalten). Fehlt es → Alternativ-Slot auf public `9.9.9.9` (kostet `.37`, dann strikt-primär verifizieren). **Constraint:** dw-24/7-Geräte `.246/.247` = Cudy-APs (kein DNS-Host); FritzBox kann kein Per-Zone-Forwarding und nur 1 DHCP-DNS-IP → echter conditional forwarder bräuchte Zusatz-Dauerläufer (abgelehnt). **On-site-Verify:** (1) Rebind-Ausnahme greift (`nslookup portainer.bf.emsenhuber.net` → stabil `10.40.20.40`); (2) BF-down-Fallback vorhanden/gesetzt; (3) falls BF+public gemischt: strikt primär. - Status: 🔜 (status:todo) · thema: firewall-dns · **Umsetzung = eigene On-site-Session** (FritzBox, Christophs manueller Schritt) - Abschluss: —
admin added the status:todothema:cloudflare-proxy labels 2026-09-07 11:26:44 +02:00
admin added status:dropped and removed status:todo labels 2026-09-11 12:12:13 +02:00
admin commented 2026-09-11 12:12:14 +02:00
Author
Owner
Copy Link

❌ Verworfen 2026-09-11.

Prämisse gegenstandslos: 420.teilzeitladen.xyz ist ein öffentlicher CF-Worker hinter CF Access (löst auf CF-Anycast auf, NS=Cloudflare) — kein BF-Origin, also kein Split-Horizon und kein BF-interner Override nötig. Die BF-seitigen Prereqs (Caddy-vhost 420 → macmini:8890, WG-Route dw→10.40.20.40) zeigten auf die gelöschte bf-mm-Architektur.

Auslöser (Geli → 420 am dw) ist über die TP41-Sofortlösung WARP gelöst — Client am 2026-09-10 via Android eingerichtet. Ohne WARP: öffentliche URL + CF-Access-Login.

Keine BF-Altlasten aufzuräumen (verifiziert: kein 420-Caddy-vhost, kein macmini:8890-Container; terpene-db/LXC400 = blaueblüten, bleibt). Prosa ins Archiv verschoben.

❌ Verworfen 2026-09-11. Prämisse gegenstandslos: `420.teilzeitladen.xyz` ist ein **öffentlicher CF-Worker hinter CF Access** (löst auf CF-Anycast auf, NS=Cloudflare) — kein BF-Origin, also kein Split-Horizon und kein BF-interner Override nötig. Die BF-seitigen Prereqs (Caddy-vhost 420 → macmini:8890, WG-Route dw→10.40.20.40) zeigten auf die gelöschte bf-mm-Architektur. Auslöser (Geli → 420 am dw) ist über die TP41-Sofortlösung **WARP** gelöst — Client am 2026-09-10 via Android eingerichtet. Ohne WARP: öffentliche URL + CF-Access-Login. Keine BF-Altlasten aufzuräumen (verifiziert: kein 420-Caddy-vhost, kein macmini:8890-Container; terpene-db/LXC400 = blaueblüten, bleibt). Prosa ins Archiv verschoben.
admin closed this issue 2026-09-11 12:12:14 +02:00
admin changed title from TP43 — dw-Standort-DNS-Uplink: eigener Resolver mit site-Overrides to TP43 — dw-Standort: interne BF-DNS-Namen über WG auflösbar machen 2026-09-11 13:20:18 +02:00
admin reopened this issue 2026-09-11 13:20:18 +02:00
admin commented 2026-09-11 13:20:18 +02:00
Author
Owner
Copy Link

Reopened 2026-09-11: korrigierter Scope. 420-Fall (WARP/TP41) war nie das Problem — offen ist die Auflösung interner BF-Namen (*.bf.emsenhuber.net) vom dw über den WG-Tunnel. Konkret am portainer.bf.emsenhuber.net aufgefallen. thema cloudflare-proxy → firewall-dns.

Reopened 2026-09-11: korrigierter Scope. 420-Fall (WARP/TP41) war nie das Problem — offen ist die Auflösung **interner** BF-Namen (`*.bf.emsenhuber.net`) vom dw über den WG-Tunnel. Konkret am `portainer.bf.emsenhuber.net` aufgefallen. thema cloudflare-proxy → firewall-dns.
admin added status:todothema:firewall-dns and removed status:droppedthema:cloudflare-proxy labels 2026-09-11 13:20:29 +02:00
admin commented 2026-09-11 13:53:31 +02:00
Author
Owner
Copy Link

Entscheidung 2026-09-11: DHCP-Multi [10.40.20.36, 10.40.20.37, 9.9.9.9] am dw (statt FB-Upstream bzw. conditional forwarder — Cudy-APs können kein DNS, FritzBox kein Per-Zone-Forward).

Live verifiziert (dig @10.40.20.36 über Tunnel): bf-Namen → 10.40.20.40/.167 (über WG erreichbar), fm-Namen → Cloudflare-Anycast 188.114.96.10/.97.10, nie 10.101.x ⇒ der fm-Route-Einwand trifft nicht zu.

Offen: On-site-Umsetzung + 2 Verifikationen (DHCP liefert Fremd-DNS aus; Clients fragen strikt in Reihenfolge → kein NXDOMAIN-Leak).

Entscheidung 2026-09-11: **DHCP-Multi `[10.40.20.36, 10.40.20.37, 9.9.9.9]`** am dw (statt FB-Upstream bzw. conditional forwarder — Cudy-APs können kein DNS, FritzBox kein Per-Zone-Forward). Live verifiziert (`dig @10.40.20.36` über Tunnel): bf-Namen → `10.40.20.40`/`.167` (über WG erreichbar), fm-Namen → Cloudflare-Anycast `188.114.96.10/.97.10`, **nie 10.101.x** ⇒ der fm-Route-Einwand trifft nicht zu. Offen: On-site-Umsetzung + 2 Verifikationen (DHCP liefert Fremd-DNS aus; Clients fragen strikt in Reihenfolge → kein NXDOMAIN-Leak).
admin commented 2026-09-11 14:25:42 +02:00
Author
Owner
Copy Link

Korrektur 2026-09-11: DHCP-Multi verworfen — die dw-FritzBox kann per DHCP nur eine DNS-IP ausliefern. Neue Entscheidung: FB-Upstream — Clients → 10.95.10.1 (FB), FB forwardet an .36+.37; zwingend die DNS-Rebind-Schutz-Ausnahme bf.emsenhuber.net (sonst werden die Privat-IP-Antworten als Rebind gefiltert). BF-down-Fallback über das FRITZ!OS-„öffentliche NS bei Unreachbarkeit"-Setting oder public im Alternativ-Slot.

Korrektur 2026-09-11: **DHCP-Multi verworfen** — die dw-FritzBox kann per DHCP nur **eine** DNS-IP ausliefern. Neue Entscheidung: **FB-Upstream** — Clients → `10.95.10.1` (FB), FB forwardet an `.36`+`.37`; zwingend die **DNS-Rebind-Schutz-Ausnahme `bf.emsenhuber.net`** (sonst werden die Privat-IP-Antworten als Rebind gefiltert). BF-down-Fallback über das FRITZ!OS-„öffentliche NS bei Unreachbarkeit"-Setting oder public im Alternativ-Slot.
admin commented 2026-09-11 14:59:21 +02:00
Author
Owner
Copy Link

Umgesetzt 2026-09-11 (Christoph, on-site an der dw-FritzBox): Upstream 10.40.20.36 + 10.40.20.37, DNS-Rebind-Ausnahme bf.emsenhuber.net gesetzt, und der Fallback-Haken „öffentliche NS verwenden, wenn die primären nicht erreichbar sind" existiert und ist aktiviert → Ideal-Variante (.37-Redundanz bleibt, BF-down fällt auf public). Schließe als done.

Umgesetzt 2026-09-11 (Christoph, on-site an der dw-FritzBox): Upstream **10.40.20.36 + 10.40.20.37**, **DNS-Rebind-Ausnahme `bf.emsenhuber.net`** gesetzt, und der Fallback-Haken „öffentliche NS verwenden, wenn die primären nicht erreichbar sind" **existiert und ist aktiviert** → Ideal-Variante (`.37`-Redundanz bleibt, BF-down fällt auf public). Schließe als done.
admin added status:done and removed status:todo labels 2026-09-11 14:59:21 +02:00
admin closed this issue 2026-09-11 14:59:21 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
status:concept
status:done
status:dropped
status:idea
status:paused
status:todo
status:wip
thema:backlog
thema:cloudflare-proxy
thema:firewall-dns
thema:identity
thema:infra
thema:ipv6-matter
thema:nautobot-doku
thema:wlan
No Label status:done thema:firewall-dns
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/bf-infra#32
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?