TIA WinCC Basic Transfer und NAT

Liebe Leute,
ich hab eine Anwendung, für die ich aktuell keine Lösung finde.

Ich hab > 10 Stationen (abhängig von Anlagengröße zwischen 3 und 90), die alle identisch aufgebaut. Sie enthalten eine kleine 1512er-CPU und ein KTP400 Basic. Außerdem ein paar Profinet-Teilnehmer.
Um nicht für jede Station ein eigenes Projekt anlegen zu müssen, werden die Stationen alls per NAT ans Leitnetz angebunden. Die Kommunikation mit dem Leitsystem erfolgt per Iso-on-Tcp, weshalb ein einfaches NAT-Gerät im Einsatz ist. Nach außen besitzen die Stationen 1 IP.

Um größere SW-Updates auszurollen hat es sich bewährt, die TCP-Ports 102 (CPU) und 2308 (Panel) nach aussen zu NAPTen, sodass das zentral vom Leitstand aus gemacht werden kann.

Mit V14 hat Siemens jetzt den Transfer zu den Basic-Panels auf TCP Port 102 umgestellt, womit das NAPTen mit einer öffentlichen IP so nicht mehr machbar ist. Aktuell hat das zur Folge, dass ich zu jeder Station hin muss und mich direkt anstöpseln muss.

Ich hab jetzt mal einiges probiert, aber wirklich schlauer bin ich nicht geworden. Wenn man sich den traffic an der WAN-Seite des NAT-Geräts ansieht, kommen vom PC nur Anfragen am TCP-Port 102 (die ja intern an die CPU weitergehen und Antworten produzieren). Dementsprechend kommt das TIA-Portal offensichtlich gar nicht auf die Idee, Alternativports (1033, 2308, 5001) zu probieren.
Hat jemand eine Idee oder einen praktikablen Ansatz, wo man ansetzen könnte, bevorzugt am Engineering-Rechner? VPN oder 2 öffentliche IPs kann das aktuell NAT-Gerät nicht, der Wechsel auf ein VPN-taugliches Gerät lässt sich aktuell preislich nicht darstellen.

Bitte um Hilfe.
lg

Vor längerer Zeit habe ich etwas ähnliches mal zur Fernwartung über einen SSH-Tunnel gemacht.
Also Port 102 über einen SSH-Tunnel mit Port 22 geschickt, und dann über den SSH-Server darüber auf die SPS zu gelangen (SSH Port Forwarding). Zusätzlich notwendig war dann ein Loopbackadapter mit der IP-Adresse der SPS. Ich habe mir dazu dann ein kleines Programm geschrieben, was je nach SPS die entsprechenden Einstellungen vorgenommen hat, also Loopbackadapter einstellen und aktivieren, SSH-Tunnel aufbauen.

Wenn ich das richtig verstehe was du vorhast, könnte das bei dir ebenfalls mit einem Loopbackadapter funktionieren, auf dem du dann mit einem kleinen Programm einen Server auf Port 102 startest und alle Daten auf eine andere Ziel-Adresse mit anderem Ziel-Port umsetzt. Port 102 ist auf einem PC mit Siemens Software aber immer schwierig, weil es einen Siemens-Dienst gibt der sehr penetrant diesen Port in Anspruch nehmen möchte.

Das Einfachste wäre es daher vermutlich, wenn du mit der Big-S-Software auf einer VM arbeitest. Die dann nur einen NAT-Adapter zum Host-Betriebssystem hat.
Auf dem kannst du dann einfach sagen, das es die IP-A von der VM auf IP-X-Port-100102 und IP-B von der VM auf IP-X-Port-110102 weiterleiten soll.
Dein NAT-Gateway auf der IP-X muss dann nur den Port-100102 auf die Interne erste IP dem Port-102 und den Port 110102 auf die zweite interne IP dem Port-102 zur Verfügung stellen...

