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>
53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
# 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-381` wg-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)
|
||
1. **`preferred-source` auf 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.**
|
||
2. wg-hub eine IP geben (z. B. dedizierte Adresse aus 10.40.0.0/16) — mehr Risiko, IP-Raum-
|
||
Eingriff, FM-Abgleich nötig.
|
||
3. 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 nach `teilprojekte.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.
|