Christoph Emsenhuber
08a1aaa80d
Die `### TPnn`-Header trugen weiterhin Status-Anspruche (▸ ✅ FERTIG …, ▸ ⏳ CUTOVER …),
obwohl Index/Status seit dem TP36-Cutover in Gitea liegt. Das war eine dritte Statusquelle,
die den Labels nachlief — Header-Marker datierten teils Wochen vor dem Issue-Update.
- 75 Header (32 aktiv + 43 Archiv) auf `### TPnn · Gitea #N — <Titel> — <Caveat>` umgestellt.
Caveats, Warnungen, Querverweise und Archiv-Links bleiben erhalten, nur der Status faellt weg.
Status-Marker im Fliesstext (Messchronik, Unterpunkte) bleiben — sie beschreiben Historie.
- TP47 fehlte als Gitea-Issue komplett (nur in der Datei seit 808d3a1) -> als #74 angelegt.
- bin/gitea-tp-sync.py schrieb in die falsche Richtung: der Abgleich leitete den Zielzustand
aus dem Datei-Marker ab (fest ✅) und haette #24 (TP34, bewusst status:dropped) auf status:done
gezogen. Jetzt werden nur noch FEHLENDE Archiv-Issues angelegt, bestehende nie angefasst.
- CLAUDE.md: Header-Form + Werkzeug-Richtung festgehalten.
- Announcement 2026-10-03 für die naechste Session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.0 KiB
Handoff 2026-09-28 — Core erreicht FM/DW-Spoke-Netze nicht aus eigener Kraft
Kontext / Auslöser
Christoph konnte von Notebook + macmini immer 10.101.0.254 (FM-Standort-GW) pingen, eine
überforderte Vorgänger-Session hatte behauptet, der Core „komme dort nicht hin". Befund
sollte jetzt geprüft und ausgeräumt werden.
Befund (alles live verifiziert 2026-09-28, crs326-core)
| Quelle | → 10.101.0.254 (FM-GW) | → 10.101.0.10 (FM-Host) |
|---|---|---|
| macmini (VLAN20, gw 10.40.20.1) | ✅ 0 % Loss | ✅ 0 % Loss |
| Notebook (VLAN10, gw 10.40.10.1) | ✅ 0 % Loss | ✅ 0 % Loss |
Core default (/ping ohne src) |
❌ 100 % Loss | ❌ 100 % Loss |
Core mit src-address=10.40.10.1 |
✅ 0 % Loss (ttl 64) | ✅ 0 % Loss (ttl 63) |
Root Cause
wg-hub (TP10 Multi-Site VPN Hub) hat keine IP-Adresse — weder live
(/ip address print where interface="wg-hub" → leer) noch im GC-Template
(mikrotik_routeros.j2:379, nur listen-port/mtu/name/private-key).
FM-seitig erlaubt die FritzBox als AllowedIPs Richtung Hub 10.40.0.0/16
(routeros/fritzbox-wg-lanlan-klickanleitung.md). Weitergeleiteter Client-Traffic
(Quell-IP 10.40.x) liegt in diesem Raum → läuft. Core-eigener Traffic ohne
explizite Quell-IP: RouterOS wählt mangels IP auf wg-hub eine Quell-IP außerhalb
von 10.40.0.0/16 (vermutlich WAN 90.146.33.177) → FM routet die Antwort nicht zurück
→ Timeout. Der Tunnel selbst ist up (FM-Peer last-handshake ~1m45s, rx 140.8 GiB).
SSoT / Governance
Die Core-Config liegt im GC-Template nautobot/mikrotik_routeros.j2. Dort existieren:
:375/ip route add ... dst-address=10.101.0.0/24 gateway=wg-hub comment="TP10: FM spoke":376/ip route add ... dst-address=10.95.10.0/24 gateway=wg-hub comment="TP10: DW spoke":379-381wg-hub Interface + fm/dw Peers (Privkey redacted)
Ein Fix gehört ins Template, nicht als Direkt-Write aufs Gerät (GC-Compliance-Regel).
Deploy via nautobot/gc-configplan.py / GC-Job „Backup → Intended → Compliance".
Fix-Optionen (noch nicht entschieden)
preferred-sourceauf die zwei TP10-Routen (Zeile 375/376, z. B.10.40.10.1). Kein FM-Eingriff nötig (FM erlaubt 10.40.0.0/16 bereits). Minimal-invasiv. Empfohlen.- wg-hub eine IP geben (z. B. dedizierte Adresse aus 10.40.0.0/16) — mehr Risiko, IP-Raum- Eingriff, FM-Abgleich nötig.
- FM-seitig AllowedIPs um die Core-WAN-IP erweitern — FritzBox-WG-Config eingeschränkt, nicht sauber.
Offene Entscheidungen
- Welche
preferred-source-IP? (10.40.10.1 = MAIN-SVI ist naheliegend.) - TP10 ist im Archiv „KERN DURCH, offen nur DDNS-Updater". Neuer Befund → TP10-Issue
reopen+ Prosa zurück nachteilprojekte.md, oder als eigenes kleines TP? (Christoph-Entscheid.) - Fix jetzt ausführen oder nur dokumentieren?
Aufwandsschätzung (Core-Ping-Fix)
Klein. 2 Zeilen Template-Edit + ein GC-Deploy-Zyklus (~30–60 min inkl. Backup/Intended/Compliance)
- Ping-Verifikation. Kein Hardware-/FM-Eingriff bei Option 1.