VPN-Server pro Agent konfigurieren (Direkt-VPN)

Ein Direkt-Anlagen-VPN ist ein dedizierter Tunnel zwischen dem Mirox-Agent einer einzelnen Anlage und dem anlageneigenen Router — das richtige Werkzeug, wenn eine Anlage bereits ein eigenes VPN betreibt oder wenn Mirox ein VPN hosten soll, in das sich der Anlagen-Router einwählt. Anders als das persönliche VPN, das jedem Benutzer ein Profil gibt, mit dem alle seine berechtigten Anlagen erreichbar sind, ist ein Direkt-VPN ein anlagenspezifischer Infrastruktur-Tunnel, den Sie einmal einrichten und über den der gesamte Datenverkehr des Teams für diese Anlage läuft.

Sie konfigurieren Direkt-VPNs auf der Seite Netzwerk einer Anlage, im Tab Site VPN. Die Netzwerk-Seite hat fünf Tabs: Übersicht (die Verbindungs-Pipeline), Netzwerkgeräte, Site VPN (diese Anleitung), Peers (wird angezeigt, wenn ein gehostetes VPN mehr als einen verbindenden Standort hat) und Zugriffsprotokoll.

In Mirox öffnen

Den Site-VPN-Tab der Anlage öffnen. In der App ist dies die Seite Netzwerk der Anlage, Tab Site VPN.

Wann ein Direkt-VPN verwenden

Greifen Sie zu einem Direkt-VPN, wenn die Konnektivität der Anlage nicht in das Standardmodell des persönlichen VPNs passt:

Der Anlagen-Router hostet bereits einen eigenen VPN-Server. Sie verfügen über eine Konfigurationsdatei (WireGuard .conf) oder ein OpenVPN-Profil (.ovpn) und möchten, dass Mirox sich zu ihm verbindet.
Der Anlagen-Router kann sich nur nach außen verbinden, aber keine eingehenden Verbindungen annehmen. Mirox hostet den VPN-Endpunkt und der Router verbindet sich mit ihm.
Sie möchten einen dauerhaft aktiven Tunnel für die gesamte Anlage, statt dass jeder Benutzer ein persönliches Profil mitführt.

Für die tägliche technische Arbeit über mehrere Anlagen hinweg — das Öffnen von Geräte-Weboberflächen, das Ausführen von Diagnosewerkzeugen — sind das persönliche VPN und der Browser-Proxy in der Regel die bessere Wahl. Die folgende Tabelle fasst den Unterschied zusammen; der vollständige Vergleich findet sich auf der VPN-Funktionsseite.

Werkzeug	Was es ist	Wer es einrichtet
Persönliches VPN	Ein persönliches Profil, mit dem jede Anlage erreichbar ist, für die Sie berechtigt sind	Jeder Benutzer im Rahmen seiner Berechtigungen
Direkt-VPN (diese Anleitung)	Ein anlagenspezifischer Tunnel zwischen dem Agent der Anlage und ihrem Router	Ein Moderator oder Admin der Organisation der Anlage
Browser-Proxy	Die Weboberfläche eines Geräts aus dem Browser öffnen, ohne Client-Installation	Der Betreiber der Anlage

Die zwei Richtungen

Ein Direkt-VPN kann in einer von zwei Richtungen betrieben werden. Der Einrichtungsassistent fragt dies zuerst ab, unter Wo befindet sich der VPN-Server?

Hinweis: Gestrichelte Linien zeigen die Verbindungsrichtung an — pro Direkt-VPN gilt nur eine Richtung.

Ausgehende Verbindung — Mirox verbindet sich zum Anlagen-Router. Der Anlagen-Router betreibt seinen eigenen VPN-Server; der Mirox-Agent verbindet sich als Client nach außen. Die Karte zeigt ein Client-Badge. Wählen Sie dies, wenn Sie bereits eine Konfigurationsdatei oder Zugangsdaten für das VPN des Routers haben.
Hier gehostet — der Anlagen-Router verbindet sich zu Mirox. Mirox betreibt den VPN-Server; die Karte zeigt ein Server-Badge. Der Endpunkt (eine anlagenspezifische Adresse samt Port), die Schlüssel und Zertifikate werden von Mirox generiert und Ihnen übergeben, damit Sie sie auf den Anlagen-Router laden. Wählen Sie dies, wenn der Router sich nach außen verbinden, aber keine eingehenden Verbindungen annehmen kann.

Alle drei Protokolle — OpenVPN, WireGuard und IPsec (IKEv2) — stehen in beiden Richtungen zur Verfügung, die richtige Wahl unterscheidet sich jedoch je nach Richtung: siehe Den VPN-Typ wählen weiter unten. Eine Anlage kann gleichzeitig einen Server je Protokollvariante hosten — WireGuard, OpenVPN über UDP, OpenVPN über TCP und IPsec — und beliebig viele ausgehende Verbindungen parallel betreiben.

