Files

Christoph Emsenhuber b77deed46c Uebergabe fuer den AGH-DNS-Cutover als eigene Session

Der Split-Horizon-Entscheid (AdGuard statt Core) macht aus 'ein paar
Eintraegen' eine Verschiebung der DNS-Aufloesung des ganzen Standorts in
einen Container -- heute liefert der DHCP in allen sieben VLANs den Core.
Das gehoert nicht ans Ende einer langen Sitzung (Lehre aus TP28).

Handoff enthaelt: Ausgangslage (Caddy produktiv, 16 Sites/17 Zertifikate),
den Auftrag in fuenf Schritten inkl. der IP-Kollision .30 (Nautobot) und
der Vorgabe, AGH als Paar 110/111 zu bauen statt als DNS-SPOF, sowie die
Staffelung VLAN fuer VLAN mit VLAN30 zuletzt.

Vier Fallen mitgegeben, alle in dieser Session bezahlt: Statuscode vom
oeffentlichen FQDN beweist nichts (grafana), pvesm free scheitert an
geschuetzten Snapshots stillschweigend, Startreihenfolge haengt nicht an
der VMID, und Core-Config braucht Golden Config.

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

2026-08-25 20:48:48 +02:00

4.9 KiB

Raw Blame History

Übergabe — nächste Session: AdGuard als Resolver + Split-Horizon (TP23 Stufe 2 ∥ TP31 Schritt 4)

Einstieg: diese Datei, dann teilprojekte.md → TP31 und TP32. Zustand am Netz: stabil. Caddy läuft produktiv, nichts steht halb offen, keine Config-Transaktion.

Warum eine eigene Session

Der Schritt verschiebt die DNS-Auflösung des ganzen Standorts vom Core in einen Container. Heute liefert der DHCP in allen sieben VLANs dns-server = <VLAN>.1; AdGuard auf 10.40.20.16 bekommt niemand. Ein Fehler trifft sofort jedes Gerät — und ist schlecht zu diagnostizieren, wenn die Auflösung selbst das Kaputte ist. Nicht ans Ende einer langen Sitzung legen (Lehre aus TP28).

Ausgangslage (Stand 2026-08-25, live geprüft)

✅ Caddy produktiv: LXC 130 caddy-bf1, 10.40.20.40, Debian 13, onboot=1, startup order=10, im Backup-Job. Caddy v2.11.4 mit dns.providers.cloudflare. 16 Sites, 17 Zertifikate per DNS-01. Config im Repo: caddy/Caddyfile, Ausrollen mit caddy/deploy.sh (liest CF_DNS_API_TOKEN aus ~/.secrets, nie auf stdout).
✅ Aufgeräumt: LXC 120/121/128/129/130(alt)/131 und 104 zerstört, PBS-Snapshots der ersten sechs restlos weg (72/72). Die 14 Snapshots von ct/104 stehen bewusst noch — einzige Kopie etwaiger Grafana-Dashboards.
✅ Startreihenfolge auf pve repariert (TP32): fünf Stufen, HA startet jetzt nach MariaDB, Docker, MQTT und z2m25.
🟡 Zwei bekannte Baustellen, beide vor der CNAME-Umstellung fällig:
- hass → 400: Home Assistant braucht 10.40.20.40 in http.trusted_proxies + use_x_forwarded_for: true.
- grafana ist tot und aus dem Caddyfile entfernt (s.u.).

Der Auftrag

User-Entscheid 2026-08-25: Split-Horizon nicht auf dem Core, sondern in AdGuard, zusammen mit TP23 Stufe 2 — „nichts zweimal bauen".

LXC 110 agh-bf1 und 111 agh-bf2 bauen. Muster: exakt wie LXC 130 (Debian 13, tag=20, onboot=1, startup order=10, im Backup-Job backup-6dcf5c10-610f). 🔑 Als Paar, nicht einzeln — TP32 reserviert 110–119 für DNS, und die gelöschten Altlasten hießen adguard-bf1/adguard-bf2: die Redundanz war schon einmal geplant. Ein einzelner AGH wäre ein DNS-SPOF auf pve. ⚠️ IP-Kollision klären: TP32 will DNS auf .3x, aber .30 ist Nautobot und .31 der nautobot-worker. Vorschlag .36/.37 als Interim.
Konfiguration übernehmen aus dem laufenden Docker-AdGuard (adguard_bf1, 10.40.20.16, in LXC 400 → Docker, Netz vlan20 = ipvlan). Dort stehen bereits DoH zum CF-Gateway und die conditional upstreams [/bf.lan/]10.40.20.1 und [/40.10.in-addr.arpa/]10.40.20.1. Backup laut TP23: AdGuardHome.yaml.bak-tp23-20260817.
Die 16 Rewrites setzen — alle Service-FQDNs aus caddy/Caddyfile → 10.40.20.40.
Erst testen, dann ausliefern. Direkt gegen die neuen Resolver abfragen (dig @<agh-ip>), bevor irgendein DHCP angefasst wird.
VLAN für VLAN umstellen, nicht alle sieben auf einmal. Vorschlag: VLAN20 zuerst (dort sitzt die Infrastruktur und man merkt Fehler sofort), dann VLAN10, der Rest zuletzt. VLAN30 (IoT, 26 Geräte) als letztes — dort ist ein Reconnect am teuersten.

Fallen, die schon bezahlt sind

🔴 Ein Statuscode vom öffentlichen FQDN beweist nichts. grafana.emsenhuber.net lieferte monatelang 302 — das war der Access-Login, während der Dienst gar nicht existierte (LXC 104 gestoppt, konfigurativ auf VLAN1 10.40.41.109, Ingress zeigte auf 10.40.20.109, das es nie gab). Immer gegen das Origin messen, nicht gegen die Fassade.
🔴 pvesm free scheitert an geschützten PBS-Snapshots stillschweigend („cannot remove protected snapshot"). Wer nur Erfolgszähler liest, hält ein halbes Aufräumen für fertig. Entschützen: pvesh set /nodes/pve/storage/pbs/content/<volid> --protected 0.
🔴 Startreihenfolge auf pve hängt NICHT an der VMID, solange ein Gast ein explizites startup: order= trägt: Proxmox startet erst alle mit order=, dann den Rest nach VMID.
⚠️ Core-Config läuft über Nautobot Golden Config. Die DHCP-dns-server-Änderung ist eine Core-Änderung ⇒ Template und ComplianceRule, sonst Drift. Aktuell 104/104, 0 Drifts.
⚠️ Caddy in LXC 130 hat einen eigenen Netzwerk-Namespace und ist deshalb nicht von der macvlan/ipvlan-Blindheit betroffen. Ein AGH im Docker-LXC 400 wäre es — ein weiterer Grund für eigene LXCs.

Danach offen (TP31 Rest)

Tunnel bf-public + cloudflared auf ap1/ap2 (arm64, 95 MB Flash frei — ⚠️ braucht je einen physischen device-mode-Wechsel am Gerät), CNAMEs umhängen (n8n → gitea → hass → vw), dann bf-nas/bf-pve/bf-mm löschen und die sechs alten Container entfernen.

4.9 KiB Raw Blame History Unescape Escape