Files
bf-infra/docs/tp10-context-digest.md
Christoph Emsenhuber dd4c6ad77c TP10 Doku konsolidiert: kanonischer Runbook + kompakter Kontext-Digest
- tp10-vpn-migration.md zur Single Source of Truth umgeschrieben: widerspruechliche
  alte Transfernetz-Tabelle/MyFRITZ-Endpoint entfernt, aktueller Stand (Proxy-ARP
  LAN-IP, DDNS bf4.emsenhuber.net, dual-range DW, geparkter ap1-Hub, vertagt+
  gebuendelt mit Bridge-Cutover, v6-Variante) konsolidiert.
- teilprojekte.md TP10-Eintrag von verbose Saga auf kompakten Status + Verweis gekuerzt.
- tp10-context-digest.md neu: ultrakompakter Handoff (lokal via Ollama nemotron-3-nano:4b
  destilliert, fakten-gegengeprueft) fuer kleines Kontextfenster.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 14:08:01 +02:00

2.3 KiB
Raw Blame History

TP10 — Kontext-Digest (kompakt, für kleines Kontextfenster)

Verdichteter Handoff-Stand. Vollständig: docs/tp10-vpn-migration.md. (Erstellt lokal via Ollama nemotron-3-nano:4b, fakten-gegengeprüft.)

  • TP10 = 2 AVM-Tunnel (FM=IPsec, DW/Geli=FB-WireGuard) → 2× WireGuard mit Hub auf ap1 (MikroTik hAP). Gated: permanenter FB-Bridge.
  • Entscheidung 2026-06-17: TP10 vertagt, gebündelt mit FB-Bridge-Cutover (VPN-auf-FB ⊕ Bridge schließen sich aus). Am Bridge-Tag hat ap1 die Public-IP → kein Port-Forward. Vorerst beide VPN über die BF-FritzBox: FM=IPsec, DW=FB-WG.
  • Root Cause (FM-PoC bewiesen): FB masqueradet den WG-Tunnel, wenn die WG-Interface-Address eine Transfernetz-IP ist. AVM = Proxy-ARP → FB-WG-Address MUSS die LAN-IP sein. Beweis: Ping 10.101.0.10 kam aus 10.255.255.2 (NAT).
  • Eckdaten:
    • Hub wg-hub ap1: UDP 51821, MTU 1412, keine IF-IP, Public-Key P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=
    • Endpoint Spokes: bf4.emsenhuber.net:51821 (Cloudflare DDNS, proxied=false → 86.56.201.104). Nicht MyFRITZ (stirbt im Bridge).
    • BF-AllowedIPs: 10.40.0.0/16
    • FM LAN 10.101.0.0/24 GW .254, FB-WG-Address = 10.101.0.254/24
    • DW/Geli CGNAT v4, LAN heute 192.168.178.0/24 GW .1, künftig 10.95.10.0/24. FB-WG-Address = 192.168.178.1/24, 10.95.10.1/24 (dual, renumber-fest). Keepalive 25.
  • Zustand: ap1-Hub geparkt (Peers disabled, WG-Routen entfernt, Firewall bleibt). DW-Config bei Geli vor Ort gestaged 2026-06-17.
  • Offen (sobald BF erreichbar): peer2 enable, allowed-address 192.168.178.0/24,10.95.10.0/24 (Key FqYZLztQ/qME5VDie5QLGH++5299WJiE1dPpQnPbzUw= oder Gelis FB-eigener Key), Routen 192.168.178.0/24 + 10.95.10.0/24 → wg-hub. peer1/FM bleibt disabled.
  • Gotchas: (1) FB-WG-Address = LAN-IP, kein Transfernetz. (2) NetBIOS routet nicht über Tunnel → per IP/DNS testen (SMB 445), kein Broadcast. (3) Gelis FB lehnt 2 WG zum selben Zielnetz ab → direkter Swap. (4) Verify: Antwort-Quelle muss echte LAN-IP sein, nicht 10.255.255.x.
  • v6-Variante (später): Gelis FB hat natives öffentliches IPv6 2a0e:7a02:31c:3000::/56 (rotiert ~30h via MyFRITZ), v6-Inbound offen → direktes WG ap1↔Geli über v6 umgeht CGNAT; Inner-Tunnel bleibt IPv4.