Initial import from bf-network-r6.opencode — opencode migration

2026-08-26 12:44:21 +02:00
commit 5ee0716dda
297 changed files with 72324 additions and 0 deletions
--- a/docs/research/vpn-comparison.md
+++ b/docs/research/vpn-comparison.md
@@ -0,0 +1,102 @@
+# VPN-Vergleich: WireGuard (RouterOS↔FritzBox) vs. Cloudflare Zero Trust / WARP
+
+> Recherche-Report · Stand 2026-06-15 · Kontext: Multi-Site-Heimnetz **FM / BF / DW**, je eine **FritzBox**; Standort **BF** zusätzlich **MikroTik hAP ax²** (RouterOS 7.23.1), der künftig BF-Router wird. CF Zero Trust + WARP bereits im Einsatz (siehe DNS-Infra-Projekt).
+
+---
+
+## TL;DR / Empfehlung
+
+**Hybrid, kein Entweder-Oder.** Für ein Mesh über **drei FritzBox-Standorte**, von denen zwei (FM, DW) **nur eine FritzBox** haben, ist der saubere gemeinsame Nenner:
+
+- **Site-to-Site-Backbone via natives WireGuard auf den FritzBoxen** (FRITZ!OS ≥ 7.50), mit **BF als Hub** (MikroTik hAP ax² als WG-Server, da statisch erreichbar / als künftiger BF-Router ohnehin Endpoint). FM und DW sind WG-Clients zum Hub → Hub-&-Spoke-Mesh.
+- **Cloudflare WARP/Zero Trust bleibt für Remote-User-Zugriff** (Laptop/Handy von unterwegs → Heimnetze) und als Identitäts-/Access-Layer. Das tut es heute schon und ist dafür die bessere Lösung als ein klassisches Road-Warrior-WireGuard.
+
+**Warum nicht WARP für Site-to-Site?** WARP/WARP-Connector kann eine FritzBox **nicht direkt** ansprechen — es braucht **an jedem Standort einen Linux-Host hinter der FritzBox** (WARP-Connector / `cloudflared`). An reinen FritzBox-Standorten (FM, DW) ist dieser Host nicht vorhanden und müsste erst beschafft/betrieben werden. Das erhöht Betriebsaufwand und Hardware-Fußabdruck, während die FritzBox WireGuard **out-of-the-box** kann.
+
+**Wichtigste Einschränkung beim WG-Pfad:** mindestens **ein** Standort muss **öffentlich erreichbar** sein (kein CGNAT, idealerweise statisch oder DynDNS). Das wird der **Hub (BF/MikroTik)**. Liegt BF selbst hinter CGNAT, kippt die Empfehlung — dann ist der CF-/WARP-Connector-Pfad (der ausschließlich ausgehende Verbindungen nutzt) der robustere Backbone.
+
+---
+
+## 1. Kann WARP eine FritzBox direkt ansprechen?
+
+**Nein.** WARP (der Client) bzw. der **WARP-Connector** koppeln Netze **nicht** mit einer FritzBox-Gegenstelle, sondern mit Cloudflares Edge.
+
+- Der **WARP-Connector** ist Software (der Cloudflare-One-Client `warp-cli` im Headless-Modus bzw. `cloudflared`), die auf **einem Linux-Host** läuft und als **Subnet-Router** das gesamte hinterliegende LAN zu Cloudflare bringt. ([CF One Docs – WARP Connector](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/private-net/warp-connector/), [Site-to-Site](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/private-net/warp-connector/site-to-site/))
+- Damit ein **FritzBox-LAN/-Dienst** über CF erreichbar wird, muss also **hinter** der FritzBox ein Linux-Host stehen (Raspberry Pi, NUC, VM, Container), der den Connector betreibt. Die FritzBox selbst kann **weder** WARP-Connector **noch** `cloudflared` ausführen.
+- **OS-Anforderung:** WARP/Connector läuft auf **Linux (apt-/yum-basiert: Ubuntu, Debian, CentOS, RHEL)**, außerdem Windows/macOS für reine Clients — **nicht** auf FRITZ!OS. ([WARP-Client Docs](https://developers.cloudflare.com/warp-client/))
+- **Port-Footprint:** der Connector-Prozess (`cloudflared` MASQUE-Pfad) alloziert **~50.000 Ports** auf dem Host — also ein dediziertes Gerät, kein „nebenbei".
+
+**Konsequenz für FM/DW (nur FritzBox):** Ohne zusätzlichen Always-on-Linux-Host kein WARP-Site-to-Site. An BF wäre ein Linux-Host theoretisch vorhanden/möglich, aber die FritzBoxen in FM/DW bleiben das Problem.
+
+---
+
+## 2. WireGuard FritzBox ↔ MikroTik – Interop & Gotchas
+
+**Machbar und erprobt.** FRITZ!OS unterstützt WireGuard ab **7.50**, RouterOS v7 hat WireGuard nativ. Mehrere dokumentierte Real-World-Setups koppeln genau diese beiden. ([Bouni Blog 2026](https://blog.bouni.de/posts/2026/site-to-site-wireguard-vpn-between-fritzbox-and-mikrotik/), [Shaw-IoT Blog](https://blog.shaw-iot.co.uk/2023/04/wireguard-vpn-between-mikrotik-routeros.html), [MikroTik-Forum](https://forum.mikrotik.com/t/configuration-issue-between-fritz-box-wireguard-server-and-mikrotik-client/175777))
+
+### Rollenverteilung
+- **MikroTik = Server** (LISTEN auf z.B. UDP 51820), **FritzBox = Client**. Die FritzBox importiert eine WG-Config-Datei (`.conf`) unter **Internet → Freigaben → VPN (WireGuard)** und gibt dort den Endpoint des MikroTik an (IP **oder DynDNS-Hostname**).
+- Diese Richtung ist robust, weil der MikroTik der stabil erreichbare Hub ist und die FritzBox als Client persistent rauswählt.
+
+### Kritische Gotchas
+1. **Keine IP-Adresse auf dem WireGuard-Interface (MikroTik-Seite) setzen.** Wird dem WG-Interface eine Adresse zugewiesen, bricht das Routing zwischen den Sites. Adressierung/Routing nur über `AllowedIPs` + statische Routes. (Der häufigste Stolperstein in allen Anleitungen.)
+2. **`AllowedIPs` = Tunnelnetz + jeweilige LAN-CIDRs.** Beide Seiten müssen die LAN-Subnetze der Gegenstelle in `AllowedIPs` führen, sonst kein Cross-Site-Routing.
+3. **MTU.** FritzBox nutzt typ. **1412** (WireGuard + IPv6 + PPPoE-Overhead); WG-Default ist 1420. Bei PPPoE/IPv6-Pfaden MTU angleichen, sonst Fragmentierung/Hänger.
+4. **`PersistentKeepalive = 25`** auf der FritzBox-(Client-)Seite für NAT-Traversal/Handshake-Stabilität.
+5. **Firewall (MikroTik):** Input-Regel für UDP-Listen-Port + Forward-Regeln für den Cross-Site-Traffic; ggf. kein NAT zwischen den getunnelten Subnetzen.
+
+### NAT / Endpoint-Erreichbarkeit (der entscheidende Punkt)
+- WireGuard braucht **mindestens einen öffentlich erreichbaren Endpoint**. Ausgehende Verbindungen funktionieren auch hinter CGNAT, **eingehende nicht**. ([Firewalla-Community](https://help.firewalla.com/hc/en-us/community/posts/38610335671443-WireGuard-behind-CGNAT-5G-Connection-T-Mobile-5G-Business-Internet), [IPv64-Forum (DE)](https://v64.tech/t/wireguard-auf-fritzbox-per-ipv4-cgnat/749))
+- **Dynamische IP** ist kein Problem, **CGNAT schon.** Der Hub (BF/MikroTik) muss also eine **public IP** haben (statisch oder via **DynDNS/MyFRITZ**). Dynamische public IP → DynDNS-Hostname als Endpoint (FritzBox akzeptiert FQDN-Endpoints; in einem dokumentierten Fall kam der Handshake erst mit FQDN statt roher IP zustande).
+- **Wenn der Hub hinter CGNAT liegt:** Hub-&-Spoke über WireGuard ist dann **nicht** direkt machbar (keine Seite eingehend erreichbar). Optionen: ISP-Option „echte IPv4"/DS-Lite-Ausnahme, IPv6-only-Tunnel (nur wenn **alle** Sites stabiles IPv6 haben), oder Umstieg auf den **CF-/WARP-Connector-Pfad** (nur ausgehend → CGNAT-immun).
+
+### Kann der MikroTik-Hub den Container-Weg gehen statt nativem WG?
+Nicht empfehlenswert auf dem **hAP ax²**: 1 GB RAM, aber nur **128 MB Onboard-Flash und kein USB**. Container (cloudflared/WireGuard-Image) brauchen Netzwerk-Storage als Workaround — fragil. ([MikroTik-Forum: hAP ax2 storage & containers](https://forum.mikrotik.com/t/hap-ax2-storage-and-containers/166157)) → **Natives** RouterOS-WireGuard nutzen, nicht containerisieren.
+
+---
+
+## 3. Pro / Contra im Direktvergleich
+
+| Kriterium | (A) WireGuard FritzBox↔MikroTik (Hub=BF) | (B) Cloudflare Zero Trust / WARP(-Connector) |
+|---|---|---|
+| **Performance** | Direkter Tunnel, kein Umweg über Edge → niedrigste Latenz, voller LAN-Speed (CPU/MTU-limitiert). | Traffic läuft über Cloudflare-Edge (Hairpin) → Zusatz-Latenz; auf Free-Plan **Daten-Cap** (10 GB Free, danach 15 GB/User; Mehrverbrauch $1/GB). |
+| **Admin-Aufwand** | Einmalige WG-Config je Site; FritzBox-Import per `.conf`; keine zusätzliche HW an FM/DW. Gotchas (keine Interface-IP, MTU) müssen sitzen. | **Linux-Host je Site** nötig (Beschaffung + Betrieb + Updates), v.a. an reinen FritzBox-Standorten FM/DW. Zentrale Policy/Routes im CF-Dashboard. |
+| **NAT-Traversal** | Braucht **1 public Endpoint** (Hub). CGNAT am Hub = K.O. | **CGNAT-immun** — Connector baut nur **ausgehende** Verbindungen zur Edge auf. Stärke dieses Pfads. |
+| **Zuverlässigkeit** | Sehr hoch, solange Hub erreichbar; keine Cloud-Abhängigkeit. SPOF = Hub-Site. | Abhängig von Cloudflare-Verfügbarkeit + Linux-Host je Site (mehr bewegliche Teile). |
+| **Kosten** | 0 €, Hardware vorhanden (FritzBoxen + hAP ax²). | Free-Plan bis **50 User**, per-User-Modell, kein Bandbreiten-Preis — aber **Daten-Cap** + Bedarf an zusätzlicher Linux-HW/Strom je Site. ([CF ZT Plans](https://www.cloudflare.com/plans/zero-trust-services/)) |
+| **Observability** | RouterOS-Logs/Torch/Traffic-Monitor (gut, lokal). FritzBox: spärlich. Kein zentrales Dashboard. | Zentrales **CF Zero Trust Dashboard**, Logs, Device-Posture, Access-Policies, Audit. Klar überlegen. |
+| **Fit zum Bestand (CF One/WARP)** | Orthogonal — koexistiert problemlos mit CF-DNS-Filtering (CGPS) und WARP-Remote-Access. | Nutzt vorhandene CF-One-Tenant; konsistente Identität/Policy. Aber erzwingt HW-Ausbau an FritzBox-only-Sites. |
+| **Remote-User-Zugriff (unterwegs)** | WG-Road-Warrior je Site separat zu pflegen. | **Stärke von WARP** — ein Client, Identitäts-basiert, Split-Tunnel, Posture. Bereits live. |
+
+---
+
+## 4. Empfehlung für FM / BF / DW
+
+**Backbone = WireGuard, Remote-Access = WARP.** Konkret:
+
+1. **Site-to-Site-Mesh über natives WireGuard.**
+   - **Hub = BF / MikroTik hAP ax²** als WG-**Server** (nativ, kein Container). Setzt **public IP an BF** voraus (statisch oder DynDNS/MyFRITZ; **kein CGNAT**).
+   - **FM und DW** = FritzBox-WG-**Clients** zum BF-Hub (Hub-&-Spoke). Damit brauchen die reinen-FritzBox-Standorte **keinen** zusätzlichen Host.
+   - Gotchas beachten: keine IP aufs WG-Interface (MikroTik), `AllowedIPs` = Tunnelnetz + alle LAN-CIDRs, MTU 1412, `PersistentKeepalive=25`, MikroTik-Firewall Input/Forward.
+   - Optional FM↔DW direkt (full mesh) nachrüsten, sobald beide einen erreichbaren Endpoint haben — sonst läuft FM↔DW über den BF-Hub.
+
+2. **WARP / Zero Trust bleibt für Remote-User** (Laptop/Handy von außerhalb → Heimnetze) **und** als Identitäts-/Access-/Observability-Layer. Kein Umbau des bestehenden CF-One-Einsatzes nötig; ergänzt das WG-Backbone statt es zu ersetzen.
+
+3. **Trigger zum Umschwenken auf den CF-WARP-Connector-Pfad als Backbone:** Falls **BF (oder kein Standort) eine eingehend erreichbare public IP** hat (CGNAT/DS-Lite ohne Ausweg). Dann an jedem Standort einen kleinen Linux-Host (Pi o.ä.) mit WARP-Connector, weil dieser nur ausgehend verbindet und damit CGNAT-immun ist — zulasten von Zusatz-HW, Edge-Latenz und Daten-Cap.
+
+**Voraussetzung-Check vor Umsetzung:** WAN-Anbindung **jedes** Standorts prüfen (public vs. CGNAT/DS-Lite, statisch vs. dynamisch, IPv4/IPv6). Das entscheidet zwischen Pfad A (mind. Hub public) und Pfad B (CGNAT-tolerant).
+
+---
+
+## Quellen
+
+- [Bouni – Site-to-Site WireGuard FritzBox↔MikroTik (2026)](https://blog.bouni.de/posts/2026/site-to-site-wireguard-vpn-between-fritzbox-and-mikrotik/)
+- [Shaw-IoT – WireGuard MikroTik RouterOS v7 ↔ FRITZ!Box 7530](https://blog.shaw-iot.co.uk/2023/04/wireguard-vpn-between-mikrotik-routeros.html)
+- [MikroTik-Forum – FRITZ!Box WG-Server ↔ MikroTik Client](https://forum.mikrotik.com/t/configuration-issue-between-fritz-box-wireguard-server-and-mikrotik-client/175777)
+- [Cloudflare One – WARP Connector (Overview)](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/private-net/warp-connector/)
+- [Cloudflare One – WARP Connector Site-to-Site](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/private-net/warp-connector/site-to-site/)
+- [Cloudflare WARP-Client – unterstützte OS](https://developers.cloudflare.com/warp-client/)
+- [Cloudflare Zero Trust – Plans & Pricing](https://www.cloudflare.com/plans/zero-trust-services/)
+- [Firewalla-Community – WireGuard hinter CGNAT](https://help.firewalla.com/hc/en-us/community/posts/38610335671443-WireGuard-behind-CGNAT-5G-Connection-T-Mobile-5G-Business-Internet)
+- [IPv64-Forum (DE) – WireGuard auf FritzBox per IPv4-CGNAT](https://v64.tech/t/wireguard-auf-fritzbox-per-ipv4-cgnat/749)
+- [MikroTik-Forum – hAP ax2 Storage & Containers (128 MB Flash)](https://forum.mikrotik.com/t/hap-ax2-storage-and-containers/166157)