Den VPN-Typ wählen

Mirox spricht drei Tunnelprotokolle — OpenVPN, WireGuard und IPsec (IKEv2) — und der Assistent stellt sie nebeneinander mit dem, was jeweils dafür und dagegen spricht. Welches empfohlen wird, hängt von der gewählten Richtung ab, und das Badge „Empfohlen" wandert entsprechend mit. Das ist keine Geschmacksfrage: Die beiden Richtungen legen den empfindlichen Teil der Verbindung auf jeweils die andere Seite des Tunnels.

Der empfindliche Teil ist die Frage, wer die Adresse der Gegenstelle auflöst — und wie oft. Mirox läuft in mehreren Rechenzentrumsregionen, und der VPN-Endpunkt einer Anlage kann bei einem Failover zwischen ihnen wechseln. Ein Client, der den DNS-Namen des Servers bei jedem Verbindungsaufbau neu auflöst, folgt diesem Wechsel von selbst; ein Client, der ihn einmal beim Start aufgelöst hat, wählt weiter eine Adresse, die nicht mehr antwortet.

Welches VPN-Protokoll soll ich wählen?

Auf einen Blick — die ausführliche, richtungsabhängige Betrachtung folgt weiter unten. Welche Option empfohlen wird, hängt von der gewählten Richtung ab, doch der Charakter jedes Protokolls ist in beiden Richtungen derselbe:

Protokoll	Typischer Einsatz	Läuft über
WireGuard	Die schlanke, moderne Variante — am schnellsten eingerichtet, ein Schlüsselpaar je Seite und keine Zertifikate. Passt gut zu einem neu aufgebauten Standort oder überall dort, wo die Zertifikatsverwaltung die Hürde ist.	IPv4, IPv6 oder beides
OpenVPN	Die universelle Variante — von praktisch jedem Router unterstützt, auch von viele Jahre alter Firmware. Die sichere Voreinstellung, wenn Mirox den Server hostet.	IPv4, IPv6 oder beides
IPsec (IKEv2)	Der Industriestandard und oft das Einzige, was ein Industrie-Router oder eine Firewall anbietet (Cisco, Lancom, Fortigate).	IPv4 oder IPv6

IPv4 oder IPv6? Ein Tunnel läuft über IPv6 ebenso gut wie über IPv4, und wenn Mirox den Server hostet, werden standardmäßig beide veröffentlicht. Was wann zu ändern ist, steht unter IP-Version. Bei einer ausgehenden Verbindung gibt es nichts zu wählen — der Tunnel folgt der Adresse des Servers vor Ort.

IP-Version

Mirox veröffentlicht die Adresse des Tunnels im DNS. Bei einem gehosteten VPN entscheiden Sie, welche Einträge dafür veröffentlicht werden:

Einstellung	Was veröffentlicht wird	Wann verwenden
IPv4 + IPv6 (Standard)	Ein A-Eintrag und ein AAAA-Eintrag	Fast immer. Der Router nutzt den, den er kann.
Nur IPv4	Ein A-Eintrag	Der Standort hat kein funktionierendes IPv6, oder sein Router lehnt IPv6-Tunnel ab.
Nur IPv6	Ein AAAA-Eintrag	Der Standort ist über IPv6 erreichbar und IPv4 ist nicht erwünscht.

Beide Einträge online zu halten gibt die größte Kompatibilität, und deshalb ist IPv4 + IPv6 vorausgewählt. Ein Router mit funktionierendem IPv6 nimmt in der Regel den AAAA-Eintrag — das ist das normale Verhalten eines IP-Stacks, der beides hat — und ein Router mit nur IPv4 nimmt den A-Eintrag. In beiden Fällen ist vor Ort nichts einzurichten.

Beides zu veröffentlichen ist bei WireGuard kein automatischer Rückfall

Ein WireGuard-Client schlägt die Adresse einmal nach, beim Start des Tunnels, und probiert die andere Familie nicht, wenn dieser Versuch scheitert. Ein Router, dessen IPv6 zwar vorhanden, aber defekt ist, kann also den AAAA-Eintrag nehmen und unten bleiben — beide Einträge zu veröffentlichen rettet ihn nicht. Genau dafür gibt es Nur IPv4. OpenVPN verhält sich anders: Es arbeitet die aufgelösten Adressen der Reihe nach ab und erholt sich von selbst.

IPsec (IKEv2) bietet nur IPv4 oder IPv6, nie beides: Eine IKE-Verbindung wählt jeweils eine Adressfamilie.

Wo Sie es finden. Da der Standard für nahezu jeden Standort richtig ist, gehört die Einstellung bei WireGuard und OpenVPN nicht zum einleitenden Assistenten — öffnen Sie im Konfigurationsschritt Erweiterte Optionen anzeigen. IPsec fragt direkt danach, da es kein "beides" als Rückfall gibt. Bei einem bestehenden VPN steht sie ganz oben unter Bearbeiten → Konfiguration. Eine spätere Änderung stört bereits bestehende Tunnel nicht.

