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/dns-registration-options.md
+++ b/docs/research/dns-registration-options.md
@@ -0,0 +1,107 @@
+# Lokale DNS-Auflösung — Research & Entscheidung (Stand 2026-06-15)
+
+> **Kontext:** TP4-Split = **DHCP auf RouterOS**, DNS separat. Technitium verworfen (keine GUI-Appliance).
+> Zusätzliche **harte Vorgabe (User):** *Container nur auf den Routern oder gar nicht — keine unnötigen
+> Abhängigkeiten von fremder Hardware (NAS/pve) für Kern-Netzdienste.*
+>
+> **Entscheidung: RouterOS-nativer DNS + nur statische Records.** Keine DHCP→DNS-Auto-Registrierung, kein Script,
+> kein externer DNS-Server. Infra-Hosts werden als statische DNS-Einträge gepflegt (haben ohnehin DHCP-Reservierungen);
+> dynamische Clients (Handys/IoT) sind bewusst **nicht** per Name erreichbar.
+
+---
+
+## 1. Kann RouterOS das nativ? — Nein (und das ist ein bekannter Gap)
+
+Der RouterOS-DNS ist ein **Caching-Forwarder + manuelle statische Einträge** — es gibt **keine** Verbindung zwischen
+DHCP-Leases und DNS, keinen „Lease-Hostnames registrieren"-Schalter. MikroTiks Forum-Antwort dazu war seit Jahren:
+„nimm ein Lease-Script".
+
+Die billige Konkurrenz macht's besser: alles **dnsmasq**-basierte (OpenWrt, pfSense/OPNsense, dd-wrt) und sogar die
+FritzBox liefern lokale Namensauflösung aus DHCP **out-of-the-box** — dnsmasq *ist* DHCP+DNS in einem Prozess.
+**Warum MikroTik nicht:** RouterOS zielt auf ISP/Enterprise-Routing, wo der Router nicht der autoritative LAN-DNS sein
+soll. Die Heim-Bequemlichkeit wurde nie gebaut. → Der „Flickwerk"-Eindruck ist berechtigt.
+
+## 2. Warum die „sauberen" Wege hier ausscheiden
+
+| Weg | Warum verworfen |
+|---|---|
+| **Technitium / AdGuard / dnsmasq auf NAS/pve** | GUI-Appliance + **fremde HW-Abhängigkeit** → gegen User-Vorgabe |
+| **Variante A: RouterOS-DHCP + RFC 2136 → BIND/PowerDNS** (standardnah) | BIND muss *irgendwo* laufen; einziger erlaubter Ort wäre der hAP selbst → **nicht praktikabel** (s.u.). Der saubere Standard verlangt einen Host, den die Vorgabe verbietet. |
+| **Lease-Script-Hybrid (eworm dhcp-to-dns)** | Self-contained, aber genau das **Script-Flickwerk**, das vermieden werden soll; MAC-basierte Records, Reverse-DNS unzuverlässig, Renewal-Lücke ([Ctrl blog](https://www.ctrl.blog/entry/routeros-dhcp-lease-script.html)) |
+| **DNS-Container auf dem hAP** | siehe HW-Check unten — gegen MikroTik-Empfehlung, Flash-Wear, kein USB |
+
+### HW-Check ap1 (live, 2026-06-15)
+| | hAP ax² (ap1) |
+|---|---|
+| Flash gesamt / **frei** | 128 MB / **~90 MB** |
+| RAM frei | 680 MB |
+| USB | **keins** |
+
+90 MB frei würden ein winziges Image *theoretisch* fassen, aber: MikroTik empfiehlt für Container **externen Speicher**
+(USB/NVMe — fehlt), das Image konkurriert mit Config/Logs auf demselben Flash, und **Flash-Write-Wear** durch einen
+dauernd schreibenden DNS ist real. → Container-DNS auf dem hAP bleibt **nicht praktikabel** (bestätigt CLAUDE.md/TP-R).
+
+→ **Fazit:** Auf dieser Hardware sind „sauberer Standard-DNS" **und** „kein Flickwerk" **und** „keine Fremd-Abhängigkeit"
+nicht gleichzeitig erreichbar. Da die Abhängigkeits-Vorgabe gewinnt, bleibt nur **router-nativ** — und ohne Script heißt
+das: **statische Records**.
+
+## 3. Entscheidung: RouterOS-nativer DNS, nur statische Einträge
+
+**Schlüsseleinsicht:** Auto-Registrierung braucht man fast nur für die dynamische Klientel (Handys/IoT) — und die
+spricht man selten per Name an. Alles, was man wirklich per Name erreicht (NAS, HA, pve, Drucker, AppleTV), hat ohnehin
+eine **statische DHCP-Reservierung**. Diese Hosts als statische DNS-Einträge zu pflegen ist **dieselbe Arbeit** wie die
+Reservierung — kein Mehraufwand, kein Script, keine Abhängigkeit.
+
+**Umsetzung (in TP4):**
+- RouterOS-DNS aktiv (`/ip dns`), als Resolver für alle VLANs (per DHCP-Option 6 verteilt).
+- Statische Forward-Einträge je Infra-Host: `/ip dns static add name=nas.bf.lan address=10.40.20.10` usw.
+  → gemeinsam mit der DHCP-Reservierung pflegen (eine Stelle, ein Vorgang).
+- Einheitliche lokale Domain `bf.lan`.
+- **Filtering/DNSSEC** standardnah über den **Upstream**: DoH zu Cloudflare/NextDNS (TP3) — filtert + validiert,
+  ohne lokalen Server. Adblock damit am Upstream, nicht lokal.
+- Dynamische Clients: bewusst **keine** Namensauflösung. Falls später doch nötig → Re-Eval (Abschnitt 4).
+- **HA (TP9):** zweiter RouterOS-Resolver auf ap2; statische Einträge müssen auf beiden gepflegt werden
+  (gleiches „identische-Config"-Thema wie DHCP/Firewall).
+
+## 4. Re-Evaluation nur, falls sich eine Randbedingung ändert
+
+- **Auto-Reg dynamischer Clients wird doch gebraucht** → entweder Lease-Script-Hybrid (eworm) akzeptieren
+  *oder* HW-Vorgabe lockern.
+- **HW-Vorgabe gelockert / Router mit USB+Storage** → dann **Variante A** (RouterOS-DHCP + RFC 2136 → BIND9) ist der
+  saubere Standard-Weg. Details/Vergleich im Anhang.
+
+---
+
+## Anhang — Variante A & PowerDNS-vs-BIND (parkiert, falls HW-Vorgabe fällt)
+
+**Variante A:** RouterOS-DHCP bleibt am Gateway, pusht Leases per nativem
+[`/tool dns-update`](https://help.mikrotik.com/docs/spaces/ROS/pages/139067407/Dynamic+DNS) (RFC 2136/3007,
+hmac-md5-TSIG, Uhr-Drift max. 5 min) an einen autoritativen DNS. Trigger = Lease-Script + Scheduler-Reconcile.
+
+Benchmark ([computingforgeeks](https://computingforgeeks.com/bind-vs-dnsmasq-vs-powerdns-vs-unbound/), gecacht):
+
+| Metrik | BIND 9.18 | PowerDNS 4.9 |
+|---|---|---|
+| Queries/s | 47.613 | 67.712 |
+| Latenz Ø | 0,29 ms | 0,95 ms |
+| RAM idle / Last | 38 / 45 MB | 24 / 29 MB |
+
+Für ein Heimnetz (<100 QPS) ist Performance irrelevant. Auswahl:
+
+| Kriterium | BIND9 | PowerDNS |
+|---|---|---|
+| Architektur | 1 Prozess = autoritativ + recursive + DNSSEC-Validate + RPZ-Adblock | Auth + separater Recursor + Backend |
+| RFC 2136 / RouterOS | Referenz; MikroTik-Doku: „works only with the BIND server" | implementiert RFC2136, aber nicht das RouterOS-Testziel; [Regressions #12332](https://github.com/PowerDNS/pdns/issues/12332) |
+| Adblock | RPZ nativ (Technitium-Ersatz) | via Recursor-Lua |
+| Moving parts | 1 Daemon deckt alles | mehr Teile, aber API/DB/Web-UI |
+
+→ Falls Variante A je gebaut wird: **BIND9** (gegen RouterOS getestet, ein Prozess deckt alles ab). PowerDNS nur bei
+Bedarf an API/DB-Backend. **Kea + DDNS → BIND** ([Doku](https://kea.readthedocs.io/en/latest/arm/ddns.html)) wäre der
+Lehrbuch-Weg, falls DHCP ohnehin auf einen Host auslagert.
+
+## Quellen
+- [Don't use RouterOS DHCP lease scripts to manage DNS — Ctrl blog](https://www.ctrl.blog/entry/routeros-dhcp-lease-script.html)
+- [eworm-de/routeros-scripts: dhcp-to-dns](https://github.com/eworm-de/routeros-scripts/blob/main/doc/dhcp-to-dns.md)
+- [MikroTik Dynamic DNS (`/tool dns-update`, RFC 2136/3007)](https://help.mikrotik.com/docs/spaces/ROS/pages/139067407/Dynamic+DNS)
+- [Kea DHCP-DDNS (D2)](https://kea.readthedocs.io/en/latest/arm/ddns.html) · [PowerDNS RFC2136](https://docs.powerdns.com/authoritative/dnsupdate.html)
+- [BIND vs dnsmasq vs PowerDNS vs Unbound — Benchmark](https://computingforgeeks.com/bind-vs-dnsmasq-vs-powerdns-vs-unbound/)
--- a/docs/research/routeros-capabilities.md
+++ b/docs/research/routeros-capabilities.md
@@ -0,0 +1,203 @@
+# RouterOS-Capabilities für hAP ax² (BF-Netz, RouterOS 7.23.1)
+
+> Recherche-Report — Stand 2026-06-15
+> Ziel: Verstehen, was RouterOS 7.23 für ein Prosumer-Multi-VLAN-Heimnetz kann, und empfehlen, was bei **knappem CPU/RAM** passt.
+
+## 0. Hardware-Fakten (live von ap1 abgefragt)
+
+| Eigenschaft | Wert | Bedeutung |
+|---|---|---|
+| Modell | hAP ax² (`C52iG-5HaxD2HaxD`) | ARM64, IPQ-6000 |
+| RouterOS | **7.23.1 stable** (build 2026-06-02) | aktuell |
+| CPU | ARM64, **864 MHz, 4 Cores** | solide, aber kein Kraftpaket |
+| RAM | **1 GB total** — im Leerlauf ~681 MB frei | **der echte Engpass** |
+| Flash | 128 MB total, ~94 MB frei | begrenzt → Container nur klein |
+| Lizenz | Level 4 | reicht für alles hier Relevante |
+
+**Konsequenz für alle Empfehlungen:** RAM ist die harte Grenze. Jeder Container kostet 10–100 MB. Mehr als 2–3 kleine Container parallel + WLAN + Routing wird eng. CPU-intensive Dinge (TLS-Terminierung, Web-Proxy unter Last, VPN-Durchsatz) treffen die 4 schwachen Cores. Faustregel: **native Pakete bevorzugen, Container sparsam, alles Schwere auf die NAS auslagern.**
+
+**Installierte vs. verfügbare Pakete (live):** Aktiv sind nur `routeros` + `wifi-qcom`. Als *available/disabled* liegen bereits auf dem Gerät: `container`, `calea`, `dude`, `iot` (MQTT/Modbus), `gps` (LoRa), `openflow`, `user-manager`, `zerotier`, `wireless`, `tr069-client`, `ups`, `rose-storage`. Aktivieren = `/system package enable …` + Reboot, kein Download nötig.
+
+---
+
+## 1. Gateway-/Router-HA via VRRP
+
+**Userfrage: „Was, wenn ap1 ausfällt?"**
+
+**(a) Was es macht:** VRRP (Virtual Router Redundancy Protocol) lässt zwei hAP eine gemeinsame **virtuelle Gateway-IP je VLAN** teilen. Der Master mit höherer Priority hält die virtuelle IP; fällt er aus, übernimmt der Backup binnen ~3× advertisement-interval (Default 1 s → ~3 s Umschaltung). Clients behalten dasselbe Default-Gateway.
+
+**(b) Verfügbarkeit:** **Nativ** in RouterOS (`/interface/vrrp`), kein Paket. VRRPv3 für IPv4+IPv6.
+
+**(c) Nutzen:** Echtes Gateway-Failover je VLAN. Mit zwei VRRP-Instanzen pro VLAN (kreuzweise Master/Backup) sogar Load-Sharing möglich.
+
+**(d) CPU/RAM-Kosten:** Vernachlässigbar (nur kleine Multicast-Advertisements). Kein Problem.
+
+**(e) Empfehlung: VIELLEICHT (für VLANs mit echtem HA-Bedarf, z. B. MAIN 10 / INFRA 20).** VRRP-Last ist gratis, aber der Betriebsaufwand für *echtes* Failover ist hoch — siehe Gotchas. Für ein Heimnetz reicht oft simpler: zweiter hAP als kalter Ersatz + Config-Backup.
+
+### Config-Skizze (kreuzweises Master/Backup, pro VLAN)
+
+```rsc
+# ap1 — Master für VLAN10, Backup für VLAN20
+/interface vrrp add name=vrrp-vlan10 interface=vlan10 vrid=10 priority=200 version=3
+/interface vrrp add name=vrrp-vlan20 interface=vlan20 vrid=20 priority=100 version=3
+/ip address add address=10.40.41.1/24 interface=vrrp-vlan10   ;# virtuelle GW-IP
+/ip address add address=10.40.42.1/24 interface=vrrp-vlan20
+
+# ap2 — gespiegelt: Backup für VLAN10, Master für VLAN20
+/interface vrrp add name=vrrp-vlan10 interface=vlan10 vrid=10 priority=100 version=3
+/interface vrrp add name=vrrp-vlan20 interface=vlan20 vrid=20 priority=200 version=3
+/ip address add address=10.40.41.1/24 interface=vrrp-vlan10
+/ip address add address=10.40.42.1/24 interface=vrrp-vlan20
+```
+
+### Gotchas (wichtig!)
+
+- **RouterOS kann NICHT „Owner" sein** → die virtuelle IP darf nicht gleichzeitig die echte Interface-IP eines Routers sein. Jeder Router braucht zusätzlich eine eigene reale IP pro VLAN (z. B. .2 / .3), die virtuelle (.1) liegt auf dem VRRP-Interface.
+- **Die VRRP-IP muss auf Master UND Backup identisch konfiguriert sein**, sonst werden Advertisements verworfen.
+- **VRRP umfasst nur die IP/Routing-Ebene — NICHT den Rest.** DHCP-Server, Firewall-/NAT-Regeln, DNS, Routen müssen auf **beiden** Routern identisch gepflegt werden, sonst ist nach Failover „Gateway up, aber Internet/DHCP tot". Das ist der eigentliche Betriebsaufwand. Tipp: DHCP-Server auf beiden mit identischem Pool/Gateway, oder DHCP-Failover-Lease-Sync vermeiden (Split-Pool).
+- Advertisement-interval **nicht unter 1 s** → sonst Flapping.
+- WAN-Seite: Failover des Internet-Uplinks ist ein *separates* Problem (siehe §10 Multi-WAN), VRRP löst nur das LAN-Gateway.
+- Quellen: [VRRP (help.mikrotik.com)](https://help.mikrotik.com/docs/spaces/ROS/pages/81362945/VRRP), [VRRP Configuration Examples](https://help.mikrotik.com/docs/spaces/ROS/pages/128221211/VRRP+Configuration+Examples)
+
+---
+
+## 2. WLAN-Mesh vs. Wired Backhaul
+
+**Ausgangslage:** Beide APs haben **verdrahtete Trunk-Uplinks** (alle VLANs).
+
+**(a)/(c) Optionen:**
+
+| Ansatz | Was | Für uns |
+|---|---|---|
+| **Wired backhaul + CAPsMAN** | Beide APs per Kabel am Trunk, gleicher Bridge/VLAN; zentrale WLAN-Config via CAPsMAN-Controller; APs broadcasten dieselben SSIDs mit 802.11r/k/v-Roaming | **Empfohlen.** Voller Speed, kein Funk-Tribut, nahtloses Roaming |
+| **WLAN-Mesh (WDS / wireless station-backhaul)** | Ein AP funkt zum anderen als Backhaul | Nur sinnvoll, wenn *kein* Kabel da wäre — ist es aber. Halbiert Funk-Durchsatz, mehr Latenz |
+
+**(b) Verfügbarkeit:** CAPsMAN ist nativ im `wifi-qcom`-Paket (ROS7 „WiFi", `/interface/wifi/capsman`). Ein hAP kann gleichzeitig CAP **und** CAPsMAN-Controller sein (kein extra Gerät nötig). 802.11r/k/v Roaming + Steering nativ.
+
+**(d) CPU/RAM:** CAPsMAN-Controller für 2 APs ist trivial-leicht. WLAN-Mesh kostet mehr (zwei Radios busy).
+
+**(e) Empfehlung: WIRED BACKHAUL + CAPsMAN nutzen, Mesh WEGLASSEN.** Kabel ist da → keinen Funk-Backhaul-Nachteil einkaufen.
+
+### Loop-Risiko über Router/LAN — wichtig
+
+Wenn **beide** APs mit allen VLAN-Trunks am selben L2-Netz hängen und zusätzlich die WLAN-Bridges dieselben Broadcast-Domains überbrücken, kann ein **L2-Loop** entstehen (Trunk-A ↔ Switch ↔ Trunk-B ↔ über AP-Bridge zurück). Gegenmittel:
+- **RSTP/MSTP auf den Bridges aktiv lassen** (`protocol-mode=rstp`) — fängt versehentliche Loops ab.
+- Sauberes Bridge-VLAN-Filtering; nur der Trunk-Port ist Tagged-Member, kein Doppelpfad.
+- **Kein gleichzeitiges WDS/Mesh, während Wired-Backhaul aktiv ist** — das ist der klassische Loop-Erzeuger (zwei parallele Pfade zwischen denselben APs). Genau deshalb: entweder/oder, nicht beides.
+- Quellen: [WiFi / CAPsMAN](https://help.mikrotik.com/docs/spaces/ROS/pages/224559120/WiFi), [Forum: mesh with wifi ax](https://forum.mikrotik.com/t/mesh-with-wifi-routeros-ax-wi-fi-6/181917)
+
+---
+
+## 3. Access-Control / Identity (RADIUS, 802.1X, EAP-TLS, dyn. VLAN)
+
+**(a) Was es macht:** WPA2/WPA3-**Enterprise** (802.1X) authentifiziert *jeden User/jedes Gerät* einzeln gegen einen RADIUS-Server — statt eines geteilten PSK. **EAP-TLS** = Client-Zertifikat pro User/Gerät (kein Passwort). Der RADIUS kann pro Auth eine **dynamische VLAN-Zuweisung** zurückgeben (Tunnel-Type=VLAN, Tunnel-Medium-Type=802, **Tunnel-Private-Group-ID=<VLAN-ID>**) → Gerät landet automatisch im richtigen VLAN, egal an welcher SSID/welchem Port.
+
+**(b) Verfügbarkeit auf 7.23:**
+- **User-Manager v5** = eingebauter RADIUS-Server (Paket `user-manager`, liegt bereits available auf dem Gerät). Kann EAP-TLS, EAP-TTLS, PEAP. Offizielles Howto: „Enterprise wireless security with User Manager v5".
+- WiFi-Interfaces: `authentication-types=wpa2-eap,wpa3-eap` nativ.
+- **Dot1X** (Paket-frei, nativ) für **wired 802.1X** an Switch-Ports mit dynamischer VLAN-Zuweisung — ABER: dyn. VLAN im Switch-Chip nur auf Geräten mit HW-VLAN-Filtering; **nicht** auf SMIPS. Der hAP ax² ist kein SMIPS, dyn. VLAN am Port ist hier grundsätzlich möglich — in der Praxis am Heim-Switch aber eher Spielerei.
+
+**LDAP-Backend (User hat openldap-Container):** **User-Manager v5 spricht KEIN LDAP.** Er hat eine eigene lokale User-DB. Will man die openldap als Wahrheitsquelle, führt der Weg über **FreeRADIUS** (mit `ldap`-Modul) — das läuft *nicht* sinnvoll als 90-MB-Container auf dem hAP, sondern auf der NAS.
+
+**(c) Nutzen:** Pro-Gerät-Identität, Zertifikats-Login (kein WLAN-Passwort-Teilen), automatische VLAN-Einsortierung (IoT→30, Gäste→90 etc.). Stark für ein segmentiertes Netz.
+
+**(d) CPU/RAM:** User-Manager-Paket ist klein (~344 KB Code), die Last entsteht bei EAP-Handshakes (TLS-Krypto). Für ein Heimnetz mit Dutzenden Geräten ist das auf dem hAP **vertretbar**, aber RAM-Budget im Auge behalten.
+
+**(e) Empfehlung:**
+- **RADIUS-Server: FreeRADIUS auf der NAS = beste Option** (LDAP-Anbindung an openldap, robust, kein hAP-RAM-Verbrauch, überlebt AP-Reboots). hAP-WLAN zeigt nur auf die NAS-RADIUS-IP. → **NUTZEN (NAS).**
+- **User-Manager v5 auf dem Router = VIELLEICHT**, als einfache/standalone Alternative *ohne* LDAP, wenn man keine NAS-Abhängigkeit will. Pragmatisch und in 1 h aufgesetzt, aber Userverwaltung getrennt von openldap.
+- **EAP-TLS pro Gerät: NUTZEN für stationäre/eigene Geräte**, aber Zertifikats-Rollout (CRL, Enrollment) ist Pflege-Aufwand → für Gäste/fremde Geräte lieber PEAP (User+Passwort) oder simpler WPA2/3-PSK je VLAN-SSID.
+- **Einfachste administrierbare Option für daheim:** pro VLAN eine eigene SSID mit eigenem WPA3-PSK. Enterprise/802.1X nur dort, wo Pro-Gerät-Identität wirklich gebraucht wird.
+- Quellen: [Enterprise wireless security w/ User Manager v5](https://help.mikrotik.com/docs/spaces/ROS/pages/92635137/), [User Manager](https://help.mikrotik.com/docs/spaces/ROS/pages/2555940/User+Manager), [Dot1X](https://help.mikrotik.com/docs/spaces/ROS/pages/328090/Dot1X), [multiduplikator/mikrotik_EAP (GitHub, EAP-TLS+CRL+WPA3)](https://github.com/multiduplikator/mikrotik_EAP)
+
+---
+
+## 4. Schlagwortliste (Schnellbewertung)
+
+| Thema | Was | Verfügbar 7.23 | Nutzen / CPU-RAM | Empfehlung |
+|---|---|---|---|---|
+| **RoMON** | L2-Management-Overlay (Router ohne IP per MAC erreichen) | Nativ | Quasi gratis | **NUTZEN** — bequemes Management beider APs auch ohne IP, Lifesaver bei Fehlkonfig |
+| **IPv6 (intern)** | SLAAC/DHCPv6, ND, Firewall | Nativ | Gering | **NUTZEN** — IPv6-Firewall nicht vergessen (Default offen!) |
+| **IPv6 (extern, 3 Standorte)** | DHCPv6-**PD** (Prefix Delegation), pro Standort /56 o. /60 → Sub-Prefixe je VLAN | Nativ (`/ipv6 dhcp-client … pool`, `/ipv6 pool`) | Gering | **NUTZEN, falls ISP IPv6+PD liefert.** Pro Standort eigener Präfix; FritzBoxen FM/BF/DW als CPE können PD weiterreichen — Topologie klären |
+| **LoRa** | LoRaWAN-Gateway-Funktion | Paket `gps`/`lora` — aber **hAP ax² hat KEINE LoRa-Hardware** | – | **WEGLASSEN** — kein Funkmodul vorhanden |
+| **MQTT** | IoT-Paket: MQTT-Publish aus Scripts/Scheduler | Paket `iot` (available) | Klein | **VIELLEICHT** — nett für „Router meldet Status an HA", aber HA/NAS macht das besser. Optional |
+| **SNMP** | Monitoring-Agent (CPU, RAM, Traffic, IF) | Nativ | Gering | **NUTZEN** — Basis fürs Monitoring (siehe icinga). Read-only Community + FW-Regel |
+| **Email settings** | SMTP-Versand aus Scripts (`/tool e-mail`) | Nativ | Gering | **NUTZEN** — Alerts (Netwatch, Failover) per Mail |
+| **NTP server** | Zeit-Server fürs LAN | Nativ | Gering | **VIELLEICHT** — als interner NTP für IoT/MGMT-VLAN sinnvoll; sonst NTP-Client reicht |
+| **ZeroTier** | P2P-Mesh-VPN | Paket `zerotier` (ARM, available) | Spürbar: bis ~60 % CPU bei Last, RAM-Footprint | **WEGLASSEN/VIELLEICHT** — funktioniert, aber CPU-hungrig auf dem hAP. Für Remote-Zugriff lieber Back-to-Home/WireGuard (§unten) |
+| **Cloudflare One / WARP** | CF Zero Trust Tunnel | **Kein natives Paket**; nur als `cloudflared`-Container | Container-RAM + CPU; macvlan-Konflikte (siehe DNS-Projekt-Notizen) | **WEGLASSEN auf dem Router** — CF-ZT gehört auf NAS/dedizierten Host, nicht auf den RAM-knappen AP |
+| **Load-Balancing / Failover (Multi-WAN)** | PCC + recursive routing / Netwatch | Nativ | Gering–mittel | **NUTZEN bei >1 WAN** — siehe §10 |
+| **OpenFlow** | SDN-Controller-Steuerung | Paket `openflow` (available) | – | **WEGLASSEN** — kein SDN-Controller im Heimnetz, sinnlos |
+| **User-Manager** | siehe §3 | Paket (available) | Klein–mittel | **VIELLEICHT** — RADIUS standalone ohne LDAP |
+| **CALEA** | Lawful-Intercept (behördl. Mitschnitt) | Paket `calea` (available) | – | **WEGLASSEN** — reines Compliance-Feature, irrelevant |
+| **icinga / check_routeros (Monitoring)** | Icinga/Nagios-Plugin via API/SNMP | Extern (auf Monitoring-Host) | 0 am Router | **NUTZEN** — `DinoTools/monitoring-check_routeros` gegen SNMP/API; CPU/RAM/IF/Temp/WLAN |
+| **spectral-scan** | Funk-Spektrum-Analyse (Störer-Suche) | Nativ im WiFi-Tool (`/interface/wifi spectral-scan`) | Kurzzeitig, on-demand | **NUTZEN (ad-hoc)** — super zur Kanalwahl/Störer-Diagnose, läuft nur bei Bedarf |
+
+Quellen u. a.: [ZeroTier](https://help.mikrotik.com/docs/spaces/ROS/pages/83755083/ZeroTier), [SNMP](https://help.mikrotik.com/docs/spaces/ROS/pages/8978519/SNMP), [RoMON](https://help.mikrotik.com/docs/spaces/ROS/pages/8978569/RoMON), [check_routeros (GitHub)](https://github.com/DinoTools/monitoring-check_routeros), [Load Balancing](https://help.mikrotik.com/docs/spaces/ROS/pages/4390920/Load+Balancing)
+
+---
+
+## 5. Reverse Proxy — Erwartung „nein" muss korrigiert werden
+
+**Bisherige Erwartung: RouterOS hat keinen Reverse Proxy. → Stimmt für ROS ≤ 7.21, aber NICHT mehr für 7.22+.**
+
+- RouterOS hatte lange nur einen **Forward/Transparent-Web-Proxy** (`/ip proxy`, deprecated, Caching) — das ist KEIN Reverse Proxy.
+- **Neu seit 7.22:** nativer **Reverse Proxy** unter `/ip/reverse-proxy`. Kann: HTTPS-Terminierung mit **ACME/Let's Encrypt**, **SNI-basiertes Routing** mehrerer Hostnames auf interne IPv4-Backends:Port, setzt `X-Forwarded-For`/`-Proto`. Da die APs auf **7.23.1** laufen, ist das **vorhanden**.
+
+**Kann es nginx-proxy-manager ersetzen?** Für simple Fälle ja, **aber nicht voll:**
+- ❌ Kein WebSocket, kein gRPC, keine Sticky Sessions, kein WAF, kein Auth-Layer, keine Log/Header-Manipulation, **nur IPv4-Backends**.
+- ⚠️ **TLS läuft auf der Router-CPU** → auf hAP/hEX kann Last die CPU auf 100 % treiben.
+
+**(e) Empfehlung: WEGLASSEN als NPM-Ersatz auf dem hAP.** NGINX Proxy Manager auf der NAS behalten (WebSocket/Backend-Vielfalt/RAM). Den nativen Reverse-Proxy höchstens für **1–2 triviale interne HTTPS-Dienste** nutzen, wenn man die NAS gerade nicht einbinden will. Wichtigste Korrektur: „RouterOS hat keinen Reverse Proxy" ist seit 7.22 **falsch** — es hat einen, nur einen schlanken.
+- Quellen: [Native Reverse Proxy 7.22 Guide (bigmike.help)](https://bigmike.help/en/devops/native-reverse-proxy-in-mikrotik-routeros-7-22-complete-setup-guide/), [Proxy (help.mikrotik.com)](https://help.mikrotik.com/docs/spaces/ROS/pages/132350000/Proxy)
+
+---
+
+## 6. mDNS-Repeater (7.16+) + Container-Reflector — bestätigt
+
+- **Bestätigt:** Seit **7.16** ist ein **mDNS-Repeater nativ eingebaut**: `/ip/dns/set mdns-repeat-ifaces=bridge,vlan-iot,vlan-main`. Relayed mDNS (`.local`, AirPlay/Chromecast/Discovery, HomeKit-Bonjour) **zwischen ausgewählten VLANs** — genau das, was man fürs IoT/MAIN-Cross-Discovery braucht. **Kostet quasi nichts.** → **NUTZEN.**
+- **Container-Reflector** (forum: „Reflector — cross-VLAN casting mDNS+SSDP+DIAL", **<10 MB RAM**): nötig nur, wenn man **zusätzlich SSDP/DIAL** (DLNA, manche Smart-TVs) reflektieren muss, was der native mDNS-Repeater NICHT abdeckt. → **VIELLEICHT**, nur wenn SSDP-Geräte zicken; sonst spart man sich den Container.
+- Quellen: [mikrotikonlineclub v7.16](https://mikrotikonlineclub.com/2024/10/03/whats-up-mikrotik-v7-16/), [Reflector-Container (Forum)](https://forum.mikrotik.com/t/reflector-cross-vlan-casting-mdns-ssdp-dial-as-a-routeros-container-10-mb-ram/271098), [mag1024/mikrotik-docker-mdns-repeater](https://github.com/mag1024/mikrotik-docker-mdns-repeater)
+
+---
+
+## 7–10 hier zusammengefasst: 5 nicht-offensichtliche Features für ein CPU/RAM-knappes Setup
+
+Diese geben viel Nutzen pro Byte RAM — alle **nativ, kein Container, vernachlässigbare Last:**
+
+1. **Netwatch** (`/tool netwatch`) — pingt Hosts/Gateways, triggert Scripts. Damit baut man **WAN-Failover, Service-Watchdogs und Mail-Alerts** ohne Zusatzsoftware. Herzstück eines schlanken HA-Setups. **NUTZEN.**
+2. **Scheduler + Scripts** (`/system scheduler`, `/system script`) — Auto-Backups (`/export` + Mail), nächtliche Cron-Jobs, Reaktion auf Events. Ersetzt viele „Ich-bräuchte-dafür-einen-Container"-Wünsche. **NUTZEN.**
+3. **DoH — DNS over HTTPS** (`/ip/dns set use-doh-server=… verify-doh-cert=yes`) — verschlüsselter Upstream-DNS direkt am Router, plus statische DNS-/FWD-Einträge. Passt zur bestehenden DNS-Infra (AdGuard/CF). Geringe Last. **NUTZEN/VIELLEICHT** (je nach DNS-Architektur — ihr filtert ohnehin via CF/AdGuard).
+4. **Back-to-Home VPN** (ROS 7.12+, ARM64 ✓) — **WireGuard-basierter** Fernzugriff per MikroTik-App/QR, NULL Server-Config, funktioniert hinter CGNAT/NAT. WireGuard ist der **CPU-effizienteste** VPN-Typ (~24 % CPU @ 1000 conns in Vergleichstests, vs. ZeroTier ~62 %). → **NUTZEN statt ZeroTier** für Remote-Zugriff auf BF. Sehr geringer Footprint.
+5. **Graphing + SNMP → externes Monitoring (icinga/Grafana auf NAS)** — der Router liefert nur Zahlen (gratis), die Auswertung/Speicherung läuft extern. Vermeidet `dude`/Container-Monitoring auf dem RAM-knappen Gerät. **NUTZEN.** (`calea`/`dude` lokal → **WEGLASSEN**.)
+
+Bonus: **`/tool/graphing`** (eingebaute RRD-Graphen) ist leichtgewichtig für schnellen Blick ohne externes System.
+
+Quellen: [Back To Home](https://help.mikrotik.com/docs/spaces/ROS/pages/197984280/Back+To+Home), [WireGuard](https://help.mikrotik.com/docs/spaces/ROS/pages/69664792/WireGuard), [Failover (WAN Backup)](https://help.mikrotik.com/docs/spaces/ROS/pages/26476608/Failover+WAN+Backup)
+
+---
+
+## 10. Multi-WAN / Load-Balancing & Failover (Detail)
+
+**(a)** Mehrere Internet-Uplinks bündeln (Load-Balance via **PCC** = Per-Connection-Classifier) oder als Backup (**Failover** via Routen-`distance` + `check-gateway` + Netwatch + **recursive routing**).
+**(b)** Alles **nativ**, kein Paket.
+**(c)** Relevant nur, wenn ein Standort >1 WAN hat (z. B. DSL + LTE). Am BF mit FritzBox als einzigem Uplink → erst relevant, wenn zweiter Uplink dazukommt.
+**(d)** Gering bis mittel (PCC-Mangle pro Verbindung). Auf dem hAP unkritisch bei Heim-Bandbreiten.
+**(e) Empfehlung: NUTZEN, sobald ein zweiter Uplink existiert** — sonst PARKEN. Failover (Netwatch + recursive route) ist simpler und robuster als PCC-Load-Balance; für daheim meist die bessere Wahl.
+Quellen: [Load Balancing](https://help.mikrotik.com/docs/spaces/ROS/pages/4390920/Load+Balancing), [Failover (WAN Backup)](https://help.mikrotik.com/docs/spaces/ROS/pages/26476608/Failover+WAN+Backup), [vishnunuk/mikrotik-dual-wan-loadbalance-failover (GitHub)](https://github.com/vishnunuk/mikrotik-dual-wan-loadbalance-failover)
+
+---
+
+## Gesamt-Empfehlungsmatrix (TL;DR)
+
+| Kategorie | Empfehlung |
+|---|---|
+| **Sofort nutzen (nativ, ~0 RAM)** | RoMON · Netwatch · Scheduler/Scripts · SNMP · Email-Alerts · mDNS-Repeater (7.16+) · spectral-scan (ad-hoc) · IPv6 intern · Wired-Backhaul + CAPsMAN (802.11r/k/v) · Back-to-Home/WireGuard für Remote |
+| **Vielleicht / situativ** | VRRP-Gateway-HA (nur MAIN/INFRA, hoher Pflegeaufwand) · User-Manager v5 als Standalone-RADIUS · EAP-TLS für eigene Geräte · IPv6-PD extern (falls ISP) · NTP-Server · MQTT · Multi-WAN (sobald 2. Uplink) · Reflector-Container (nur bei SSDP/DLNA) · DoH |
+| **Auf die NAS auslagern** | FreeRADIUS (+LDAP/openldap) · NGINX Proxy Manager · icinga/Grafana-Monitoring · Cloudflare One/WARP (cloudflared) |
+| **Weglassen** | LoRa (keine HW) · OpenFlow · CALEA · ZeroTier (CPU-hungrig → WireGuard nehmen) · `dude` lokal · nativer Reverse-Proxy als NPM-Ersatz |
+
+**Drei zentrale Korrekturen/Erkenntnisse:**
+1. **Reverse Proxy:** RouterOS 7.22+ HAT einen nativen Reverse-Proxy (`/ip/reverse-proxy`, ACME/HTTP-2, SNI) — die Annahme „nein" ist überholt. Ersetzt NPM aber NICHT (kein WS/gRPC, nur IPv4, TLS auf Router-CPU).
+2. **„Was wenn ap1 ausfällt?":** VRRP löst Gateway-Failover technisch elegant und gratis, aber echtes HA verlangt **identische DHCP/Firewall/NAT-Pflege auf beiden** Geräten — das ist der Haken, nicht die VRRP-Last.
+3. **RAM ist König:** Bei 1 GB gilt „nativ vor Container, NAS vor Router". RADIUS, Reverse-Proxy, CF-Tunnel, Monitoring gehören auf die NAS; der hAP macht Routing/WLAN/VRRP/Netwatch.
--- 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)