Datenübertragung mit OPC-oder VPN-Tunnel

Roli

Level-1
Beiträge
10
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
es geht darum, mehrere Datenpunkte übers Internet zu übertragen. Auf einer Seite sitzt ein Beckhoff CX mit WIN XP und einem OPC-Server. Auf der anderen Seite des "internets" läuft ein PC dessen OPC-Client die Daten in eine Datenbank schreiben soll.
eins vorweg:OPC UA kann nicht eingesetzt werden.
Nun zum Problem:
--es gibt Freeware OPC-Tunneler die recht simpel einzusetzen sind und wahrscheinlich nicht schlecht funktionieren. Aber der Sicherheitsaspekt bleibt dabei ziemlich auf der Strecke, weil bei den Routern Ports geöffnet werden müssen.
--Mit einem von Windows verwalteten VPN Tunnel bekomm ich zwar die Verbindung zustande, aber ich kann mit dem Client nicht auf den Server zugreifen. Müsste man hier mit den berüchtigten DCOM-Einstellungen beginnen, oder gibt es einen anderen Weg?
--Wer hat Erfahrung damit und kann mir bitte weiterhelfen?
 
ich habe sowas auch schon mal realisieren müssen (ist aber schon eine ganze Weile her).
ich habe es mit selbstgeschriebenen verteilter Applikation gelöst.
d.h. auf dem Server lief gleichzeitig auch ein OPC-Client, welcher wiederrum als Server für meinen Client-PC (hier: Datenbank-Client) diente.
Vorteil: Der OPC-Client auf dem Server pufferte die Daten bei fehlerhafter Internetverbindung. Sobald diese wieder verfügbar war, wurden die Daten "nach-gesendet". ich habe es damals mit WCF und VPN gelöst. Ist aber auch ohne VPN machbar.
 
Hallo,

es gibt dazu im Grunde nur 3 Möglichkeiten:

1.) DCOM Ports zum Internet hin öffnen, was kompletter Wahnsinn wäre.
Also bitte NICHT machen.

2.) Die schon erwähnten Tunnel-Lösungen.
Solche Tunneler gibts z.B. von Softing und Matrikon.
Ich weiß nicht welche Ports das proprietäre Protokoll dann nützt,
aber das könnte man dann wieder über VPN oder SSH tunneln um eventuell fehlende Sicherheit hinzuzufügen.

3.) OPC UA
Warum kann das nicht gemacht werden?
Beckhoff hat sogar schon OPC UA Server auf der SPS.
Auf Client-Seite könnte man dann immer noch einen OPC UA/DA Wrapper einsetzen. Solche Wrapper (oder Gateways) gibts z.B. bei Unified Automation.
Das ist meiner Meinung nach die beste Lösung.

UA verwendet nur einen Port, den man leicht in der Firewall freischalten, oder auch über VPN tunneln kann.
Security ist mit dabei bei UA.
Keine DCOM Konfiguration.
Mit einem Gateway für die Umsetzung auf der Client Seite kann man auch ganz einfach einen klassischen OPC DA Client anschließen. Z.b. ein HMI.

Mit UA/DA Gateways auf beiden Seiten kann man sogar auch OPC DA über OPC UA "tunneln".
 
Ich habe das schonmal mit einer Portweiterleitung durch einen SSH-Tunnel versucht, aber das scheint irgendwie nicht zu funktionieren. Vielleicht weiß ja jemand einen Grund (Dr.OPC?).

Und zwar habe ich es vom Prinzip her wie in der Beschreibung auf dieser Seite gemacht:
http://www.blisstonia.com/eolson/notes/smboverssh.php

Rechnernamen:
A: Rechner mit dem OPC-Server
B: Rechner mit OPC-Client

Auf Rechner A habe ich einen SSH-Server installiert. Auf Rechner B habe ich einen SSH-Client (Putty) laufen. Dort habe ich einen SSH-Port-Tunnel eingerichtet, welcher mir IP:port 127.0.0.1:135 durch den SSH-Tunnel schicken soll.
Wenn man die Verbindung beobachtet wenn man sich direkt über Netzwerk verbindet, sollte Port 135 ausreichend sein.
Es scheint jedoch so, dass die Suche nach OPC-Servern auf dem eigenen Rechner nicht über localhost und Port 135 läuft. Oder ich kann nicht alle Anfragen auf localhost und Port 135 durch den Tunnel schicken.

Ich habe es auch schon mit einem zusätzlichen Loopback-Adapter probiert, und den Tunnel dementsprechend angepasst - funktioniert aber auch nicht.

Prinzipiell funktioniert das SSH-Tunneling bei mir, ich habe das schon für einige andere Anwendungen so laufen, aber eben auf anderen (höheren) Ports.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe das schonmal mit einer Portweiterleitung durch einen SSH-Tunnel versucht, aber das scheint irgendwie nicht zu funktionieren. Vielleicht weiß ja jemand einen Grund (Dr.OPC?).
Wenn Du mich schon fragst werde ich versuchen es zu erklären. Einfach gesprochen ist es so: DCOM verwendet zwar den Port 135 um auf der Gegenseite Objekte zu kreieren, dann werden aber sofort "dynamisch" andere Ports ausgehandelt über die dann kommuniziert wird. Diese dynamischen Ports liegen in einem viel höheren Bereich und sind "zufällig" gewählt.