IPv6 innerhalb des Tunnels

Die Einstellung oben legt fest, welche Familie das verschlüsselte Paket zur Anlage transportiert. Was Sie innerhalb des Tunnels adressieren — die Geräte der Anlage —, ist heute IPv4. Die Plattform ist auch dort auf IPv6 vorbereitet; es ist schlicht noch nicht gebaut, weil es bisher keine Anlage gebraucht hat. Sind die Geräte Ihrer Anlage über IPv6 adressiert, sagen Sie uns Bescheid — wir setzen es um.

Hier gehostet (Mirox ist der Server) — OpenVPN wird empfohlen

In dieser Richtung ist der Anlagen-Router der Client, das Neu-Auflösen übernimmt also dessen Firmware — Hardware, die wir nicht administrieren und aus der Ferne nicht reparieren können.

Option	Dafür spricht	Dagegen spricht
OpenVPN (empfohlen)	Löst die Serveradresse bei jedem Verbindungsaufbau neu auf — nach einem Mirox-Failover kommt der Tunnel von selbst zurück, unabhängig von Hersteller und Firmware des Routers. Wird von praktisch jedem Router unterstützt, auch von viele Jahre alter Firmware.	Zertifikatsbasiert: Im Router müssen eine CA, ein Zertifikat und ein Schlüssel eingetragen werden statt eines einzelnen Schlüsselpaars.
WireGuard	Mit wenigen Werten eingerichtet — ein Schlüsselpaar je Seite, kein Zertifikatspaket.	Die meisten Router lösen die Serveradresse nur einmal beim Start auf; nach einem Mirox-Failover bleibt der Tunnel unten, bis der Router neu startet oder Mirox zurückschwenkt (Failback). Ältere Router-Firmware bietet WireGuard womöglich gar nicht an.
IPsec (IKEv2)	Der Standard auf Industrie-Routern (Cisco, Lancom, Fortigate).	Pre-shared Key und manuelle Einrichtung am Router — keine Konfigurationsdatei zum Einlesen. Langsamer: Die Verschlüsselung läuft im Userspace und passt daher am besten zu Telemetrie mit geringem Datenvolumen.

Die entscheidende Frage lautet hier also nicht, welches Protokoll das modernere ist — das ist WireGuard —, sondern welches einen Regionswechsel auf Hardware übersteht, die wir nicht kontrollieren. OpenVPN tut das auf jeder Firmware, deshalb ist es vorausgewählt. Wählen Sie WireGuard, wenn die Zertifikatsverwaltung für den konkreten Router die größere Hürde ist — und nehmen Sie in Kauf, dass nach einem Failover ein Neustart des Routers nötig sein kann. Wählen Sie IPsec, wenn der Router nichts anderes anbietet.

Die Zertifikate laufen Ihnen nicht ab

Die Zertifizierungsstelle, das Serverzertifikat und jedes Peer-Zertifikat, das Mirox für einen gehosteten OpenVPN-Server ausstellt, sind langlebig. Es gibt keine Erneuerungspflicht und nichts, was Jahre später stillschweigend abläuft — der Preis von OpenVPN ist die einmalige Einrichtung am Router, nicht die Wartung.

WireGuard-Reconnect-Port

WireGuard merkt sich die Adresse, zu der es sich zuerst verbunden hat, und löst sie nie wieder neu auf. Wird die Mirox-Serverseite eines gehosteten WireGuard-Tunnels also einmal verlegt — bei einem Failover oder zur Wartung —, kann ein verbundener Site-Peer getrennt bleiben, bis er neu gestartet wird. OpenVPN und IPsec prüfen die Adresse selbst neu und brauchen keine solche Einstellung; WireGuard nicht.

Der Reconnect-Port beseitigt diese Schwäche. Es ist der WireGuard-Listen-Port des entfernten Routers (des Site-Peers). Tragen Sie ihn ein, wenn Sie ein gehostetes WireGuard-VPN anlegen, oder später bei einem bestehenden Peer unter Bearbeiten → Remote Peer, oder je Peer unter Peers → Bearbeiten. Ist er gesetzt, kann Mirox die Gegenstelle nach einem Umzug der Serverseite an ihrer eigenen öffentlichen Adresse neu anwählen, sodass sich der Tunnel automatisch wiederherstellt und einen Failover übersteht. Bleibt er leer, bleibt der Tunnel fixiert: Die Serverseite wird nicht verlegt, und nach einem Umzug bliebe der Tunnel unten, bis der Router sich von allein neu verbindet. Um einen Reconnect-Port wieder zu entfernen, löschen Sie einfach das Feld und speichern.

