TP31: SoT-Frage beantwortet + cf-sync.py; Uebergabe nach User-Korrekturen
SoT: CF und Caddy werden NICHT synchron gehalten - die Doppelpflege faellt mit Schritt 5/6 weg. Heute stehen 19 Ingress-Regeln und 16 Caddy-Sites nebeneinander und stimmen fachlich ueberein; im Zielbild haelt CF nur noch eine Catch-all auf 10.40.20.40. Danach: Caddyfile = Name->Origin, CF = welcher Name ist oeffentlich (4), AGH = Name->IP intern. Nebeneffekt: die 12 internen Namen brauchen keinen oeffentlichen DNS mehr. caddy/cf-sync.py (read-only, Exit 1 bei Drift) findet im ersten Lauf sieben Abweichungen, alle auf CF-Seite: grafana noch im Ingress, nautobot und gateway-dw als CNAME ohne Ingress (Quelle der 302), drei *.bf-CNAMEs auf den zerstoerten NPM, dazu die Wildcard-Access-App, die alles maskiert. Uebergabe korrigiert nach User-Einwand und Gegenmessung: - Rewrites sind veraltet, nicht wertlos - Hosts leben auf VLAN20 weiter, also Ziele umbiegen statt Namen loeschen. - Die Redundanz existiert doch, reziprok ueber die Standorte: FM antwortet auf 10.101.0.16/.17 (DS415+) - und beide liefern fuer nas.bf die tote VLAN1-Adresse. Ein Rewrite-Satz nur im neuen BF-Paar erzeugt standortabhaengig verschiedene Antworten. - Vorratsregel auf .16 wird gestrichen statt erweitert (User-Entscheid). - Cave: emsenhuber.net ist die Domain, bf.lan nur der DHCP-Suffix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -39,20 +39,26 @@ Auflösung selbst das Kaputte ist. **Nicht ans Ende einer langen Sitzung legen**
|
||||
|
||||
## 🔴 Was den Plan ändert — drei Funde vom 2026-08-25 (spät), alle live erhoben
|
||||
|
||||
### 1. Der Bestands-AdGuard ist ein **Archiv, keine Vorlage**
|
||||
### 1. Die Rewrites sind **veraltet, nicht wertlos** — Ziele umbiegen statt löschen
|
||||
> 🔴 **Korrektur (User, 2026-08-26):** „manche hosts leben auf vlan 20 weiter" — die erste Fassung
|
||||
> hat die `10.40.41.x`-Einträge pauschal als tot bezeichnet. Falsch ist das **Ziel**, nicht der
|
||||
> **Name**: `nas`, `macmini`, `appletv`, `tv`, `mfc` gibt es weiter, sie sind nur umgezogen
|
||||
> (NAS `10.40.20.10`, macmini `10.40.20.167`, Brother MFC `10.40.10.6` — der steht auf **VLAN10**).
|
||||
> ⇒ **Jeder Name einzeln bewerten: umbiegen, wenn der Host lebt; streichen, wenn nicht.**
|
||||
`adguard_bf1` (`10.40.20.16`, Docker in LXC 400) läuft seit 7 Tagen und hält **24 Rewrites** — davon
|
||||
ist der überwiegende Teil **tot**:
|
||||
|
||||
| Klasse | Anzahl | Beispiel | Warum tot |
|
||||
| Klasse | Anzahl | Beispiel | Was damit zu tun ist |
|
||||
|---|---|---|---|
|
||||
| Ziel im **toten VLAN1** | 8 | `nas.bf…→10.40.41.10`, `mfc.bf…→10.40.41.4`, `macmini.bf…→10.40.41.167` | VLAN1 ist seit 2026-08-18 leer (TP19) |
|
||||
| Ziel **`nginx-bf.emsenhuber.net`** | 9 | `portainer`, `z2m25`, `nodered`, `grafana`, `vw`, `speedtest`, … | der NPM (LXC **128**) ist **heute** zerstört worden |
|
||||
| **FritzBox-Reste** | 2 | `*.myfritz.net → 100.72.62.31` / `10.40.41.254` | FB6660 seit 2026-07-01 ausgebaut |
|
||||
| FM-Standort | 3 | `nas.fm…→10.101.0.10` | anderer Standort, hier nicht anfassen |
|
||||
| Ziel im toten VLAN1, **Host lebt** | 8 | `nas.bf…→10.40.41.10`, `mfc.bf…→10.40.41.4`, `macmini.bf…→10.40.41.167` | **umbiegen** auf die VLAN20/VLAN10-Adresse |
|
||||
| Ziel **`nginx-bf.emsenhuber.net`** | 9 | `portainer`, `z2m25`, `nodered`, `grafana`, `vw`, `speedtest`, … | Ziel ersetzen durch **`10.40.20.40`** — Caddy tritt an die Stelle des NPM (LXC 128 ist zerstört) |
|
||||
| **FritzBox-Reste** | 2 | `*.myfritz.net → 100.72.62.31` / `10.40.41.254` | streichen (FB6660 seit 2026-07-01 ausgebaut) |
|
||||
| FM-Standort | 3 | `nas.fm…→10.101.0.10` | dort gepflegt, s. Fund 2 |
|
||||
|
||||
⇒ **Übernehmen: `upstream_dns`, `bootstrap_dns`, Filterlisten. NICHT die Rewrites.**
|
||||
Die 16 Rewrites werden **aus `caddy/Caddyfile` neu erzeugt** (jeder Site-Name → `10.40.20.40`).
|
||||
Die Altlasten oben sind eine **eigene, bewusste Entscheidung je Name** — nicht mitschleppen.
|
||||
⇒ **Übernehmen: `upstream_dns`, `bootstrap_dns`, Filterlisten.**
|
||||
Die 16 Service-Rewrites entstehen **neu aus `caddy/Caddyfile`** (jeder Site-Name → `10.40.20.40`).
|
||||
Die Host-Rewrites oben werden **einzeln entschieden** — nicht blind mitschleppen, aber auch nicht
|
||||
pauschal wegwerfen.
|
||||
|
||||
Was dort **richtig** steht und mitmuss:
|
||||
```
|
||||
@@ -61,15 +67,42 @@ upstream_dns:
|
||||
- '[/bf.lan/]10.40.20.1'
|
||||
- '[/40.10.in-addr.arpa/]10.40.20.1'
|
||||
```
|
||||
🔑 Die zweite Zeile ist **nicht optional**: der Core vergibt `domain=bf.lan` und legt aus jeder Lease
|
||||
> ⚠️ **Cave (User, 2026-08-26): `emsenhuber.net` ist unsere Domain, nicht `bf.lan`.**
|
||||
> `bf.lan` ist nur der **DHCP-interne Suffix**, den der Core heute vergibt (`domain=bf.lan` +
|
||||
> `add-dns-entries-suffix=lan`) — er hat keine Namensautorität. **Offene Entscheidung für diese
|
||||
> Session:** so lassen oder auf `bf.emsenhuber.net` heben (dann zieht der conditional upstream mit
|
||||
> und die Lease-Namen liegen unter der echten Domain). Nicht nebenbei umstellen — es betrifft jeden
|
||||
> Lease-Namen.
|
||||
|
||||
🔑 Der conditional upstream ist **nicht optional**: der Core vergibt `domain=bf.lan` und legt aus jeder Lease
|
||||
einen `*.lan`-Eintrag an (`add-dns-entries-suffix=lan`). Ohne diesen conditional upstream sterben
|
||||
**alle** Lease-Namen. Ebenso bleibt **mDNS Sache des Core** (`mdns-repeat-ifaces` = vlan10/20/30/40/90).
|
||||
|
||||
### 2. `10.40.20.17` ist **nicht** „bf2"
|
||||
Dort läuft **`adguard_fm2`** — die zweite Instanz des **FM**-Standorts, hier nur mitgehostet. Sie
|
||||
beantwortet `gitea.emsenhuber.net` mit **`10.40.41.123`**, also ebenfalls ins tote VLAN1.
|
||||
⇒ **Nicht als Vorlage, nicht als „vorhandene Redundanz" verbuchen.** BF hat heute **einen** AGH.
|
||||
(Dass FM stale Rewrites hat, ist ein eigener Punkt — nicht in dieser Session.)
|
||||
### 2. Die Redundanz **gibt es** — wechselseitig standortübergreifend (und sie ist überall stale)
|
||||
> 🔴 **Korrektur (User, 2026-08-26):** „die redundanz gab es schon! und zwar wechselseitig
|
||||
> standortübergreifend. bei fm klarerweise auf ds415+ gehostet."
|
||||
|
||||
**Live gegengeprüft (2026-08-26, `nslookup` über den WG-Tunnel):**
|
||||
|
||||
| Instanz | wo | antwortet auf 53 | `nas.bf.emsenhuber.net` → |
|
||||
|---|---|---|---|
|
||||
| `adguard_bf1` | BF, Docker in LXC 400 (`10.40.20.16`) | ✅ | BF-Rewrite, VLAN1-Ziel |
|
||||
| `adguard_fm2` | **BF** (`10.40.20.17`), für FM | ✅ | — |
|
||||
| FM-Resolver 1 | **FM**, DS415+ (`10.101.0.16`) | ✅ | **`10.40.41.10`** |
|
||||
| FM-Resolver 2 | **FM**, DS415+ (`10.101.0.17`) | ✅ | **`10.40.41.10`** |
|
||||
|
||||
⇒ Das Muster ist **reziprok**: jeder Standort hostet auch eine Instanz des anderen, spiegelbildlich
|
||||
auf `.16`/`.17`. (`10.101.0.10` — die FM-NAS selbst — antwortet **nicht** auf 53.)
|
||||
|
||||
🔑 **Die Konsequenz ist größer als „ein Paar bauen":** die BF-Namen liegen in **vier** Resolvern an
|
||||
**zwei** Standorten, und **beide FM-Instanzen antworten heute mit der toten VLAN1-Adresse**. Ein
|
||||
Rewrite-Satz, den nur das neue BF-Paar kennt, erzeugt **standortabhängig verschiedene Antworten** für
|
||||
denselben Namen. Zum Auftrag gehört deshalb eine Festlegung:
|
||||
- **entweder** den Rewrite-Satz als *eine* Quelle definieren und auf alle Instanzen ausrollen,
|
||||
- **oder** — wartungsärmer und konsistent mit der SoT-Antwort für CF/Caddy (s. TP31) — festlegen, dass
|
||||
**FM die BF-Namen nicht mehr selbst beantwortet**, sondern per conditional upstream nach BF fragt.
|
||||
- ⚠️ **Nicht in dieser Session mitfixen, aber notieren:** FM zeigt auf tote Ziele. Das braucht ein
|
||||
eigenes Fenster und den DS415+-Zugang.
|
||||
|
||||
### 3. Die Firewall-Vorratsregeln zeigen auf die **falsche** IP
|
||||
TP5 Etappe 2 hat vorgesorgt, aber hart auf den heutigen Container:
|
||||
@@ -82,8 +115,10 @@ TP5-E2: LAN->AGH dns-tcp accept tcp dst-address=10.40.20.16 dst-port=53
|
||||
**`forward`-Fluss über VLAN-Grenzen** — und die Firewall ist seit 2026-08-18 deny-by-default.
|
||||
Ohne passende Regeln verlieren **IOT, MEDIA, UNTRUSTED, GUEST und MGMT** schlagartig die Auflösung,
|
||||
während VLAN20 (wo der Resolver steht) unauffällig weiterläuft.
|
||||
⇒ **Die beiden Regeln auf die neuen AGH-Adressen erweitern, bevor irgendein DHCP angefasst wird** —
|
||||
und zwar **über Nautobot Golden Config**, nicht ad hoc: Core-Config ist GC-only.
|
||||
✅ **Entscheid (User, 2026-08-26): die Vorratsregel auf `10.40.20.16` wird GESTRICHEN** — „`.16` war
|
||||
historisch, passt aber nicht mehr ins System." Also **nicht erweitern, sondern ersetzen**: die zwei
|
||||
alten Zeilen raus, zwei neue auf das Paar `10.40.20.36/.37` rein — **über Nautobot Golden Config**,
|
||||
nicht ad hoc (Core-Config ist GC-only), und **bevor** irgendein DHCP angefasst wird.
|
||||
|
||||
## Der Auftrag
|
||||
|
||||
|
||||
@@ -1509,6 +1509,43 @@ Der `http:`-Block ist eingetragen (`use_x_forwarded_for: true` + `trusted_proxie
|
||||
⚠️ **Preis, offen benannt:** mit Split-Horizon greift **Access innerhalb des Netzes nicht mehr**; dort
|
||||
tragen TP5-Segmentierung und die App-eigene Auth.
|
||||
|
||||
#### 🧭 Wo liegt die Source of Truth? — beantwortet 2026-08-26
|
||||
> **User-Frage:** „schaffen wir es mit überschaubarem aufwand cf und caddy synchron zu halten? wo
|
||||
> liegt die sot?"
|
||||
|
||||
**Antwort: gar nicht synchron halten — die Doppelpflege fällt mit Schritt 5/6 von selbst weg.**
|
||||
Heute steht dieselbe Zuordnung *Name → Origin* an **zwei** Orten: im CF-Ingress (19 Regeln über drei
|
||||
bf-Tunnel) und im `caddy/Caddyfile` (16 Sites). Der Vergleich am 08-26 zeigt: **sie stimmen fachlich
|
||||
überein** — jeder gemeinsame Name zeigt auf **dasselbe** Origin. Es gibt also nichts zu versöhnen,
|
||||
nur etwas abzuschaffen.
|
||||
|
||||
Im Zielbild hat der Tunnel `bf-public` **eine einzige Catch-all-Regel auf `10.40.20.40`**. Damit hält
|
||||
Cloudflare **keine** Host→Origin-Zuordnung mehr, und die SoT ist eindeutig:
|
||||
|
||||
| Was | SoT | wo gepflegt |
|
||||
|---|---|---|
|
||||
| Name → Origin (alle Dienste) | **`caddy/Caddyfile`** (Git) | dieses Repo |
|
||||
| Welcher Name ist öffentlich | **CNAME + Access-App** (4 Namen) | Cloudflare |
|
||||
| Name → IP **intern** | **AdGuard-Rewrites** (TP23 Stufe 2) | AGH-Paar |
|
||||
|
||||
⇒ Zu pflegen bleiben **vier** öffentliche Namen statt neunzehn Ingress-Regeln. Und die zwölf internen
|
||||
Namen brauchen dann **gar keinen öffentlichen DNS-Eintrag mehr** — heute ist z. B. `pve.emsenhuber.net`
|
||||
öffentlich auflösbar (hinter Access), danach ist es von außen schlicht unbekannt. **Das ist ein
|
||||
Sicherheitsgewinn, kein Nebeneffekt.**
|
||||
|
||||
🛠️ **Werkzeug dafür: [`caddy/cf-sync.py`](../caddy/cf-sync.py)** — read-only, liest CF-Ingress, Zonen-DNS
|
||||
und Access-Apps und stellt sie gegen den Caddyfile; Exit 1 bei Drift (cron-/CI-tauglich). Erster Lauf
|
||||
2026-08-26 fand **7 echte Abweichungen**, alle in Cloudflare, keine in Caddy:
|
||||
- **`grafana` steht noch im Ingress** (`bf-nas → 10.40.20.109:3000`) — ein Origin, das es nie gab.
|
||||
- **`nautobot` hat noch seinen CNAME**, aber seit TP16.3 keine Ingress-Regel ⇒ läuft in die Catch-all;
|
||||
**das** ist die Quelle des 302, das man leicht für „lebt noch" hält. Dasselbe bei `gateway-dw`.
|
||||
- **Drei `*.bf`-CNAMEs zeigen auf `nginx.bf`** — den heute zerstörten NPM (`phpmyadmin`, `speedtest`,
|
||||
`z2m25`).
|
||||
- Eine **Wildcard-Access-App `*.emsenhuber.net`** deckt die ganze Zone ab — sie ist der Grund, warum
|
||||
jeder FQDN ein sauberes 302 liefert, auch wenn dahinter nichts läuft.
|
||||
🔑 **Merkregel daraus:** *ein Eintrag ohne Gegenstück ist unsichtbar, solange etwas davor antwortet.*
|
||||
Der Drift-Check muss deshalb **beide** Richtungen prüfen — Ingress ohne Site **und** CNAME ohne Ingress.
|
||||
|
||||
#### HA-Ausblick (nicht Teil der Umsetzung)
|
||||
**Es bleibt bei Caddy** — zustandslos bis auf den Zertifikatsspeicher, identisches Caddyfile je Instanz,
|
||||
versionierbar; NPM hätte eine Datenbank, die man mitreplizieren müsste.
|
||||
|
||||
Reference in New Issue
Block a user