bf-infra/docs/warp-egress-native-crs326.md

WARP-Egress — nativer Consumer-WARP (WireGuard) auf dem crs326-core

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.

1. Kontext / Warum

• Cannaleo-Origin 164.90.191.7 (blaueblueten.de, DigitalOcean multi-tenant, ~400 Vhosts) blockt die Heim-IP 90.146.33.177 hart (leerer 403, live 2026-09-25).
• Scope (User-Vorgabe 2026-09-25): nicht der ganze Outbound, sondern genau eine Ziel-IP (164.90.191.7/32 — blaueblueten.de apex + www, beide identisch). Nur Privatbestellungen, Traffic überschaubar gering.
• Terpenfinder wird NICHT über diesen Weg in Betrieb genommen (eigene, saubere Lösung — siehe §5).

2. Was gebaut wurde (2026-09-26, live)

1. Consumer-WARP-Key per wgcf registriert (ViRb3 v2.3.0, Wegwerf-Konto via api.cloudflareclient.com). → mcp/cloudflare/.env (CF_WARP_CLIENT_PRIVKEY, gitignored) + ~/.secrets/wgcf-client/ (account + profil).
2. Auf crs326-core (WG-Zeilen via sshpass -e, Rest per MikroMCP/ssh):
   • /interface wireguard add name=warpout mtu=1280 private-key=… comment="WARP Egress (privat)"
   • Peer warp-cf-pop: public-key bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=, endpoint engage.cloudflareclient.com:2408, allowed-address=0.0.0.0/0, persistent-keepalive=25s
   • /ip address add 172.16.0.2/32 interface=warpout
   • /routing table add name=warpout fib + /ip route add 0.0.0.0/0 gateway=warpout routing-table=warpout
   • /routing rule add dst-address=164.90.191.7/32 action=lookup-only-in-table table=warpout
   • NAT masquerade out-interface=warpout + forward accept out-interface=warpout
3. Verifiziert: Key korrekt (abgeleiteter Public-Key == Router-Public-Key HTFM3gj3FyT0EjWkG+2LLmvtxaFz1kH/P1iDwM0HswI=), Konto „Active" (wgcf status).

3. Befund: Handshake schlägt fehl

• Peer warp-cf-pop: rx=0, kein last-handshake — Cloudflare antwortet nie auf den WG-Handshake, egal welcher Endpoint (162.159.192.1 / .193.2 / .193.5).
• Ursache (recherchiert): Cloudflare blockt inoffizielle WireGuard-Clients für Consumer-WARP. Der offizielle Client setzt ein spezielles Handshake-Feld (reserved/Client-ID, z. B. b91981), das RouterOS (und jedes plain-wgcf-Profil) nicht setzt; dazu Abuse-Prevention. Der Mesh-Connector cf-mesh läuft nur, weil das ein anderes Produkt ist (Zero Trust, nicht Consumer).
• Quellen: ViRb3/wgcf Issue #542 · #515 · #158.

4. Abbau (2026-09-26)

• Alle 8 Objekte entfernt (Routing-Regel, Route, Tabelle, NAT, Firewall, Adresse, Peer, Interface). Core wieder im Ursprungszustand — keine Drift, Golden-Config-Compliance unverändert.
• Backup pre-warp-egress-20260925.backup liegt auf dem Core (vor dem Versuch, TP22-Regel).
• CF_WARP_CLIENT_PRIVKEY bleibt in mcp/cloudflare/.env (nutzlos, da Client geblockt; kann bei Bedarf entfernt werden).

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.