Nur setzen, wenn dieser Port wirklich erreichbar ist

Einen Reconnect-Port zu setzen, ist ein Versprechen, dass Mirox den Router dort erreichen kann — und genau das ermöglicht es, den Tunnel für einen Failover zu verlegen. Sobald er gesetzt ist, kann die Serverseite also verlegt werden, und diese Verlegung trennt den Tunnel kurz und stellt ihn dann wieder her. Damit er heilt und nicht unterbrochen bleibt, muss der Router vor Ort tatsächlich auf diesem WireGuard-Port lauschen, über seine öffentliche IPv4- oder IPv6-Adresse erreichbar sein und den Port in der Firewall vor Ort geöffnet haben. Ist der Port nicht erreichbar, trennt ein Umzug den Tunnel ohne Rückweg — tragen Sie ihn daher erst ein, wenn der WireGuard-Endpunkt der Anlage lauscht und die Firewall ihn zulässt. Im Zweifel lassen Sie ihn leer; der Tunnel bleibt dann einfach, wo er ist.

Für jeden WireGuard-Site-Peer einen Reconnect-Port zu setzen, wird empfohlen, sofern der Listen-Port des Routers bekannt und erreichbar ist.

Ausgehend (Mirox ist der Client) — WireGuard wird empfohlen

In dieser Richtung existiert der Server vor Ort bereits, und Mirox wählt sich dort ein. Das dreht beide Argumente von oben um:

Die neu auflösende Seite ist jetzt unsere. Mirox löst die Adresse des Servers vor Ort immer wieder neu auf und verbindet sich selbstständig neu — bei jedem Protokoll. Der Einwand, der den gehosteten Fall entschieden hat, entfällt damit vollständig.
Auch die Firmware-Frage entfällt. Am Router muss nichts installiert werden; das Protokoll ist schlicht das, was der bestehende Server spricht, und Mirox übernimmt seine Einstellungen von dort.

Der Server vor Ort muss aus dem Internet erreichbar sein

Diese Richtung funktioniert nur, wenn Mirox sich einwählen kann. Der Anschluss der Anlage braucht also eine eigene Adresse, die aus dem öffentlichen Internet erreichbar ist. Eine der beiden Familien genügt: eine öffentliche IPv4- oder eine öffentliche IPv6-Adresse. Ein Anschluss ohne öffentliches IPv4, aber mit funktionierendem IPv6, ist damit völlig ausreichend.

Ausgeschlossen ist diese Richtung nur dann, wenn der Anbieter den Anschluss in seinem eigenen geteilten Netz hält und der Router deshalb auf keiner der beiden Familien eine von außen erreichbare Adresse besitzt. Typisch ist das bei günstigen Mobilfunk- und SIM-Tarifen. Lassen Sie die Anlage auf der Internetseite ihres Routers nachsehen: eine IPv4-Adresse, die als mit anderen Kunden geteilt ausgewiesen ist, und keine öffentliche IPv6-Adresse auf der Verbindung bedeuten, dass diese Richtung nicht möglich ist. Ein DynDNS-Name, der sich auflöst, beweist hier nichts — er löst auf einem geteilten Anschluss genauso auf.

Ist das der Fall, hosten Sie das VPN stattdessen hier (Abschnitt oben): Der Router wählt sich dann nach außen, und das funktioniert auf jedem Anschluss. Wählen Sie dort OpenVPN — ein gehosteter WireGuard-Tunnel ließe sich auf einem solchen Anschluss auch von unserer Seite nicht reparieren, weil ein Reconnect-Port genau dieselbe Erreichbarkeit voraussetzt, und bliebe nach einem Failover unten, bis der Router sich von selbst neu verbindet.

Übrig bleibt, was in Mirox importiert werden muss — und genau darin unterscheiden sich die drei wirklich:

Option	Dafür spricht	Dagegen spricht
WireGuard (empfohlen)	Ein Schlüsselpaar und ein Endpunkt sind der gesamte Import — sonst muss zwischen beiden Enden nichts zusammenpassen. Mirox löst die Adresse des Servers vor Ort neu auf und verbindet sich selbstständig neu, sodass ein DynDNS-Wechsel oder ein Leitungsabbruch von allein heilt.	Der Server vor Ort muss den öffentlichen Mirox-Schlüssel als Peer eintragen — eine fertige Profildatei genügt dort nicht.
OpenVPN	Fast jeder bestehende VPN-Server bietet es an, und seine `.ovpn`-Datei lässt sich hier unverändert hochladen.	Chiffre, HMAC und TLS-Einstellungen müssen exakt zum Server passen — Abweichungen scheitern lautlos, deshalb geht der Assistent sie in einem eigenen Schritt mit Ihnen durch. Das Profil ist ein Paket: CA, Zertifikat, Schlüssel und der tls-auth-Schlüssel müssen alle von vor Ort kommen.
IPsec (IKEv2)	Oft das Einzige, was eine Industrie-Firewall anbietet (Cisco, Lancom, Fortigate).	Pre-shared Key und beide IKE-Identitäten müssen mit der Gegenseite von Hand abgestimmt werden — es gibt kein Profil zum Einlesen. Langsamer: Die Verschlüsselung läuft im Userspace und passt daher am besten zu Telemetrie mit geringem Datenvolumen.

