1 Commits

Author SHA1 Message Date
909e604ea6 TP23 Stufe 6: Bypass-Sperre-Entwurf abgelegt (log-only + reject), NICHT deployt
Zwei RouterOS-Skripte fuer die DNS-Bypass-Sperre der TP5-forward-Kette,
gespiegelt am TP5-Etappen-Stil (idempotent, place-before, Auto-Revert):
- phaseA: Substrat (dns-resolvers/dns-bypass-exempt/jit-dns-bypass) +
  Exempt/JIT-Accepts + log-only TP5-WOULD-DROP-DNS.
- phaseB: reject icmp-port-unreachable + Auto-Revert-Scheduler.

Freigegeben 2026-09-11, bewusst NICHT deployt (Christoph remote, hartes
Vor-Ort-Gate). Zwei Live-Verifikationen vor dem Deploy im Dateikopf markiert:
Egress-Accept-Anker der forward-Kette + Exempt-IPs des dev-MacBooks
(MikroMCP war beim Schreiben zu allen Geraeten tot -> nicht geraten).
log-only wird beim Deploy als gc-Transaktion gefuehrt.

Runbook-Zeiger auf beide Dateien ergaenzt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-12 11:50:22 +02:00
4 changed files with 105 additions and 65 deletions

View File

@@ -1,65 +0,0 @@
# Handoff 2026-09-12 — TP25 „ap2 unterperformt": Messung blockiert (kein Manager-Zugriff)
**Kurz:** Die ap2-In-situ-Frage (2 m/−80 dBm) konnte **nicht** gemessen werden. Grund ist **kein**
WLAN-/Gerätedefekt, sondern ein **fehlender Management-Pfad zum Manager `crs326-core`** von den
verfügbaren Vantage-Points. Auf Christophs Entscheidung **vertagt**, kein Geräte-Write, SPOF nicht
angefasst.
## Bestandsaufnahme (erledigt)
- Gitea #17 (TP25) = nur Zeiger, `status:wip`, Prosa im Repo. SSoT bestätigt.
- Prosa `docs/teilprojekte.md` ab Zeile 1081 + Archiv-Langfassung gelesen.
- Handoffs `20260902-fund-e` (Fund E geschlossen, 7.24.1 war die Ursache) und
`20260903-kanalplan` (Kanalplan live, In-situ-Messung als einziger Rest offen) gelesen.
- **Einziger offener TP25-Punkt bleibt: ap2 unterperformt.**
## Warum die Messung blockiert ist (live verifiziert, nicht geraten)
Registration-Table/Scan liegen unter CAPsMAN **nur am Manager** (`crs326-core`). Dieser ist von
beiden Messpunkten nicht erreichbar:
**Vantage 1 — diese Session (Mac am dw-Standort):**
- Default-GW `fritz.box` 10.95.10.1 → BF nur über **WG-Tunnel**; **Cloudflare WARP aktiv** (lief).
- **ICMP zu ganz BF ok** (ap2, NAS, Nautobot, core — alle ~32 ms, 0 % Loss).
- **Direktes TCP nach BF tot**: VLAN20-Hosts (NAS:22, Nautobot:8080, pve:8006) → `connect`
kommt nie zustande (`connect=0.000`, `http=000`). MikroTik-Ports schienen bei `nc -z` „offen",
aber jeder echte Handshake (SSH-kex, REST, HTTPS) wird **resettet** → das waren
**WARP-lokale nc-Fehlmeldungen** (CLAUDE.md-Gotcha: `nc -z` falsch-positiv/-negativ).
- ⇒ Von hier existiert **kein** TCP-Management-Pfad in BF. Der Pfad trägt gerade nur ICMP.
Passt zum WARP-/Tunnel-Muster (WARP = QUIC-Proxy, kein ICMP; hier umgekehrt: nur ICMP kommt durch).
**Vantage 2 — mikromcp (DS923, im BF-LAN, kein WARP):**
- `check_router_health` core → **Connect Timeout :80** (~10,5 s).
- ap1/ap2 → **`other side closed` / `ECONNRESET`** (TCP an, Handshake zu).
- `run_command` core → `Timed out waiting for handshake`; ap2 → `Connection lost before handshake`.
- ⇒ Auch der on-LAN-Pfad erreicht die Flotte nicht. Mögliche Ursachen (von hier **nicht** trennbar,
daher nicht entschieden): VLAN20-Firewall auf :80 (mgmt-input nur VLAN10/HA:8728/Nautobot:22/cf-mesh),
mikromcp-Host-Netzproblem auf der DS923, oder real.
**Wichtig:** Der Core ist **nicht** nachweislich defekt — ICMP + Routing sind gesund. Der Defekt liegt
im Zugangspfad, nicht (belegbar) am Gerät.
## Nebenbefund: Doku-Drift ap2-Kanal (nicht verifizierbar mangels Manager-Zugriff)
- CLAUDE.md + `teilprojekte.md`-Langfassung: ap2 = **ch44 / 5220** (2,4 GHz ch11).
- Handoff 09-03: ap2 = **5300/5320** (ch60/64, DFS Band B) + ch11.
- Was **live** läuft, ist offen. Beim nächsten Manager-Zugriff via
`/interface wifi radio print` (Frequenz je Radio) klären und die Doku angleichen.
## Nächste Session — was zu tun ist
1. **Sauberen Pfad herstellen** (Christophs Wahl, offen): WARP trennen + retest, ODER aus einer
**BF-LAN-Session** (macmini) messen, ODER zuerst **mikromcp/DS923-Erreichbarkeit** zur Flotte klären.
2. Sobald Manager erreichbar, der Messplan aus Handoff 09-03 §„Aufstellorts-Messplan":
- `/interface wifi radio print terse proplist=cap,radio-mac,interface` (Karten-Snapshot; wandert bei Rejoin).
- `/interface wifi radio print` → aktuelle Frequenz/TX je Radio (ap2 ch prüfen, Doku-Drift oben).
- `/interface wifi registration-table print terse where ssid=dirtyvader-main` → Signal/Rate der ap2-Clients.
- `/interface wifi scan cap-wifiN duration=…` **am Manager** → 5-GHz-Umfeld an ap2 (Wiederholung des 08-24-Scans).
- Ziel: −80 dBm@2 m einordnen (Platzierung/Antenne/TX vs. Kanal-Umfeld), mit Zahlen.
3. **Gotchas** (CLAUDE.md/09-03): scan/registration-table nur am Manager · `list_wifi_interfaces`
leakt PSKs (nicht benutzen) · `cap-wifiN`-Karte wandert · vor Client-Diagnose `uptime`+`grep " caps,"`.
## Grenze eingehalten
Kein Geräte-Write. Core (SPOF) nicht angefasst. WARP nicht getrennt (Christophs Client). Doku-Drift
dokumentiert statt stillschweigend „korrigiert".

