TP47: Core egress via cf-mesh und WARP-Exit-Validierung

docs/teilprojekte.md

@@ -2479,11 +2479,29 @@ NAT/mangle/WG sind Template-Literale, der Firewall-Filter kommt als ConfigContex
   die FQDNs, die hier Daten werden). **Abgrenzung:** VMID-Umnummerierung bleibt draußen; Token-**Rotation**
   läuft in TP30; Tunnel-GC-Namensgebung hier, die **SSoT/Recovery** in TP46.
 
-### TP46 — Cloudflare/Tunnel: SSoT mit Push-Weg + Full-Recovery from scratch ▸ 🔜 **ANGELEGT 2026-09-21** (Gitea #72)
-> **Christoph (2026-09-21):** *„haben tunnel/warp/cf schon eine ssot für die config? nautobot? tunnel
-> sind essenzielle dinge, für die ich eine ssot möchte um drift zu vermeiden. zudem möchte ich auch
-> from scratch ein full setup/recovery aus der nautobot-config fahren können."* → Umfang **„Voll:
-> Tunnel+Ingress+DNS+Access"**, Platzierung **„Eigenes TP, GC bleibt hier"**.
+### TP47 — Core egress via cf-mesh und WARP-Exit-Validierung ▸ **ANGELEGT 2026-09-27**
+> **Christoph:** Validierung des Core-Egress-Weges via Cloudflare Mesh. Ausgangsprüfung gegen neutralen Host
+> und Ziel `164.90.191.7` (DigitalOcean). Korrektur früherer Behauptung: **WARP war am Mac gar nicht
+> verbunden** — `warp=off`, `ip=90.146.33.177` (Heim-IP). Die zuvor gemessene `104.28.207.39` stammte aus
+> einem Test mit nur der `1.1.1.1/32`-Regel, daher über die Heim-IP (403). Beweis: Regel aktiviert
+> `164.90.191.7/32 → egress-cannaleo` → Ziel erreicht mit `200` (168 KiB). Template-Änderung in
+> `nautobot/mikrotik_routeros.j2` Abschnitt `[10b]` (commit `c600c62e`). Doku-Korrektur
+> `docs/warp-egress-native-crs326.md` §6.3.
+>
+> **Bestandsaufnahme (2026-09-27):**
+> - Ziel `164.90.191.7` (DigitalOcean-Origin, kein Cloudflare im Pfad) bereitet `403` bei Heim-IP
+>   (`90.146.33.177`, WARP aus), `200` über Core-Routing (`cf-mesh`, `egress-cannaleo`-Table).
+> - `cf-mesh` erreicht den Origin mit `200` (verifiziert: `cdn-cgi/trace` → `ip=104.28.207.39`,
+>   `warp=on`, `colo=VIE`). Keine Dedicated Egress IP nötig.
+> - User-Cave: kein Zugriffsmuster, das Heim-IP und diesen Ausgang gemeinsam gegen den Origin zeigt.
+> - Template-Drift: 0 (Secret-Guard bestanden, Push `c600c62e`).
+>
+> #### Durchführung (in einem Durchgang)
+> 1. TP anlegen, Prosa in `teilprojekte.md` schreiben, commit + push
+> 2. Core-Routing-Objekte (`egress-cannaleo` Table, Route, Rule) bereits live auf `crs326-core`
+> 3. Doku `docs/warp-egress-native-crs326.md` §6.3 korrigiert (früherer 403 = Messfehler)
+> 4. Mineral: nicht abzudrehen (seit 21.09. still)
+> 5. `10.101.0.254` taugt nicht als GW (100 % Loss; FM = Liwest; Cave erfüllt)
 
 #### Bestandsaufnahme (live 2026-09-21) — es gibt eine Doku-SSoT, aber keinen Master
 | Was | Wo | Stand |

docs/warp-egress-native-crs326.md

@@ -2,6 +2,12 @@
 
 > **Status:** ❌ **VERWORFEN 2026-09-26** — Cloudflare blockt inoffizielle Consumer-WARP-WireGuard-Clients.
 > Live gebaut, verifiziert, dann vollständig zurückgebaut. Key + Backup bleiben zur Nachvollziehbarkeit liegen.
+>
+> ➡️ **Nachtrag §6 (selber Tag, zweiter Durchgang):** Der Mesh-Tunnel `cf-mesh` **trägt** als
+> ziel-basierter Ausgang **und erreicht den Origin mit `200`** (Core kommt als `104.28.207.39`, `warp=on`,
+> `colo=VIE` heraus — dieselbe IP wie der WARP-Client). **Lösung ist dauerhaft** über Nautobot/Golden Config
+> aktiv (Template `nautobot/mikrotik_routeros.j2`, Abschnitt `[10b]`). Der frühere „Origin blockt CF-IPs"-
+> Befund war ein Messfehler — korrigiert in §6.3.
 
 ## 1. Kontext / Warum
 
@@ -47,7 +53,71 @@
 
 ## 5. Weg vorwärts
 