In der Praxis ist die Wahl oft schon getroffen: Es muss das Protokoll sein, das der bestehende Server spricht. Die Empfehlung greift, wenn der Standort mehr als eines anbietet — und wenn der Standort gerade erst aufgebaut wird, lohnt es sich, WireGuard zu verlangen.

UDP oder TCP (nur OpenVPN)

OpenVPN läuft über UDP oder TCP. UDP ist die Betriebsart, für die es gemacht ist — schneller und auf einer schwachen Mobilfunkstrecke deutlich stabiler — und die Voreinstellung. TCP ist für den einen Standort gedacht, dessen Firewall kein UDP hinauslässt oder dessen Router ausschließlich TCP anbietet.

Hier gehostet: Die Wahl sitzt im Schritt Konfiguration hinter Erweiterte Optionen anzeigen, neben den Krypto-Einstellungen. Lassen Sie sie unangetastet, sofern Sie nicht wissen, dass UDP blockiert ist. Der Transport gehört zur Identität des Servers, eine Anlage kann also einen UDP- und einen TCP-OpenVPN-Server nebeneinander hosten.
Ausgehend: Eine hochgeladene .ovpn-Datei gibt ihn bereits an; bei manueller Eingabe wählen Sie UDP oder TCP zusammen mit den Verbindungsdetails.

OpenVPN-Kompatibilitätseinstellungen

Diese finden sich im Schritt Konfiguration des Assistenten. Dessen Standardansicht enthält bewusst keine Stellschrauben — ein unangetasteter gehosteter Server rendert das moderne Profil, das für jeden Router im Support-Zeitraum richtig ist. Die Kompatibilitäts-Presets und die einzelnen Direktiven erscheinen hinter Erweiterte Optionen anzeigen.

Bei OpenVPN können Sie die Einstellungen eines älteren Routers nachbilden, sodass sich selbst Legacy-Firmware verbindet: Cipher, Authentifizierungs-Digest, minimale TLS-Version, Komprimierung, mssfix, Renegotiationsintervall und der TLS-Auth-Modus. Der Assistent validiert die Kombination bereits während der Eingabe und weist Paarungen zurück, die keine unterstützte Router-Firmware tatsächlich aushandeln kann.

Ein gehosteter OpenVPN-Server bietet zusätzlich:

PKI-Schlüsselalgorithmus — neue Server verwenden standardmäßig RSA-2048, den Algorithmus, den gängige Industrie-Router akzeptieren; ECDSA P-256 steht zur Verfügung, wo der Router es unterstützt. Der Algorithmus wird bei der Erstellung festgelegt; ihn später zu ändern bedeutet, die gesamte Zertifikatskette zu rotieren.
CA rotieren — stellt die Zertifizierungsstelle des Servers, das Server-Zertifikat und das Zertifikat jedes verbindenden Peers in einem Schritt neu aus. Die neue Konfiguration jedes Peers wird einmalig zum Download angezeigt; die alten Zertifikate funktionieren nicht mehr, sobald die Rotation angewendet wird.
Benutzerauthentifizierung erforderlich — verbindende Peers müssen zusätzlich einen Benutzernamen und ein Passwort vorweisen, die Sie pro Peer festlegen.

IPsec-(IKEv2-)Einstellungen

Für IPsec fragt der Assistent, was ein IKEv2-Responder braucht: den Pre-shared Key — lassen Sie ihn bei einem gehosteten Server leer, dann erzeugt Mirox einen starken und zeigt ihn nach dem Anlegen einmalig an —, die lokale und die entfernte IKE-Identität (optional; standardmäßig wird der FQDN des Endpunkts verwendet), die IKE- und ESP-Proposals, deren Lebensdauern und das DPD-Intervall, das bestimmt, wie schnell eine tote Gegenstelle erkannt wird. Beide Seiten müssen sich bei den Proposals einig sein, und es gibt kein Profil zum Austauschen — diese Werte werden am Router von Hand eingetragen.

Bevor Sie beginnen

Wer Direkt-VPNs konfigurieren kann

Der Site-VPN-Tab ist sichtbar für Technische Betriebsführung oder höher auf der Anlage (einschließlich Betreiber). Das Erstellen, Bearbeiten oder Löschen eines Direkt-VPNs erfordert einen Moderator oder Admin der anlageneigenen Organisation. Niedrigere Rollen sowie Benutzer, die die Anlage über eine Kooperation erreichen, sehen die konfigurierten Tunnel, können sie aber nicht ändern. Der Zugriff folgt dem Berechtigungssystem.

