TIA Problem mit verschiedenen IP-Bereichen

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich hab ein Problem mit einer S7-1214C, selbes Problem betrifft aber auch eine S7-1513. Ich würde gerne wissen ob ich das Problem programm-/einstellungstechnisch lösen kann oder ob ich zusätzliche Hardware benötige.

Die Situation...
Ein Verbund aus mehreren CPUs (1214, 1511, 1513) arbeiten in einer Anlage miteinander in einem 162.19.XXX.XXX-Netzwerkbereich. Es gibt auch einige HMIs und mehrere Interfacemodule. Nun soll eine Datenbankanbindung mit MariaSQL realisiert werden. Hierfür gibt es einen super Baustein von Marvin-Mangold auf Github. Die Datenbank befindet sich im IP-Bereich 162.18.XXX.XXX. Es unterscheidet sich also das zweite IP-Segment.
Befindet sich die CPU im exakt gleichen Netz wie die Datenbank funktioniert alles super. Sind CPU und Datenbank in den oben genannten unterschiedlichen Netzen, dann funktioniert die Verbindung nicht.

Folgendes habe ich bereits versucht:
Ich habe die Subnetzmaske der CPU auf 255.254.0.0 geändert, dort sollte eigentlich beide Netze abgedeckt sein, aber es funktioniert trotzdem nicht. Die IT hat mir die Firewall so angepasst, dass ich eigentlich problemlos von einem Bereich in den anderen kommen könnte. Mit dem PG kann ich problemlos alles anpingen. Allerdings muss ich im PG das Gateway auf die IP der Firewall einstellen. In der S7 finde ich keine Gateway-Einstellung oder ist damit "Router" gemeint? Das habe ich noch nie genutzt und weiß auch gar nicht genau was dort passiert. Aber auch wenn ich unter Router die IP der Firewall eingebe, ist keine Verbindung mit der Datenbank möglich.

Nun habe ich gelesen, dass sich das nur mit einem zusätzlichen Kommunikationsmodul, sprich zusätzliche Netzwerkkarte lösen lässt. Ist das tatsächlich so oder gibt es im Ist-Zustand auch noch eine andere Möglichkeit? Oder hat jemand noch eine Idee? Oder hab ich etwas falsch gemacht? Hab ich etwas vergessen zu konfigurieren?
Eine Möglichkeit wäre evtl. noch eine interne Umleitung der Firewall zu der Datenbank-Adresse, dann könnte ich die Firewall als Ziel am Baustein konfigurieren, welche sich ja im gleichen IP-Bereich befindet wie die CPUs.

 

[Oberchefe]

In der S7 musst du die IP der Firewall unter Router eintragen, dann könnte es funktionieren.

 

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

In der S7 musst du die IP der Firewall unter Router eintragen, dann könnte es funktionieren.

Funktioniert leider nicht…
Kann aber möglicherweise auch an der Firewall selbst liegen, dass da irgendeine Einstellung fehlt oder falsch ist.
Mit dem PG komme ich jedenfalls durch.

Darum wollte ich jetzt erstmal nachfragen, bevor ich nach etwas suche, was evtl. mit der S7 gar nicht möglich ist.

 

[SPS-freak1]

Hi,

Ich bin leider im SQL Thema garnicht Zuhause, aber die grundsätzlichen Themen sind ja immer die gleichen.
Um die Firewall zu testen müsstest du doch mit einem Tool wie Herkules prüfen können ob du eine Verbindung aufbauen kannst. Du hast doch sicher einen Port den du ansprechen willst. Heißt du gibst deinem PG die Adresse deiner SPS (SPS bitte dazu abstecken vom Netz) und versucht dann eine Verbindung auf den gewünschten Port aufzubauen. Klappt das so schon nicht, liegt es meist an der Firewall.
Um dann zu prüfen ob alle Ports frei sind, nimmst du AngryIP Scan und prüfst ob die gewünschten Ports bis zur Datenbank erreichbar sind.

Meine Erfahrung ist, das meistens da der Hund begraben ist. Sollte es wieder erwarten dann gehen, dann muss man sich genauer die IP Konfiguration der SPS anschauen.

Grüße

 

[KarlMeier]

Danke für die Tipps!
Also mit dem PG kann ich die Datenbank anpingen. Und das PG, sowie die SPS können aus dem anderen Netz auch angepingt werden. Die grundsätzliche Verbindung über die Firewall scheint also zu funktionieren.
Ob das allerdings für alle Ports zutrifft konnte ich noch nicht testen.

 