Mit anderen Worten: nur den Port 135 forwarden bringt nichts, denn es kommen direkt nach Instantiierung der Gegenseite dynamisch weitere Ports dazu. (nur das initiale "Aushandeln" welche anderen Ports das genau sind, passiert über den Port 135)

Die Tunnel-Produkte (von verschiedenen Herstellern z.B. Softing oder Matrikon) schicken die Daten über das Netz in einem eigenen Protokoll das (wie du schon erkannt hast, meist völlig ungesichert ist) ABER nur einen Port benötigt (z.B. über http Port 80 läuft) nur dann hast du eine Chance dieses über einen (gesicherten) VPN Tunnel zu forwarden. Also ein OPCTunnel der in einem VPNTunnel steckt.

Microsoft sagt:
Distributed Component Object Model (DCOM) uses Remote Procedure Call (RPC) dynamic port allocation. By default, RPC dynamic port allocation randomly selects port numbers above 1024. You can control which ports RPC dynamically allocates for incoming communication and then configure your firewall to confine incoming external communication to only those ports and port 135 (the RPC Endpoint Mapper port).
Du könntest also noch versuchen Windows so zu konfigurieren, dass die dynamischen Ports nicht zufällig vergeben werden, sondern sich nur in einem ganz bestimmten "Bereich" befinden dürfen und diese Ports schleust du auch noch (zusätzlich zum 135) über VPN rüber. Ob das wirklich funktioniert habe ich selber aber noch nicht probiert.

Daher nochmal die Frage (auch schon von gergap gestellt): Warum kannst/willst du nicht OPC UA benutzen, das verwendet nur einen Port (default 4840) kann aber auch auf jeden anderen konfiguriert werden und die Verschlüsselung (SSL) ist schon dabei, auch ohne VPN.
 
Zuletzt bearbeitet:
Wenn Du mich schon fragst werde ich versuchen es zu erklären. Einfach gesprochen ist es so: DCOM verwendet zwar den Port 135 um auf der Gegenseite Objekte zu kreieren, dann werden aber sofort "dynamisch" andere Ports ausgehandelt über die dann kommuniziert wird. Diese dynamischen Ports liegen in einem viel höheren Bereich und sind "zufällig" gewählt.

Mit anderen Worten: nur den Port 135 forwarden bringt nichts, denn es kommen direkt nach Instantiierung der Gegenseite dynamisch weitere Ports dazu. (nur das initiale "Aushandeln" welche anderen Ports das genau sind, passiert über den Port 135)
Wie ich mittlerweile festgestellt habe, lässt es sich wohl nicht einrichten dass Port 135 überhaupt getunnelt wird. Selbst wenn ich einen weiteren Loopback-Adapter einrichte, nimmt Windows hier sofort Port 135 in Beschlag sodass ich darauf nie einen eigenen Server ans Laufen bekomme.
Wenn ich auf dem Loopback-Adapter alle Protokolle bis auf TCP/IP deaktiviere, wird zwar auf dieser IP-Adresse der Port nicht mehr als belegt angezeigt (bei netstat -a -n), aber durch den Tunnel bekommt man es trotzdem nicht. Liegt wohl an dem Eintrag "0.0.0.0:135" dass Windows immer als erstes zum Zug kommt.

Eigentlich schade, denn das wäre eine relativ einfache Möglichkeit gewesen, eine gesicherte und vor allem einfach zu konfigurierende OPC-Verbindung zwischen zwei Rechnern herzustellen.
Ich habe letztens noch krampfhaft versucht eine DCOM Verbindung zu einem Siemens IPC und WinCCflexible OPC-Server hinzubekommen, war nichts zu machen (Siemens Support wusste auch nicht weiter). Auf einem anderen Rechner auch mit WinCCflex OPC habe ich es dagegen problemlos ans Laufen bekommen - manchmal steckt da echt der Teufel drin...
 
Deinen VPN Tunnel kannst du abschreiben. Ausser du hast zusätzlich noch einen Softing- oder Matrikon-Tunnel, der die wilde DCOMKommunikation erstmal auf einen Port "begrenzt", und den du dann über VPN schiebst. Auch david.ka hat das offenbar so gemacht.

Da Beckhoff schon OPC UA bietet (eine Seite hast du also schon) verstehe ich nur nicht warum du auf der anderen Seite nicht einfach auch UA machst?

Ich habe letztens noch krampfhaft versucht eine DCOM Verbindung zu einem Siemens IPC und WinCCflexible OPC-Server hinzubekommen
Ich bin vor Jahren schon über diese Anleitung gestolpert (unten auf der Seite findest du eine Checkliste für DCOM Einstellungen) und sie hat mit schon mehrfach geholfen, vielleicht "entkrampft" es auch dich. :ROFLMAO:
http://www.ascolab.com/de/dokumente.html
 
Zurück
Oben