- docs/tp23-stufe6-bypass-sperre-runbook.md: separate Vor-Ort-Session; AGH-SPOF-Warnung
(nicht aus der Ferne / nicht waehrend Abwesenheit), log-only-Vorstufe -> Drop mit Auto-Revert,
Exempt/JIT-Bau, DoH-443-Grenze, Rollback + Abnahme
- teilprojekte.md: TP23-Zeiger auf den Runbook + Vor-Ort-Gate
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
TP25-kanalplan-ap1-live.json state open->committed (Nachzug aus dem
gc-transaktion commit). Dazu die zwei In-situ-Messrunden vom 09-04:
tp25-runde-1er (Walk iphone/s22) und tp25-runde-dauerping (Dauerping
ipad/iphone/macbook/s22) als Rohdaten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ap3 trug auf wifi1/wifi2 einen Werks-Inline security.ft=yes (Bring-up-Skript
tp28-ap3-phase2-cap.rsc unset !ft-over-ds, aber nicht !ft; Abnahme zaehlt nur
benannte security-Objekte -> Inline-Wert unsichtbar). Gemischtes FT-ESS =
Strong-Signal-Abbrueche (-43/-45 dBm) NUR auf ap3 bei 3/3 Strichen. Live per
!security.ft geradegezogen (uniform ft=no), Bring-up-Quelle korrigiert.
Kanalplan committed: Template auf DFS-Frequenzlisten (ch-5g-ap1=5260,5280,
ch-5g-ap2=5300,5320) + ap1-Provisioning-Zeilen (radio-mac ...E5/...E6) wieder
aufgenommen. Push nach bf-golden-config + GitRepo-Sync + refresh-compliance ->
140/140, 0 Drifts; Transaktion TP25-kanalplan-ap1-live committed.
Doku: Ist-Stand, Fund-E-Block, CLAUDE.md Punkt 5 (Merkregel: nach jeder
sec-main-FT-Aenderung jeden CAP einzeln auf security.ft pruefen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hebel 2 (ft=no) doch gezogen: sec-main von ft=yes ft-over-ds=yes auf
ft=no ft-over-ds=no. Template (nautobot/mikrotik_routeros.j2) + Push nach
bf-golden-config + Nautobot-Sync; wifi-security damit gruen (Live stand
schon auf ft=no, das Template war der Drift).
Doku nachgezogen (CLAUDE.md Punkt 5, teilprojekte.md Ist-Stand/Quick-Index/
Fund-E-Block): Soll ft=yes ft-over-ds=yes -> ft=no ft-over-ds=no, 802.11r aus.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Die Konsole (docs/tp6-marker/server.py) war beim Multi-Pin-Umbau nicht
mitgezogen worden: hartkodiert auf 2 Clients, pinnte ueber die alte
Gegen-AP-Automatik. Jetzt:
- Client-Liste aus geraete.txt (schreibt tp25-walk-messung.sh), Fallback
auf die zwei alten MACs fuer Alt-Laeufe.
- Kein eigenes SSH mehr: je Client letzte Zeile von sampler-<name>.csv
(AP/Signal) + Ping-Verlust aus walk-ping-<name>.csv.
- N Client-Karten; Alarm, wenn ein gepinnter Client nirgends haengt.
- Pin-UI: je Client AP/Band waehlen, set/off/verify via tp25-pin-multi.sh
(POST /pinmulti). Alte 2-Client-Automatik (entscheide/pin_setzen/auto)
entfernt; tp25-pin-s22.sh liefert nur noch die map.
- tp25-runde.sh loest beim Aufraeumen den Multi-Pin statt des S22-Pins.
Doku: Ist-Stand-Block + Quick-Index + Messwerkzeug-Bullets nachgezogen,
neuer Handoff 2026-09-04.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Fuer die gepinnte Pro-AP-Abdeckungsmessung: pinnt mehrere Clients gleichzeitig
band-genau auf je einen AP (je Sonde alle cap-wifiN AUSSER dem Ziel per
access-list reject, eigener Tag TP25-PINM-<name>), iPhone bleibt frei. Loest
AP+Band -> cap-wifiN live aus der Karte (reuse tp25-pin-s22.sh map), cacht nie.
Modi set/verify/off/map. 3.2-safe (keine assoziativen Arrays, macOS /bin/bash).
access-list steht unter keiner ComplianceRule -> kein Nautobot-Drift; off raeumt
vollstaendig auf.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- tp25-walk-messung.sh: halber Refactor geschlossen — Rumpf schleift ueber die
PH_*-Arrays (pro Geraet ein Sampler + ein Core-Ping, sampler-<name>.csv /
walk-ping-<name>.csv), PID-Arrays im Cleanup, Archiv-/Echo-Block generisch.
Lief vorher unter set -u gar nicht (unbound $PHONE_MAC).
- tp25-gehweg-auswertung.py: liest N benannte Geraete per glob; altes 2-Rollen-
Schema (sampler.csv/walk-ping.csv/walk-ping-iphone.csv/beide-telefone.csv) bleibt
als Legacy-Fallback erhalten. Beide Pfade getestet.
- tp25-pin-s22.sh: karte() repariert — channel.frequency ist seit dem DFS-Kanalplan
(2026-09-03, Frequenz-Listen) ein Array; der alte Skalar-Vergleich blankte map,
wodurch ap-map.txt leer blieb. Fix nimmt bei :typeof=array das erste Element.
Live-Smoke (4 Geraete) gruen: alle erreichbar, sauberes Cleanup, korrekte AP-Map.
Naechster Schritt: In-situ-Walk (nur Zahlen, Commit/Rollback des Kanalplans separat).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Uebergabeprompt fuer die Messsession: Aufstellorte begehen, entscheiden
ob Zielzustand (Template + Commit) oder Nachjustieren. Enthaelt Messplan,
Rollback- und Commit-Weg, sowie die relevanten CLAUDE.md-Gotchas
(scan/registration-table nur am Manager, cap-wifiN wandert, DFS-CAC).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sideboard-Test fuer ap1 (TP28) plus Umsetzung des TP25-Kanalplans
in einem Zug am Manager (crs326-core):
L2 (TEST-ether3-trunk-ap1-sideboard-2, bridge-vlan, committed):
- ether3 zum AP-Trunk fuer ap1 hinzugefuegt (analog ether15/ether21)
- Template mikrotik_routeros.j2 nachgezogen: ether3 in allen VLAN-Zeilen
WLAN (TP25-kanalplan-ap1-live, wifi-channel, OFFEN bis 2026-09-10):
- ch-5g-ap1: 5180 -> Frequenz-Liste 5260,5280 (DFS Band B, ch52/56)
- ch-5g-ap2: 5220 -> Frequenz-Liste 5300,5320 (DFS Band B, ch60/64)
- Neue Provisioning-Regeln fuer ap1 (radio-mac E5=5G, E6=2G), analog ap2/ap3
- remote-cap provision fuer ap1 und ap2
Live-Ergebnis (35 Clients an der Registration-Table, vorher 30):
- ap1: 5260/5280 + 2412 (ch1), 9/9 Interfaces up
- ap2: 5300/5320 + 2462 (ch11), 9/9 up
- ap3: 5180 + 2437 (ch6), unveraendert
- Keine 5-GHz-Kollisionen mehr, 2,4-GHz sauber auf ch1/6/11
Follow-up in naechster Session: In-situ-Messungen an den Aufstellorten;
bei ok Template auf Frequenz-Listen + ap1-Provisioning-Regeln erweitern
und die offene Akte committen. Snapshot fuer Rollback liegt bereit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
(A) DHCP-Search-Domain der 7 Netze emsenhuber.net -> bf.emsenhuber.net ueber
die GC-Pipeline (kein Direkt-Write): Template Z.133 gehoben, per
push-gc-template.py ins bf-golden-config-Repo (7a4068c4), GitRepo-Sync,
neuer manueller Job tp42-dhcp-domain in gc-configplan.py (set [find], weil
add das existierende Netz doppeln wuerde), Deploy an crs326-core.
Live 7/7 = bf.emsenhuber.net, Compliance 140/140 keine Drifts.
Nebenbefund: Remote-GC-Template hing dem lokalen hinterher (noch *.bf.lan +
router.lan) -> mit an den Live-Stand angeglichen.
Loest den Kernkonflikt: DHCP verteilte bare emsenhuber.net, Records leben
unter bf.emsenhuber.net -> bare macmini loest jetzt beim Lease-Renew.
(B) .16 (adguard_bf1) abgebaut: lag im mit FM geteilten Portainer-Stack 195
zusammen mit adguard_fm2 (.17, Standort FM). Statt Stack-Delete die compose
auf nur .17 getrimmt + redeployt (Prune). .16 weg, .17 laeuft (kurzer Blip).
Nautobot-Soll (Scope 4) an TP37 gekoppelt, separat.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gegen die Geraete gemessen: .bf.lan ist ueberall weg, DHCP-domain auf
emsenhuber.net vereinheitlicht, Core-Static + Caddyfile konsistent auf
.bf.emsenhuber.net (deckt sich mit GC-Template). Drift hat ~80% erledigt.
Kernkonflikt: DHCP verteilt bare emsenhuber.net, Records leben unter
bf.emsenhuber.net -> bare macmini loest nicht. Entscheidung (User):
Zielschema = bf.emsenhuber.net (wenig-Arbeit-Weg); .16 (adguard_bf1)
abbauen, .17 (=FM) bleibt.
Netto-Rest = 2 Infra-Eingriffe: DHCP-domain ->bf.emsenhuber.net ueber die
GC-Pipeline (Template Z.133 + push-gc-template.py + Deploy) und .16-Teardown.
Kein Core-Objekt haengt an .16 (Firewall/NAT/DNS/Addr-List live geprueft).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kern von TP31 (Caddy als Host->Origin-SoT, cloudflared 6->1 Knoten) lief
über den Piloten TP16.3 durch: bf-public 12 conns, vier öffentliche Namen
über Caddy (https://10.40.20.40:443), Alttunnel bf-nas/bf-pve/bf-mm weg.
cf-sync.py:107 akzeptierte nur http://<caddy>; der Flip legte die Namen auf
https://...:443 -> Abnahme-Tool meldete vier Fehlalarme. Fix: auch https://
als "zeigt auf Caddy". Drift-Check jetzt grün (nur ds-bf als bewusst intern).
Schritt-6-Teil "MCP-Clients auf FQDN" durch TP35 Schicht 1 umgekehrt (LAN-IP),
damit gegenstandslos. Quick-Index/TP-Abschnitt/Ist-Stand-Block nachgezogen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kein eigenständiger claude-mcp-Token mehr: in TP41 T4 (2026-09-01) zu
zt-svc umbenannt+rotiert, mcp/cloudflare/.env trägt jetzt
CF_ACCESS_CLIENT_ID/_SECRET. Quick-Index (🔜→✅), TP-Abschnitt und
Ist-Stand-Block nachgezogen; alte ".env leer"-Notiz als überholt erhalten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
terpene-db-Tunnel (b83b68f0) war seit TP16.3 §6 versehentlich mit
terpene-cloudflared entfernt → VPC-Service zeigte auf toten Tunnel →
Worker 503. Mesh von CF abgelehnt (5101, kein cloudflared-Tunnel).
Neuer cfd_tunnel terpene-db (f2d2fc8a) + Connector auf LXC 400 (VLAN20),
VPC-Service umgehängt. Kein Firewall-Loch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Follow-up nach dem TP41-Kernmerge (20671ae): App-Launcher D1, Geli-Enrollment
verifiziert (zt-humans), IdP-Anleitungen, TP43-Anlage, TP41-Doku-Abschluss.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Zwei Sessions haben denselben Fall bewertet und kamen zu entgegengesetzten
Schluessen. Aufgeloest zugunsten der Kollektor-Messung.
Der Widerspruch und sein Beleg:
- Die Nacht-Session las `get_log ... sinceMinutes=1440` -> total 0 und schloss
auf "Fund E geheilt, Hebel 1 committen". Das ist der FLUECHTIGE Ringpuffer des
Routers: live nachgemessen 1000 Zeilen, aeltester Eintrag 01.09. 00:38:58 --
keine 9 h Tiefe. Der Core-Reboot 14:36 hatte ihn geleert, der 31.08. Vormittag
war darin nicht enthalten. "total 0" hiess "im Puffer nichts", nicht "in 24 h
nichts" -- genau die Falle, wegen der am 30.08. der Kollektor gebaut wurde.
- Im Kollektor stehen fuer 08:09-14:36 (Hebel 1 ALLEIN, vor dem Upgrade) 124x
reauthenticating: 09h=1, 11h=2, 12h=20, 13h=31, 14h=70 -- alle vom iPhone
allein, also Client-Befund nach der eigenen Merkregel. Dazu Christophs zwei
erlebte Ausfaelle 13:16 und 14:23. Zwischen 09:00 und 14:36 lag kein Reboot.
Daraus gehandelt (User-Entscheid: symmetrisch am Geraet, jetzt):
- Backup pre-tp25-funde-rollback, dann ft-over-ds=yes + remote-cap provision
- Rueckbau-Diff zeigte genau eine Abweichung, kein Kollateral
- Abnahme: CAPs durchgehend Ok, ap2 9/9 und ap3 9/9 running, frische DHCP-Lease
(~1 min alt), Transaktion "zurueckgebaut", Compliance 140/140
- Der Rueckbau IST das Experiment: bleibt es ruhig, war 7.24.1 die Ursache;
kehrt das Haemmern zurueck, hatte die Nacht-Session recht. Bis zur Messung
am 2026-09-02 frueh committet niemand.
Zwei Nebenbefunde:
- gc-configplan.py --refresh-compliance scheitert STILL ohne NAUTOBOT_TOKEN:
Meldung ausgegeben, aber Exit-Code 0. Gehoert gefixt.
- Compliance ist 140/140, nicht 135/135: es gibt eine 28. ComplianceRule
`interface-veth`, angelegt 31.08. 20:04, Urheber offen.
Der ap2-Befund der Nacht-Session (2 m Abstand, -80 dBm, 0 Clients auf ap2)
bleibt unberuehrt gueltig und ist weiter der beste Hinweis auf die
23:02-Stoerung. CLAUDE.md enthaelt in diesem Commit auch deren TP16.3-Zeile
(gemeinsame Datei, Hunks nicht trennbar).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diese Aenderungen stammen NICHT aus dieser Session. Sie lagen seit 01:41 uncommittet
im gemeinsamen Working Tree, in dem parallel mehrere Sessions schreiben -- jedes
read-modify-write haette sie stillschweigend ueberschreiben koennen. Daher hier
unveraendert gesichert, bevor irgendetwas anderes passiert.
Inhalt:
- TP39 (LXC-Hygiene pve) abgeschlossen und nach teilprojekte-archiv.md verschoben
- TP41-Cloudflare-Backup unter docs/cf-backup/tp41-20260901/
- handoff-20260901-tp25-ap2-verdacht.md: Befund, dass ap2 unterperformt
(iPhone 2 m entfernt, aber -80 dBm; 0 Clients auf ap2 gegen 29 auf ap3).
Dieser Teil ist wertvoll und unabhaengig -- er erklaert Christophs
23:02-Stoerung vom 31.08.
WARNUNG zum TP25-Teil: der hier eingesammelte Stand wertet Fund E als "Hebel 1
wirkt DOCH, commit-bereit". Diese Wertung ist ueberholt -- sie beruht auf einer
Messung im fluechtigen Router-Ringpuffer. Korrektur folgt im naechsten Commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die 7-Tage-Frist wurde auf User-Entscheid aufgehoben ("es wird nichts mehr
sein"). Reihenfolge Container -> Tunnel eingehalten (umgekehrt gaebe es 530er).
Vorbedingung geprueft: alle vier Namen auf bf-public, kein Name mehr an den
Alttunneln -> Abbau gefahrlos.
7 Container entfernt, per exakter Namensliste (nicht per Filter):
LXC 400 (pve): cloudflared-bfmm, cloudflared-bfnas
macmini: cloudflared-bfpve, cloudflared-bfnas
NAS ep14: cloudflared-bfpve, cloudflared-bfmm
plus terpene-cloudflared -- auf zusaetzlichen User-Entscheid, weil
420.teilzeitladen.xyz jetzt ueber Caddy/CF laeuft. Kein Stack dahinter, also
kein Wiederauferstehen.
Beweis VOR der Tunnel-Loeschung: 420.teilzeitladen.xyz lieferte mit bereits
entferntem terpene-cloudflared echten Origin-Inhalt (assetlinks-JSON, 200) --
der Dienst haengt also nicht mehr am Tunnel.
4 Tunnel geloescht: bf-mm, bf-nas, bf-pve, terpene-db -- jede ID gegen die
Behalten-Liste (bf-public, fm) geprueft.
Schlusskontrolle: nur noch bf-public (12) + fm (4) healthy; alle vier BF-Namen
und 420 weiterhin 200.
Der terpene-db-Tunnel-Token stand kurz im docker-inspect-Output; mit der
Tunnel-Loeschung ungueltig, kein Rotationsbedarf.
TP16.3 damit vollstaendig abgeschlossen (Status ✅ 2026-09-01). Quick-Index,
Abschnittsheader, §6-Record, Ist-Stand, Runbook §6 und Handoff nachgezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SKIP-NAME-RESOLVE (letzter offener TP39-Punkt, jetzt zu)
mysql.user gelesen (User gab DB-Zugang per /root/.my.cnf): KEIN Grant lautet auf
einen DNS-Hostnamen -- alle % / IP-Literal / localhost. skip-name-resolve kann
also niemanden aussperren; der Reverse-Lookup war reiner Ballast. Gesetzt als
eigenes Drop-in /etc/mysql/mariadb.conf.d/90-skip-name-resolve.cnf (nicht die
#-Zeile in 50-server.cnf, Paket-Update-stabil), @@skip_name_resolve=1 nach
Neustart verifiziert. Wirkung: gitea/vw/hass je 0 von 12 frischen Anfragen
langsam, max 0,25 s -- die Ursache ist damit beseitigt, nicht nur entschaerft.
RESIZE (im selben Fenster aufgetaucht)
LXC 302 war zu 100% voll (62/65 GB). Rootfs +30G online gewachsen -> 95 GB / 69%,
MariaDB lief durch. Puffer, kein Fix: 59 GB davon sind die homeassistant-DB.
TP40 ANGELEGT (User-Okay): HA-Recorder-Retention
states.ibd = 41 GB, unbegrenzt gewachsen (kein purge_keep_days wirksam). Scope:
purge_keep_days setzen (Christophs Policy-Zahl), rauschende Entities excluden,
purge mit repack -- danach TP39-Resize neu bewerten. Kein eigenmaechtiges
Loeschen: purge wirft echte Historie weg.
TP30 um zwei Posten erweitert
#5 Nautobot-Tokens (Leak 08-31, in der Liste bisher nur im Fliesstext).
#6 MariaDB root-Passwort: heute ins Transkript geraten -- die .my.cnf trug
"password <wert>" OHNE =, die Feld-Maskierung ankerte auf = und griff nicht.
Dritte Panne derselben Klasse nach SHELLY_DEVICE_PW und den Nautobot-Tokens;
Merkregel (Schluesselnamen ankern, nie ein evtl. fehlendes Trennzeichen) im
TP30-Text nachgeschaerft. #6 ist zugleich der billigste Posten -- kein externer
Konsument, die Dienste nutzen eigene DB-User.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
101 iob-master, 102 mqtt5, 106 influxdb2, 107 redis meldeten networking.service
und ifupdown-wait-online.service dauerhaft als failed, bei funktionierendem Netz.
Folge: alles mit After=network-online.target startet nach einem Reboot nicht --
influxdb2 kam gestern Nacht nicht hoch (Unit enabled, kein Startversuch im
Journal).
URSACHE, und es ist dieselbe Altlast wie beim toten Resolver:
in /etc/network/interfaces standen noch auto-Stanzas aus dem alten VLAN1-Schema
(eth0 -> 10.40.41.x, teils mit gateway 10.40.41.254) sowie aus frueheren
Versuchen (veth16, veth24, ein Tippfehler eth01) -- alle auf Interfaces, die es
im Container gar nicht gibt. ifup -a scheitert daran, waehrend das echte veth20
sauber hochkommt. Der VLAN-Umzug hat die Container umgehaengt, aber die alten
Stanzas nie entfernt.
FIX: nur Stanzas entfernt, deren Interface in ip -br link fehlt; lo, veth20 und
veth20.2 unangetastet. Backup je Container: /etc/network/interfaces.bak-20260901.
ABNAHME war ein echter Reboot, nicht systemctl is-active: 106 neu gestartet,
influxdb kam nach 5 s VON SELBST hoch, networking active, null failed units.
Endstand ueber alle 13 LXC: dns=10.40.20.1 durchgehend, networking ueberall
sauber. Ohne Netzbezug bleiben run-rpc_pipefs.mount (101, 150) und
proxmox-regenerate-snakeoil.service (108), beide vorbestehend.
MESSFALLE, mit in CLAUDE.md aufgenommen: nc -z meldete waehrenddessen neun
Dienste gleichzeitig als "Port zu" -- inklusive des SSH-Ports, ueber den diese
Session gerade arbeitete, waehrend curl vom selben Host HTTP 200 in 24 ms bekam.
Bei "alles gleichzeitig kaputt" zuerst das eigene Werkzeug verdaechtigen. Es
waere um ein Haar die zweite falsche Ausfallmeldung dieser Nacht geworden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fasst die zwei Restpunkte aus dem Wartungsfenster der Nacht zusammen, statt sie
auf zwei TPs zu verteilen -- beides betrifft dieselben pve-LXCs und wird in einem
Fenster erledigt:
1. skip-name-resolve auf der MariaDB. Der Reverse-Lookup ist heute nur schnell
(21-24 ms statt 10.010 ms), nicht abgeschafft. Vorher mysql.user lesen:
Hostname-basierte Grants brechen sonst und sperren vw/HA/gitea aus.
Blocker: DB-Credentials noch nicht lokalisiert (Bezug TP30).
2. networking.service + ifupdown-wait-online.service sind in 101/102/106/107
dauerhaft failed, bei vorhandenem Netz. Folge: alles mit
After=network-online.target startet nach einem Reboot nicht -- belegt an
influxdb2, das nach dem Neustart nicht hochkam (Unit enabled, kein
Startversuch im Journal). 101 wurde nie angefasst und zeigt dasselbe, es ist
also vorbestehend.
Dazu der Resolver-Sweep als wiederkehrende Kontrolle statt Einmalaktion: derselbe
Fehlertyp wurde 2026-07-10 (TP14.2a) an NAS und LXC 400 behoben, aber nie im
Bestand gesucht -- deshalb lag er hier noch. Die NAS-Container gehoeren mit
geprueft (DSM-Fallstrick: Interface-DNS != was dockerd liest).
Quick-Index, TP-Abschnitt und Ist-Stand-Block mitgezogen; Handoff verlinkt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FLIP (User-Freigabe, vorgezogen)
n8n / gitea / hass / vw laufen jetzt ueber bf-public, der oeffentliche Verkehr
geht damit erstmals ueber Caddy statt an ihm vorbei. Je Name einzeln geflippt und
dazwischen gemessen; Antwortzeiten vorher/nachher unveraendert. Nachweise:
gitea echte Gitea-Antwort, hass WebSocket 101 Switching Protocols (der
Companion-App-Pfad, den das Runbook als "nur vom User pruefbar" fuehrte),
vw /alive + /api/config 200 und WS-Hub 401 von Vaultwarden selbst, n8n vom User
im Browser bestaetigt (von aussen nicht bis zum Origin pruefbar, s. TP14.4).
Die drei Alttunnel bleiben als Rueckfallebene stehen -- §6 ist NICHT Teil davon.
10-SEKUNDEN-ZOLL AUF gitea/vw/hass -- Ursache gefunden und behoben
gitea hing bei ~10% der Anfragen exakt 10,1 s, quer ueber Web-UI, /api/healthz
und den Git-Pfad. MariaDB (LXC 302) hatte skip-name-resolve auskommentiert und
machte bei JEDER NEUEN Verbindung einen Reverse-Lookup, waehrend ihr resolv.conf
auf den toten 10.40.41.254 zeigte: 10.010 ms je Lookup, Pool-Verbindungen
schnell -- daher wirkte es sporadisch. An derselben DB haengen Vaultwarden, Home
Assistant und gitea (per Verbindungstabelle belegt, nicht vermutet; die erste
Annahme "vaultwarden nutzt SQLite" war falsch und wurde vom User korrigiert).
Fix: nameserver 10.40.20.1 + Reboot fuer fuenf LXCs (302, 102, 106, 107, 150).
Nachher 21-24 ms und 0 von 25 Proben langsam.
Offen: skip-name-resolve selbst -- bricht Hostname-basierte Grants, vorher
mysql.user lesen (DB-Zugang fehlt).
LATENT, NICHT VON DIESER SESSION VERURSACHT
networking.service + ifupdown-wait-online.service sind in 101/102/106/107
failed; influxdb2 kam nach dem Reboot nicht hoch (Unit enabled, kein
Startversuch im Journal). 101 wurde nie angefasst und zeigt dasselbe -- die
Container liefen nur 13+ Tage ohne Neustart.
RUNBOOK-KORREKTUREN
§5.3 "Caddy sieht den Request" konnte nie funktionieren: im Caddyfile steht keine
log-Direktive, ein erfolgreicher Request hinterlaesst nichts. Ersetzt durch die
Werkzeuge, die tatsaechlich etwas beweisen -- erzwungener oeffentlicher Weg per
curl --resolve (Pflicht wegen Split-Horizon), Verbindungstabelle am Core statt
Firewall-Zaehler (cloudflared haelt die Origin-Verbindung offen, der Zaehler
steht still obwohl alles laeuft), Antwort-Fingerabdruck, WebSocket mit --http1.1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
veth / ip address / ip firewall nat der drei cloudflared-Connectoren standen seit
der Vor-Ort-Session per Direkt-Write am Geraet (Runbook §3.4), waehrend /ip address
und /ip firewall unter GC-Drift-Kontrolle stehen: sechs extra-Drifts, Compliance
128/135. Sie sind inhaltlich richtig und sollen DAUERHAFT gelten -- deshalb ins
Template und nicht in eine gc-transaktion (die ist fuer befristete Versuche).
Kein Re-Baseline, kein Rueckbau, keine Zeile aufs Geraet: nur die SoT nachgezogen.
Neu ist die 28. ComplianceRule interface-veth. Vorher gab es fuer /interface veth
keine Regel -- das tragende Stueck des ganzen Aufbaus haette geloescht werden
koennen, ohne dass irgendetwas meldet.
Zwei Funde:
(a) Der veth-Export traegt zwei geraetevergebene MACs (mac-address,
container-mac-address), auf jedem AP anders. Eine nackte Regel haette damit
Dauer-Drift auf allen drei APs erzeugt, also genau die immer-rote Zahl, die
niemand mehr liest. Zwei eng auf die veth-Zeile verankerte ConfigReplace-Regeln
normalisieren sie im Backup (Lookbehind haelt container-mac-address heraus,
[^\n]*? haelt die Regel in der Zeile; Selbsttest mit Negativfaellen im Skript).
Bewusst mit der vorhandenen Maske <<REDACTED>> statt einer eigenen: sie ist im
Repo zugleich die Push-Sperre (gc-configplan.py verweigert config_set damit) --
eine Zeile mac-address=<<...>> darf nie aufs Geraet.
Kostet Backup-Treue: die veth-MACs stehen in bf-golden-config nicht mehr im
Klartext. Vertretbar, RouterOS vergibt sie beim Neuanlegen ohnehin neu.
Verworfene Alternative: MACs je Geraet modellieren -- widerspricht der
Begruendung, die fuer die VAP-MACs schon im ConfigContext-Skript steht.
(b) Der erste Compliance-Lauf meldete SUCCESS und war trotzdem unvollstaendig:
139 statt 140 Eintraege, crs326-core/interface-veth fehlte, im Job-Log
"RENDER COMPLIANCE TASK GROUP failed: Broken pipe". Zweiter Lauf sauber.
Merkregel im Runbook (Falle 16): Abnahme ist die ANZAHL der Eintraege
(Regeln x Geraete), nicht die Konformitaetsquote.
Stand danach: 139/140. Uebrig bleibt genau crs326-core/wifi-security -- die offene
Transaktion TP25-fund-e-ft-over-ds einer laufenden Messung, die bleiben muss.
Ausserdem: frischer Ingress-Snapshot von bf-public vor §5 und das geschaerfte
§5.1-Erfolgskriterium (200 mit leerem Body + server: Caddy = Strecke bewiesen,
404 = Ingress-Regel fehlt) -- am Live-System gemessen, nicht angenommen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Repo-Stand ergaenzt: alles liegt auf main (e474e5e), von dort starten.
- Live-Stand vor der Uebergabe gegengeprueft (12 Connectoren, drei
Container running, Caddy mit SNI 200 / ohne SNI 000) und im Kopf
vermerkt, damit die Folgesession weiss, wie alt die Zahlen sind.
- TP30 als von Christoph vertagt markiert, mit dem Hinweis, dass der
Superuser-Token bis dahin kompromittiert bleibt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Branch enthaelt jetzt origin/main (0680cca, TP25 Fund E / TP27) und
die Korrektur c8b2a15 aus claude/nervous-williams-acf000.
Inhaltliche Korrektur an meinen eigenen Dateien
- Ich hatte die wifi-security-Drift (ft-over-ds=no auf sec-main) dem
7.24.1-Upgrade zugeschrieben. Falsch: gc-transaktion.py status fuehrt
TP25-fund-e-ft-over-ds als OFFEN -- der Hebel wurde 08:09 bewusst
gesetzt, der Core erst 14:36 gehoben. Sie gehoert einer laufenden
TP25-Session, braucht keine Entscheidung und darf nicht gruen gemacht
werden. Korrigiert im §5-Prompt und im §2/§3-Handoff.
- Merkregel in CLAUDE.md: vor jeder Drift-Bewertung gc-transaktion.py
status lesen. Dazu die Abgrenzung Transaktion (befristeter Versuch)
vs. Soll/Template (Dauerzustand) -- die sechs AP-Drifts aus TP16.3
§3.4 sind Dauerzustand und gehoeren deshalb ins Template, nicht in
eine Transaktion.
- Notiert: gc-transaktion.py findet den Token aus einem Worktree heraus
nicht (210-nautobot.yml liegt nur im Haupt-Checkout); die
Transaktionsliste kommt trotzdem, nur die Compliance-Spalte fehlt.
Konflikt in teilprojekte.md (ROS-7.24.1-Zeile) zusammengefuehrt statt
eine Seite zu verwerfen: TP27-Erledigung samt Zeitstempeln aus main plus
die npk-Folge fuer TP16.3 aus diesem Branch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ich hatte die 134/135 dem 7.24.1-Upgrade zugeschrieben. Falsch. Auf main steht
a0a650e "TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main, Messung laeuft" --
der Hebel wurde am 2026-08-31 um 08:09 bewusst gesetzt, der Core erst um 14:36
gehoben. gc-transaktion.py status fuehrt TP25-fund-e-ft-over-ds als OFFEN
(Scope wifi-security, Ablauf 2026-09-03, Drift im Scope).
Die 134/135 sind also Absicht, kein Schaden, und brauchen keine Entscheidung
von Christoph -- sie gehoeren einer anderen, laufenden Session. Gruen machen
wuerde den Versuch unsichtbar machen.
Lehre, in beiden Dateien festgehalten: vor jeder Drift-Bewertung
gc-transaktion.py status lesen. Drift aus einem laufenden Versuch sieht
identisch aus wie ein Versehen -- genau dafuer existiert das Werkzeug, und ich
habe es nicht benutzt.
Handover-Punkt 5.1 von "braucht eine Entscheidung" auf "nicht anfassen"
umgestellt, Abnahme-Checkliste entsprechend.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- TP38 (OOB-Mgmt, untagged-VLAN99-Port je Switch): Nummer von Christoph
bestaetigt, Herkunft des Nummernwechsels im TP-Abschnitt vermerkt.
- Neu: docs/tp16.3-paragraph5-session-handoff-prompt.md -- fertiger
Prompt fuer die Flip-Session, nach der Konvention der drei bereits
vorhandenen *-session-handoff-prompt.md.
Enthaelt als erste Auflage die offene Drift-Entscheidung (128/135),
die vor dem ersten Flip fallen muss.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Merge von claude/nervous-williams-acf000 (d5b3ce3) plus Ergebnis der
Vor-Ort-Session vom 2026-08-31.
Ergebnis
- je ein cloudflared 2026.6.1 auf ap1/ap2/ap3, bf-public healthy/12
(vorher 0 Connectoren), Flash je AP 54-55 MiB frei, WLAN zurueck.
Drei Runbook-Fehler aufgedeckt und korrigiert (§2.2, §3.3, §3.5, §8)
- Flash-Budget war Faktor 2,5 zu optimistisch: cloudflared entpackt
69,5 MiB (gemessen mit docker export), nicht 28 MB -- das offizielle
Image passt auf keinen der drei APs. Ersatz: eigenes FROM-scratch-Image
mit 35,3 MiB aus dem statisch gelinkten Binary, Binary-SHA e93824f6
gepinnt, Neubau byte-identisch. tools/build-cfd-image.py.
- docker save schreibt seit Docker 25 OCI statt docker-v1 -> RouterOS
meldet "no config found in manifest". tools/oci2docker.py als Konverter.
- /container/envs nimmt list=, nicht name= (auch MikroMCPs
manage_container_env ist dadurch fuer dieses Feld unbrauchbar).
Weitere Funde
- Der device-mode-Bestaetigungs-Boot installiert keine Pakete; erst
Paket-Reboot, dann device-mode.
- "A - AVAILABLE" in /system package print ist ein Download-Katalog,
kein Paket auf dem Geraet (Gegenprobe am Core: 2,9 MB frei, listet
10,1 MB wifi-qcom als verfuegbar).
- MikroMCPs export_config exportiert unvollstaendig (301 B statt 6,2 KiB).
Offen und entscheidungsbeduerftig
- Compliance 128/135: §3.4 verlangt Direkt-Writes fuer ip address/nat,
die unter GC-Kontrolle stehen -> sechs neue extra-Drifts, zwei je AP.
Inhaltlich richtig, gehoeren ins Soll -- kein Re-Baseline, kein Rueckbau.
- Zwei Nautobot-Tokens sind in dieser Session ins Transkript geraten
(unzureichende sed-Maskierung) -> Rotation noetig, TP30. Merkregel in
CLAUDE.md ergaenzt.
Merge-Konflikte aufgeloest
- Nummernkonflikt: beide Branches hatten ein TP37. main behaelt TP37
(Nautobot als Netzwerkdoku, User-Okay 08-30), OOB-Mgmt wird TP38.
Braucht noch Christophs Okay.
- Drei CF-Rollback-Snapshots hatten gleichen Namen bei verschiedenem
Inhalt -> aelterer Stand als *-vor-hostname-schnitt.json erhalten,
keiner verworfen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei von Christoph gemeldete Ausfaelle (13:16 Terrasse, 14:23 Arbeitszimmer)
stehen im Kollektor und tragen dieselbe Signatur: Reauth-Schwall, dann ein
Loch von 7 bzw. 5,5 Minuten. Beide liegen NACH dem Hebel von 08:09.
- Hebel 1 (ft-over-ds=no) hat nicht gegriffen: 124x reauthenticating nach
dem Eingriff, Stundenvergleich auf gleicher Firmware 07h=79 vs 14h=70.
Erfolgskriterium war ~0. Gewertet wird nur 08:09-14:36 (Christoph-Entscheid),
danach kommt das Upgrade als zweite Variable dazu. Transaktion bleibt OFFEN,
Compliance bleibt bewusst 134/135.
- TP27 erledigt: Flotte einheitlich auf 7.24.1 (ap2 08:56, core 14:36,
ap1 14:50, branch 14:52; ap3 kam bereits so). Nach dem Upgrade live geprueft:
3 CAPs Ok, 4 Provisioning-Regeln, ap2 9x running, 30 Clients, ft-over-ds=no
hat den Reboot ueberlebt.
- Fund B entwarnt: die 13 CAP-joined / 4 activity timeout waren die
Upgrade-Reboots, keine CAPWAP-Instabilitaet. Neuer Gotcha: ein Burst ueber
VIELE MACs ist Infrastruktur, ueber EINE MAC ein Client.
- Zweiter Gotcha: die cap-wifiN-Karte verschiebt sich bei JEDEM Rejoin, nicht
nur beim Provisionieren -- sie wanderte an einem Tag zweimal, womit die
Tabelle im Vormittags-Handoff nach sechs Stunden falsch war. Interface-Namen
in Logzeilen sind ohne zeitnahen Snapshot nicht zuschreibbar.
- Offen fuer die naechste Session: Hebel 2 (ft=no) ODER wpa2-psk,wpa3-psk --
sec-main ist auch die einzige SSID ohne wpa2-psk, und "association rejected,
no cached PMK" (157x am 31.08., 0x am 30.08.) ist eine SAE/PMKSA-Meldung.
Vorher pruefen, ob 7.24.1 das Verhalten schon veraendert hat.
- wifi-p750w-coverage-and-map.md ist vom 2026-07-02 und als Coverage-Beleg
unbrauchbar (vor CAPsMAN-Cutover, vor ap2-Umzug, vor ap3).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auslöser (User 2026-08-31): beim Core-Neustart war crs326-branch nicht mehr
erreichbar, weil sein Management ausschliesslich ueber den Core laeuft.
Live nachgemessen: auf dem Branch ist vlan99 tagged=ether1,ether24,bridge mit
untagged="" - es gibt also keinen Weg zu 10.40.99.2, der nicht durch den Core
fuehrt. Wer den Core zerkonfiguriert, verliert den Branch gleich mit und damit
die Moeglichkeit, es vom Branch aus zu reparieren.
Zweiter, unangenehmerer Befund: crs326-branch hat GAR KEINE input-Regeln (Kette
leer). Sein gesamter Schutz besteht heute darin, dass VLAN99 nur ueber den Core
erreichbar ist und dessen forward-Kette deny-by-default faehrt - die
Erreichbarkeitsbeschraenkung IST die Zugangskontrolle. Damit ist ein untagged
MGMT-Port ein physischer Generalschluessel, und das TP traegt eine explizite
Auflage: Port disabled im Normalbetrieb ODER input-Regeln auf beiden Switches
ODER physische Sicherung. Empfehlung im Abschnitt: die input-Regeln, weil sie
eine Luecke schliessen, die unabhaengig von diesem TP besteht.
Kandidat ether23 - auf core und branch beide running=false, also frei, und auf
beiden Geraeten dieselbe Nummer.
Abnahme im Abschnitt so formuliert, dass sie den Zweck prueft: Laptop an
branch ether23, Core-Trunk gezogen, 10.40.99.2 muss antworten. Alles andere
misst nur den Normalfall.
Quick-Index (nach TP36 einsortiert), TP-Abschnitt und Ist-Stand mitgezogen;
Handover 20260831 auf den angelegten TP umgestellt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nautobot: ap1 stand als einziges Geraet noch auf SoftwareVersion 7.24 (ap2,
ap3, core, branch waren bereits richtig) -> auf 7.24.1 gesetzt. Danach
Backup/Intended/Compliance.
Folge fuers Runbook: aus zwei container.npk wird EINE. Die Zwei-Dateien-Regel
vom 08-30 war rein versionsbedingt, nicht modellbedingt - cAP ax und hAP ax^2
teilen sich die arm64-Pakete. §0, §2.1, §3.1 und Falle 1 umgeschrieben.
Die Regel dahinter bleibt: npk muss exakt zur ROS-Version passen, sonst ist
das Paket nach dem Reboot inaktiv - ohne Fehlermeldung.
Neue Compliance-Drift, NICHT von dieser Session und bewusst offen gelassen:
crs326-core / wifi-security - sec-main hat am Geraet ft-over-ds=no, Soll ist
yes (ft=yes ist korrekt). Kam mit dem Upgrade. 134/135 compliant. Braucht eine
Entscheidung (Geraet korrigieren oder neuen Wert zum Soll erklaeren) plus
Re-Provisionierung der CAPs; ein Re-Baseline ohne Entscheid wuerde die
Drift-Erkennung wertlos machen.
Handover docs/handoff-20260831-tp16.3-vorort-session.md fuer die Folgesession
(§2/§3: npk, device-mode, Container). Enthaelt u.a. den Hinweis, dass ein
fehlschlagendes /tool fetch vom AP auf Caddy KEIN Fehler ist, sondern die
SNI-Abweisung - und dass der TLS-Alert sogar beweist, dass die Freigabe traegt.
Offen notiert, nicht angelegt: TP-Vorschlag "dedizierter untagged-VLAN99-Port
je Switch" (Out-of-Band-Mgmt) - Auslöser war, dass crs326-branch beim
Core-Neustart nicht erreichbar war. Wartet auf Christophs Okay.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sshpass -p schreibt das Passwort in argv, wo es in ps und jedem argv-Trace
steht -- die Klasse, an der am 2026-08-22 das Core-Passwort verbrannt ist.
Nach gc-transaktion.py (voriger Commit) jetzt auch die fuenf unter routeros/:
SSHPASS-Env + sshpass -e.
Nachweis, gemessen statt gelesen:
- alle 13 subprocess.run mit sshpass tragen env= (per AST geprueft; ohne env
waere SSHPASS leer und alles still kaputt)
- Signaturen passen zu den Aufrufen (AST-Arity; py_compile findet das NICHT)
- echter Lauf des gepatchten Codes gegen den lebenden Core: backup-core.py
importiert, IP zur Laufzeit auf 10.40.99.1 -> "name: crs326-core", rc=0
- Passwort in argv? nein. In ps waehrend der Verbindung? nein, 40 Stichproben
- Negativkontrolle: derselbe Test mit einem Dummy-Wert ueber die alte -p-Form
-> 36 Treffer. Die Probe ist also nicht blind, das "nein" hat Aussagekraft
Mitgefixt, weil es im umgebauten Code lag: apply-core-cutover-l3.py griff in
run_silent auf ein pw zu, das dort gar nicht existierte -- jeder Fehlerfall
endete in einem NameError statt in der gedachten Meldung.
Fuer TP30 aendert das NICHTS: der Weg ist zu, der Wert bleibt verbrannt.
Posten #1 (MikroTik-admin) bleibt faellig. Im TP so hingeschrieben, damit es
niemand als erledigt liest.
--- Archivierung (Christoph-Entscheid) ---
Beim Fixen fiel auf, dass alle vier Cutover-Skripte auf tote Adressen zeigten:
apply-core-cutover-l3.py 10.40.41.211 tot (VLAN41 seit 2026-08-27 weg)
backup-core.py 10.40.41.211 tot
restore-core.py 192.168.88.1 tot (Werks-Temp-Pfad)
backup-ap1.py 10.40.10.1 ANTWORTET -- ist aber der CORE
backup-ap1.py war der gefaehrliche: er waere nicht gescheitert, er haette den
Core gesichert und die Datei ap1-pre-core-cutover-*.backup genannt. Wer das
spaeter zurueckspielt, spielt Core-Config auf einen AP.
Entscheid war archivieren, nicht reparieren -- der Cutover ist am 2026-08-08
durch, die Skripte haben ihre Aufgabe erfuellt. Sie liegen jetzt unter
routeros/archiv-tp15-cutover/ mit README nach dem Muster von switch/.
Die Pfad-Nebenwirkungen des Verschiebens sind ABSICHTLICH nicht repariert
(backup-core.py schriebe jetzt ins Archivverzeichnis, apply-core-cutover-l3.py
faende seine .rsc nicht mehr) -- sie zu reparieren hiesse, die Skripte wieder
lauffaehig zu machen, und das ist gerade nicht die Absicht.
Der sshpass-Fix wurde trotzdem VOR dem Verschieben gemacht: Archiv-Code wird
abgeschrieben, also soll dort das richtige Muster stehen.
import-core-rsc.py bleibt, wo es ist -- als einziges generisch nuetzlich. Sein
Default-Host ist ebenfalls tot (--host mitgeben), und in --host steckt ein
zweiter latenter Bug: sys.argv[1] wird als RSC-Pfad gelesen, bevor auf --host
geprueft wird. NICHT gefixt, eigene Runde.
Zeiger gesetzt in: CLAUDE.md (sshpass-Gotcha), teilprojekte.md (TP30),
teilprojekte-archiv.md (TP15), Handoff 2026-08-31.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein Hebel, sonst nichts. 2026-08-31 08:09 am Manager crs326-core:
/interface wifi security set [find name="sec-main"] ft-over-ds=no
/interface wifi capsman remote-cap provision [find]
ft=yes bleibt -- FT laeuft weiter over-the-air, nur nicht mehr over-the-DS.
Nimmt exakt die Aenderung vom 2026-08-17 zurueck.
Abnahme (Lease, nicht Registration-Table):
- Manager, alle vier aktiven Master-VAPs cap-wifi3/4/5/6: ft=true ft-over-ds=false
- alle 3 CAPs state=Ok, alle VAPs running=yes AM CAP gelesen
- iPhone nach 71 s zurueck auf dirtyvader-main, frische Lease 10.40.10.196,
auth-type=ft-wpa3-psk, -54 dBm; 30 Clients gesamt zurueck
- Log 08:13:20 zeigt sauberes "roamed to" zwischen zwei APs -> Roaming intakt
- Geraete-Backup vorher: pre-tp25-funde-ftoverds.backup
Governance: Transaktion TP25-fund-e-ft-over-ds OFFEN (Scope wifi-security,
Ablauf 2026-09-03). Compliance steht deshalb ABSICHTLICH auf 134/135; der Diff
ist exakt ft-over-ds=yes->no, kein Kollateral-Drift durch die Re-Provisionierung.
Das GC-Template wird erst beim COMMIT nachgezogen -- vorher gruen machen wuerde
den laufenden Versuch unsichtbar machen, und gc-transaktion.py verweigert den
Commit ohnehin, solange der Scope driftet. 135/135 kommt nach der Messung zurueck.
Messstand nach 25 min: weiter 93, letzter reauthenticating 07:34:43 (vor dem
Eingriff). Logging nachweislich lebendig (593 wireless-Zeilen heute, beide SSIDs).
Noch kein Ergebnis, nur ein sauberer Schnitt.
Drei Funde:
- cap-wifiN-Karte hat sich beim Re-Provisionieren VERSCHOBEN: ap2 war 1/2 ->
jetzt 3/5, ap3 war 5/6 -> jetzt 4/6, ap1 hat 1/2 bekommen. Wer die 07:xx-Zeilen
gegen die neuen liest, ordnet dem falschen AP zu.
- Korrektur am Vormittagsbefund: main unterscheidet sich in ZWEI Attributen, nicht
einem -- es ist auch die einzige SSID ohne wpa2-psk. Die Kontrollgruppe trennt FT
und WPA3-only nicht. Wenn Hebel 1 und 2 beide nichts bewegen, ist
authentication-types der naechste Kandidat, NICHT signal-range.
- gc-transaktion.py rief sshpass -p auf (Passwort in argv, Klasse vom 2026-08-22).
Auf SSHPASS-Env + -e umgestellt, weil das Skript laufen musste. Fuenf weitere
Dateien unter routeros/ haben dasselbe Muster und sind bewusst NICHT angefasst
(Stop-Bedingung; gehoert zu TP30). Entwarnung: /export auf 7.24 gibt Passphrasen
gar nicht aus (live geprueft), die Transaktionsakte im Git ist sauber.
Nebenbei: .gitignore hatte docs/nas-vlan20/stacks/ MIT Schraegstrich -- im Worktree
liegt dort ein Symlink auf den Haupt-Checkout, der war damit nicht ignoriert.
Doku an allen drei Stellen nachgezogen (Quick-Index, TP25-Abschnitt, Ist-Stand-Block)
plus CLAUDE.md-Pflichtlektuere und neuer Handoff mit Entscheidungstabelle fuer 09-01.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A) bf-public-Ingress von http://10.40.20.40:80 auf https://10.40.20.40:443
umgestellt, originServerName je Regel. Die :80-Variante haette ueber
Cloudflare eine Redirect-Schleife gebaut (Caddy antwortet dort 308 auf
https, das Ziel laeuft zurueck in denselben Tunnel).
B) Freigabe vlan99 -> vlan20:443 auf crs326-core angelegt - ueber Nautobot
Golden Config, NICHT per Direkt-Write: ip-firewall-filter steht seit TP26
unter Drift-Kontrolle, und die zwei genehmigten Ausnahmen (#2 Bring-up,
#4 WireGuard-Keys) decken diesen Fall nicht.
- Backup vorher: core-pre-tp16.3-blockerB-20260831.backup (TP22-Regel 3)
- gc-manual-plan.py, Change-ID TP16.3-BlockerB, Plan Completed
- Position verifiziert: direkt vor TP5: log-only / TP5: deny-by-default
- Re-Baseline ingest-core-firewall.py --apply, dann --refresh-compliance
=> 135/135 compliant, 0 Drifts
- funktional: /tool fetch von ap3 erreicht Caddy und bekommt einen
TLS-Alert VON Caddy - ein Alert kann nur vom Server kommen, das Paket
ist also da. Der Alert ist die SNI-Abweisung (ohne SNI 000, mit
korrektem SNI 200) und damit genau der Grund fuer originServerName.
C) ROUTER_AP3_USER/_PASS in ~/.secrets/credentials.env nachgetragen (war nur
in ~/.claude.json), chmod 600, Sicherung .bak-20260831. REST-Auth gegen
ap3 = HTTP 200.
Vor Ort startet die Arbeit damit bei §2/§3 (container.npk, device-mode,
Container). Quick-Index, TP16.3-Abschnitt und Ist-Stand mitgezogen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
