Netzwerkanforderungen für Firewall und Proxy
Diese Seite listet die Ziele im Internet, die der OPC Router von sich aus anspricht – Lizenzierung, pronubes-Anbindung, Solution Gallery – mit Port und Zweck. Sie richtet sich an die Netzwerkabteilung und kann unverändert weitergegeben werden.
Welche Ports der OPC Router selbst belegt und was davon eingehend freizugeben ist, steht unter Netzwerk-Ports. Verbindungen der Plug-ins zu angebundenen Systemen – OPC-Server, Datenbanken, MQTT-Broker – sind projektspezifisch und in keiner der beiden Listen enthalten; sie planen Sie bei der Projektierung, siehe Netzwerkeinstellungen.
Der OPC Router läuft als Windows-Dienst beziehungsweise als Container-Prozess. Beide übernehmen die Proxy-Einstellungen des angemeldeten Benutzers nicht. In Netzen mit Pflicht-Proxy, restriktiver Firewall oder TLS-Inspection scheitern ausgehende Verbindungen deshalb, obwohl dieselbe Adresse im Browser auf demselben Rechner funktioniert.
Aufgebaut werden sie vom Dienst Web Management (inray.OPCRouter.Web.Management), der dauerhaft im Hintergrund läuft – unabhängig davon, ob die Oberfläche geöffnet ist.
Ausgehende Verbindungen
In der folgenden Tabelle werden die ausgehenden Verbindungen aufgelistet und für jedes Ziel erklärt, wofür es gebraucht wird und ob es für den Betrieb erforderlich ist.
| Ziel | Port | Protokoll | Zweck | Pflicht/Optional |
|---|---|---|---|---|
license.opc-router.com | 443 | HTTPS (GraphQL) | Online-Lizenzierung: Lizenzprüfung und -aktivierung, siehe Lizenz im OPC Router aktivieren | Pflicht |
opcrouter.eu.auth0.com | 443 | HTTPS | Device-Code-Anmeldung bei der Lizenzaktivierung über einen Benutzer-Account statt eines Lizenzschlüssels | Optional – nur bei diesem Anmeldeweg |
login.opc-router.cloud | 443 | HTTPS | B2C-Anmeldung am Lizenzportal (älterer Anmeldeweg) | Optional – nur bei diesem Anmeldeweg |
<tenant>.pronubes.cloud | konfigurierbar, Standard 443 | HTTPS | pronubes-Anbindung: Health Sharing, Projektupload, Connection Targets. Adresse und Port stellen Sie unter pronubes Connectivity ein. | Optional – nur wenn „pronubes aktivieren“ eingeschaltet ist |
<tenant>.pronubes.cloud | wie oben | WSS (dauerhafte WebSocket-Verbindung) | Fernverwaltung des Routers aus dem pronubes-Management heraus | Optional – nur wenn zusätzlich „Fernverwaltung aktivieren“ eingeschaltet ist |
github.com, codeload.github.com | 443 | HTTPS | Solution Gallery: Abruf aus dem Repository OPC-Router/solutions; der Download folgt einer Weiterleitung von github.com auf codeload.github.com | Optional – nur bei der Standardquelle. Zeigt OR_SOLUTION_GALLERY auf eine eigene Quelle, gilt deren Adresse. |
*.pki.goog, mindestens c.pki.goog und i.pki.goog | 80 | HTTP | Zertifikatsprüfung für license.opc-router.com, login.opc-router.cloud und <tenant>.pronubes.cloud, ausgestellt von Google Trust Services | Pflicht |
*.lencr.org, mindestens ye1.c.lencr.org und ye1.i.lencr.org | 80 | HTTP | Zertifikatsprüfung für opcrouter.eu.auth0.com, ausgestellt von Let's Encrypt | Pflicht bei Device-Code-Anmeldung |
Zertifikatsprüfung über HTTP auf Port 80
Zwei Eigenschaften dieser Ziele führen regelmäßig zu Fehlersuchen:
- Port 80 statt 443. Sperrlisten und Zwischenzertifikate werden als reines HTTP ausgeliefert; beide sind von der Zertifizierungsstelle signiert und brauchen keine eigene Transportverschlüsselung. Eine Regel, die ausgehend nur 443 erlaubt, deckt sie nicht ab.
- Teil der Zertifikatsprüfung, nicht des Produkts. Die Abfragen stellt das Betriebssystem beim Validieren des Serverzertifikats, nicht der OPC Router. Schlagen sie fehl, meldet der Fehler die Adresse des eigentlichen Ziels – etwa
license.opc-router.com–, nicht das gesperrte Ziel auf Port 80.
Die beiden Unterdomänen erfüllen dabei verschiedene Aufgaben: c. liefert die Sperrliste (CRL), i. das Zwischenzertifikat der ausstellenden Stelle. Google Trust Services und Let's Encrypt betreiben keinen OCSP-Responder mehr; ihre Zertifikate nennen ausschließlich einen CRL-Verteilungspunkt. Eine Freigabe für OCSP ist für diese beiden Stellen damit gegenstandslos.
Verarbeitet Ihre Firewall keine Wildcards, geben Sie c.pki.goog, i.pki.goog, ye1.c.lencr.org und ye1.i.lencr.org einzeln frei. Die Zertifizierungsstellen wechseln diese Präfixe bei einer Zertifikatserneuerung; die Wildcard-Regel hält länger.
Lizenzierung von pronubes Edge
Geben Sie zusätzlich license.pronubes.com über TCP 443 frei – darüber laufen Lizenzaktivierung und Lizenzabgleich von pronubes Edge. Die Zertifikatsprüfung dieses Ziels deckt *.pki.goog bereits ab. Die vollständige Liste für pronubes Edge steht in der pronubes-Dokumentation.
Regeln für Arbeitsplatz-Ziele
Die obige Tabelle nennt ausschließlich Ziele, die der OPC Router selbst anspricht. In dieser Tabelle werden die Ziele genannt, die nur an einem Arbeitsplatz mit Browser gebraucht werden und keine Freigabe auf dem Server benötigen, auf dem der OPC Router läuft.
| Ziel | Port | Protokoll | Zweck |
|---|---|---|---|
license.opc-router.com, license.opc-router.de, login.opc-router.cloud | 443 | HTTPS | Zugriff auf das Lizenzportal und Anmeldung dort. Die deutsche Oberfläche verlinkt auf license.opc-router.de, die englische auf license.opc-router.com. |
<tenant>.pronubes.cloud | 443 | HTTPS | Zugriff auf das pronubes-Portal |
pronubes.eu.auth0.com | 443 | HTTPS | Anmeldung bei pronubes Management |
cdn.auth0.com | 443 | HTTPS | Grafiken für die Anmeldeseite |
*.lencr.org, mindestens ye1.c.lencr.org und ye1.i.lencr.org | 80 | HTTP | Zertifikatsprüfung für pronubes.eu.auth0.com |
*.pki.goog | 80 | HTTP | Zertifikatsprüfung für <tenant>.pronubes.cloud und das Lizenzportal |
An einem Arbeitsplatz mit normalem Internetzugang sind diese Ziele in der Regel erreichbar. Eine eigene Regel ist nur nötig, wenn auch die Arbeitsplätze hinter einer Freigabeliste stehen.
Ziele für Login-Anbieter
Das pronubes Management bietet die Möglichkeit, sich zusätzlich zum Login mit E-Mail und Passwort auch mit einem Microsoft- oder Google-Account anzumelden. Im Folgenden sind für jeden Login-Anbieter die Ziele aufgelistet, damit der Login mit ihnen reibungslos funktioniert. Diese Ziele werden nur benötigt, wenn diese Anbieter verwendet werden.
Ziele für den Microsoft-Login
| Ziel | Port | Protokoll | Zweck |
|---|---|---|---|
login.microsoftonline.com | 443 | HTTPS | Microsoft-Anmeldung |
aadcdn.msftauth.net, aadcdn.msauth.net | 443 | HTTPS | Grafiken für die Anmeldeseite |
Ziele für den Google-Login
| Ziel | Port | Protokoll | Zweck |
|---|---|---|---|
accounts.google.com | 443 | HTTPS | Google-Anmeldung |
accounts.google.de | 443 | HTTPS | Google-Anmeldung: länderspezifische Weiterleitung für den deutschen Login. Außerhalb Deutschlands kann statt .de eine andere länderspezifische Domain nötig sein. |
gstatic.com, fonts.gstatic.com | 443 | HTTPS | Schriften für die Anmeldeseite |
Proxy-Verhalten
- Ein Proxy wird je Dienst über die Umgebungsvariablen
HTTPS_PROXYundNO_PROXYgesetzt. Im Container übergeben Sie sie wie die übrigen konfigurierbaren Umgebungsvariablen. NO_PROXYmuss alle internen Ziele enthalten, die nicht über den Proxy laufen sollen – insbesondere HTTP- und REST-Plug-in-Ziele, den Redundanzpartner undlocalhost. Die Einstellung wirkt prozessweit: Fehlt ein internes Ziel, versucht der Dienst auch diese Verbindung über den Proxy aufzubauen.- Ein Proxy mit Authentifizierung wird derzeit nicht unterstützt.
Bei der Windows-Installation deckt HTTPS_PROXY den Sperrlisten-Verkehr auf Port 80 nicht ab. Die Prüfung führen dort die Zertifikatsdienste von Windows durch, und diese verwenden die systemweite WinHTTP-Konfiguration statt der Umgebungsvariablen des Dienstes. Erlaubt Ihr Netz kein direktes ausgehendes HTTP, müssen die Sperrlisten-Ziele zusätzlich über den WinHTTP-Proxy erreichbar sein. Prüfen mit netsh winhttp show proxy.
TLS-Inspection
Setzt Ihr Netz TLS-Inspection ein, braucht der OPC Router eines von beiden:
- eine Ausnahme von der Inspection für die oben genannten Ziele, oder
- das Zertifikat der Inspection-Zertifizierungsstelle im Zertifikatsspeicher des lokalen Computers – nicht nur in dem des angemeldeten Benutzers.
Prüfanleitung
-
Direkten Weg testen. Prüfen Sie vom Rechner mit dem OPC Router aus beide Ports – die HTTPS-Ziele auf 443, die Sperrlisten-Ziele auf 80:
Test-NetConnection license.opc-router.com -Port 443
Test-NetConnection c.pki.goog -Port 80 -
TLS-Handshake prüfen, nicht nur den Port. Ein offener Port belegt nicht, dass eine TLS-Inspection die Verbindung unverändert durchlässt:
Invoke-WebRequest https://license.opc-router.com -UseBasicParsingMeldungen wie „Die SSL-Verbindung konnte nicht hergestellt werden“ oder „Das Remotezertifikat ist ungültig“ deuten auf TLS-Inspection oder eine fehlgeschlagene Sperrlistenprüfung, nicht auf einen gesperrten Port.
-
Proxy-Protokoll prüfen. Fehlt ein Ziel im Protokoll des Proxys vollständig, nutzt der Dienst den Proxy nicht – prüfen Sie dann seine Umgebungsvariablen. Erscheint es mit einer Sperrung, fehlt die Regel auf dem Proxy.
-
Status im Produkt prüfen. Kontrollieren Sie den Lizenzstatus und – falls konfiguriert – den Verbindungsstatus zu pronubes im Web Management.