So etwas sollte dein NAT-Gateway können und für die Siemens-Software macht es dann keinen Unterschied mehr, das dahinter faktisch nur eine IP irgendwo dazwischen liegt...

MfG Fabsi

Thomas_v2.1 schrieb:

Vor längerer Zeit habe ich etwas ähnliches mal zur Fernwartung über einen SSH-Tunnel gemacht.
Also Port 102 über einen SSH-Tunnel mit Port 22 geschickt, und dann über den SSH-Server darüber auf die SPS zu gelangen (SSH Port Forwarding). Zusätzlich notwendig war dann ein Loopbackadapter mit der IP-Adresse der SPS. Ich habe mir dazu dann ein kleines Programm geschrieben, was je nach SPS die entsprechenden Einstellungen vorgenommen hat, also Loopbackadapter einstellen und aktivieren, SSH-Tunnel aufbauen.

Wenn ich das richtig verstehe was du vorhast, könnte das bei dir ebenfalls mit einem Loopbackadapter funktionieren, auf dem du dann mit einem kleinen Programm einen Server auf Port 102 startest und alle Daten auf eine andere Ziel-Adresse mit anderem Ziel-Port umsetzt. Port 102 ist auf einem PC mit Siemens Software aber immer schwierig, weil es einen Siemens-Dienst gibt der sehr penetrant diesen Port in Anspruch nehmen möchte.

Zum Vergrößern anklicken....

Der Ansatz ist interessant, allerdings lässt sich das nicht so einfach umsetzen, da ich an der Gegenstelle ausser meinem NAT-Gerät, einer SPS und dem Panel nur Profinet-RT-Teilnehmer habe. Auf welcher Plattform ist der Loopback-Adapter gelaufen?

Fabpicard schrieb:

Das Einfachste wäre es daher vermutlich, wenn du mit der Big-S-Software auf einer VM arbeitest. Die dann nur einen NAT-Adapter zum Host-Betriebssystem hat.
Auf dem kannst du dann einfach sagen, das es die IP-A von der VM auf IP-X-Port-100102 und IP-B von der VM auf IP-X-Port-110102 weiterleiten soll.
Dein NAT-Gateway auf der IP-X muss dann nur den Port-100102 auf die Interne erste IP dem Port-102 und den Port 110102 auf die zweite interne IP dem Port-102 zur Verfügung stellen...

So etwas sollte dein NAT-Gateway können und für die Siemens-Software macht es dann keinen Unterschied mehr, das dahinter faktisch nur eine IP irgendwo dazwischen liegt...

MfG Fabsi

Zum Vergrößern anklicken....

Ganz Trivial ist das auch nicht, aber prinzipiell ist der Ansatz gangbar. Ich bräuchte in der VM 2 NAT-Schnittstellen, eine zum PLC-Transfer, eine für den Panel-Transfer. In der Panel-Transfer-Schnittstelle müsste dann die NAPT-Regel angesetzt werden, die prinzipiell jede Port 102-Anfrage auf 2308 umsetzt - oder Port 102 einfach sperrt. Diese Regel wäre dann in der Host-Maschine umzusetzen.

Ich werde mir das mal ansehen, wenn ich wieder etwas mehr Luft habe und gebe Bescheid, zu was ich gekommen bin.

Noch eine Frage zu dem Thema: Da der HMI-Transfer jetzt auch Port 102 nutzt, liegt die Vermutung nahe, dass es sich um eine RFC1006-Verbindung mit speziellem TSAP handelt. Prinzipiell ließe sich wohl auch ein Tunnel ausprogrammieren, welcher die Anfragen für einen bestimmten TSAP transparant ins lokale Netz weiterleitet? Was meint ihr?

Ich hab sowas ähnliches schon mal zum SMLP-Routing für SEW-Antriebe gemacht, allerdings hatte ich hierfür eine Vorlage und somit eine ganz grobe Protokoll-Beschreibung.

maxder2te schrieb:

Auf welcher Plattform ist der Loopback-Adapter gelaufen?

