diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 79bd87f..55e1699 100644 --- a/docs/teilprojekte.md +++ b/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 | diff --git a/docs/warp-egress-native-crs326.md b/docs/warp-egress-native-crs326.md index b3ea3da..331bc4b 100644 --- a/docs/warp-egress-native-crs326.md +++ b/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=/32 action=lookup-only-in-table` + `masquerade out-interface=`. 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. diff --git a/nautobot/mikrotik_routeros.j2 b/nautobot/mikrotik_routeros.j2 index 9a4f078..8243cc6 100644 --- a/nautobot/mikrotik_routeros.j2 +++ b/nautobot/mikrotik_routeros.j2 @@ -396,6 +396,17 @@ /ip address add address=100.96.0.6 comment="TP16.1 Mesh-Overlay" interface=cf-mesh network=100.96.0.6 /ip route add comment="TP16.1 Mesh" disabled=no distance=1 dst-address=100.96.0.0/12 gateway=cf-mesh +# [10b] EGRESS (2026-09-26) — ziel-basierter Ausgang fuer 164.90.191.7/32 (cannaleo/DO-Origin). +# Der Origin blockt die Heim-IP 90.146.33.177 hart (403), Cloudflare aber nicht: WARP-Client +# und cf-mesh kommen beide durch (live gemessen, gleiche Ausgangs-IP 104.28.x). Genau EIN Ziel, +# ein Ausgang — kein Default-Route-Eingriff, restlicher Traffic unberuehrt. Kein extra NAT noetig: +# masquerade out-interface-list=WAN greift fuer cf-mesh NICHT, CF-NATet die LAN-Source im Mesh +# selbst (verifiziert von macmini 10.40.20.167). Cave User: kein Zugriffsmuster, das Heim-IP und +# diesen Ausgang gemeinsam gegen den Origin zeigt — der Ausgang ist ausschliesslich fuer cannaleo. +/routing table add fib name=egress-cannaleo +/ip route add comment="TP-EGRESS: cannaleo via cf-mesh" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=cf-mesh routing-table=egress-cannaleo +/routing rule add action=lookup-only-in-table comment="TP-EGRESS: cannaleo 164.90.191.7/32 via cf-mesh" disabled=no dst-address=164.90.191.7/32 table=egress-cannaleo + # [11] QoS — BEWUSST LEER (TP6 geschlossen 2026-08-23). # # Hier stand einen Tag lang eine CAKE-Queue. Sie ist entfernt, weil sie GEMESSEN