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

TP45 — VLAN20/VLAN30 ins TP32-Schema + DNS/FQDN aus Nautobot #71

New Issue
Open
opened 2026-09-21 12:56:06 +02:00 by admin · 3 comments
admin commented 2026-09-21 12:56:06 +02:00
Owner
Copy Link

Anriss: VLAN20 und VLAN30 in die TP32-Nummern-/Adress-Systematik überführen, danach
DNS/FQDN aus Nautobot. Ausgelöst durch „viele *.emsenhuber.net wirken verschwunden" (2026-09-21).

Root Cause (live bewiesen): nicht Caddy und nicht Cloudflare haben etwas verloren —
(a) AGH wertet DNS-Rewrites im Filter-Pfad aus; für filtering_enabled: false-Clients
(alle Browser-Gruppen) werden sie übersprungen → Fallback auf den conditional forward auf den Core,
der nur 10 Statics hat → NXDOMAIN für 11 Dienstnamen. (b) ds-bf geht als einziger Ingress-Eintrag
direkt auf http://10.40.20.10:8080 statt über Caddy und fällt damit unter TP5: deny-by-default.

Prosa/Detail: docs/teilprojekte.md → ### TP45.

Reihenfolge (Christoph-Entscheide 2026-09-21):

  • A VLAN20 virtuelle Gäste ins Schema — Nautobot zuerst (.30-.34 → .154-.156/.158),
    danach AGH .36/.37 → .30/.31. 27 Skript-/Config-Dateien hängen an 10.40.20.30.
  • B VLAN30 — nur die Pool-Grenze, Geräte bleiben vorerst (Christoph: „nur Pool-Grenze").
  • C DNS/FQDN: ds-bf über Caddy, coolify.bf neu, .bf-Namen vollständig auf den Core,
    AGH nur noch Filtering mit Upstream Core, TP34 FQDN-als-Datum.
  • D Tunnel-Inventar + GC + generische Namen, TP30 #10 (TUNNEL_TOKEN), Leak-Ursachen.
  • E nas/pve/macmini umziehen (eigene Session, nur planen + reservieren).
  • F CF-/Tunnel-SSoT + Recovery → TP46.

Vorarbeit erledigt: TP32-Oktett-Tabelle korrigiert (.10-.19/.20-.29-Split, Server-Block
.100-.149, Broker/Funk .9x, Platform .8x); CCU-Startgruppe live 40 → 50 korrigiert
(sie gehört zur Anwendungsgruppe wie haos, nicht zu Funk).

Blocker/Voraussetzung: DHCP-Reservierungen werden von Golden Config nirgends gerendert
(26 VLAN30 + 1 VLAN20 liegen als Handarbeit auf dem Gerät) → Renderer muss erst gebaut werden.

Abgrenzung: VMID-Umnummerierung bleibt draußen (TP32: „Bestand bleibt, wo er ist").
Tunnel-Token-Rotation läuft in TP30; hier wird nur Posten #10 gesetzt.

Anriss: VLAN20 und VLAN30 in die TP32-Nummern-/Adress-Systematik überführen, danach DNS/FQDN aus Nautobot. Ausgelöst durch „viele *.emsenhuber.net wirken verschwunden" (2026-09-21). **Root Cause (live bewiesen):** nicht Caddy und nicht Cloudflare haben etwas verloren — (a) AGH wertet DNS-Rewrites im **Filter-Pfad** aus; für `filtering_enabled: false`-Clients (alle Browser-Gruppen) werden sie übersprungen → Fallback auf den conditional forward auf den Core, der nur 10 Statics hat → NXDOMAIN für 11 Dienstnamen. (b) `ds-bf` geht als einziger Ingress-Eintrag **direkt** auf `http://10.40.20.10:8080` statt über Caddy und fällt damit unter `TP5: deny-by-default`. Prosa/Detail: `docs/teilprojekte.md` → `### TP45`. **Reihenfolge (Christoph-Entscheide 2026-09-21):** - **A** VLAN20 virtuelle Gäste ins Schema — **Nautobot zuerst** (`.30-.34` → `.154-.156`/`.158`), danach AGH `.36/.37` → `.30/.31`. 27 Skript-/Config-Dateien hängen an `10.40.20.30`. - **B** VLAN30 — **nur die Pool-Grenze**, Geräte bleiben vorerst (Christoph: „nur Pool-Grenze"). - **C** DNS/FQDN: `ds-bf` über Caddy, `coolify.bf` neu, `.bf`-Namen vollständig auf den Core, AGH nur noch Filtering mit Upstream Core, TP34 FQDN-als-Datum. - **D** Tunnel-Inventar + GC + generische Namen, TP30 #10 (`TUNNEL_TOKEN`), Leak-Ursachen. - **E** nas/pve/macmini umziehen (**eigene Session**, nur planen + reservieren). - **F** CF-/Tunnel-SSoT + Recovery → **TP46**. **Vorarbeit erledigt:** TP32-Oktett-Tabelle korrigiert (.10-.19/.20-.29-Split, Server-Block `.100-.149`, Broker/Funk `.9x`, Platform `.8x`); CCU-Startgruppe live `40 → 50` korrigiert (sie gehört zur Anwendungsgruppe wie `haos`, nicht zu Funk). **Blocker/Voraussetzung:** DHCP-Reservierungen werden von Golden Config **nirgends gerendert** (26 VLAN30 + 1 VLAN20 liegen als Handarbeit auf dem Gerät) → Renderer muss erst gebaut werden. **Abgrenzung:** VMID-Umnummerierung bleibt draußen (TP32: „Bestand bleibt, wo er ist"). Tunnel-Token-**Rotation** läuft in TP30; hier wird nur Posten #10 gesetzt.
admin added the status:todothema:firewall-dnsthema:nautobot-dokuthema:infra labels 2026-09-21 12:56:06 +02:00
admin commented 2026-09-21 23:06:03 +02:00
Author
Owner
Copy Link

Fund B — Adress-Recycling: die Core-Adressliste nautobot erlaubt jetzt AGH den MGMT-SSH

Live gemessen 2026-09-21 am crs326-core (list_address_list_entries list=nautobot), 6 Eintraege:

.id Adresse Kommentar angelegt
*1 10.40.20.30 nautobot web 2026-08-18 04:47
*2 10.40.20.31 nautobot worker = der Deploy-Pfad 2026-08-18 04:47
*3 10.40.20.32 nautobot scheduler 2026-08-18 04:47
*5 10.40.20.154 nautobot web (TP45: .154, Alt-.30 bis Rueckbau) 2026-09-21 13:02
*6 10.40.20.155 nautobot worker = der Deploy-Pfad (TP45: .155, Alt-.31 bis Rueckbau) 2026-09-21 13:02
*7 10.40.20.156 nautobot scheduler (TP45: .156, Alt-.32 bis Rueckbau) 2026-09-21 13:02

Die Kollision: die Alt-Adressen .30/.31 wurden am selben Tag an AGH uebergeben
(b52d6aa raeumt Nautobot auf .154-.158, 974ecbc/139d7c0 geben .30/.31 an
agh-bf1/agh-bf2 — live belegt: net1 = .30/.31, http://10.40.20.30 liefert das
AGH-Dashboard). Die Alt-Eintraege stehen aber als Uebergang bis zum Rueckbau. Damit
erlaubt src-address-list=nautobot -> vlan99:22 jetzt AGH (LXC 110/111) den MGMT-SSH,
nicht mehr Nautobot.

Warum das zaehlt: die Liste wird von Golden Config nirgends gerendert (handgelaufenes
routeros/tp5-etappe2-whitelists.rsc, s. CLAUDE.md „Recovery-Luecke") — schon deshalb ein
Sonderfall. Jetzt kommt hinzu, dass zwei ihrer Eintraege die Bedeutung gewechselt haben,
ohne dass sich die Liste geaendert hat. Eine Least-Privilege-Ausnahme gilt damit fuer ein
Geraet, das sie nie beantragt hat. Die Compliance-Zahl sieht davon nichts, weil nichts
gerendert wird.

Die Pipeline selbst ist nicht gebrochen: .155 (der Deploy-Pfad) steht drin, der
Nautobot-Worker kommt weiter durch.

Offen / beim Rueckbau zu klaeren:

  • .32 ist frei — nichts hat es uebernommen, nur noch historischer Eintrag.
  • Beim Rueckbau der Doppeladressen muessen .30/.31 aus der Liste raus, sonst bleibt
    AGH dauerhaft im MGMT-Zugang.
  • Derselbe Mechanismus trifft Schicht E: der Plan stellt die Regel „keine andere Zelle
    darf eine Alt-IP beanspruchen" auf — in Schicht A ist sie passiert. Beim Aufbau der
    Sekundaer-IPs fuer nas/pve/macmini (nas .10 -> .110, pve .100 -> .121,
    macmini .167 -> .130) die Alt-IPs explizit gegen Neubelegung sperren.
### Fund B — Adress-Recycling: die Core-Adressliste `nautobot` erlaubt jetzt AGH den MGMT-SSH Live gemessen 2026-09-21 am `crs326-core` (`list_address_list_entries list=nautobot`), **6 Eintraege**: | .id | Adresse | Kommentar | angelegt | |---|---|---|---| | *1 | `10.40.20.30` | nautobot web | 2026-08-18 04:47 | | *2 | `10.40.20.31` | nautobot worker = der Deploy-Pfad | 2026-08-18 04:47 | | *3 | `10.40.20.32` | nautobot scheduler | 2026-08-18 04:47 | | *5 | `10.40.20.154` | nautobot web (TP45: .154, Alt-.30 bis Rueckbau) | 2026-09-21 13:02 | | *6 | `10.40.20.155` | nautobot worker = der Deploy-Pfad (TP45: .155, Alt-.31 bis Rueckbau) | 2026-09-21 13:02 | | *7 | `10.40.20.156` | nautobot scheduler (TP45: .156, Alt-.32 bis Rueckbau) | 2026-09-21 13:02 | **Die Kollision:** die Alt-Adressen `.30`/`.31` wurden **am selben Tag** an AGH uebergeben (`b52d6aa` raeumt Nautobot auf `.154-.158`, `974ecbc`/`139d7c0` geben `.30`/`.31` an agh-bf1/agh-bf2 — live belegt: `net1` = `.30`/`.31`, `http://10.40.20.30` liefert das AGH-Dashboard). Die Alt-Eintraege stehen aber als Uebergang **bis zum Rueckbau**. Damit erlaubt `src-address-list=nautobot -> vlan99:22` jetzt **AGH** (LXC 110/111) den MGMT-SSH, nicht mehr Nautobot. **Warum das zaehlt:** die Liste wird von Golden Config **nirgends gerendert** (handgelaufenes `routeros/tp5-etappe2-whitelists.rsc`, s. CLAUDE.md „Recovery-Luecke") — schon deshalb ein Sonderfall. Jetzt kommt hinzu, dass **zwei ihrer Eintraege die Bedeutung gewechselt haben, ohne dass sich die Liste geaendert hat**. Eine Least-Privilege-Ausnahme gilt damit fuer ein Geraet, das sie nie beantragt hat. Die Compliance-Zahl sieht davon nichts, weil nichts gerendert wird. **Die Pipeline selbst ist nicht gebrochen:** `.155` (der Deploy-Pfad) steht drin, der Nautobot-Worker kommt weiter durch. **Offen / beim Rueckbau zu klaeren:** - `.32` ist frei — nichts hat es uebernommen, nur noch historischer Eintrag. - Beim Rueckbau der Doppeladressen muessen `.30`/`.31` aus der Liste **raus**, sonst bleibt AGH dauerhaft im MGMT-Zugang. - Derselbe Mechanismus trifft **Schicht E**: der Plan stellt die Regel „keine andere Zelle darf eine Alt-IP beanspruchen" auf — in Schicht A ist sie passiert. Beim Aufbau der Sekundaer-IPs fuer nas/pve/macmini (`nas .10 -> .110`, `pve .100 -> .121`, `macmini .167 -> .130`) die Alt-IPs explizit gegen Neubelegung sperren.
admin added status:wip and removed status:todo labels 2026-09-21 23:06:33 +02:00
admin commented 2026-09-22 12:28:36 +02:00
Author
Owner
Copy Link

Schicht C — FQDN-Wiederherstellung vorgezogen: C1–C3 durch (2026-09-22, Commit 6d1d56e)

Die IP-Umstellung (A/B/E) dauert länger; die internen Namen mussten jetzt zurück. C ist damit
vor A/B erledigt — A, B, E bleiben wie geplant offen.

  • C1 — 17 Namen in den Core. nautobot/mikrotik_routeros.j2 → 27 /ip dns static (vorher 10);
    Deploy über den neuen GC-Job tp45-c-dns (idempotenter Upsert, liest die Zeilen aus dem Template
    selbst). Abnahme am Gerät: 27 Statics, --refresh-compliance → 145/145, 0 Drifts.
    (140 → 145 = die neue 29. Regel „DHCP-Reservierungen" aus 09-21 × 5 Geräte — erklärt, nicht Zufall.)
  • C2 — AGH entdoppelt. upstream_dns = nur 10.40.20.1, CF-DoH + conditional Forward raus,
    alle 26 Rewrites weg (Weg: adguard/agh-sync.py push). Vorher/Nachher geprüft: verhaltensneutral.
    Abnahme: .36 == .37 · /admin header-frei 200, mit CF-Connecting-IP weiter 404 · Filter intakt.
  • C3 — ds-bf über Caddy. CF-Ingress-Origin http://10.40.20.10:8080 → https://10.40.20.40:443
    (+ originServerName). Öffentlich 200 in 0,24 s (vorher 000 nach 20 s). CF-MCP kann nicht
    schreiben     (1001) — Write über CF_API_TOKEN aus mcp/cloudflare/.env.
  • WARP-Abnahme ✅ (Christophs Bedingung): unter WARP dig → .40, Route über utun8, /admin 200.
    Der 404 des Users war Browser-/mDNS-Cache. Hebel (a) nicht nötig.

Zwei Befunde, dokumentiert (nicht geändert):

  • 🔴 AAAA bleibt öffentlich — der Core hält nur A-Statics und reicht AAAA weiter → bare Namen
    liefern die CF-IPv6. Heute inert (kein globales IPv6). Latent. Christoph 09-22: dokumentieren, nicht ändern.
  • 🔴 AGH ist doppelt adressiert — LXC 110/111 haben eth0 .36/.37 und eth1 .30/.31;
    Schicht A ist dort halb umgestellt (neue IP live + per DHCP verteilt, Alt-IP lebt). Gehört in die
    „siedeln"-Messung.

Offen in C: coolify.bf (nicht ausgerollt) · C4 (TP34, FQDN als Daten).

**Schicht C — FQDN-Wiederherstellung vorgezogen: C1–C3 durch (2026-09-22, Commit `6d1d56e`)** Die IP-Umstellung (A/B/E) dauert länger; die internen Namen mussten jetzt zurück. C ist damit **vor** A/B erledigt — A, B, E bleiben wie geplant offen. - **C1 — 17 Namen in den Core.** `nautobot/mikrotik_routeros.j2` → **27** `/ip dns static` (vorher 10); Deploy über den neuen GC-Job `tp45-c-dns` (idempotenter Upsert, liest die Zeilen aus dem Template selbst). Abnahme am **Gerät**: 27 Statics, `--refresh-compliance` → **145/145, 0 Drifts**. (140 → 145 = die neue 29. Regel „DHCP-Reservierungen" aus 09-21 × 5 Geräte — erklärt, nicht Zufall.) - **C2 — AGH entdoppelt.** `upstream_dns` = nur `10.40.20.1`, CF-DoH + conditional Forward raus, **alle 26 Rewrites weg** (Weg: `adguard/agh-sync.py push`). Vorher/Nachher geprüft: verhaltensneutral. Abnahme: `.36 == .37` · `/admin` header-frei 200, mit `CF-Connecting-IP` weiter 404 · Filter intakt. - **C3 — `ds-bf` über Caddy.** CF-Ingress-Origin `http://10.40.20.10:8080` → `https://10.40.20.40:443` (+ `originServerName`). Öffentlich **200 in 0,24 s** (vorher 000 nach 20 s). CF-**MCP kann nicht schreiben** (1001) — Write über `CF_API_TOKEN` aus `mcp/cloudflare/.env`. - **WARP-Abnahme ✅** (Christophs Bedingung): unter WARP `dig` → `.40`, Route über `utun8`, `/admin` 200. Der 404 des Users war Browser-/mDNS-Cache. Hebel (a) nicht nötig. **Zwei Befunde, dokumentiert (nicht geändert):** - 🔴 **AAAA bleibt öffentlich** — der Core hält nur A-Statics und reicht AAAA weiter → bare Namen liefern die CF-IPv6. Heute inert (kein globales IPv6). Latent. Christoph 09-22: dokumentieren, nicht ändern. - 🔴 **AGH ist doppelt adressiert** — LXC 110/111 haben `eth0` `.36`/`.37` **und** `eth1` `.30`/`.31`; Schicht A ist dort halb umgestellt (neue IP live + per DHCP verteilt, Alt-IP lebt). Gehört in die „siedeln"-Messung. **Offen in C:** `coolify.bf` (nicht ausgerollt) · **C4** (TP34, FQDN als Daten).
admin commented 2026-09-22 13:03:30 +02:00
Author
Owner
Copy Link

C4 geschärft + Träger festgelegt (2026-09-22).

  • C4 = die internen Namen als Daten, nicht Caddyfile-Rendering. Die 27 A-Statics auf crs326-core (*.bf.emsenhuber.net, live geprüft 2026-09-22) sind heute Handarbeit und werden von GC nirgends gerendert ⇒ Recovery-von-null erzeugt einen Core ohne interne Namensauflösung — dieselbe Recovery-Lücke wie die DHCP-Reservierungen und die nautobot-Adressliste.
  • Träger: #73 TP34.2 — Interne DNS-Namen als Daten (status:todo, Christoph-Entscheid „gemeinsame Arbeit"). Parent #24 (TP34) bleibt status:dropped — dort war Caddyfile-Rendering verworfen, hier ist der Gegenstand ein anderer.
  • Repo nachgezogen: docs/teilprojekte.md (neuer Abschnitt ### TP34.2, Schicht-C-Tabelle, „Offen in C", Abh./Blockiert, Follow-up), docs/teilprojekte-archiv.md (Zeiger auf die Fortsetzung), CLAUDE.md Pflichtlektüre.

Offen in Schicht C bleibt damit: coolify.bf (Port unbekannt — nicht raten) + C4 → #73.

**C4 geschärft + Träger festgelegt (2026-09-22).** - **C4 = die internen Namen als Daten**, nicht Caddyfile-Rendering. Die **27** `A`-Statics auf `crs326-core` (`*.bf.emsenhuber.net`, live geprüft 2026-09-22) sind heute Handarbeit und werden **von GC nirgends gerendert** ⇒ Recovery-von-null erzeugt einen Core **ohne** interne Namensauflösung — dieselbe Recovery-Lücke wie die DHCP-Reservierungen und die `nautobot`-Adressliste. - **Träger: #73 `TP34.2 — Interne DNS-Namen als Daten`** (`status:todo`, Christoph-Entscheid „gemeinsame Arbeit"). Parent **#24 (TP34) bleibt `status:dropped`** — dort war *Caddyfile-Rendering* verworfen, hier ist der Gegenstand ein anderer. - Repo nachgezogen: `docs/teilprojekte.md` (neuer Abschnitt `### TP34.2`, Schicht-C-Tabelle, „Offen in C", Abh./Blockiert, Follow-up), `docs/teilprojekte-archiv.md` (Zeiger auf die Fortsetzung), `CLAUDE.md` Pflichtlektüre. **Offen in Schicht C bleibt damit:** `coolify.bf` (Port unbekannt — nicht raten) + **C4 → #73**.
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:wip thema:firewall-dns thema:infra thema:nautobot-doku
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#71
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?