204 lines
20 KiB
Markdown
204 lines
20 KiB
Markdown
# 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.
|