[SPS-freak1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja ich würde wirklich versuchen gezielt den Port zu nutzen, den auch sie SQL Verbindung nutzt. Ping geht eigentlich so gut wie immer.
Aber dafür kannst du einfach Herkules nehmen und die gewünschte Verbindung zum gewünschten Port per TCP oder UDP aufbauen.

 

[KarlMeier]

Ja ich würde wirklich versuchen gezielt den Port zu nutzen, den auch sie SQL Verbindung nutzt. Ping geht eigentlich so gut wie immer.
Aber dafür kannst du einfach Herkules nehmen und die gewünschte Verbindung zum gewünschten Port per TCP oder UDP aufbauen.

Meinst du dieses Programm?

Hercules SETUP utility | HW-group.com

www.hw-group.com

 

[SPS-freak1]

Hi,

Ja genau, das nutzen wir dafür immer. Ist Freeware und sehr simpel in der Bedienung. Für grundlegenden Kommunikationen reicht das auch.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ob du ne Verbindung zur Datenbank bekommst, kannst du auch z.B. mit HeidiSQL testen. Ist ganz praktisch und kann div. Datenbanken.

 

[KarlMeier]

Ob du ne Verbindung zur Datenbank bekommst, kannst du auch z.B. mit HeidiSQL testen. Ist ganz praktisch und kann div. Datenbanken.

Wie genau meinst du das? Stehe gerade etwas auf dem Schlauch.

Meinst du ich soll das am PG installieren und schauen ob ich damit aus dem IP-Bereich der CPU durchkomme?

 

[Blockmove]

Wie genau meinst du das? Stehe gerade etwas auf dem Schlauch.
Inwiefern kann ich etwas bzgl. meiner Problematik mit HeidiSQL testen?

• Du steckst das Netzwerkkabel an der S7 aus
• Nun vergibst du deinem Notebook die gleichen Netzwerkeinstellungen wie der Steuerung und hängst es ans Netzwerk
• Mit Ping und Hercules kannst du die grundlegende Netzwerkverbindung zum Datenbankserver testen
• Mit HeidiSQL kannst du die Anmeldung an der Datenbank testen und auch Daten testweise schreiben

Wenn du durch die Firewall kommst, heißt das noch lange nicht, dass die Anmeldung an MariaDB funktioniert. Die Datenbank hat da auch zig Konfigurationsmöglichkeiten. Da ist dann ein Tool wie HeidiSQL ganz nützlich.

 

[Pipboy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe die Subnetzmaske der CPU auf 255.254.0.0 geändert

Das muss 255.255.0.0 sein und der Router muss eingetragen sein.
Mit 254 hat die CPU keinen Grund ein Gateway anzusprechen.

 

[KarlMeier]

Das muss 255.255.0.0 sein und der Router muss eingetragen sein.
Mit 254 hat die CPU keinen Grund ein Gateway anzusprechen.

So hatte ich es als erstes probiert.
Maske auf 255.255.240.0 und unter Router die IP der Firewall.
Hat nicht funktioniert, dann hab ich die Maske geändert und es hat auch nicht funktioniert.

Ich vermute, dass das Problem bei der Firewall liegt.

 

[Blockmove]

Das muss 255.255.0.0 sein und der Router muss eingetragen sein.
Mit 254 hat die CPU keinen Grund ein Gateway anzusprechen.

Die SPS hängt wohl in einem Netz 162.19.x.x
Die Datenbank hängt wohl in einem Netz 162.18.x.x

Daher sollte eigentlich die Subnetzmaske 255.254.0.0 schon passen um auf beide Netzwerke zugreifen zu können.
Gateway braucht man da eigentlich keines.

Was mich aber wundert:
Sowohl 162.18.x.x als auch 162.19.x.x sind eigentlich öffentliche IP-Adressen und haben normalerweise in einem Firmennetz nix verloren.

@KarlMeier
Sicher dass die IP-Adressen richtig sind?
Die privaten IP-Adressen für den Einsatz in nem Firmennetz wären z.B. 172.16.0.0 – 172.31.255.255.
Frag mal die ITler ob's nen Grund für die - aus meiner Sicht - ungewöhnliche Konfiguration gibt.

 

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die SPS hängt wohl in einem Netz 162.19.x.x
Die Datenbank hängt wohl in einem Netz 162.18.x.x

Daher sollte eigentlich die Subnetzmaske 255.254.0.0 schon passen um auf beide Netzwerke zugreifen zu können.
Gateway braucht man da eigentlich keines.

Was mich aber wundert:
Sowohl 162.18.x.x als auch 162.19.x.x sind eigentlich öffentliche IP-Adressen und haben normalerweise in einem Firmennetz nix verloren.

@KarlMeier
Sicher dass die IP-Adressen richtig sind?
Die privaten IP-Adressen für den Einsatz in nem Firmennetz wären z.B. 172.16.0.0 – 172.31.255.255.
Frag mal die ITler ob's nen Grund für die - aus meiner Sicht - ungewöhnliche Konfiguration gibt.

Die IP-Adressen sind nicht die Tatsächlichen… Aber die Bereichs-Unterschiede sind gleich.

 

[PN/DP]

Wenn Ping funktioniert, dann ist das Thema Subnetzmaske und Gateway/Router bereits funktionierend gelöst und nicht Ursache, wenn die Datenbank-Verbindung nicht funktioniert.

 

[SPS-freak1]

Wenn Ping funktioniert, dann ist das Thema Subnetzmaske und Gateway/Router bereits funktionierend gelöst und nicht Ursache, wenn die Datenbank-Verbindung nicht funktioniert.

Was ja dann nur die Physik klärt, nicht aber auch auch die richtigen Ports frei sind.

 

[mgl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn der Ping funktioniert, liegt der Fehler irgendwo am Server.
- Prüfe da bitte die Server Firewall ob diese Anfragen am Port des SQL-Servers entgegennimmt und nicht abweist
- Prüfe die Port-Einstellungen ob diese passen bei Server / Client richtig eingestellt sind
- Prüfe ob der Server bzw. der SQL-Server läuft
- Prüfe die Server Einstellungen ob sie auch Anfragen aus anderen Netzen zulassen

-----


Welchen Status Code liefert der Baustein von Marvin Mangold?

 

[Pipboy]

Daher sollte eigentlich die Subnetzmaske 255.254.0.0 schon passen

Da ist doch scheinbar eine Firewall dazwischen die routen soll.
Das bringt nichts auf einer Seite irgendwas an der Maske zu drehen.

 

[mgl]

Da ist doch scheinbar eine Firewall dazwischen die routen soll.
Das bringt nichts auf einer Seite irgendwas an der Maske zu drehen.

Ich habe den Text nochmal genauer gelesen und jetzt auch verstanden. Der Ping funktioniert also nur dadurch am PG weil da das Gateway eingetragen ist. Dementsprechend muss die Gateway-Adresse bei der Router-Einstellung auch in der SPS eingetragen werden. Die Subnetzmaske kann dann entsprechend der Firewall und SPS-Adresse angepasst werden. Das Routing in das richtige Netz übernimmt dann die Firewall.

Die IT muss allerdings auch dafür sorgen, dass die Pakete nicht nur vom PG sondern auch von der SPS auch an den SQL-Server von der Firewall durchgereicht werden.

Angenommen:
Firewall IP-Adresse: 162.19.1.1
SPS IP-Adresse: 162.19.1.10

Dann trägst du die IP-Adresse der Firewall, also 162.19.1.1 in deiner SPS als Route ein. Da Firewall und SPS im Subnetz 162.19.1.XXX hängen, würde dann die Netzmaske 255.255.255.0 passen. Wenn nun die SPS sich mit einer Adresse außerhalb der Netzwerk-Maske verbinden möchte z.B. 162.18.XXX.XXX, dann leitet sie das Paket an den Router / die Firewall und die Firewall kümmert sich um die Weiterleitung zum richtigen Ziel.

Achtung:
Eine Netzwerkmaske von 255.254.0.0 in der SPS ist dann falsch, da die SPS dann den Adressbereich 162.18.XXX.XXX kennt und ohne Router erreichbar ist. Dementsprechend würde die SPS direkt versuchen das Paket an den SQL Server zu schicken anstatt den Router / Gateway/ die Firewall zu verwenden.

-----

Im Prinzip kann man das mit der Post und dem Verschicken eines Briefs vergleichen. Ist die Postleitzahl identisch mit deiner Postleitzahl (oder dem Postleitzahlenbereich definiert durch die Netzmaske), dann versuchst du den Brief selber zu zu stellen und die Kosten für eine Briefmarke zu sparen und bringst den Brief nicht zum Briefkasten. Ist die Postleitzahl nicht in deinem Bereich, gehst du gleich zur Post (der Router / die Firewall / das Gateway) und die übernimmt den Transport zur richtigen Adresse.