Halten Sie bereit:

Die Richtung, die Sie benötigen (ausgehend vs. gehostet), je nachdem, was der Anlagen-Router unterstützt.
Für die ausgehende Richtung: die VPN-Konfigurationsdatei des Routers (.conf oder .ovpn) oder die Endpunktadresse und Schlüssel zur manuellen Eingabe.
In der ausgehenden Richtung gibt der bereits vor Ort laufende Server das Protokoll vor. In der gehosteten Richtung haben Sie die freie Wahl — siehe Den VPN-Typ wählen.
Das/die Anlagen-Subnetz(e) hinter dem Router, das/die Sie erreichen möchten — die lokalen Netzwerkbereiche (CIDRs), in denen sich die Wechselrichter, Logger und anderen Geräte befinden.

Ein Direkt-VPN hinzufügen

In Mirox öffnen: Öffnen Sie den Site-VPN-Tab der Anlage — die Seite Netzwerk der Anlage, Tab Site VPN.
Klicken Sie auf VPN-Verbindung hinzufügen. Ein kurzer Assistent öffnet sich.
Wählen Sie die Richtung — Mirox verbindet sich zum Park-Router (ausgehend) oder Park-Router verbindet sich zu Mirox (gehostet).
VPN-Typ — wählen Sie OpenVPN, WireGuard oder IPsec (IKEv2). Der Assistent kennzeichnet die für die gewählte Richtung empfohlene Option und wählt sie vor; jede Karte listet auf, was dafür und was dagegen spricht. Siehe Den VPN-Typ wählen.
Konfiguration — (nur gehostet) das Kompatibilitätsprofil für den Anlagen-Router. Die Voreinstellung passt zu jedem Router der letzten Jahre; Erweiterte Optionen anzeigen blendet den Transport (UDP/TCP), die einzelnen Krypto-Direktiven, die optionale Benutzername/Passwort-Authentifizierung, den WireGuard-Pre-shared-Key bzw. die IPsec-Responder-Einstellungen ein.
Verbindungsdetails — (nur ausgehend) laden Sie die .conf/.ovpn-Datei des Routers hoch oder wechseln Sie zur manuellen Eingabe und tippen Sie Endpunkt und Schlüssel ein. Bei OpenVPN folgt ein Schritt Kompatibilitätsprüfung, in dem der Assistent zeigt, was er aus dem Profil gelesen hat, damit Sie es korrigieren können.
Anlagen-Subnetz — fügen Sie den/die hinter dem Router erreichbaren lokalen Netzwerkbereich(e) hinzu. Die Plattform validiert jeden Bereich und blockiert alles, was mit dem reservierten Tunnelbereich, einer Organisations-VPN-Route oder einem anderen Direkt-VPN auf derselben Anlage kollidieren würde.
Prüfen und anwenden — bestätigen Sie die Zusammenfassung und klicken Sie dann auf Anwenden.

Der Tunnel benennt sich selbst

Es gibt kein Namensfeld auszufüllen. Mirox benennt den Tunnel nach der Anlage und dem gewählten Protokoll — zum Beispiel Solarpark Nord OpenVPN-UDP — und hängt eine Nummer an, falls dieser Name bereits vergeben ist, sodass er auf der Anlage eindeutig ist. Umbenennen oder eine Beschreibung ergänzen können Sie jederzeit unter Bearbeiten → Allgemein.

Speichern Sie die Zugangsdaten des gehosteten VPNs sofort

Wenn Sie ein gehostetes VPN erstellen, generiert Mirox die Konfiguration, die der Anlagen-Router zum Einwählen benötigt — einschließlich seines privaten Schlüssels bzw. Zertifikats — und zeigt sie nur einmal an. Laden Sie sie herunter und auf den Router, bevor Sie den Dialog schließen; sie kann später nicht mehr abgerufen werden. Geht sie verloren, rotieren Sie den Peer (WireGuard) bzw. die Zertifikate (OpenVPN), um eine neue zu erhalten.

Sobald der Tunnel steht, werden die Geräte in den konfigurierten Anlagen-Subnetzen erreichbar, und jede Netzwerkgeräte-Erkennung, die Sie auf der Anlage ausführen, scannt durch ihn hindurch.

Die Standardroute ist niemals erlaubt

Ein Direkt-VPN trägt niemals eine 0.0.0.0/0-Route nach dem Prinzip „alles senden“. Listen Sie stets die expliziten Anlagen-Subnetze auf, die Sie erreichen möchten. Wenn Sie eine Konfiguration hochladen, die eine Standardroute enthält, entfernt die Plattform diese und fordert Sie auf, die spezifischen Bereiche hinzuzufügen.

Ein bestehendes Direkt-VPN verwalten

