Christoph Emsenhuber da452ce1f3 TP23 Stufe 1 (DoH) + TP5 Etappe-2-Nachtrag ausgerollt, Etappe-3-Drop vorbereitet
Drei Skripte aus der Folgesession. Stand am Geraet zum Commit-Zeitpunkt
(per REST gegengeprueft, nicht aus den Dateikoepfen abgeschrieben):

- tp23-stufe1-doh-core.rsc  -> LIVE. use-doh-server auf den
  Cloudflare-Gateway-Resolver, verify-doh-cert=true. Nur der GTS Root R4
  importiert statt eines Bundles: der Core hat ~2,8 MB freien Flash, und die
  Kette endet nachweislich dort. Der Root wurde per SFTP hochgeladen, nicht
  per fetch geholt -- fetch haette check-certificate=no gebraucht und damit
  genau die Pruefung ausgehebelt, die hier aufgebaut wird.
  Schliesst zugleich TP21.1 TODO 1.

- tp5-etappe2-nachtrag.rsc  -> LIVE. 17 TP5-E2-Whitelists (11 + 6).
  Vier Luecken, die der Kollektor ueber dreieinhalb Stunden gezeigt hat:
  Matter (udp/5540, 92 der 119 Zeilen -- die E2-Regel war protocol=tcp und
  liess Matter komplett durchfallen), der Nautobot-Deploy-Pfad (kommt von
  .20.31 = worker, nicht von .20.30 = web; jetzt als address-list, weil der
  scheduler dieselben Jobs faehrt), und zwei Rueckwege aus abgelaufenen
  Conntrack-Eintraegen. Dazu eine Vorratsregel fuer AdGuard, damit das
  spaetere DNS-Umstellen ein reiner DHCP-Change bleibt.

  Korrigiert meine Aussage vom Vortag: "die Log-Regel ist verstummt" beruhte
  auf einem 70-Sekunden-Fenster und war so nicht haltbar. Genau deshalb
  verlangt das Runbook ein mehrtaegiges Fenster.

- tp5-etappe3-drop.rsc  -> VORBEREITET, NICHT AUSGEROLLT. Kein Drop und kein
  Scheduler auf dem Geraet. Der Auto-Revert steht im Skript bewusst VOR dem
  Drop, sonst gibt es ein Fenster ohne Sicherung; der Drop kommt HINTER die
  Log-Regel, damit der Kollektor weiter sieht, was gefressen wird.

Gate fuer Etappe 3: die Log-Regel steht aktuell auf 0 Paketen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 04:52:40 +02:00
2026-06-15 19:00:40 +02:00

bf-network-r6

BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.

SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.

Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md

Struktur:

  • docs/vlan-plan.md — VLAN-/Adressplan (final)
  • docs/core-switch-prep.md — Core-Switch Status & Phasen
  • docs/firmware-flash-runbook.md — FW-Flash Historie
  • switch/cli/CLI-REFERENCE.md — bestätigte CLI-Syntax
  • switch/cli/*.cli / *.exp — reproduzierbare Konfig-Scripts
  • inventory/bf.csv / bf.md — IP-Doku (aus IPs.xlsx gespiegelt)
  • inventory/bf-core-ports.csv / .md — Switch-Port-Map

Aktueller Stand (2026-06-09):

  • Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
  • Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
  • Phase C (Firewall) + Phase D (Adress-Migration) ausstehend
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Readme 21 MiB
Languages
Python 57.9%
RouterOS Script 33.8%
Jinja 6.6%
Shell 1.7%