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

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.