View File

@@ -23,6 +23,12 @@ Das ist der letzte Baustein von TP23 und lebt in der **TP5-Firewall** (`forward`
Reihenfolge-Regel („erst der Ersatz, dann die Sperre").
- `dns-bypass-exempt`-Gruppe existiert auf dem Resolver-Paar (AGH-Client-Seite).
**Entwurf liegt bereit (freigegeben 2026-09-11, NOCH NICHT deployt — Christoph war remote):**
- Phase A (Substrat + Exempt/JIT-Accepts + log-only): `routeros/tp23-stufe6-phaseA-exempt-log.rsc`
- Phase B (reject + Auto-Revert): `routeros/tp23-stufe6-phaseB-reject.rsc`
- 🔴 **Vor dem Deploy live verifizieren** (im Dateikopf markiert): (1) der Egress-Accept-Anker in
der forward-Kette, vor dem die Regeln stehen müssen; (2) die Exempt-IPs des dev-MacBooks.
**Noch zu bauen (Teil dieser Session, VOR dem Drop):**
- **Firewall-Exempt** ist noch NICHT da: eine Address-List `dns-bypass-exempt` (permanent) mit dem
dev-MacBook (`10.40.10.183` **und** `10.40.10.82`, dual-homed) + Agent-Toolchain, plus eine

View File

@@ -0,0 +1,59 @@
# TP23 Stufe 6 — PHASE A: Substrat + Exempt/JIT-Accepts + log-only-Vorstufe.
#
# 🔴🔴 NUR VOR ORT. Dieser Deploy allein bricht noch nichts (kein drop/reject),
# aber Phase B (der reject) macht .36/.37 zum DNS-SPOF ohne Fern-Rollback.
# Runbook: docs/tp23-stufe6-bypass-sperre-runbook.md.
#
# STATUS: ENTWURF, freigegeben 2026-09-11, NOCH NICHT DEPLOYT (Christoph war remote).
#
# ┌─ LIVE-VERIFY VOR DEM DEPLOY (nicht raten — MikroMCP war beim Schreiben tot) ─┐
# │ (1) ANKER <<EGRESS-ACCEPT>>: die forward-Regel, die HEUTE LAN->WAN-DNS zu │
# │ 8.8.8.8:53 durchlaesst (der generische Internet-Egress-Accept). Meine │
# │ Regeln muessen DAVOR stehen, sonst greift der Egress-Accept zuerst und │
# │ die log-only-Regel zaehlt 0. Anker aus der Live-Kette holen: │
# │ /ip firewall filter print where chain=forward │
# │ und unten das place-before-Kommentar ersetzen. Faellt externer DNS heute │
# │ schon in deny-by-default (TVs mit 8.8.8.8 loesen JETZT nicht auf), ist │
# │ Stufe 6 gegenstandslos — dann Runbook neu bewerten. │
# │ (2) EXEMPT-IPs: dev-MacBook ist dual-homed. Beide Beine gegen die Realitaet │
# │ pruefen (en5/en0 koennen per DHCP gewechselt haben): │
# │ /ip dhcp-server lease print where comment~"macbook" │
# │ und mit der AGH-Seite (clients.persistent 'dns-bypass-exempt') abgleichen.│
# └───────────────────────────────────────────────────────────────────────────┘
#
# Weg (KEIN mikromcp-Direkt-Write — ip-firewall-filter steht unter Drift-Kontrolle):
# Backup davor: create_backup routerId=crs326-core (core-pre-tp23-s6-<datum>.backup)
# Deploy: python3 nautobot/gc-manual-plan.py --device crs326-core \
# --commands-file routeros/tp23-stufe6-phaseA-exempt-log.rsc \
# --change-id TP23-S6-PhaseA --deploy
# log-only als befristeter Versuch fuehren (NICHT als Versehen lesbar machen):
# python3 nautobot/gc-transaktion.py (Transaktion 'TP23-S6-would-drop-dns')
# Soll-Sync (Substrat + Accepts sind Dauerzustand -> ins intended):
# python3 nautobot/ingest-core-firewall.py --apply
# python3 nautobot/gc-configplan.py --refresh-compliance
# ---------------------------------------------------------------------------
# 0) Substrat: erlaubte Resolver (dst), permanente Exempts (src), leere JIT-Liste.
:do { :if ([:len [/ip firewall address-list find list="dns-resolvers" address="10.40.20.36"]] = 0) do={ /ip firewall address-list add list=dns-resolvers address=10.40.20.36 comment="TP23-S6: AGH agh-bf1" } } on-error={ :log info "tp23s6A: 00a warf" }
:do { :if ([:len [/ip firewall address-list find list="dns-resolvers" address="10.40.20.37"]] = 0) do={ /ip firewall address-list add list=dns-resolvers address=10.40.20.37 comment="TP23-S6: AGH agh-bf2" } } on-error={ :log info "tp23s6A: 00b warf" }
:do { :if ([:len [/ip firewall address-list find list="dns-bypass-exempt" address="10.40.10.183"]] = 0) do={ /ip firewall address-list add list=dns-bypass-exempt address=10.40.10.183 comment="TP23-S6: dev-MacBook en5 (VERIFY)" } } on-error={ :log info "tp23s6A: 00c warf" }
:do { :if ([:len [/ip firewall address-list find list="dns-bypass-exempt" address="10.40.10.82"]] = 0) do={ /ip firewall address-list add list=dns-bypass-exempt address=10.40.10.82 comment="TP23-S6: dev-MacBook en0 (VERIFY)" } } on-error={ :log info "tp23s6A: 00d warf" }
# 1) Exempt-Accepts. dev-MacBook + Agent-Toolchain behalten ihren DNS-Ausweg.
# MUSS vor der log-only-Regel stehen (action=accept terminiert -> Exempt-Traffic
# erreicht die Log-Regel nie und taucht im WOULD-DROP-Log korrekt NICHT auf).
:do { :if ([:len [/ip firewall filter find comment="TP23-S6: dns-exempt udp"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address-list=dns-bypass-exempt protocol=udp dst-port=53,853 comment="TP23-S6: dns-exempt udp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 01a warf" }
:do { :if ([:len [/ip firewall filter find comment="TP23-S6: dns-exempt tcp"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address-list=dns-bypass-exempt protocol=tcp dst-port=53,853 comment="TP23-S6: dns-exempt tcp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 01b warf" }
# 2) JIT-Accepts. Leere, selbstverfallende Liste (Muster jit-admin, tp5-etappe4):
# /ip firewall address-list add list=jit-dns-bypass address=<ip> timeout=1h
:do { :if ([:len [/ip firewall filter find comment="TP23-S6: dns-jit udp"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address-list=jit-dns-bypass protocol=udp dst-port=53,853 comment="TP23-S6: dns-jit udp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 02a warf" }
:do { :if ([:len [/ip firewall filter find comment="TP23-S6: dns-jit tcp"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address-list=jit-dns-bypass protocol=tcp dst-port=53,853 comment="TP23-S6: dns-jit tcp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 02b warf" }
# 3) log-only-Vorstufe. Loggt LAN->extern DNS, das NICHT zu einem erlaubten
# Resolver geht. dst-address-list=!dns-resolvers negiert die Liste. Mehrere
# Tage lesen (Kollektor 10.40.20.18:514), dann Phase B. NUR 53/853-Zeilen zaehlen.
:do { :if ([:len [/ip firewall filter find comment="TP23-S6: WOULD-DROP-DNS udp"]] = 0) do={ /ip firewall filter add chain=forward action=log log-prefix="TP5-WOULD-DROP-DNS" protocol=udp dst-port=53,853 dst-address-list=!dns-resolvers comment="TP23-S6: WOULD-DROP-DNS udp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 03a warf" }
:do { :if ([:len [/ip firewall filter find comment="TP23-S6: WOULD-DROP-DNS tcp"]] = 0) do={ /ip firewall filter add chain=forward action=log log-prefix="TP5-WOULD-DROP-DNS" protocol=tcp dst-port=53,853 dst-address-list=!dns-resolvers comment="TP23-S6: WOULD-DROP-DNS tcp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 03b warf" }
:log info ("tp23s6A: ENDE exempt-udp=" . [:tostr [:len [/ip firewall filter find comment="TP23-S6: dns-exempt udp"]]] . " log-udp=" . [:tostr [:len [/ip firewall filter find comment="TP23-S6: WOULD-DROP-DNS udp"]]] . " resolvers=" . [:tostr [:len [/ip firewall address-list find list="dns-resolvers"]]] . " exempt=" . [:tostr [:len [/ip firewall address-list find list="dns-bypass-exempt"]]])

View File

@@ -0,0 +1,40 @@
# TP23 Stufe 6 — PHASE B: der scharfe Schnitt (reject) + Auto-Revert.
#
# 🔴🔴 NUR VOR ORT, mit offener Konsole. Erst NACHDEM das WOULD-DROP-DNS-Log
# (Phase A) mehrere Tage ruhig/verstanden ist und jeder externe Resolver
# entschieden wurde (Reservierung auf AGH / Exempt / bewusst brechen lassen).
# AB HIER ist .36/.37 ein DNS-SPOF ohne Fern-Rollback (Runbook, Gate).
#
# STATUS: ENTWURF, freigegeben 2026-09-11, NOCH NICHT DEPLOYT.
#
# WARUM reject STATT drop: reject icmp-port-unreachable laesst Clients schneller
# auf den naechsten (erlaubten) Resolver fallen, statt in einen Timeout zu laufen.
#
# WARUM die Log-Regel STEHEN BLEIBT: action=log terminiert NICHT — das Paket wird
# geloggt und faellt dann in die reject-Regel darunter. Gleiche Doktrin wie
# tp5-etappe3-drop (Log VOR Drop), der Kollektor zeigt weiter, was reject frisst.
#
# Weg (wie Phase A, ueber Nautobot GC):
# Deploy: python3 nautobot/gc-manual-plan.py --device crs326-core \
# --commands-file routeros/tp23-stufe6-phaseB-reject.rsc \
# --change-id TP23-S6-PhaseB --deploy
# Danach (reject ist jetzt Dauerzustand -> Soll, log-only-Transaktion schliessen):
# python3 nautobot/ingest-core-firewall.py --apply
# python3 nautobot/gc-configplan.py --refresh-compliance # Ziel gruen
#
# Rollback sofort (Vor-Ort-Konsole): /ip firewall filter set [find comment~"TP23-S6: reject"] disabled=yes
# -> Clients koennen sofort wieder externe Resolver nutzen. Bzw. Auto-Revert unten.
# ---------------------------------------------------------------------------
# 0) Auto-Revert ZUERST — deaktiviert die reject-Regeln nach 10m, falls nicht
# bestaetigt (analog tp5-etappe3/4). Nach der Abnahme abbestellen:
# /system scheduler remove [find name="tp23s6autorevert"]
:do { :if ([:len [/system scheduler find name="tp23s6autorevert"]] = 0) do={ /system scheduler add name="tp23s6autorevert" interval=10m on-event="/ip firewall filter set [find comment~\"TP23-S6: reject\"] disabled=yes; /system scheduler remove [find name=\"tp23s6autorevert\"]; :log warning \"tp23s6: AUTO-REVERT hat die DNS-reject-Regeln abgeschaltet\"" } } on-error={ :log info "tp23s6B: 00 scheduler warf" }
# 1) reject. Gleiche Match-Tupel wie die WOULD-DROP-DNS-Log-Regeln, direkt
# dahinter (place-before denselben Egress-Anker -> landet nach den Log-Regeln).
# <<EGRESS-ACCEPT>>: derselbe live-verifizierte Anker wie in Phase A.
:do { :if ([:len [/ip firewall filter find comment="TP23-S6: reject dns udp"]] = 0) do={ /ip firewall filter add chain=forward action=reject reject-with=icmp-port-unreachable protocol=udp dst-port=53,853 dst-address-list=!dns-resolvers comment="TP23-S6: reject dns udp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6B: 01a warf" }
:do { :if ([:len [/ip firewall filter find comment="TP23-S6: reject dns tcp"]] = 0) do={ /ip firewall filter add chain=forward action=reject reject-with=icmp-port-unreachable protocol=tcp dst-port=53,853 dst-address-list=!dns-resolvers comment="TP23-S6: reject dns tcp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6B: 01b warf" }
:log info ("tp23s6B: ENDE reject-udp=" . [:tostr [:len [/ip firewall filter find comment="TP23-S6: reject dns udp"]]] . " reject-tcp=" . [:tostr [:len [/ip firewall filter find comment="TP23-S6: reject dns tcp"]]] . " autorevert=" . [:tostr [:len [/system scheduler find name="tp23s6autorevert"]]])