Troubleshooting und Migration zur Secure Redundanz
Ab Version 5.4 wird die Legacy-Redundanz nicht mehr unterstützt. Für eine nahtlose und sichere Kommunikation müssen alle Ihre Instanzen dieselbe Redundanzversion verwenden. Bitte beachten Sie, dass die verschiedenen Redundanzversionen nicht miteinander kompatibel sind.
Die Secure Redundanz verwendet einen gemeinsamen Pre-Shared-Key und ermöglicht dadurch eine sichere, verschlüsselte Kommunikation zwischen Primär- und Sekundärdienst. Wenn Sie bisher die Legacy Redundanz verwendet haben, sollten Sie diese Anleitung für den Umstieg auf die Secure Redundanz sorgfältig durchgehen.
Diese Seite ergänzt die eigentliche Konfiguration der Redundanz. Sie beschreibt die Einrichtung der Secure Redundanz für neue Konfigurationen und Migrationen, sowie typische Fehler bei Verbindung, Zertifikaten und Pre-Shared-Key.
Hinweise zum Einrichten von Secure Redundanz bei Migration und Neueinrichtung
Primärdienst
Die eigentliche Konfiguration wird im aktuellen Dialog in Redundanz beschrieben. Für neue Konfigurationen und Migrationen ist an dieser Stelle vor allem wichtig, dass Sie den Pre-Shared-Key zuerst erzeugen und anschließend in beiden Systemen konsistent hinterlegen.
Öffnen Sie im Bereich Pre-Shared-Key zunächst die Schaltfläche Generieren. Dadurch wird ein neuer Schlüsselwert erzeugt. Fügen Sie diesen Wert danach in die Zwischenablage ein und übernehmen Sie ihn in das Schlüsselpaar, das auf Primär- und Sekundärdienst verwendet werden soll.
Im Bearbeiten-Dialog wird der Schlüssel im internen Store angelegt. Verwenden Sie einen eindeutigen Key und übernehmen Sie den zuvor generierten Wert in Wert. Speichern Sie den Eintrag anschließend, um ihn für die aktuelle OPC Router-Instanz zu verwenden.
Die Generierung des Pre-Shared-Key ist auch über den „Sekundärdienst“ möglich. Wichtig ist, dass Sie denselben Pre-Shared-Key auf dem Primär- und Sekundärdienst haben.
Sekundärdienst
Konfigurieren Sie danach den Sekundärdienst entsprechend der aktuellen Beschreibung in Redundanz. Stellen Sie dabei sicher, dass derselbe Pre-Shared-Key verwendet wird und dass der Sekundärdienst das Web-Management des Primärdienstes erreichen kann.
Veröffentlichen Sie die Änderungen sowohl auf dem Primär- als auch auf dem Sekundärdienst. Danach können Sie die Verbindung testen und prüfen, ob der Sekundärdienst den Primärdienst erreicht. Der Sekundärdienst sollte anschließend im Zustand Standby bleiben, bis der Primärdienst nicht mehr erreichbar ist.
Troubleshooting
Adresse oder DNS-Name kann nicht aufgelöst werden
Wenn Sie diese Fehlermeldung während des Verbindungstests erhalten, kann der konfigurierte Hostname oder DNS-Name nicht aufgelöst werden.
Prüfen Sie, dass Sie die richtige IP-Adresse oder den richtigen DNS-Namen im korrekten Format verwenden.
Läuft der OPC Router in einer Dockerumgebung mit internem Netzwerk, wird dort der Dockername als Adresse verwendet.
Port ist nicht verfügbar
Diese Fehlermeldung kann auftauchen, wenn die Adresse (IP / DNS-Name) stimmt, aber der Dienst nicht auf dem Port ist.
Prüfen Sie, dass Sie den richtigen Port adressieren, dass der Dienst dort tatsächlich lauscht und dass keine Firewall die Verbindung blockiert.
Bei interner Dockerkommunikation im internen Netzwerk einer Dockerumgebung muss der eigene Port und nicht der exponierte Port verwendet werden. Wird der Docker zum Beispiel mit der Portzuordnung -p 8083:8080 exponiert, dann wird im internen Netzwerk auf Port 8080 zugegriffen.
Pre-Shared-Keys unterscheiden sich zwischen den beiden Diensten
Diese Fehlermeldung kann auftreten, wenn sich der Pre-Shared-Key auf Primär- und Sekundärdienst unterscheidet oder nicht konsistent im internen Store hinterlegt wurde.
Es genügt, den Pre-Shared-Key auf dem Primärdienst zu generieren, ihn zu kopieren und anschließend identisch in den Sekundärdienst einzufügen.
Achten Sie darauf, dass Sie die Änderungen nach der Generierung des neuen Pre-Shared-Keys auf Ihrem Primärdienst veröffentlichen, bevor Sie die Verbindung erneut testen.
Zertifikatsprobleme (HTTPS)
Diese Fehlermeldung kann auftreten, wenn Sie HTTPS für den Primärdienst verwenden, das zugehörige (möglicherweise selbst signierte) Zertifikat aber auf dem Sekundärdienst noch nicht als vertrauenswürdig verfügbar ist.
Wenn auf dem Primärdienst ein selbst signiertes Zertifikat verwendet wird, können Sie das gewählte Zertifikat dort in der Zertifikatsverwaltung ohne privaten Schlüssel exportieren und anschließend auf dem Sekundärdienst importieren.
Wählen Sie danach auf dem Sekundärdienst, über welchen Zertifikatsspeicher das Zertifikat als vertrauenswürdig bereitgestellt werden soll:
- Router: Importieren Sie das Zertifikat in die Zertifikatsverwaltung des OPC Routers und wählen Sie in den Redundanzeinstellungen bei Vertrauenswürdige Zertifikate die Option Router.
- Windows: Importieren Sie das Zertifikat in den Windows-Zertifikatsspeicher und wählen Sie in den Redundanzeinstellungen bei Vertrauenswürdige Zertifikate die Option Windows.
Wenn Sie den OPC-Router-Zertifikatsspeicher verwenden, gehen Sie auf dem Sekundärdienst in drei Schritten vor:
- Öffnen Sie die Zertifikatsverwaltung über den Menüpunkt Zertifikate.
- Wählen Sie Import im Reiter OPC Router Zertifikate und importieren Sie das Zertifikat, das auf dem Primärdienst für HTTPS verwendet wird.
- Markieren Sie das importierte Zertifikat anschließend mit Vertrauen als vertrauenswürdig.
Der folgende Screenshot zeigt beispielhaft die Einstellung Router in den Redundanzeinstellungen.
Wenn der Primärdienst HTTPS verwendet, ist bei Windows-Installationen häufig 5001 statt 5000 relevant. Bei Docker-Containern wird intern standardmäßig Port 8443 verwendet; nach außen wird typischerweise Port 443 exponiert. Prüfen Sie deshalb in jedem Fall die Firewall-Freigabe und den tatsächlich verwendeten internen beziehungsweise exponierten Port.