Zum Vergrößern anklicken....

Ein Loopbackadapter ist bei Windows dabei, kann über den Gerätemänager hinzugefügt werden.

maxder2te schrieb:

Noch eine Frage zu dem Thema: Da der HMI-Transfer jetzt auch Port 102 nutzt, liegt die Vermutung nahe, dass es sich um eine RFC1006-Verbindung mit speziellem TSAP handelt. Prinzipiell ließe sich wohl auch ein Tunnel ausprogrammieren, welcher die Anfragen für einen bestimmten TSAP transparant ins lokale Netz weiterleitet? Was meint ihr?

Zum Vergrößern anklicken....

Das ist quasi das was ich bei Nettoplcsim mache. Nur leite ich die Daten nicht an eine weitere Netzwerkschnittstelle weiter, sondern packe nach RFC1006 die Daten ein und aus, gebe die Nutzdaten an die Step7-interne S7online-Schnittstelle (entsprechend eingepackt) weiter, über die sich auch Plcsim ansprechen lässt.

Nur über den TSAP kannst du das aber nicht festmachen, denn ein HMI ist nur über die IP-Adresse identifizierbar. Als TSAP wird immer der gleiche Wert verwendet. Darum die Variante mit Loopbackadapter und der passenden IP-Adresse, dann muss in TIA auch nichts umgestellt werden. Außer dass TIA sich leider sehr anstellt, wenn die Funktion "erreichbare Teilnehmer" / DCP nicht funktioniert.

Thomas_v2.1 schrieb:

Darum die Variante mit Loopbackadapter und der passenden IP-Adresse, dann muss in TIA auch nichts umgestellt werden. Außer dass TIA sich leider sehr anstellt, wenn die Funktion "erreichbare Teilnehmer" / DCP nicht funktioniert.

Zum Vergrößern anklicken....

DCP ist über NAT so oder so immer ein sch...
Mir war an dieser Stelle nicht klar, dass der Loopback-Adapter lokal am Engineering-PC läuft. Ich werd mir das mal ansehen.....

Danke schon mal für die Tipps.

Ich habe bei einem Test festgestellt, dass schon sehr viel in der Richtung alleine mit Windows Bordmitteln möglich ist. Es folgt eine kleine Anleitung was man damit machen kann, ich glaube das ist schon ganz brauchbar.

Einrichtung eines Port-Proxy zur Umleitung von Daten von einer IP-Adresse / Portnummer auf eine andere IP-Adresse / Portnummer


Ist-Stand
=======
Server: IP-Adresse 192.168.1.11, Serverdienst lauscht auf TCP-Port 8000
Client: IP-Adresse 192.168.1.10

Aufgabenstellung
============
Der Client soll den Serverdienst anstelle von 192.168.1.11:8000 auf 192.168.1.222:7000 erreichen.

Vorgehensweise
============
1. Loopbackadapter nachinstallieren (Beschreibung für Windows 7)
- Systemsteuerung -> Gerätemanager aufrufen
- Menü Aktion -> Legacyhardware hinzufügen
- "Hardware manuell aus einer Liste wählen und installieren" auswählen
- Netzwerkadapter wählen
- Aus der Liste Hersteller "Microsoft" und als Netzwerkadapter "Microsoft Loopbackadapter" auswählen
- Mit "Weiter" bestätigen und installieren

2. Unter den Netzwerkverbindungen dem Loopbackadapter die IP-Adresse 192.168.1.222 zuweisen

3. Eingabeaufforderung mit Administratorrechten öffnen

4. Portproxy einrichten über Eingabe:

5. Die Proxytabelle lässt sich ausgeben über

6. Eine TCP-Verbindung zu 192.168.1.222:7000 wird jetzt auf 192.168.1.11:8000 weitergeleitet und kann benutzt werden.

7. Nach Abschluss des Tests den Portproxy wieder deaktivieren mit:

8. Empfehlenswert ist es den Loopbackadapter anschließend zu deaktivieren