MikroTik Installer

Ein Windows-Programm, mit dem sich MikroTik-Router/-Switches in wenigen, klar geführten Schritten einrichten lassen – auch ohne Netzwerk-Vorkenntnisse. Statt WinBox-Menüs und RouterOS-Fachbegriffen gibt es ein Interview: Verbindung herstellen, ein paar verständliche Fragen beantworten, fertig.

Hinweis: Dies ist ein unabhängiges, privates Open-Source-Projekt ohne jede kommerzielle Absicht. Es steht in keiner Verbindung zu MikroTik und wird nicht von MikroTik unterstützt, gesponsert oder geprüft. Siehe Markenrechte & Haftungsausschluss.

Was der Assistent einrichtet

Schritt für Schritt, mit Erklär-Tooltips (ⓘ) bei jedem Fachbegriff:

1. Verbindung – IP-Adresse, Benutzername, Passwort; bereits erfolgreich verbundene Geräte erscheinen als „Bekannte Router" zur Wiederverwendung (siehe unten)
2. Was möchtest du tun? – Weiche direkt nach dem Verbinden: kompletter Einrichtungs-Assistent (Standard) oder direkt zu „Backup verwalten" (siehe unten) — Letzteres überspringt den kompletten restlichen Assistenten
3. Geräte-Erkennung – liest Modell, RouterOS-Version und Schnittstellen aus
4. Vorhandene Netzwerke – bei einem Bestandsgerät: nach Kategorien gruppierte, anklickbare Grafik der bereits eingerichteten Bridges, VLANs, IP-Adressen, DHCP-Server, WLANs und IP-gebundenen Firewall-/NAT-Regeln (siehe unten); bei werksneuen Geräten erscheint nur ein kurzer Hinweis
5. Geräte im Netzwerk – nach Anschluss gruppierte Liste aller aktuell erkannten Geräte (aus DHCP-Leases, ARP- und Bridge-Host-Tabelle zusammengeführt), mit der Möglichkeit, einem Gerät direkt eine feste IP-Adresse zuzuweisen oder das wieder rückgängig zu machen (siehe unten)
6. Modus wählen – geführter Assistent (Standard) oder Experten-Modus: Letzterer blendet in den folgenden Schritten zusätzliche, technischere RouterOS-Optionen ein (siehe unten)
7. Internet-Zugang – WAN-Schnittstelle, DHCP oder feste IP, NAT
8. Heimnetzwerk (DHCP) – Bridge, IP-Bereich, DHCP-Server, DNS
9. VLANs (optional) – zusätzliche, getrennte Netzwerke (z. B. Gäste, IoT), im Experten-Modus wahlweise fest einem oder mehreren Anschlüssen zugeordnet (portbasiert, siehe unten)
10. WLAN (übersprungen, wenn nicht vorhanden – oder bewusst abwählbar, z. B. bei einem reinen Switch)
11. Firewall – sichere Basisregeln, optionale Portfreigaben
12. Zusammenfassung – alle geplanten Änderungen im Klartext, automatisches Backup auf dem Gerät vor dem Anwenden, PDF-Export mit allen Zugangsdaten inkl. WLAN-QR-Code zum Ausdrucken/Aufbewahren
13. RouterOS-Update (optional) – prüft auf eine neuere RouterOS-Version und kann sie mit deutlicher Warnung starten

Nichts wird am Gerät verändert, bevor der Nutzer in der Zusammenfassung ausdrücklich auf „Jetzt einrichten“ klickt (Ausnahme: die explizite „Jetzt wiederherstellen“-Aktion in „Backup verwalten“, siehe unten).

Vorhandene Netzwerke (IST-Zustand-Analyse)