Jedes Direkt-VPN erscheint als Karte auf dem Tab Site VPN, gekennzeichnet als Server (gehostet) oder Client (ausgehend), mit einer Live-Verbindungsleiste und einem Traffic-Indikator. Bei einem gehosteten VPN mit mehreren verbindenden Standorten zeigt die Leiste den schlechtesten verbindenden Peer — ein ausgefallener Standort färbt die gesamte Karte ein. Öffnen Sie das ...-Menü der Karte für:

Bearbeiten — Name, Beschreibung, Subnetze, Verbindungseinstellungen oder Schlüssel ändern. Der Bearbeitungsdialog hat die Tabs Allgemein, Subnetze, Konfiguration (Protokolleinstellungen) und Remote Peer (Schlüssel/Zertifikat der Gegenseite, Rotation und das Hinzufügen weiterer Peers).
VPN neu starten — den Tunnel ohne Änderung seiner Konfiguration durchstarten; nützlich nach einer Einstellungsänderung oder einem kurzzeitigen Abbruch.
Live-Status — den Inspektionsdialog öffnen (siehe unten) mit Live-Zustand je Peer, Logs, Diagnose und Debug-Werkzeugen.
Diagnose — (wird angezeigt, wenn der Tunnel aktuell getrennt ist) direkt zur automatischen Diagnose springen.
Peers verwalten — (gehostete VPNs mit mehr als einem verbindenden Standort) zum Tab Peers springen.
Löschen — den Tunnel entfernen. Zur Bestätigung müssen Sie den Namen des Tunnels eintippen; der Dialog listet die Netzwerkgeräte auf, die ihre Route verlieren würden.

Der Inspektionsdialog: Live-Status, Logs, Diagnose, Debug

Live-Status auf einer Karte öffnet einen Dialog mit vier Tabs und einem Live-Verbindungs-Badge:

Live-Status — eine Karte pro Peer, etwa einmal pro Sekunde aktualisiert, direkt von der Anlage: Verbindungszustand, Tunnel-IP, Endpunkt, empfangener/gesendeter Datenverkehr mit Live-Raten und — protokollspezifisch — das Handshake-Alter (WireGuard; mehr als ~3 Minuten bedeutet, dass die Verbindung aktuell nicht etabliert ist) oder die Sitzungsdauer (OpenVPN). Peers mit einer Tunnel-Adresse erhalten ein eingebettetes Latenz-Diagramm aus einer kontinuierlichen Erreichbarkeitsprüfung.
Diagnose — die automatische Diagnose mit einem Klick: Ein KI-Assistent liest die jüngsten Logs und den Live-Zustand des Tunnels, erklärt seine Befunde in verständlicher Sprache und kann — bei OpenVPN-Einstellungskonflikten — eine sichere Konfigurationskorrektur vorschlagen, die Sie mit einem Klick anwenden. Siehe auch die Seite KI-Assistent.
Logs — das Live-Verbindungslog des Tunnels mit farblicher Kennzeichnung der Log-Level und Zurückblättern in die Historie.
Debug — rein lesende Werkzeuge, die an der Anlage ausgeführt werden: die Routing-Tabelle des Tunnels, ein frei wählbarer Ping durch den Tunnel und eine ICMP-Aufzeichnung, die zeigt, ob Anfragen tatsächlich hinausgehen und ob überhaupt etwas antwortet — der klassische Weg, „Tunnel steht, aber der Standort antwortet nicht“ von „Tunnel ist unten“ zu unterscheiden.

Einen gehosteten WireGuard-Peer neu verbinden

WireGuard schlägt die Gegenstelle einmal nach, beim Start des Tunnels — ein Standort-Peer findet diesen Server also nicht wieder, wenn sich dessen Adresse ändert. Ist der Tunnel eines solchen Peers unterbrochen, bietet seine Karte unter Live-Status eine Schaltfläche Neu verbinden mit bereits eingetragener zuletzt bekannter Adresse und Port — ein einziger Handshake von unserer Seite genügt: Der Peer löst die Adresse neu auf und trägt die Verbindung danach selbst. Passen Sie die Felder an, wenn der Standort umgezogen ist.

Angeboten wird das nur bei einem gehosteten WireGuard-VPN, nur solange dieser Peer getrennt ist, und es ändert nichts Gespeichertes — es wird keine Konfiguration geschrieben und der Agent der Anlage nicht neu gestartet. Nichts, was Sie hier eingeben, kann die Lage verschlechtern: Meldet sich der Peer später von einer anderen Adresse, übernimmt WireGuard schlicht die Adresse, von der das Paket tatsächlich kam.

„Keine Daten — möglicherweise veraltet“

Das Live-Badge wird rot, wenn kein frischer Messwert eintrifft. Das bedeutet, dass der Messwert nicht verfügbar ist — es wird bewusst niemals als „Tunnel unten“ angezeigt, denn ein fehlender Messwert ist kein Beleg für einen Ausfall.

