Christoph Emsenhuber
3ae6399b93
Consumer-WARP über natives RouterOS-WG gebaut, verifiziert, zurückgebaut. Befund: Handshake rx=0, Cloudflare blockt inoffizielle WG-Clients (reserved/Client-ID + Abuse-Prevention). Weg: Dedicated Egress. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
54 lines
3.5 KiB
Markdown
54 lines
3.5 KiB
Markdown
# 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](https://github.com/ViRb3/wgcf/issues/542) ·
|
|
[#515](https://github.com/ViRb3/wgcf/issues/515) · [#158](https://github.com/ViRb3/wgcf/issues/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.
|