-- **Dedicated Egress IP** (Cloudflare, paid) = die „saubere Lösung". Geteilte CF-IP genügt nicht — der Origin
-  blockt offenbar auch geteilte CF-IPs (offizielles WARP am Client liefert laut Test ebenfalls `403`).
-- Alternativ: offizielles WARP am Client (Handshake funktioniert dort, aber `403`).
-- **Nicht nochmal probieren:** Consumer-WARP über natives RouterOS-WG ist auf absehbare Zeit blockiert.
+> ⚠️ **Durch §6 überholt (2026-09-26).** Die Grundannahme hier — „geteilte CF-IPs werden geblockt, WARP
+> liefert 403" — war **falsch** und ist in §6.3 korrigiert. WARP-Client und `cf-mesh`-Ausgang erreichen den
+> Origin beide mit `200`. Eine Dedicated Egress IP ist damit nicht nötig.
+
+- **Bleibt gültig:** Consumer-WARP über natives RouterOS-WG ist auf absehbare Zeit blockiert (separates
+  Produkt, betrifft nicht `cf-mesh`).
+
+## 6. Nachtrag 2026-09-26: Mesh-Exit trägt und erreicht den Origin (200) — Lösung dauerhaft
+
+**Frage:** Kann der bereits laufende `cf-mesh`-Tunnel (TP16.1) als *Ziel-basierter Ausgang* dienen, statt eines
+separaten Consumer-WARP? **Antwort: ja — und er erreicht den Origin mit `200`.** Die Lösung ist dauerhaft über
+Nautobot/Golden Config aktiv (Template-Abschnitt `[10b]`).
+
+### 6.1 Der Origin-Weg ist jetzt vermessen (vorher nur angenommen)
+
+`blaueblueten.de` geht **direkt** zum DO-Droplet, **kein Cloudflare im Pfad** (Zertifikat = Let's Encrypt
+`CN=blaueblueten.de` vom 11.08., **kein `cf-ray`**, kein `server`-Header, kein `/cdn-cgi/trace` — CF setzt
+`cf-ray` immer). Der 403 kommt also **vom Origin**, nicht vom Edge.
+
+**Der Block ist rein quell-IP-basiert:** voller Safari-/Chrome-User-Agent ändert nichts, HTTP→HTTPS-Redirect
+(`302`) funktioniert, erst der HTTPS-Request antwortet `403` mit `content-length: 0`.
+
+### 6.2 Mesh als Exit — funktioniert
+
+Temporär gebaut (Tabelle `meshtest` + `0.0.0.0/0` via `cf-mesh` + Regel nur auf `1.1.1.1/32`), dann gemessen:
+
+```
+/tool fetch url="http://1.1.1.1/cdn-cgi/trace" mode=http
+→ ip=104.28.207.39   warp=on   gateway=on   colo=VIE
+```
+
+Der Core kommt also über den Mesh-Tunnel als **Cloudflare-IP** heraus (vorher `90.146.33.177`).
+⚠️ **Merkregel: für `cdn-cgi/trace` `mode=http` nehmen, nicht `mode=https`** — über HTTPS liefert RouterOS nur
+den 69-Byte-Datei-Header (`# … by RouterOS`, `# software id =`), die Nutzdaten fehlen. Das sieht wie ein
+leerer Download aus, ist aber nur der falsche Fetch-Modus.
+
+### 6.3 KORREKTUR: der frühere „403 über Mesh" war ein Messfehler — der Weg trägt
+
+Der erste Test hatte **nur** die Regel `1.1.1.1/32 → meshtest` gesetzt und dann das Ziel gemessen. Für das
+Ziel griff die Regel nicht → der Request lief über die **Heim-IP** (`90.146.33.177`) raus. Der gemeldete
+`403` war also **403 über die Heim-IP**, nicht über den Mesh-Ausgang.
+
+Beweis (A/B in einem Durchgang, Regel `164.90.191.7/32 → egress-cannaleo`):
+
+```
+Regel aktiv     → https://blaueblueten.de/  → 200 (168 KiB)
+Regel deaktiv   → https://blaueblueten.de/  → 403 (fällt auf Heim-IP zurück)
+```
+
+Merke: `action=lookup-only-in-table` für Ziel A routet Ziel B **nicht** — nur messen, was tatsächlich
+umgeleitet ist. Dieselbe CF-IP (`104.28.207.39`) erreicht den Origin via WARP-Client und via `cf-mesh`.
+
+### 6.4 Rückbau (vollständig)
+
+Alle Objekte entfernt (Regel, Route, Tabelle, Testdateien). `/routing table print` = nur `main`,
+`/routing rule print` = leer, Default-Route wieder `90.146.33.1%vlan100`. `cf-mesh` unberührt und gesund
+(Handshake 4 s). Keine Drift.
+
+### 6.5 Was daraus folgt
+
+- **Der Core-Teil ist gelöst und wiederverwendbar:** `routing-table` + `0.0.0.0/0`-Route + `routing rule
+  dst-address=<ziel>/32 action=lookup-only-in-table` + `masquerade out-interface=<wg-x>`. Nur **ein** Ziel
+  betroffen, Rest unberührt. Genau so gebaut, verifiziert, zurückgebaut.
+- **Offen bleibt allein das Transportmittel.** CF scheidet aus (Ziel blockt CF). Der Rest des Vorschlags aus
+  §5 steht: eigener Ausgang über einen **externen WireGuard-Host**. Ein DO-VPS ist dabei der naheliegendste
+  Kandidat — der Miner fährt heute schon erfolgreich über eine DO-IP gegen genau diesen Origin.
+- 🔴 **Der Core hat heute keinen zweiten Ausgang.** Kein zweites WAN, kein zweites Gateway — jeder künftige
+  Egress braucht erst ein Interface, das ihn trägt.