Die Anlagen-Subnetze verwalten

Die Subnetze, die ein Direkt-VPN routet, machen die Geräte der Anlage erreichbar. Fügen Sie Bereiche jederzeit aus der Bearbeiten-Ansicht des VPNs hinzu oder entfernen Sie sie. Das Entfernen eines Subnetzes, hinter dem sich noch Netzwerkgeräte befinden, lässt diese Geräte ohne Route zurück — der Löschdialog warnt Sie und listet auf, welche Geräte betroffen sind, sodass Sie sie zuerst einem anderen Tunnel zuweisen können.

Gehostetes VPN: Verbindende Peers

Ein gehostetes VPN nimmt verbindende Peers zweier Arten an:

Site-Peers — der Anlagen-Router selbst (oder ein anderer fester Standort), der sich einwählt und seine Subnetze ankündigt. Der erste Site-Peer wird beim Einrichten eines gehosteten VPNs für Sie erstellt; sein Schlüssel bzw. Zertifikat liegt im Tab Remote Peer des Bearbeitungsdialogs. Ein gehostetes VPN kann mehrere Site-Peers bedienen — etwa eine Anlage, die auf mehrere Router aufgeteilt ist, von denen jeder seine eigenen Bereiche ankündigt.
Benutzer-Peers — einzelne Personen, die sich mit einem persönlichen Profil in denselben gehosteten Server einwählen. Ein getrennter Benutzer-Peer ist normal (Personen verbinden sich bei Bedarf) und zählt niemals als Standortausfall.

Bei mehr als einem Site-Peer zeigt die Netzwerk-Seite der Anlage den Tab Peers: eine Tabelle aller verbindenden Peers mit Tunnel-IP, Identität (öffentlicher WireGuard-Schlüssel oder OpenVPN-Zertifikatsname), Datenverkehr, Verbindungshistorie und Bearbeitung je Peer (Subnetze, Schlüssel-/Zertifikatsrotation, Löschen). Bei einem einzelnen Site-Peer liegen dieselben Einstellungen direkt im Bearbeitungsdialog und der Tab Peers bleibt ausgeblendet.

Das Löschen eines gehosteten Servers ist destruktiv

Das Löschen eines gehosteten VPNs entfernt den Server und jeden verbindenden Peer — Standorte wie Benutzer. Deren Konfigurationen funktionieren sofort nicht mehr und können nicht neu ausgestellt werden; wird der Server später neu erstellt, müssen an jeden Peer frische Konfigurationen ausgegeben werden.

Wenn der Tunnel sich nicht verbindet

Der Tab Diagnose automatisiert das meiste hiervon; die folgenden Muster sind das, wonach er (und der KI-Assistent) sucht:

Symptom	Wahrscheinlichste Ursache	Wo nachsehen
Gehostetes VPN, ein Peer hat sich noch nie verbunden	Die generierte Konfiguration wurde nie auf dem Router installiert, oder sie wählt die falsche Adresse bzw. den falschen Port	Peer-Konfiguration auf den Router laden; Endpunkt auf der Karte prüfen
Peer war verbunden, jetzt getrennt, Logs zeigen „sent … received 0“	Der entfernte Router antwortet nicht mehr — oft nach einem Router- oder Modem-Neustart	Entfernten Router/Modem stromlos neu starten; dessen Internet-Uplink prüfen
Tunnel verbunden, aber Geräte nicht erreichbar	Der Standort-Router blockiert den Verkehr oder routet ihn nicht (bei mehreren Router-Marken landen VPN-Schnittstellen standardmäßig in einer WAN-ähnlichen Zone, die nur ausgehenden Verkehr erlaubt)	Debug-Tab: Ping + ICMP-Aufzeichnung — „Verkehr geht hinaus, aber nichts antwortet“ bestätigt es; Route/Firewall-Regel auf dem Router hinzufügen
Ausgehendes OpenVPN verbindet sich nie	Einstellungskonflikt mit dem entfernten Server (Cipher, TLS-Version, Komprimierung …)	Diagnose ausführen — sie kann die passenden Einstellungen als Ein-Klick-Korrektur vorschlagen
Ausgehendes WireGuard direkt nach einer Schlüssel-/PSK-Änderung getrennt	Der Tunnel hat die neuen Schlüssel noch nicht neu geladen	VPN neu starten auf der Karte
Verbindung flattert (wiederholt auf/ab)	Instabiler Uplink am entfernten Standort, oder eine Peer-Konfiguration wird von zwei Geräten verwendet	Verbindungshistorie auf der Karte; je Gerät einen eigenen Peer ausstellen
Alles an der Anlage gleichzeitig ausgefallen	Internet- oder Stromausfall am Standort — kein VPN-Problem	Die Verbindungs-Pipeline im Tab Übersicht