Bei einem bereits konfigurierten Bestandsgerät liest der dritte Schritt automatisch aus, was dort schon eingerichtet ist, und zeichnet es als Diagramm: jeder Knoten ist eine Bridge, ein VLAN, eine IP-Adresse, ein DHCP-Server, ein WLAN, eine IP-gebundene Firewall-/NAT-Regel oder der Internet-Zugang. Die Grafik ist in Kategorie-Spalten von links nach rechts gruppiert (Internet → Netzwerk-Schnittstellen → IP-Adressen → DHCP-Server → Firewall-Regeln) für eine klare Übersicht statt eines einzelnen unübersichtlichen Baums. Ein Klick auf einen Knoten hebt alles hervor, was mit ihm verbunden ist — sowohl den Weg („Hops") bis zum Internet-Zugang als auch alles, was von diesem Knoten abhängt (z. B. zeigt ein Klick auf eine Bridge alle angeschlossenen Ports, VLANs, IP-Adressen und DHCP-Server). Rein informativ — verändert nichts am Gerät und fließt nicht in die vom Assistenten geplante Konfiguration ein. Bei einem werksneuen Gerät ohne bestehende Konfiguration erscheint statt der Grafik nur ein kurzer Hinweis.

Geräte im Netzwerk (LAN-Scanner)

Der vierte Schritt führt DHCP-Leases (/ip/dhcp-server/lease), die ARP-Tabelle (/ip/arp) und die Bridge-Host-Tabelle (/interface/bridge/host) per MAC-Adresse zu einer Geräteliste zusammen, gruppiert nach dem physischen Anschluss, an dem ein Gerät tatsächlich hängt (aus der Bridge-Host-Tabelle — ARP/Lease zeigen bei gebrückten Setups sonst nur die Bridge selbst, nicht den echten Port). Rein informativ bis auf eine Aktion: Bei einem Gerät mit DHCP-Lease lässt sich diese per Klick fest zuweisen (RouterOS „Make Static") oder wieder entfernen. Ein „Aktualisieren"-Button lädt die Liste jederzeit neu.

RouterOS kennt keinen direkten „wieder dynamisch machen"-Befehl — das Rückgängig-Machen entfernt den Lease-Eintrag komplett. Das betroffene Gerät merkt das aber nicht sofort: Es hält seine bisherige IP-Adresse client-seitig weiter, bis es von sich aus eine neue DHCP-Anfrage stellt (Lease-Renewal-Timer) oder der Link neu aufgebaut wird (Kabel/WLAN trennen und neu verbinden, Neustart). Bis dahin zeigt die Zeile „Feste IP entfernt" mit deaktiviertem Button und einem erklärenden Hinweistext, statt kommentarlos auszugrauen. Wie die IST-Zustand-Analyse verändert dieser Schritt nichts an der vom Assistenten geplanten Soll-Konfiguration.

Experten-Modus

Wer RouterOS kennt, kann im vierten Schritt den Experten-Modus wählen. Die Schritte 5–9 zeigen dann zusätzlich (Laien-Modus bleibt exakt wie zuvor, Defaults entsprechen dem bisherigen Verhalten):

• Internet-Zugang: DHCP-Standardroute/-DNS an/aus, feste MTU, NAT nur für ein bestimmtes Subnetz
• Heimnetzwerk: DHCP-Lease-Zeit, Domainname, NTP-Server
• VLANs: frei wählbares Adress-Präfix, eigener DNS-Server, Lease-Zeit, „Von Heimnetz isolieren“ (automatische Trennregel), Anschlüsse fest zuordnen (portbasiert, siehe unten)
• WLAN: WPA2/WPA3/gemischt, SSID verstecken, Band/Kanal festlegen
• Firewall: Portfreigabe auf eine Quell-IP beschränken, Portbereiche statt Einzelport, Zugriffe protokollieren, IP-/Subnetz-Sperrliste

Backup verwalten

Eigenständiger Bereich, erreichbar direkt im zweiten Schritt („Was möchtest du tun?") — ohne den restlichen Einrichtungs-Assistenten zu durchlaufen. Liest das verbundene Gerät selbst aus und zeigt sofort: vorhandene Backups auf dem Gerät, einen „Neues Backup erstellen"-Button für eine frische, unabhängige Sicherung (z. B. vor eigenen Änderungen direkt in WinBox — erscheint sofort in der Liste) und „Aktualisieren" zum erneuten Auflisten. Ein Backup lässt sich direkt aus der Liste zurückspielen.

RouterOS prüft beim Zurückspielen selbst nicht, ob ein Backup zum verbundenen Gerät passt — es importiert klaglos eine Fremd-Konfiguration mit ggf. falsch zugeordneten Interfaces. Der Assistent verhindert das mit einer vierstufigen Prüfung: Jedes hier selbst erstellte Backup trägt Gerätemodell, Architektur und Seriennummer im Dateinamen (z. B. mikrotik-installer-RB750Gr3_arm_414403A029A5-20260917-193000.backup, jeweils per _ getrennt).

• Passt genau (Modell, Architektur und Seriennummer stimmen überein, oder die Seriennummer ist auf einer Seite nicht bekannt) — direkt wiederherstellbar.
• Gleiches Modell, anderes physisches Gerät (Modell und Architektur passen, aber eine bekannte, abweichende Seriennummer) — gelb markiert, nur nach ausdrücklicher Bestätigung „auf eigene Gefahr" wiederherstellbar. Erkennt z. B. ein baugleiches Ersatzgerät, das ein reiner Modell-Abgleich fälschlich als identisch durchließe.
• Anderes Modell oder andere Architektur — rot markiert, ohne Override-Möglichkeit blockiert (echtes Risiko falsch zugeordneter Interfaces).
• Nicht prüfbar (kein erkennbarer Name, z. B. ein Backup aus WinBox) — nur nach ausdrücklicher Bestätigung, dass es zum Gerät passt.

Wie beim normalen Anwenden wird vor dem Zurückspielen zusätzlich eine Sicherung des aktuellen Zustands erstellt — falls das Zurückspielen nicht das gewünschte Ergebnis war, lässt sich so auch das noch rückgängig machen. Das Gerät startet nach dem Zurückspielen automatisch neu.

Portbasierte VLANs

Im Experten-Modus lässt sich jedem VLAN im VLAN-Schritt zusätzlich eine Checkliste von Anschlüssen zuordnen (z. B. „Ether4"). Geräte, die dort eingesteckt werden, gehören dann automatisch zu diesem Netzwerk – auch ohne eigene VLAN-Unterstützung (802.1Q-Tagging), z. B. ein einzelner Access Point, eine smarte Steckdose oder eine Netzwerkdose im Gästezimmer. Ohne diese Auswahl bleibt ein VLAN wie bisher rein „getaggt" und ist nur über einen VLAN-fähigen Switch/Access Point erreichbar.

Ein Anschluss kann immer nur einem Netzwerk zugeordnet sein; eine Doppelzuordnung wird erkannt und blockiert „Weiter" mit einer Fehlermeldung. Technisch aktiviert das erst beim Anwenden die Bridge-VLAN-Filterung (vlan-filtering) auf der Heimnetz-Bridge – und zwar bewusst als allerletzten Schritt, nachdem alle PVID- und Bridge-VLAN-Tabellen-Einträge stehen, damit dabei keine Verbindung (auch nicht die eigene, laufende Einrichtung) unterbrochen wird. Die zugeordneten Anschlüsse erhalten zusätzlich frame-types=admit-only-untagged-and-priority-tagged und ingress-filtering=yes, damit ein daran angeschlossenes Gerät sich nicht per manuell getaggten Frames in ein anderes VLAN (z. B. das Heimnetz) einschleichen kann. Anschlüsse ohne eigene VLAN-Zuordnung bleiben unverändert Teil des normalen Heimnetzes.

Eingabevalidierung

Adress-, Bereichs- und Portfelder in WAN, Heimnetzwerk, VLANs und Firewall werden direkt beim Tippen geprüft (IP-/„Adresse/Präfix"-Format, Start ≤ Ende bei Adress- und Portbereichen, Portzahlen 1–65535) und zeigen bei ungültiger Eingabe sofort eine rote, laientaugliche Fehlermeldung statt erst beim Anwenden mit einer RouterOS-Fehlermeldung zu scheitern. „Weiter" bleibt so lange gesperrt, bis alle Felder des aktuellen Schritts gültig sind. Behebt nebenbei einen echten Absturzpfad: Ohne diese Prüfung riefen LanConfigurator/VlanConfigurator bei jedem Tastendruck ungeprüft IPAddress.Parse auf einer möglicherweise unvollständigen Eingabe auf.

Bekannte Router

Nach jeder erfolgreichen Verbindung merkt sich der Assistent Host, Benutzername und (sobald die Geräte-Erkennung gelaufen ist) die Hardware-Bezeichnung als Namensvorschlag — rein lokal, ohne weiteren Geräte-Zugriff. Das Passwort liegt dabei nicht in der lokalen Datei, sondern im Windows-Anmeldeinformationsspeicher (Systemsteuerung → Anmeldeinformationsverwaltung).

Bekannte Router leben ausschließlich als kompakte Kurzauswahl dauerhaft in der Sidebar, unabhängig vom aktuellen Schritt — das Hauptfenster selbst (Verbindungs-Schritt) zeigt nur noch das Formular für ein neues, noch unbekanntes Gerät, ohne Dopplung. Ein Klick auf einen Sidebar-Eintrag verbindet direkt (ohne Umweg über das Formular) und springt bei Erfolg automatisch weiter; ein kleines Papierkorb-Symbol entfernt einen Eintrag wieder. Der Name kommt automatisch vom Gerätemodell — eine eigene Umbenennung gibt es bewusst nicht mehr, um die Sidebar kompakt zu halten. Sobald eine Verbindung besteht, zeigt dieselbe Stelle stattdessen Gerätename/-modell (sobald die Geräte-Erkennung gelaufen ist, bis dahin nur die Adresse) mit einem „Wechseln"-Button, um die Verbindung zu trennen und zu einem anderen Gerät zurückzukehren.

Da viele MikroTik-Geräte werksseitig dieselbe Standardadresse verwenden (192.168.88.1/admin), würde eine reine Host+Benutzername-Zuordnung mehrere unterschiedliche physische Geräte fälschlich als dasselbe behandeln. Der Assistent liest deshalb zusätzlich die Seriennummer aus (/system/routerboard) und legt bei einem Host+Benutzername-Treffer mit unterschiedlicher Seriennummer einen eigenen Eintrag an, statt den bestehenden zu überschreiben — kennt eine Seite (noch) keine Seriennummer (z. B. ein virtuelles CHR-Testgerät), wird im Zweifel derselbe Eintrag aktualisiert.

Für Nutzer

• Windows 10/11, keine Installation nötig
• Einfach MikroTik-Installer.exe herunterladen und starten – eine einzelne, eigenständige Datei (~67 MB), kein separates .NET muss installiert werden
• Portable: läuft von jedem Ordner/USB-Stick, schreibt nichts in Registry oder AppData

Ist die Datei vertrauenswürdig?

Jede Version wird nicht lokal, sondern öffentlich nachvollziehbar per GitHub Actions direkt aus diesem Quellcode gebaut (siehe .github/workflows/release.yml) – niemand fügt der exe manuell etwas hinzu. Bei jedem Release findest du zusätzlich:

• eine .sha256-Prüfsumme neben der exe, mit der du die Integrität deines Downloads überprüfen kannst (Get-FileHash MikroTik-Installer.exe -Algorithm SHA256 unter PowerShell)
• einen VirusTotal-Scan-Link in den Release-Notizen, der die exakt gebaute Datei durch 70+ Antiviren-Engines prüft

Die exe ist nicht mit einem kostenpflichtigen Code-Signing-Zertifikat signiert – Windows SmartScreen zeigt daher beim ersten Start ggf. „Unbekannter Herausgeber" an. Das ist bei kostenlosen Open-Source-Projekten ohne Firmenhintergrund normal und kein Hinweis auf Schadsoftware; über „Weitere Informationen" → „Trotzdem ausführen" lässt sich der Hinweis bestätigen.

Für Entwickler

Voraussetzungen

• .NET 8 SDK

Bauen & Testen

dotnet build
dotnet test src/MikrotikInstaller.Core.Tests/MikrotikInstaller.Core.Tests.csproj
dotnet run --project src/MikrotikInstaller.App

Release-Build (eine einzelne .exe)

.\build-release.ps1

Erzeugt src/MikrotikInstaller.App/bin/Release/net8.0-windows/win-x64/publish/MikroTik-Installer.exe – self-contained, single-file, ohne .NET-Runtime-Installation beim Nutzer.

Es gibt außerdem einen Gitea-Actions-Workflow (.gitea/workflows/build.yml), der das bei jedem Push automatisch übernimmt.

CI/CD (Gitea Actions)

Ein selbstgehosteter Runner (gitea-runner, Name „danielpc-windows") läuft im User-Modus ohne Docker direkt auf dem Windows-Entwicklungsrechner und nutzt dessen bereits installiertes .NET 8 SDK – daher kein actions/setup-dotnet-Schritt im Workflow (der würde versuchen, nach C:\Program Files\dotnet zu schreiben, wofür dem User-Modus-Runner die Rechte fehlen). runs-on: windows-latest im Workflow muss daher exakt dem Label entsprechen, mit dem der Runner registriert wurde (windows-latest:host).

Läuft der Runner nicht dauerhaft im Hintergrund (z. B. nach einem Neustart), bleiben Pushes einfach in der Warteschlange, bis er wieder gestartet wird – nichts geht verloren, es gibt nur keine sofortige Rückmeldung.

Interner Testzugang (nur Debug-Builds)

Im Verbindungs-Schritt aktiviert die Kombination 127.127.127.127 / admin / admin einen komplett simulierten Router (kein echtes Gerät nötig, keine Netzwerkverbindung) – damit lässt sich der gesamte Assistent gefahrlos durchklicken. Dieser Zugang ist per #if DEBUG ausgeschlossen und existiert in veröffentlichten Release-Builds nicht.

Projektstruktur

src/
  MikrotikInstaller.App/          WPF-UI (Views, ViewModels, Wizard-Shell)
  MikrotikInstaller.Core/         RouterOS-Clients, Konfigurationslogik, PDF-Export
  MikrotikInstaller.Core.Tests/   Unit-Tests für Core (xUnit)

Core kapselt die gesamte RouterOS-Kommunikation hinter IRouterOsClient – wahlweise über die REST-API (RouterOS 7+) oder die binäre API (Port 8728/8729, ältere Geräte), mit automatischem Fallback. Jede Konfigurations-Funktion (WAN, LAN, VLAN, WLAN, Firewall) erzeugt sowohl die auszuführenden RouterOS-Befehle als auch eine laienverständliche Klartext-Zusammenfassung.

App ist reines MVVM: Ein generischer Wizard-Shell (MainViewModel) navigiert durch eine Liste von Schritt-ViewModels; Schritte ohne Inhalt für das jeweilige Gerät (z. B. WLAN ohne WLAN-Hardware) werden automatisch übersprungen.

Architektur

flowchart TB
    subgraph App["MikrotikInstaller.App (WPF, MVVM)"]
        MainVM["MainViewModel<br/>Wizard-Navigation"]
        Steps["Step-ViewModels<br/>Connection - DeviceOverview - NetworkAnalysis - ModeSelection -<br/>Wan - Lan - Vlan - Wlan - Firewall - Summary - Update"]
        Session["WizardSession<br/>geteilter Zustand über alle Schritte"]
        MainVM --> Steps --> Session
    end

    subgraph Core["MikrotikInstaller.Core"]
        Configurators["*Configurator<br/>Wan / Lan / Vlan / Wireless / Firewall<br/>erzeugen ConfigurationAction + Klartext-Zusammenfassung"]
        Factory["RouterOsClientFactory<br/>waehlt REST / Binary / Demo"]
        IClient(["IRouterOsClient"])
        Rest["RestRouterOsClient<br/>RouterOS 7+, Port 443/80"]
        Binary["BinaryRouterOsClient<br/>Port 8728/8729"]
        Demo["DemoRouterOsClient<br/>nur #if DEBUG, kein echtes Geraet"]
        Discovery["DeviceDiscoveryService"]
        Backup["RouterBackupService"]
        Updates["RouterOsUpdateService"]
        Export["SummaryPdfExporter + WifiQrCodeGenerator"]

        Factory --> Rest & Binary & Demo
        Rest -.-> IClient
        Binary -.-> IClient
        Demo -.-> IClient
    end

    Device[("MikroTik-Geraet<br/>RouterOS")]

    Session --> Factory
    Steps --> Configurators --> IClient
    Steps --> Discovery & Backup & Updates & Export
    Discovery --> IClient
    Backup --> IClient
    Updates --> IClient
    Rest --> Device
    Binary --> Device

Verbindungsaufbau läuft immer über RouterOsClientFactory: REST-API zuerst, bei Fehlschlag Fallback auf die binäre API; nur bei den Test-Zugangsdaten 127.127.127.127 (und nur in Debug-Builds) wird stattdessen der DemoRouterOsClient verwendet. Alle Configurators, DeviceDiscoveryService, RouterBackupService und RouterOsUpdateService sprechen ausschließlich gegen die Abstraktion IRouterOsClient, nie gegen eine konkrete Implementierung.

Der ModeSelectionStepViewModel-Schritt setzt lediglich WizardSession.IsExpertMode (bool). Jeder folgende Step-ViewModel liest dieses Flag als Passthrough-Property; die zugehörige View blendet damit zusätzliche Eingabefelder ein oder aus (Visibility-Binding auf denselben BoolToVisibilityConverter, der auch sonst im Wizard verwendet wird). Es gibt keine zweite Steps-Liste und keinen separaten Codepfad — bei nicht gesetzten Experten-Feldern (Default) erzeugen die Configurators exakt dieselben RouterOS-Befehle wie im reinen Laien-Modus.

IST-Zustand-Analyse

flowchart LR
    Service["NetworkAnalysisService<br/>Core/Analysis"]
    Facts["Existing*-Records<br/>Bridge-Ports, VLANs, IP-Adressen,<br/>DHCP-Server, Routen, WLANs, Firewall-Regeln"]
    StepVM["NetworkAnalysisStepViewModel<br/>App"]
    Graph["TopologyNodeViewModel / TopologyConnectionViewModel<br/>Kategorie-Spalten (links -&gt; rechts), IsHighlighted"]
    Editor["nodify:NodifyEditor<br/>Klick -&gt; SelectedItem -&gt; Teilbaum-Hervorhebung"]

    Service --> Facts --> StepVM --> Graph --> Editor

NetworkAnalysisService fragt (fehlertolerant pro Endpunkt) /interface/bridge/port, /interface/vlan, /ip/address, /ip/pool, /ip/dhcp-server, /ip/route, /interface/wireless, /ip/firewall/nat und /ip/firewall/filter ab und liefert reine Fakten — keine Positions-/Grafik-Konzepte, Core bleibt UI-frei. Firewall-/NAT-Regeln werden nur aufgenommen, wenn sie eine konkrete Adresse binden (to-addresses bzw. dst-address/src-address) — generische, nur interface-basierte Basisregeln bleiben bewusst außen vor.

Der Step-ViewModel (App) baut daraus einen Baum: jeder Knoten hat höchstens einen ParentNodeId (Bridge-Port → Bridge, VLAN → Eltern-Interface, IP/DHCP → ihr Interface, Firewall-Regel → die IP-Adresse, deren Subnetz die gebundene Adresse enthält, WAN-Interface → synthetischer „Internet"-Knoten anhand der Standardroute). Positioniert wird in Kategorie-Spalten (TopologyLayout.Bands) von links nach rechts: X = Kategorie-Index, Y = laufende Zeile innerhalb der Spalte (sortiert nach Baum-Tiefe, damit zusammengehörige Knoten wie eine Bridge und ihre Ports nahe beieinander stehen). Kategorie-Beschriftungen sind eigene, nicht anklickbare Einträge im selben Nodify-Item-Raum wie die Knoten, damit sie beim Pan/Zoom exakt mitwandern statt als Overlay zu driften. Ein Klick hebt den kompletten verbundenen Teilbaum hervor (Vorfahren und Nachfahren), nicht nur den Weg nach oben. Die Grafik selbst nutzt Nodify (reines, abhängigkeitsfreies WPF-Steuerelement für MVVM-Node-Editoren) — Klicks laufen über dessen eingebautes SelectedItem-Binding, nicht über eigene Maus-Behandlung.

Datenstruktur

Die wichtigsten Records, die während eines Assistenten-Durchlaufs entstehen und durch WizardSession zusammengehalten werden:

classDiagram
    class WizardSession {
        +IRouterOsClient Client
        +RouterDevice Device
        +bool IsExpertMode
        +string WanInterfaceName
        +string LanBridgeName
        +WanSettings WanSettings
        +LanSettings LanSettings
        +VlanDefinition[] VlanDefinitions
        +WirelessSettings WirelessSettings
        +FirewallSettings FirewallSettings
        +ConfigurationAction[] WanActions
        +ConfigurationAction[] LanActions
        +ConfigurationAction[] VlanActions
        +ConfigurationAction[] WirelessActions
        +ConfigurationAction[] FirewallActions
        +RouterOsUpdateInfo UpdateInfo
    }

    class RouterOsCredentials {
        <<record>>
        +string Host
        +string Username
        +string Password
        +int? RestPort
        +int? BinaryPort
        +bool UseEncryption
        +bool AllowUntrustedCertificate
    }

    class RouterDevice {
        <<record>>
        +string IdentityName
        +string BoardModel
        +string RouterOsVersion
        +string Architecture
        +bool HasWireless
        +InterfaceInfo[] Interfaces
        +string? SerialNumber
    }

    class InterfaceInfo {
        <<record>>
        +string Name
        +InterfaceKind Kind
        +bool IsRunning
        +bool IsDisabled
        +string? Comment
    }

    class InterfaceKind {
        <<enum>>
        Ethernet
        Bridge
        Vlan
        Wireless
        Other
    }

    class WanSettings {
        <<record>>
        +string InterfaceName
        +WanAddressMode Mode
        +string? StaticAddressCidr
        +string? StaticGateway
        +bool UseDhcpDefaultRoute
        +bool UseDhcpDns
        +int? Mtu
        +string? NatSourceAddress
    }

    class LanSettings {
        <<record>>
        +string BridgeName
        +string[] MemberInterfaces
        +string RouterAddressCidr
        +string DhcpPoolStart
        +string DhcpPoolEnd
        +string PrimaryDnsServer
        +string? SecondaryDnsServer
        +string? DhcpLeaseTime
        +string? DomainName
        +string? NtpServer
    }

    class VlanDefinition {
        <<record>>
        +int VlanId
        +string Name
        +string RouterAddressCidr
        +string DhcpPoolStart
        +string DhcpPoolEnd
        +bool IsolateFromLan
        +string? DnsServerOverride
        +string? DhcpLeaseTime
        +string[]? AccessPorts
    }

    class WirelessSettings {
        <<record>>
        +string InterfaceName
        +string Ssid
        +string Password
        +WirelessSecurityMode SecurityMode
        +bool HideSsid
        +string? Band
    }

    class WirelessSecurityMode {
        <<enum>>
        Wpa2
        Wpa3
        Wpa2Wpa3Mixed
    }

    class FirewallSettings {
        <<record>>
        +string WanInterfaceName
        +string LanBridgeName
        +PortForward[] PortForwards
        +string[]? BlockedAddresses
    }

    class PortForward {
        <<record>>
        +string Name
        +string Protocol
        +int ExternalPort
        +string TargetAddress
        +int InternalPort
        +string? AllowedSourceAddress
        +bool LogRule
        +int? ExternalPortRangeEnd
        +int? InternalPortRangeEnd
    }

    class ConfigurationAction {
        <<record>>
        +string Description
        +ApplyAsync(IRouterOsClient, CancellationToken) Task
    }

    class RouterOsUpdateInfo {
        <<record>>
        +bool IsCheckSuccessful
        +string InstalledVersion
        +string? LatestVersion
        +bool IsUpdateAvailable
    }

    class SummaryDocumentData {
        <<record>>
        +string DeviceIdentityName
        +string DeviceModel
        +WanSettings? Wan
        +LanSettings? Lan
        +VlanDefinition[] Vlans
        +WirelessSettings? Wireless
        +FirewallSettings? Firewall
        +string? BackupName
    }

    WizardSession --> RouterDevice
    WizardSession --> WanSettings
    WizardSession --> LanSettings
    WizardSession --> VlanDefinition
    WizardSession --> WirelessSettings
    WizardSession --> FirewallSettings
    WizardSession --> ConfigurationAction
    WizardSession --> RouterOsUpdateInfo
    RouterDevice --> InterfaceInfo
    InterfaceInfo --> InterfaceKind
    WirelessSettings --> WirelessSecurityMode
    FirewallSettings --> PortForward
    SummaryDocumentData --> WanSettings
    SummaryDocumentData --> LanSettings
    SummaryDocumentData --> VlanDefinition
    SummaryDocumentData --> WirelessSettings
    SummaryDocumentData --> FirewallSettings

WanSettings, LanSettings, VlanDefinition[], WirelessSettings und FirewallSettings dienen doppelt: als Eingabe für die *Configurator-Klassen (die daraus ConfigurationActions bauen) und – gebündelt in SummaryDocumentData – als Grundlage für den PDF-Export.

Verwendete Bibliotheken

• WPF-UI – modernes Fluent-Design für WPF
• CommunityToolkit.Mvvm – MVVM-Grundgerüst
• Nodify – anklickbare Netzwerk-Grafik im Schritt „Vorhandene Netzwerke"
• PDFsharp – PDF-Erzeugung
• QRCoder – WLAN-QR-Code

Die MikroTik-Markenfarbe (#009245) wurde aus der offiziellen Website übernommen; das App-Icon ist ein eigenes, neutrales Netzwerk-Symbol (kein MikroTik-Logo).

Roadmap

Die Weiterentwicklung wird als Milestones mit zugehörigen Issues im internen Gitea-Dev-Repository getrackt (nicht auf GitHub, siehe Für Entwickler zur Remote-Aufteilung).

Neun der Milestones (M-*-Präfix) entstanden aus einem Feature-Vergleich mit einer parallel entwickelten, funktional deutlich weiter fortgeschrittenen macOS/SwiftUI-Version desselben Assistenten (unabhängiges privates Repository, unabhängige Implementierung, keine gemeinsame Codebasis) und sollen schrittweise Funktionsparität herstellen.

Milestone	Status	Fokus
v1.0 – Realgerät-Validierung	Offen	Kompletter Wizard-Durchlauf inkl. „Jetzt einrichten" (RouterOS-Befehle, Backup, PDF-Export, Update-Prüfung) gegen ein echtes physisches Gerät verifizieren – größter offener Validierungs-Gap. Dabei insbesondere die portbasierte VLAN-Zuordnung (vlan-filtering) gegen ein Echtgerät prüfen, da bisher nur gegen den simulierten Demo-Client getestet
v1.1 – Release-Housekeeping	Offen	v1.0.0-Tag-Strategie klären, Copyright-Name in LICENSE bestätigen, Trennung Gitea (laufendes Dev) / GitHub (nur Releases) wiederherstellen
v1.2 – Eingabevalidierung	✅ Abgeschlossen	Live-Fehlermeldungen bei ungültigen Eingaben (IP-/Subnetz-Format, Adressbereiche, Portbereiche) direkt in WAN/LAN/VLAN/Firewall, vom Nutzer bestätigt. Dabei nebenbei einen eigenständigen Bug behoben: Firewall-/NAT-Regeln duplizierten sich bei wiederholtem Wizard-Lauf gegen dasselbe Gerät (Issue #19)
v1.3 – SFTP-Backup-Download	Offen	Backup-Download aufs PC per SFTP nachrüsten (bisher liegt das Backup nur auf dem Gerät selbst)
IST-Zustand-Analyse	✅ Abgeschlossen	Kernfunktion umgesetzt und vom Nutzer bestätigt (Kategorie-Grafik, Firewall-/NAT-Regeln, Teilbaum-Hervorhebung). Offen: optisches Feintuning sowie Route-zu-Interface-Zuordnung gegen ein echtes Bestandsgerät verifizieren (derzeit best-effort, RouterOS-versionsabhängig)
CI/CD – Gitea-Actions-Runner	✅ Abgeschlossen	Selbstgehosteter Runner registriert, build.yml erfolgreich scharf getestet (Run #26: Tests + Publish + Artefakt-Upload grün). Läuft aktuell nur, solange der Runner-Prozess manuell gestartet ist — kein Autostart/Dienst eingerichtet
M-Bekannte-Router – Gespeicherte Verbindungen	✅ Abgeschlossen	Zuletzt genutzte Router mit Name/Standort merken, vom Nutzer bestätigt (siehe „Bekannte Router" oben)
M-Geräte – LAN-Scanner	✅ Abgeschlossen	DHCP-Leases + ARP + Bridge-Hosts je Anschluss zusammengeführt, feste IP-Zuweisung (siehe „Geräte im Netzwerk" oben). Offen: Verhalten von „Make Static" gegen ein echtes Gerät verifizieren (Issue #30)
M-Backup-Wartung – Wiederherstellung, Werksreset, Firmware-Update	Teilweise abgeschlossen	Backup zurückspielen mit vierstufigem Seriennummer-/Architektur-/Modell-Abgleich als Brick-Schutz ✅, eigenständiger „Backup verwalten"-Bereich außerhalb des Interviews ✅ (siehe „Backup verwalten" oben; Verhalten von /system/backup/load gegen ein echtes Gerät offen, Issue #32). Noch offen: Werksreset-Notfallschalter, Routerboard-Firmware-Update (Issue #28)
M-Übersicht-Edit – Direktes Bearbeiten im Diagramm	Offen	IST-Zustand-Diagramm von rein lesend auf bearbeitbar (Rückschreiben ans Gerät) erweitern
M-SSH – SSH-Fallback-Transport	Offen	SSH-CLI-Fallback-Verbindung für Geräte/Firmware ohne REST-API, inkl. Hostkey-TOFU
M-Netzwerk-Tools – Ping/Traceroute/DNS/Port-Scan	Offen	Netzwerk-Werkzeuge vom Router aus sowie lokaler TCP-Port-Scan
M-Live-Traffic – Live-Durchsatzanzeige	Offen	Live-Traffic-Anzeige an Interfaces und im LAN-Scanner
M-Experte – Generischer RouterOS-Zugriff	Offen	Eigener Bereich mit generischer Menü-Engine + kuratierten Formularen für die wichtigsten RouterOS-Bereiche, über die bisherigen Experten-Zusatzfelder hinaus
M-i18n – Zweisprachigkeit DE/EN	Offen	Umschaltbare Sprache für die gesamte App

Ablaufplan (Priorisierung)

Reihenfolge oben in der Tabelle bereits danach sortiert; Begründung nach Phasen:

1. Fundament/Sicherheit zuerst ✅ — v1.2 (behebt einen echten Absturzpfad) zusammen mit dem eigenständig gefundenen Firewall-/NAT-Idempotenz-Bug (Issue #19, kein Milestone) und CI/CD sind abgeschlossen. v1.0 (Realgerät-Validierung) bleibt offen, bis Testhardware verfügbar ist — bevor auf der bestehenden Basis neue Flächen entstehen, muss sie gegen echte Hardware stehen.
2. Unabhängige Mac-Paritätsfeatures ohne SSH-Abhängigkeit — M-Bekannte-Router ✅ und M-Geräte/LAN-Scanner ✅ abgeschlossen, M-Backup-Wartung teilweise (Backup-Wiederherstellung ✅, Werksreset/Firmware-Update offen). Noch offen: Rest von M-Backup-Wartung, v1.3 (SFTP-Backup-Download, gleicher Themenbereich, sinnvoll im selben Zug), M-Übersicht-Edit (baut auf der bereits verifizierten Nodify-Integration auf).
3. Transport-Fundament — M-SSH: einzige Mac-Funktion, die einen komplett neuen Transport-Layer braucht (Ping/Traceroute/DNS-Auflösung und /interface monitor-traffic sind reine CLI-Befehle ohne REST-Äquivalent). Bewusst erst nach Phase 2, damit die risikoarmen Features nicht auf die größere Transport-Arbeit warten müssen.
4. Darauf aufbauend — M-Netzwerk-Tools (Port-Scan-Teil ist unabhängig und könnte vorgezogen werden, Ping/Traceroute/DNS brauchen M-SSH) und M-Live-Traffic (falls kein REST-Äquivalent für /interface monitor-traffic existiert, ebenfalls M-SSH-abhängig — das wird als Erstes bei der Umsetzung geprüft).
5. Größtes Einzelstück zuletzt unter den Mac-Milestones — M-Experte (generischer Zugriff auf >300 RouterOS-Menüs) ist der mit Abstand größte Umfang und blockiert nichts anderes; am besten inkrementell über einen längeren Zeitraum, Bereich für Bereich wie beim Mac-Vorbild.
6. Querschnitt zuletzt — M-i18n erst, wenn die UI-Fläche der vorherigen Phasen weitgehend steht, sonst laufend neue unübersetzte Strings.
7. Release-Abschluss — v1.1 (Release-Housekeeping) kurz vor dem tatsächlichen v1.0.0-Tag, nicht vorher.

Abgleichs-Rhythmus mit der Mac-Version: Kein einmaliger Abgleich, sondern wiederkehrend — nach Abschluss eines M-*-Milestones hier oder einer entsprechenden Funktion auf Mac-Seite jeweils kurz prüfen, ob sich die READMEs/Milestones beider Projekte noch decken. RouterOS-API-Eigenheiten, die keine sprach-/framework-spezifische Ursache haben (wie der Firewall-Idempotenz-Bug, Issue #19), werden in beide Projekte übernommen, sobald sie auf einer Seite auffallen.

Lizenz

Dieses Projekt steht unter der MIT-Lizenz. Der Quellcode darf frei verwendet, verändert und weiterverbreitet werden – auch in eigenen (auch kommerziellen) Projekten –, solange der Lizenz- und Copyright-Hinweis erhalten bleibt. Die Software wird ohne jede Gewährleistung bereitgestellt („as is").

Markenrechte & Haftungsausschluss

• Kein offizielles MikroTik-Produkt. Dieses Projekt ist eine unabhängige, private Entwicklung und steht in keiner Verbindung zu MikroTikls SIA. Es wird nicht von MikroTik entwickelt, geprüft, unterstützt, gesponsert oder in irgendeiner Form autorisiert.
• Markenrechte bleiben unangetastet. „MikroTik", „RouterOS", „WinBox" und alle weiteren genannten Produkt- und Markennamen sind Marken bzw. eingetragene Marken von MikroTikls SIA. Sie werden hier ausschließlich zur sachlichen Beschreibung der Kompatibilität verwendet (nominativer Gebrauch), nicht um eine Verbindung, Zusammenarbeit oder Billigung durch MikroTik zu suggerieren. Das App-Icon ist ein eigens erstelltes, neutrales Symbol – kein MikroTik-Logo.
• Nicht-kommerzielles Hobbyprojekt. Der Autor verfolgt mit diesem Projekt keinerlei finanzielle Absicht. Es wird kostenlos und ohne Gewinnerzielungsabsicht als Open Source zur Verfügung gestellt, in der Hoffnung, dass es anderen Nutzern beim Einrichten ihrer Geräte hilft.
• Nutzung auf eigene Verantwortung. Wer den Installer einsetzt, ändert Konfigurationen auf eigenen Netzwerkgeräten in eigener Verantwortung. Es wird keine Haftung für Schäden, Datenverlust oder Fehlkonfigurationen übernommen, die durch die Nutzung dieser Software entstehen (siehe auch Gewährleistungsausschluss in der LICENSE).

Sollte MikroTikls SIA Einwände gegen Inhalte dieses Repositories haben, bitte über die Kontaktmöglichkeiten dieses GitHub-Profils melden – entsprechende Inhalte werden umgehend angepasst oder entfernt.