146 lines
8.3 KiB
Markdown
146 lines
8.3 KiB
Markdown
# Übergabe an die Doku-/Review-Session — Stand 2026-08-18, 06:30
|
|
|
|
> **Wofür das hier ist:** Du hast in der Nacht auf den 18. eine Analyse gefahren und drei Befunde
|
|
> gemeldet. **Alle drei waren richtig.** Parallel lief eine zweite Session, die dieselben Dateien
|
|
> bearbeitet hat — daher dieses Dokument: es sagt dir, was inzwischen erledigt ist, was von deinen
|
|
> Befunden offen bleibt, und wo du weiterarbeiten kannst, ohne dass wir uns gegenseitig überschreiben.
|
|
|
|
---
|
|
|
|
## 1. Deine drei Befunde — Abgleich
|
|
|
|
### ✅ Befund 1: Doku-Drift — bestätigt, inzwischen behoben
|
|
|
|
Du hattest recht, und die Ursache war banal: die andere Session hat in der Nacht die **TP-Abschnitte**
|
|
und `CLAUDE.md` nachgezogen, aber den **„Ist-Stand (Kurz)"-Block** oben in `teilprojekte.md` übersehen.
|
|
Genau den Block, den eine frische Session zuerst liest.
|
|
|
|
Alle vier von dir genannten Punkte waren falsch und sind jetzt korrigiert:
|
|
|
|
| stand dort | tatsächlich (live geprüft 08-18) |
|
|
|---|---|
|
|
| „reine Standalone-APs, kein CAPsMAN" | CAPsMAN auf dem Core seit 08-17 (TP28) |
|
|
| RouterOS 7.19.5 / 7.23 | **alle vier auf 7.24**, RouterBOOT ebenfalls 7.24 |
|
|
| DNS „plain 1.1.1.1" | **DoH** zum CF-Gateway, `verify-doh-cert=yes` |
|
|
| 68/68 Compliance | **92/92 bei 23 Rules, 0 Drifts** |
|
|
|
|
**TP26/TP27 haben jetzt Abschnitte.** Du hattest auch damit recht: beide existierten nur als Commits
|
|
und `.rsc`-Dateien. TP27 ist Christophs eigene RouterBOOT-/7.24-Arbeit aus Commit `b93514a` — daher
|
|
kam die 7.24, die im Ist-Stand-Block fehlte.
|
|
|
|
### ✅ Befund 2: TP6-Prämisse — bestätigt, jetzt im Dokument verankert
|
|
|
|
`docs/call-quality-diagnosis.md` sagt es sogar im **Kopf**: TP6 „hat sich als **Nicht-QoS-Problem**
|
|
entpuppt". Dazu die Ergebnistabelle: `CAKE / QoS | kein Bufferbloat-Spielraum | ❌ nicht deployt`.
|
|
|
|
Das steht jetzt in TP6 selbst, samt der Einschränkung, die du selbst genannt hast (FritzBox-Ära,
|
|
Edge seither getauscht). **Der kritische Pfad ist entsprechend umformuliert:** nächster Schritt ist
|
|
eine Messung gegen den heutigen Edge, nicht der Bau einer Queue.
|
|
|
|
### ✅ Befund 3: Fasttrack — bestätigt, plus zwei Fakten, die du nicht wissen konntest
|
|
|
|
Live nachgezählt am 08-18:
|
|
|
|
```
|
|
2 accept | defconf: accept est,rel,untracked | 32.979.171 Pakete
|
|
3 fasttrack-connection | defconf: fasttrack | 0 Pakete
|
|
0 von 445 Verbindungen fasttracked
|
|
```
|
|
|
|
**Ergänzung 1 — es ist kein Zufall, sondern ein Cutover-Artefakt.** `ap1` hatte die Reihenfolge vor
|
|
dem Cutover **richtig** (Fasttrack zuerst, MikroTik-defconf). Umgedreht wurde sie beim handgebauten
|
|
Core-Aufbau in TP21.1.
|
|
|
|
**Ergänzung 2 — seit dem 18. steht der Fehler als *Absicht* in der SoT.** Das Re-Baseline
|
|
(`ingest-core-firewall.py --apply`) nach TP5 E3/E4 hat die Reihenfolge unverändert nach Nautobot
|
|
geschrieben, Rule `ip-firewall-filter` mit `config_ordered=true`. Das ist die Kehrseite dieses
|
|
Werkzeugs: es erklärt den Ist-Stand zum Soll, ohne zu prüfen, ob der sinnvoll ist. Steht jetzt als
|
|
Warnung in TP21.
|
|
|
|
**Offen und bewusst nicht entschieden** (gehört Christoph): Reihenfolge korrigieren · Fasttrack-Regel
|
|
entfernen · so lassen. Vorher wäre zu messen, was Fasttrack-los den **Inter-VLAN**-Durchsatz kostet
|
|
(NAS ↔ MAIN läuft geroutet über die Core-CPU). Für 10 Mbit WAN irrelevant, für Gigabit-Transfers nicht.
|
|
|
|
---
|
|
|
|
## 2. Was in der Nacht passiert ist (Kontext, den du sonst rekonstruieren müsstest)
|
|
|
|
Chronologisch, alles verifiziert und committet:
|
|
|
|
1. **TP23 Stufe 1 — DoH auf dem Core.** GTS Root R4 importiert (~1 KB statt CA-Bundle — der Core hat
|
|
nur 2,8 MB freien Flash), `verify-doh-cert=yes`.
|
|
⚠️ Der Deploy meldete **FAILURE, obwohl alles saß**: `/certificate import` gibt `failed: 0` aus, und
|
|
der Job scannt den Output stumpf nach dem Wort.
|
|
2. **TP23 Stufe 2 — AdGuard vorbereitet, bewusst NICHT scharf geschaltet.** Conditional Upstreams,
|
|
sechs CIDR-Gruppen, `dns-bypass-exempt`. **Kein DHCP-Scope angefasst.**
|
|
3. **TP5 Etappe 2-Nachtrag.** Das „die Log-Regel ist verstummt" von Etappe 2 stammte aus einem
|
|
**70-Sekunden**-Fenster und war falsch — über dreieinhalb Stunden liefen 119 Zeilen auf. Drei der
|
|
vier Lücken hätten den Drop zum Ausfall gemacht, darunter: **der Netmiko-Deploy kommt von
|
|
`10.40.20.31` (`nautobot-worker`), nicht von `.20.30`.**
|
|
4. **TP5 Etappe 3 + 4 — deny-by-default in beiden Ketten.** Abnahme: 11 gedroppte Pakete in 15 Minuten,
|
|
alle von der eigenen Sonde. Die 5 mDNS-`input`-Regeln sind dadurch erstmals scharf.
|
|
5. **NTP.** Der Standort hatte **nirgends** eine funktionierende Zeitsynchronisation. Jetzt: Core als
|
|
Quelle, DHCP-Option 42, ComplianceRule `system-ntp`.
|
|
6. **TP7.1 — SSDP-Relay** als LXC 108 auf pve. User-bestätigt: „sonos ist da!"
|
|
7. **TP28-Rest — GC-Modell auf CAPsMAN umgebaut.** Die APs trugen noch die komplette
|
|
Standalone-WLAN-Config aus TP3; abgeräumt.
|
|
8. **TP19 und TP3.2 geschlossen.**
|
|
|
|
### ⚠️ Korrektur zu Punkt 7 — und die wichtigste Lehre der ganzen Nacht
|
|
|
|
Ich hatte den AP-Cleanup mit „30 Clients vorher, 30 nachher, kein Aussetzer" abgenommen. **Das war der
|
|
falsche Maßstab.** Parallel lief bereits ein Ausfall, den genau diese Zahl verdeckt hat:
|
|
|
|
Seit dem CAPsMAN-Cutover vom **08-17** war `/interface wifi cap slaves-datapath` auf beiden APs **leer**
|
|
— das einzige Feld, das die vom Manager erzeugten Slave-VAPs lokal in die Bridge hängt. Der Core schickt
|
|
`datapath.bridge=bridge` mit, der CAP übernimmt davon aber **nur die `vlan-id`**. Folge: `-iot`, `-media`,
|
|
`-untrusted` und `-guest` hingen **in gar keiner Bridge**. Clients assoziierten sauber und bekamen
|
|
**nie DHCP** — **14 Stunden lang**. `dirtyvader-main` lief weiter, weil `wifi1`/`wifi2` statische
|
|
Bridge-Ports sind, und hat den Ausfall getarnt.
|
|
|
|
Gefunden und behoben hat es Christoph am 08-18 um 09:13 (Commit `1ba8260`): `dp-caps-slaves`
|
|
(`bridge=bridge`, bewusst **ohne** `vlan-id`) + `slaves-datapath` darauf, auf beiden APs.
|
|
|
|
**Zwei Konsequenzen, die du kennen solltest:**
|
|
|
|
1. **Die Registration-Table ist kein Abnahmekriterium.** Sie zeigte während des Ausfalls zufriedene
|
|
IOT-Clients — und ich habe damit „kein Aussetzer" attestiert. **Richtig ist eine frische DHCP-Lease
|
|
pro SSID.** Steht inzwischen so in `CLAUDE.md`.
|
|
2. **Es war nicht die TP5-Härtung**, obwohl der zeitliche Zusammenfall das nahelegt: `torch` auf vlan30
|
|
am Core war leer **und** der TP5-Drop-Log zeigte nichts. Beides leer heißt: es kommt nichts an, es
|
|
wird nichts verworfen → **L2-Problem, nicht Firewall**. Diese Merkregel steht jetzt ebenfalls in
|
|
`CLAUDE.md` und ist bei künftigen „connect ok, kein DHCP"-Fällen der erste Griff.
|
|
|
|
**Nautobot-Betrieb:** der Stack hat sich zweimal selbst umgebracht. Ursache war der **Image-Healthcheck**
|
|
(voller Django-Start alle 10 s, Aufrufe stapeln sich → ENOMEM → DSM räumt ab), nicht Celery. Behoben.
|
|
Steht in TP21.
|
|
|
|
---
|
|
|
|
## 3. Arbeitsteilung — damit wir uns nicht überschreiben
|
|
|
|
`docs/teilprojekte.md` ist die einzige Datei, die beide Sessions anfassen wollen. In der Nacht wurde
|
|
sie viermal committet.
|
|
|
|
**Vorschlag:** die andere Session hält sich ab jetzt von `teilprojekte.md` fern, solange du daran
|
|
arbeitest. Vor jedem Edit `git pull`, danach zügig committen — der Stand ist auf
|
|
`gitea/main` gepusht.
|
|
|
|
### Was für dich sinnvoll offen liegt
|
|
|
|
- **Doku-Konsistenz weiter prüfen.** Du hast den Ist-Stand-Block gefunden; wahrscheinlich gibt es mehr
|
|
davon. Lohnende Kandidaten: `docs/ip-plan.md` (enthält noch `10.40.41.x`-Zeilen aus der VLAN1-Ära),
|
|
`docs/doku-cleanup-session.md` Punkt E (laut Follow-up-Liste „teilweise"), und die Memory-Dateien —
|
|
mehrere behaupten noch „kein CAPsMAN".
|
|
- **TP13 / TP14.4 / TP16.3** — die hattest du bereits offen. TP14.4 (CF-Access-Service-Token rotieren)
|
|
ist unverändert offen, TP16.3 ebenfalls (Recherche durch, Umsetzung offen).
|
|
- **Nicht anfassen ohne Rücksprache:** die Fasttrack-Reihenfolge (Entscheidung gehört Christoph) und
|
|
alles, was einen GC-Push auslöst — die Compliance steht gerade auf 92/92 und das sollte sie bleiben.
|
|
|
|
### Zwei Regeln, die in der Nacht teuer erkauft wurden
|
|
|
|
1. **Job-Status ist kein Wirksamkeitsnachweis.** Zweimal meldete ein Plan „Completed", ohne etwas zu
|
|
ändern (`[find !dynamic]` ist auf `/interface wifi configuration` ein **Syntaxfehler**, kein Filter),
|
|
und einmal „FAILURE", obwohl alles saß. Nur die Gegenprüfung am Gerät zählt — `--assert` nutzen.
|
|
2. **Ein Zählerstand über 70 Sekunden ist keine Messung.** Siehe TP5 oben.
|